[noise] Extensions for forward secrecy and New Hope

[Rhys Weatherley]

On Sun, Aug 28, 2016 at 5:27 PM, Trevor Perrin <trevp at trevp.net> wrote:

> We previously discussed whether to treat a DH+PQ scheme as:
>  (A) A hybrid DH function that redefines the "e" token to send a hybrid
> DH+PQ key, and redefines "dhee" to call MixKey() on the combined DH+PQ
> output.
>  (B) Separate functions triggered by their own tokens ("f" and "dhff", for
> example).
>
> Your current spec is in-between:  It calls MixHash() and MixKey()
> separately for the PQ values, instead of concatenating them with the DH
> values, but the sequence of calls is determined by redefining the rules for
> "e" and "dhee", instead of by separate tokens.
>

I did explore (A) and started to code it up in a trial branch.  The
"Discussion" section of the proposed extension talks about why it didn't
really work.  In summary, the virtual DH function becomes odd: NewHope only
works on dhee, but not dhes, dhse, or dhss - the virtual DH function needs
to be split apart for some tokens but not others.  The trial implementation
got very messy very fast.

It makes sense for SymmetricState to process the PQ and DH values
> independently, particularly for MixKey():  We've designed the KDF to
> produce secure output if any MixKey() input is secure, and we want to
> ensure the PQ scheme can't worsen the DH.
>

Agreed.

>
> But if we're going this route, I wonder if we should go all the way to (B):
> [...snip...]
> (Assuming "f" is encrypted we have to move it after the "dhee", as shown
> here, to not violate pattern validity.  Your spec doesn't encrypt "f", in
> which case the transformation is simpler - "e, f, dhee, dhff, ...").
>
>  * The pattern name continues to determine the SymmetricState calls, as
> currently.
>
>  * This avoids redefining the existing "e" and "dhee" tokens.
>
>  * The pattern notation makes the the exact sequence of steps more clear.
>

I'm not against this idea.  Using tokens gives more flexibility as to where
the extra fs operations occur.  In New Hope, Alice is the one that can pre
compute parameters.  Which means that it can make more sense if the
responder sends the first f token instead of the initiator; e.g.

Noise_XXreversehfs
  -> e
  <- e, dhee, f, s, dhse
  -> f, dhff, s, dhse

That type of pattern isn't possible with a straight doubling of e and
dhee.  But would be possible with a token-based approach.

However, I was trying to keep the system orthogonal in that adding a new
feature to Noise applies equally to existing patterns.  New cipher and hash
algorithms, features like PSK's and SSK's, etc, operate independently of
the pattern.

My goal was "existing behaviour plus this one new thing" -
Noise_XX_25519+NewHope is still essentially XX in its structure.  Adding
new explicitly named patterns like XXhfs kind of breaks this - now we have
patterns that only work with specific combinations of non-pattern
parameters.  Maybe it is unavoidable - NewHope already only works with
interactive patterns and not one-way patterns.

If we defined a "default hfs transformation", then existing patterns could
be accommodated.  For instance, the presence of a forward secrecy algorithm
name might implicitly apply the default transformation of "e -> e, f", "e,
dhee -> e, dhee, f, dhff" if the pattern doesn't already involve f.  If
that isn't what the user requires then they can define a new pattern.


> Naming and separator chars
>

I have no preference one way or the other on this.  All of the proposals so
far are awkward in different ways.  Whatever consensus decides.


> Encrypting the forward-secrecy values
> [...snip...]
> I'm not sure I've thought this through, but maybe this argues for
> encrypting the PQ public values?
>

Sure.

Although, as I outlined in the thread "Oddity with IKnoidh, IXfallback, and
PSK's", fallback patterns can get odd if values needed to perform the
fallback are encrypted too early in the handshake.  But fallback scenarios
already define specific pairs of patterns, so a PQ Noise Pipes need only
choose a combination that works even if other combinations don't.

Cheers,

Rhys.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20160829/0403f2b2/attachment.html>