[noise] new branch: psk2

[Jason A. Donenfeld]

On Sat, Nov 14, 2015 at 8:16 AM, Trevor Perrin <trevp at trevp.net> wrote:
>
> This makes it crucial for each party's first message to begin with
> "e", so I reordered "s, e" -> "e, s" in a couple patterns, and
> explained this in Section 6.1 "Pattern validity".
>
>  * A more subtle "invalid" pattern would be one that sent encrypted
> data without first doing a DH with the sender's ephemeral against any
> public keys the remote party has sent.  Example:
>
>  -> e, s
>  <- e, dhee, dhss

Are there any _useful_ patterns where these patterns would occur? Or
is it possible to work around this in pretty much all scenarios? It
seems like the current list of Noise handshakes covers mostly
everything. I think a comment of mine on here triggered the advent of
the *K variety, but beyond this, I can't think of other useful
families.

If it is, in fact, not excluding anything useful, I don't think this
is a big deal.

But, I would suggest in screech (and other implementations too), you
implement this validation in the handshake constructor, so if folks
are inclined to start tinkering, they'll have to ask themselves "hmm,
what does this code do here?" and then explicitly choose to
disable/remove it.


> This could be insecure if the DH function allows a public value with
> small order, e.g. with the traditional Curve25519 DH function an
> attacker could send a value which forces the output to zero.  If a
> bogus initiator repeatedly sends such an "e", then the responder's
> dhee randomization will fail, and there will be key reuse based on the
> dhss key.
>
> The IETF is contemplating ECDH functions that perform an explicit
> check of the output against zero, but that introduces other issues
> (more complex, not all existing implementations do this, not all DH
> functions necessarily do this, the check should be const-time, need to
> research point validation patents, etc).

That's an excellent point. Nearly every crypto library contains a
constant time memcmp. It doesn't seem like it's that much of a burden
to require aborting on deterministic output. By the way, I've got some
nice test vectors for Curve25519 for non-canonical points as well as
these zero points. Here's my list of test vectors I'm using in my unit
tests [2]. They might be useful elsewhere too. The zero ones come from
djb's ECDH page [1] where he lists all the numbers on the curve that
should yield this. "How do I validate Curve25519 public keys?"

I'd support aborting. But perhaps that complicates things with other
curves? I don't know.


> The upside is efficiency
> and simplicity when using correct patterns, which feels more
> important.

True, that's compelling.



[1] http://cr.yp.to/ecdh.html
[2] http://0bin.net/paste/IQGchMJBnnQhqdSA#2-VZajjSURpg/gDgU7f3TUR/UspNWLIjjerIhDa0t0d