[noise] Disco objects (was Re: spectemplate / spectools)
trevp at trevp.net
Wed Nov 22 11:43:40 PST 2017
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
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
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".
More information about the Noise