[noise] Post-Quantum Noise with New Hope

[Trevor Perrin]

On Sat, Jul 16, 2016 at 12:55 AM, Rhys Weatherley <rhys.weatherley at gmail.com
> wrote:

>
> I realised this morning that old school modexp-DH can be either "balanced"
> or "unbalanced".  If the group prime and generator are agreed to ahead of
> time by Alice and Bob, then the system is "balanced".  But if the
> parameters are dynamic and sent by Alice in the handshake, then it becomes
> "unbalanced".  I believe that TLS uses modexp-DH this way for forward
> secrecy.
>

Validating "regular DH" parameters dynamically is generally a bad idea, so
people mostly use fixed groups for DH.



> Great minds.  This is actually similar to my original thoughts on using
> New Hope.  Initially, I was thinking of special "qa" and "qb" tokens but
> once I found a way to implement "qa = e", and "qb = e, dhee" I set it aside
> in favour of making the least number of changes to the structure of Noise.
>

Right, this is just an adaptation of your idea.

More options to consider:

 * Currently, we have "e" and "s" tokens which represent handshake data,
and "dh**" tokens which perform a crypto op and call MixKey().  It might be
good to keep that distinction, instead of having an "ekem2" token that does
both, for clarity and because it allows deferring the crypto op, e.g. if
you want to exchange values but defer computation for DoS resistance.

Is it reasonable to have 2 ekem exchanges in a handshake (one started by
the initiator, one started by the responder?  If not, the crypto op could
just be named "ekem".  If so, it needs to distinguish which computation
it's referring to ("ekem21" vs "ekem12", for example?).  Hmm.

 * Maybe we should clarify which tokens are data and which are computations
in the notation, e.g. capitalization?


Noise_XX(s, rs):                 Noise_XXekem(s, rs):
  -> e                             -> e, ekem1, s
  <- e, DHEE, s, DHSE              <- e, ekem2, DHEE, EKEM21, s, DHSE
  -> s, DHSE                       -> s, DHSE


 * Schemes like NTRU Prime allow reusable keys.  We might be able to extend
our naming convention for that with "skem".  I.e., you could do mutual
post-quantum auth as well as forward-secrecy with something like:

Noise_XXskem(s, rs):
  -> e, ekem1
  <- e, ekem2, DHEE, EKEM21, s, DHSE, skem1
  -> skem2, SKEM21, s, DHSE, skem1,
  <- skem2, SKEM21

NTRU / NTRU Prime could be used for skem or ekem, but NewHope could only be
used with ekem?

Ideally cryptographers would invent DH-equivalent PQ schemes, and we could
eliminate the "kem" stuff entirely, but for now maybe this would work?


Trevor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20160716/86d0ae19/attachment.html>