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

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...

Trac:
Username: vynX

changed milestone to %Tor: unspecified in legacy/trac

added component::core tor/tor in Legacy / Trac isaremoved in Legacy / Trac milestone::Tor: unspecified in Legacy / Trac points::2 in Legacy / Trac priority::low in Legacy / Trac reporter::vynX in Legacy / Trac resolution::worksforme in Legacy / Trac severity::minor in Legacy / Trac status::closed in Legacy / Trac tor-03-unspecified-201612 in Legacy / Trac type::defect in Legacy / Trac unsolved in Legacy / Trac version::tor unspecified in Legacy / Trac labels

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?

Trac:
Points: N/A to 2
Keywords: N/A deleted, unsolved added
Status: new to needs_information

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.

Trac:
Username: vynX

Trac:
Keywords: N/A deleted, isaremoved added
Milestone: Tor: 0.2.9.x-final to Tor: 0.2.???

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.

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....

Milestone renamed

Trac:
Milestone: Tor: 0.2.??? to Tor: 0.3.???

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

Trac:
Milestone: Tor: 0.3.??? to Tor: unspecified
Keywords: N/A deleted, tor-03-unspecified-201612 added

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

Trac:
Status: needs_information to closed
Resolution: N/A to worksforme

closed

changed time estimate to 16h

moved from legacy/trac#19419 (moved)

added Bug label and removed 1 deleted label

added Needs Insight label and removed 1 deleted label