[noise] Post-Quantum Noise with New Hope

[Rhys Weatherley]

On Sun, Jul 17, 2016 at 9:56 PM, Trevor Perrin <trevp at trevp.net> wrote:

>
> I think at that point it might be simpler to run two Noise_XX() handshakes
>> in parallel and mix them with SSK's.  Or just switch completely to a
>> post-quantum "XX" and drop the classical handshake.
>>
>
> I'm not sure how much confidence we have in current PQ schemes resisting
> *classical* cryptanalysis, must less PQ cryptanalysis.  So I'm opposed to
> deploying current PQ encryption schemes by themselves.
>

Fair enough.

>
>
> How about we apply some KISS?  The odd one out is ekem: there is a need
>> for adding another ephemeral-only exchange for obtaining extra forward
>> secrecy from a different algorithm.
>>
>> Noise_XXf(s, rs):
>>     -> e, f
>>     <- e, f, dhee, dhff, s, dhse
>>     -> s, dhse
>>
>> Where "f" stands for "forward secrecy ephemeral".
>>
>
> That's not bad, though if we're pushing for simple patterns, just
> "doubling" the DH functions deserves a closer look.  I.e., for NewHope:
>
> "e" = sends an unencrypted DH value, then sends a (potentially encrypted)
> NewHope value.  The first occurrence of "e" sends NewHope message #1, the
> next "e" by the other party sends NewHope message #2.
>
> "dhee" = calls MixKey() on the DH output, then calls MixKey() on the
> NewHope output.
>

Looks fine to me.  With a note that "potentially encrypted" is only
possible if there is a PSK, because otherwise encryption doesn't start
until the "dhee" token.  However, encrypting the New Hope ephemeral is
probably not worth the effort as you said further down.

There are also issues in fallback patterns with encrypting public keys with
PSK's too early in the handshake as I found with IKnoidh / IXfallback.
That problem may also happen with IK / XXfallback if the PQ ephemeral
public key was encrypted.  We might end up in a situation where you can use
Noise Pipes with PQ or PSK but not both.

So for PQ auth, the doubling approach loses some real flexibility in the
> auth case, since it constrains us to using "regular" auth that complies
> with whatever limits the PQ scheme has.
>
> OTOH, PQ forward-secrecy is the more immediate goal, so maybe it's better
> to use doubling to just keep things simple for now, and hope that more
> flexible PQ schemes are invented if/when PQ auth becomes important?
>

Agreed.  Cross that road when we come to it.

Cheers,

Rhys.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20160718/618cad02/attachment.html>