Opened 15 months ago

Closed 6 months ago

#19419 closed defect (worksforme)

Tor generates different onion "hostname" out of same private key?

Reported by: vynX Owned by:
Priority: Low Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor: unspecified
Severity: Minor Keywords: unsolved, isaremoved, tor-03-unspecified-201612
Cc: Actual Points:
Parent ID: Points: 2
Reviewer: Sponsor:

Description

When I copy some older private_key files I generated with Shallot time ago to a new tor process, then give it a kill -1, it parses the private_key and produces a different hostname to match it. It's odd because the private key is the one that should have the nice name, instead it now gets an ugly new one. Any guess on what I could have done wrong? Apparently nobody else ran into this problem...

Child Tickets

Change History (8)

comment:1 Changed 15 months ago by nickm

Keywords: unsolved added
Points: 2
Status: newneeds_information

Do you get the same result if you copy _all_ the files from the old process?

Do you get the same result if you restart instead of sending a HUP signal?

comment:2 Changed 15 months ago by vynX

Stopping tor, copying the onion directory in place (the two files), then restarting tor... same effect. What could cause the same key file to produce a different hash? Or is it impossible and thus the mistake somewhere in my file handling...?

What do you mean by _all_ the files? I don't have the state of last year's tor. In fact this is a shallot key I hadn't previously used in deployment. I just generated it a year earlier. Can shallot produce bogus key pairs? I tried two and they both receive this treatment.

Last edited 15 months ago by vynX (previous) (diff)

comment:3 Changed 14 months ago by isabela

Keywords: isaremoved added
Milestone: Tor: 0.2.9.x-finalTor: 0.2.???

comment:4 Changed 13 months ago by nickm

Here is what I just tried.

1: I started Tor with HiddenserviceDir abc.

./src/or/tor -hiddenservicedir /tmp/abc/ -hiddenserviceport 80

2: Then I stopped Tor.

3: Then I copied the abc directory to make a new def directory.

4: Then I removed the hostname from the def directory.

5: Then I started tor with def:

./src/or/tor -hiddenservicedir /tmp/def/ -hiddenserviceport 80

I got the same hostname in def/hostname as I saw in abc/hostname.

So I wasn't able to reproduce this bug. What we're going to need to figure this out is step-by-step instructions to try to reproduce the problem you're seeing.

comment:5 Changed 13 months ago by yawning

Err. Unless I'm misreading this, the old private key never was actually used to tor prior to producing the wrong result. The bug seems to be that the host name given by tor for a given private key doesn't match the expected one from Shallot.

I don't think this is reproducible without the modulus and public exponent (the public key) in question, and it's not immediately clear to me how that sort of thing fails....

comment:6 Changed 10 months ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:7 Changed 9 months ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:8 Changed 6 months ago by nickm

Resolution: worksforme
Status: needs_informationclosed

Closing as "worksforme", but please reopen if you can come up with any way to reproduce this.

Note: See TracTickets for help on using tickets.