dalek-cryptography / x25519-dalek

X25519 elliptic curve Diffie-Hellman key exchange in pure-Rust, using curve25519-dalek.
BSD 3-Clause "New" or "Revised" License
328 stars 133 forks source link

'Secret' trait for unified DH #58

Closed super-horst closed 4 years ago

super-horst commented 4 years ago

Introduced a Secret trait to encapsulate Diffie-Hellman functionality of both StaticSecret and EphemeralSecret.

Any overlaying logic would not care if it calculates DH on a static or ephemeral secret. This would enable to build generic interfaces using the trait as a DH mediator.

For example X3DH uses static and ephemeral keys during it's agreement calculation: https://www.signal.org/docs/specifications/x3dh/#sending-the-initial-message

hdevalence commented 4 years ago

I wrote a comment about a similar issue here that might be relevant: https://github.com/dalek-cryptography/x25519-dalek/issues/56#issuecomment-610648689

Hmm, an EphemeralSecret is just a StaticSecret where the compiler enforces at compile-time that the key is only used once. If you don't want to have two code paths, this means that you're OK with relaxing this compile-time verification. So it seems like an alternate solution would be to do

type SecretKey = x25519_dalek::StaticSecret;

and use that SecretKey type for both static and ephemeral keys. Would that work?

super-horst commented 4 years ago

Hmm, an EphemeralSecret is just a StaticSecret where the compiler enforces at compile-time that the key is only used once.

That is precisely where I stumbled too. IMHO it makes no sense to enforce that the EphemeralSecret is only used once. While it makes sure that no one does anything stupid, it also removes alot of flexibility.

So it seems like an alternate solution would be to do

type SecretKey = x25519_dalek::StaticSecret;

and use that SecretKey type for both static and ephemeral keys. Would that work?

Dunno about this type definition though, I'm not that deep into rust to give a qualified opinion here.