[noise] new branch: psk2
Trevor Perrin
trevp at trevp.net
Sat Nov 14 14:08:05 PST 2015
On Sat, Nov 14, 2015 at 5:24 AM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> Minor typo:
Thanks.
> On Sat, Nov 14, 2015 at 8:16 AM, Trevor Perrin <trevp at trevp.net> wrote:
>> I realized a problem in how we were using ephemerals as nonces. So
>> I'd like to eliminate encryption of ephemeral public keys, and also
>> streamline PSK by using ephemeral public keys in place of explicit
>> randoms:
>
> Doesn't this, then, remove the anti-DoS protections? IOW, a DH occurs
> before a Poly1305 occurs?
It's true that this results in a DH before any PSK-based decryption,
for the responder.
I don't agree that this removes "anti-DoS protections", because I
don't think doing things the other way provides DoS protection.
Note that simply replaying the initiator's first message defeats this
"protection". If your threat model doesn't allow attackers to observe
messages for replay, then having the initiator's first message begin
with a secret value in clear gets the same "protection", for cheaper
(no crypto ops for responder at all, just a const-time comparison).
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.
If you want more DoS resistance there's other tricks (require the
initiator's first message to be padded to a large size; use client
puzzles to force initiators to solve a hashcash problem before the
responder consider their message). But I think those get outside what
the core of Noise should consider.
Trevor
More information about the Noise
mailing list