tor-llcrypto 0.7.0 ed25519 apis seemingly incompatible with version 0.4.0
tldr; how do I round-trip the ED25519-V3 keyblob format used in c-tor using the latest tor-llcrypto
crate?
The title's not exactly accurate I suspect, but let me lay out the problem I"m having.
I'm attempting to upgrade the tor-llcrypto
crate in gosling
from version 0.4.0 to 0.7.0 in preparation for implementing an arti-client
based backend. I have various cryptographic primitives in my tor-interface
crate needed for working with c-tor and the gosling handshake which can be found here: https://docs.rs/tor-interface/0.2.1/tor_interface/tor_crypto/index.html
So the problem I am currently running into is updating my Ed25519Privateykey
type which used to simply wrap an pk::ed25519::ExpandedSecretKey
. Of course this type is now unavailable from the underlying ed25519_dalek
crate w/o the hazmat feature which seemss fine, I should be able to update my APIs to reflect this with little issue.
The problem I need to solve is round-tripping an ExpandedSecretKey to and from the ED25519-V3:blahblahblah... format used in c-tor for the ADD_ONION
command.
From what I can tell, it seems like some of the bit-twiddling found here ( https://docs.rs/ed25519-dalek/1.0.1/src/ed25519_dalek/secret.rs.html#265 ) in older versions no longer happens or is no longer necessary somehow?
From what I can tell, the correct pipeline for me ought to now be:
- ED25519-V3 keyblob decoded to
- 64 byte array (lower 32 bytes the 'Scalar', upper 32 bytes the nonce/hash-prefix) to
- ExpandedKeyPair::from_secret_key_bytes()
and then the reverse to go the other way. The reason why I'm here is that my initial round-trip attempt has failed (existing test vectors no worky) and I've been staring at and comparing different versions of the ed25519 crates and my eyes are bleeding.
My existing code for this process can be found here: https://docs.rs/tor-interface/0.2.1/src/tor_interface/tor_crypto.rs.html#169
The main big red flag I'm seeing is that this code snippet with all the bit-twiddling on thje scalar does not seem to exist anymore anywhere I can find in the upstream ed25519 crates where I would have expected them: #1021 (comment 2936940)
Namely, it seems the newer implementation just ensures the Scalar's signbit is 0 without un-setting the lowest 3 bits to 0 (though it seems Scalar::from_bits() has always unset the sigbit so I don't understand why it was being set there). But maybe I just need to dig deeper
I'm sure I can get something working if I bash at this for long enough, but I wanted to check in and make sure I'm not missing something obvious or to see if I just need to keep the legacy crate around for the c-tor backend and drop the keyblob conversion codes for the arti-based backends.
In the end I don't know how ed25519 is meant to work beyond the user-facing hand-wavey public/private key cryptogrphay aspects of it so I could use some help here.