Closed super-horst closed 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 aStaticSecret
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 dotype SecretKey = x25519_dalek::StaticSecret;
and use that
SecretKey
type for both static and ephemeral keys. Would that work?
Hmm, an
EphemeralSecret
is just aStaticSecret
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.
Introduced a
Secret
trait to encapsulate Diffie-Hellman functionality of bothStaticSecret
andEphemeralSecret
.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