[noise] DoS resistance

Trevor Perrin trevp at trevp.net
Fri Jul 17 17:58:33 PDT 2015


On Thu, Jul 16, 2015 at 10:42 PM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>
> So in benchmarking this thing, I've been looking at denial of service
> resistance.
>
> I can send around 10 gigabits of data per second of illegitimate
> post-handshake data messages, before the CPU is maxed out. That's
> good.
> But, I can only send around 70 megabits per second of handshake
> messages, before the CPU is maxed out. Bad news bears.
[...]
> So noise is fast during data packets, slow during handshake (HandshakeIK).
>
> I wonder if there are some tricks we could use for speeding this up.


Hmm, hard question.

Is the issue how much amplification there is between client
computation and server computation?  HandshakeIK lets the client
calculate the first message once, then repeatedly send it to the
server, triggering 4 DHs:

HandshakeIK:
  <- s
  ******
  -> e, dhes, s, dhss
  <- e, dhee, dhes


Suppose the client spends the first RT just to retrieve the server's
ephemeral public key.  I think you can rearrange things so the client
can only trigger 1 extra DH for each re-send, or 3 server DHs per 2
client DHs:

  <- s
  ******
  ->
  <- e
  -> e, dhee, s, dhse, dhes

You could also require the first message to be padded to a certain
length, to equalize the costs between client and server further.

That requires keeping session state on the server before
authentication, which you also didn't want to do.  But maybe that's a
tradeoff you have to choose between.

If you want to shift the costs so that the client has to do more work
than the server you could do "client puzzles" where the 1st RT
challenges the client to solve some hashcash type puzzle, but that
probably doesn't belong in the Noise core.


Trevor


More information about the Noise mailing list