[noise] Disco objects (was Re: spectemplate / spectools)

[Trevor Perrin]

On Wed, Nov 22, 2017 at 6:25 PM, David Wong <davidwong.crypto at gmail.com> wrote:
>
> I think the point of the approach was more about the simplicity.
>
> Compare this: http://www.discocrypto.com/disco.html#out-of-order-transport-messages
> to this split: http://www.discocrypto.com/disco.html#modifications-to-the-symmetric-state

Let's weigh that:

In the first case (which I prefer) you return 64-byte objects (just
the "capacity") and encryption is:
 - copy capacity to new Sponge state, AD(nonce), send_ENC, send_MAC
 - increment the nonce

In the second case (which you prefer) you return 200-byte objects (the
whole Sponge state) and encryption is:
 - send_ENC, send_MAC
 - store the new Sponge state

Noise libraries already handle the nonce, so in a general Noise
library it's probably easier to leave that intact then replace it.
Even in a specialized library, I doubt that storing and incrementing
an 8-byte integer has a complexity cost worth worrying about,
particularly when the alternative involves storing a 200-byte evolving
state.

The AD() operation is already used in Disco, so I also don't see much
complexity cost to AD(nonce).

In contrast, spec'ing two different ways to do the same thing adds a
lot of complexity to spec authoring, to analysis, to protocol
designers figuring out which one to use, and to implementers and API
designers who have to support both.


> I'll add that out-of-order protocols are definitely not the strong
> point of Noise either

Wireguard is our most visible / flagship use right now.  It's possible
that out-of-order protocols *are* our strong point.

At least, there's a lot of interesting lossy/out-of-order cases we
could consider Noise for (thinking of QUIC, DTLS, and MinimaLT; or
radio protocols like cellular, bluetooth, and wifi).


>, at the moment the specification mentions them
> but there is quite a lot of "invisible" work that needs to be done so
> that it can be implemented.

Sure, they require more work on top of the Noise core, but that's true
of any use of Noise.


> It's even possible that a lot of things in
> Noise might have to change their API as well to make the reception of
> handshake messages possible out-of-order and with some of them being
> dropped.

Like what?  Wireguard doesn't require other changes to our core APIs.
Out-of-order seems like it can be handled by adding things like
(timers, acks, retransmission, sequence numbers, replay detection).
None of which changes the core crypto.


> I think it would be good to have more discussions about Noise on top
> of UDP and what it would look like.

Sure.  There was an earlier thread with Jake, Jason, and DJB about
this, I would've liked to see that extended.


>> also think all Noise crypto algorithms should provide the same
>> security properties.  That allows people to swap algorithms based on
>> performance/availability/quantitative security level without worrying
>> they might invalidate some subtle property their protocol depends on.
>
> True, but I'd argue that Disco is an extension not something you can
> swap around in vanilla Noise anyway.

Right now, Noise crypto is very modular:  You can easily swap
algorithms based on performance, availability, and quantitative
security level.  While doing this, you don't have to worry about
compatibility with protocol designs (like "out-of-order"), or
different qualitative security properties.

That's a nice set of properties, I think it would be a mistake to move
away from that.


> So I just added a call to meta_RATCHET(0) which will make the state
> start on a new block.
> This way everytime you encrypt you start by doing an AD(nonce) on a
> new block. No overflow.

I assumed that's how it worked, but AD(nonce) will still occupy space,
so will sometimes cause things to spill into another "block".

Trevor