[noise] new branch: psk2

[Jason A. Donenfeld]

On Sat, Nov 14, 2015 at 11:08 PM, Trevor Perrin <trevp at trevp.net> wrote:
> Note that simply replaying the initiator's first message defeats this
> "protection".

I had thought about this too, but I had in mind the use case where
attackers just start firing bogus packets at ports all across the
internet, DDoS style. You're right though that it's perhaps a bit
silly.

>
> Also, you're probably worrying too much about computational DoS based
> on a single ECDH.  Modern server-class CPUs can do ~20K variable-base
> 25519 ops per second per core.  If you optimize for the responder's
> fixed public key, you can increase that ~3x.

I didn't know this, okay, great. curve25519-donna seems to be all
variable-base. Do you know any implementations out there that allow
the aforementioned precomputation? Perhaps I'll ask this over on
[curves].

The approach I've taken so far with primitives in my implementation is
to get super fast versions of ChaChaPoly, but just stick with
reference C implementations for DH and Hash, since I figured it was
hopeless. Now I realize I'd be well served by using optimized
implementations for those too.

>
> If you want more DoS resistance there's other tricks (require the
> initiator's first message to be padded to a large size;

I fear this might make low-reliability connections even less reliable though.

> use client
> puzzles to force initiators to solve a hashcash problem before the
> responder consider their message

I like the hashcash approach, but that always seems to involve keeping
track of previously solved puzzles, since I'm dead-set on a 1-rtt
handshake. The other thing is that in some cases, in my protocol, the
initiator and the responder change roles and re-handshake.

> ).  But I think those get outside what
> the core of Noise should consider.

Yes, you're right. I should probably get my head outside of the
"crypto is the answer!" zealotry, and write a simple implementation of
the token bucket algorithm or a basic fixed-size time-sorted black
list, or really just go check out some of the literature from the
networking people who have already solved this problem countless
times, and are likely tired of non-networking people like me ignoring
their work while half-assing something that doesn't work.

=~=~=~=~=~=

With that said, I'm quite pleased with the PSK mode you're proposing
here. It seems to be a very easy non-invasive addition to the
protocol. It doesn't change the message size. And it provides some
post-quantum assurance. The hope is that by the time ECDH is broken
(which is, most likely, simply a matter of time), things actively in
use will use whatever the next generation for DH is. So that way,
those current users won't be able to impersonate or eavesdrop on one
another. And, by that time too, the old PSKs that were used prior will
have been forgotten and out of service, so any recorded past traffic
won't be decryptable. In other words, we know that our traffic is
being recorded for future decryption. But, we don't necessarily know
that malicious parties are investing resources into actively stealing
PSKs for algorithms they can't yet break; this would be much more
costly. So, PSK+ECDH seems to give a nice compromise of the deployment
eases of public key crypto, while at some time giving some
future-assurance.

This is, anyway, my understanding of why it's useful. Are there other
use cases you had in mind for it too?