[noise] Extension spec: KEM-based Hybrid Forward Secrecy
Trevor Perrin
trevp at trevp.net
Sun Nov 18 01:14:15 PST 2018
I started a spec for Hybrid Forward Secrecy with KEMs (i.e. using
algorithms like NewHope etc to add resistance against retroactive
decryption by a quantum computer).
https://github.com/noiseprotocol/noise_hfs_spec/blob/master/output/noise_hfs.pdf
https://github.com/noiseprotocol/noise_hfs_spec
This is based on Rhys's old spec, with a few changes:
* Using "e1" and "ekem1" for token names, since I think these names
are likely to be consistent with a future "multi-algorithm" naming
scheme that can mix KEMs, DHs, and signatures in a single handshake.
(If it doesn't turn out that way that's OK too, since token names are
purely a spec artifact).
* Earlier we always put the KEM public key directly after the first
DH ephemeral. I moved it after the next DH in the same message, so
that in (NK, XK, IK) the KEM public key is sent after "es" so gets
encrypted:
XKhfs:
<- s
...
-> e, es, e1
<- e, ee, ekem1
-> s, se
There's an argument to be made that we shouldn't be encrypting KEM
ciphertext and public keys at all, since we don't encrypt DH ephemeral
public keys.
However the ephemeral DHs are a special case, since we rely on them to
randomize the encryption. Aside from that, Noise tries to maximally
encrypt things, which helps obscure which protocol is executing. And
encryption might have some small security benefits in forcing a
cryptanalytic attacker to break DH before he can even start attacking
the KEM.
Trevor
More information about the Noise
mailing list