[noise] Extensions for forward secrecy and New Hope

Trevor Perrin trevp at trevp.net
Tue Aug 30 23:09:49 PDT 2016

On Tue, Aug 30, 2016 at 2:23 AM, Rhys Weatherley <rhys.weatherley at gmail.com>

> Here's a quick pass:
> https://github.com/rweather/noise_spec/blob/forward_
> secrecy/extensions/ext_hybrid_forward_secrecy.md

I like it.  I think this approach is better than [1].

What about simplifying the transformation to just:
 - "e" -> "e, f"
 - "dhee" -> "dhee, dhff"

You're making it more complicated by moving the dhee before the f so that f
gets encrypted:
 - "e, dhee" -> "e, dhee, f, dhff"
 - "e" -> "e, f"

That works on all current patterns but isn't guaranteed to work.  For
example it would fail on:
 -> e
 <- e
 -> dhee [...]

Encrypting the second "f" isn't particularly important.  Using patterns
allows us to do it, but I'm not sure it needs to be the default.

Other comments, mostly editorial:

 * extra -> hybrid in a few places
 * forward secrecy key -> forward secrecy public key
 * Sets **f** = GENERATE_KEYPAIR_F()
 * I would move the rationale about encrypting "f" tokens to an end
rationale section, mimicking the spec, and mention indistinguishability and
protection from tampering.
 * 4.4 similarly seems more like rationale, and perhaps unnecessary.
 * Maybe spell out the pre-message options:
 "e, f"
 "e, f, s"
(unless we wanted to be stricter about "e" and f" coupled together?

 * Second pattern validity bullet appears redundant
 * Final recommendations seems unnecessary.  It's not actually all that
important to protect the "f" with encryption.
 * 5.3 seems like it's going to need more thought.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20160830/44ef5e6a/attachment.html>

More information about the Noise mailing list