Opened 4 years ago

Closed 3 years 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:


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 4 years 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 4 years 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 4 years ago by vynX (previous) (diff)

comment:3 Changed 3 years ago by isabela

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

comment:4 Changed 3 years 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 3 years 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 3 years ago by teor

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

Milestone renamed

comment:7 Changed 3 years 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 3 years 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.