[noise] Extensions for forward secrecy and New Hope

[Trevor Perrin]

On Mon, Aug 29, 2016 at 1:55 AM, Rhys Weatherley <rhys.weatherley at gmail.com>
wrote:

> 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).
>>
> [...]

> 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.
>

Yeah, that made sense to me.


But if we're going this route, I wonder if we should go all the way to (B):
>>
> [...]

> 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.
>


That's interesting, though of course that loses PQFS for the server's
identity.  But allowing people to choose these trade-offs does seem like a
good argument for the flexibility of tokens.

Another argument is that we'll probably have more ways of transforming
patterns in the future, and we'd like these to be composable.  If
transformations are expressed as operations on patterns, then it's easy to
try composing them.  If they're expressed by redefining the text for
existing tokens, it's harder to visualize the final outcome, and we have to
worry about clashing text changes.

For example, here's some transformations applied to XX ("hfs", "sig", and
"ss" are speculative, but they should be easy to figure out).

It's fairly easy to read the final protocol from the pattern, I think it
would be harder if the transformations were rewriting the spec text without
changing the pattern:


Noise_XX(s, rs):
  -> e
  <- e, dhee, s, dhse
  -> s, dhse

Noise_XXsig(s, rs):
  -> e
  <- e, dhee, s, sig
  -> s, sig

Noise_XXsig+hfs(s, rs):
  -> e, f
  <- e, f, dhee, dhff, s, sig
  -> s, sig

Noise_XXsig+hfs+noidh(s, rs):
  -> e, f
  <- e, f, s, dhee, dhff, sig
  -> s, sig

Noise_XXsig+hfs+noidh+ss(s, rs):
  -> e, f
  <- e, f, s, dhee, dhff, sig
  -> s, dhss, sig



> 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.
>


PSKs are orthogonal, and violate what I just said about transforms (since
they change the processing rules, and don't modify the pattern).  If we
were designing PSKs now, we might consider expressing "psk" as a
transformation.  However that's not a backwards-compatible change (since
"Noise_XXpsk" is a different name from "NoisePSK_XX"), and I don't think we
should change core features like this without a much better reason.

SSKs were maybe added too quickly.  They were intended to be a
cheap-and-easy way to add PQFS, but it seems like we're working out a
better approach.  I don't think anyone's using them, and I don't like
cluttering the spec with unused features.

Perhaps we should remove SSK?



> 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.
>

But it seems reasonable that some patterns might impose conditions on the
non-pattern parameters - a "hybrid forward secrecy" pattern requires
specifying an additional public-key algorithm for hybrid forward secrecy,
that seems OK?


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.
>

I think it's better to have transformations be an explicit part of the
pattern name.  Also, listing multiple public-key algorithms might be used
for other things besides an "hfs" transformation.

For example, in addition to a "sig" transformation that uses the same
public-key type for DH and signatures, you could imagine a "sig2" that
allows static public keys that are different from DH keys.  For example,
"XXsig2_25519+RSA3072" might mean use 25519 for ephemeral DH, but use
static RSA keys for signing.  "sig3" could allow different static public
key types for initiator and responder.

So it seems better to explicitly indicate an "hfs" transformation, rather
than infer it from the presence of multiple public-key algos.



>
>
>> 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.
>

I guess "+" still seems as good as anything, to me.



> 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.
>

Good point, I'll need to think about that more, particularly in combination
with PSK.

If you were able to try a writeup of the transformation/token-based
approach, that would be super-helpful in comparing approaches, and seeing
whether this pans out.

Trevor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20160829/984d16ef/attachment.html>