Opened 3 years ago

Closed 2 years ago

#23254 closed defect (not a bug)

BridgeAuth offline key mode seems broken

Reported by: isis Owned by:
Priority: Medium Milestone: Tor: 0.3.3.x-final
Component: Core Tor/Tor Version: Tor:
Severity: Normal Keywords: tor-dirauth, tor-bridgeauth, tor-ed25519-keys, tor-offline-keys
Cc: Actual Points:
Parent ID: Points: 3
Reviewer: Sponsor: SponsorM-can


Yesterday I renewed the signing keys for the Bifröst (see #23253) but the machine still couldn't join the network. This is my best understanding of the problem, which I repeatedly witnessed trying to fix the machine:

19:29                 isis+ | so it seems the bridgeauth was still down, even though i "fixed" the expired signing keys yesterday
19:30                 isis+ | which apparently it doesn't even need signing keys, so why i wasted an afternoon fixing it when i'm supposed to be preparing for a talk is a bit annoying
19:30                 isis+ | but nobody runs this code so hey, what should i expect
19:31                 isis+ | this time it was not in the consensus because the other dirauths didn't recognise it because it "had new keys"
19:33                 isis+ | which, upon inspection, seemed to mean that, even though i have always specified "OfflineKeys 1", the bridgeauth somehow generated a ed25519_master_id_secret_key (??) however it kept the old 
                              ed25519_master_id_public_key, and then it used this new ed25519_master_id_secret_key to sign the ed25519_signing_cert (which had already been signed by the real ed25519_master_id_secret_key which 
                              is kept…
19:33                 isis+ | …offline)
19:33                 isis+ | this resulted in a complete clusterfuck of mismatched and mis-signed keys
19:35                 isis+ | and even though the ed25519_signing_cert was already generated offline (afaict correctly) it was the bridgeauth's insistence on making a new ed25519_master_id_secret_key that was causing the 
19:37                 isis+ | the only way i could think of, without fixing all these probable bugs, to fix this, was to go back to the offline machine and use the correct ed25519_master_id_secret_key to regenerate new 
                              keypairs with "OfflineKeys 0" and no signing_cert expiration, and then transfer all the keys to lapsedpacifist
19:37                 isis+ | so the bridgeauth no longer has "offline keys" but i guess it never really did, and it wouldn't even be useful even if it could

Sorry, I'll clean up the IRC paste mess into a proper description later, I seriously have to go prepare my slides for my talk. :(

Child Tickets

Change History (2)

comment:1 Changed 2 years ago by arma

Maybe we close this one for the same reason we closed #23253?

I think Isis was confusing the relay identity ed key with the authority signing key with the authority identity key -- there are sure a lot of keys to keep track of, and when your Tor is yelling at you about one of them, it's not always easy to tell which one it's talking about.

comment:2 Changed 2 years ago by nickm

Resolution: not a bug
Status: newclosed

Right; I think this was key confusion. See #23253, and please reopen if we are misunderstanding.

Note: See TracTickets for help on using tickets.