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

[David Wong]

> We've already discussed that any security benefit to making later
> encryptions depend on earlier ones (the "in-order" approach) is tiny.
> It might give you some post-compromise security if the attacker
> compromises you and *then* fails to observe some messages, but that
> can be done better with other mechanisms (periodic re-handshaking; "DH
> ratcheting").

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

I'll add that out-of-order protocols are definitely not the strong
point of Noise either, 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. 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. (I feel like "out-of-order" doesn't really make justice to
UDP because it lacks the "messages can be dropped" element.)

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


> 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.

I first implemented the Noise protocol framework, and then modified it
to get Disco. It was mostly deletions and it was pretty quick.
Now if I had wanted to get the nonce-version of Disco, it would
definitely have been more work.
>From that experience, the current way is easier to implement coming
from a Noise library. The change of API did not pose any problem to my
library.


> The in-order approach doesn't have an AD(nonce) operation per each
> message.  For an 8-byte nonce, I think AD(nonce) in Strobe appends 10
> bytes to sponge state, which will sometimes overflow and cause another
> sponge operation, so on average it increases the cost by encrypting 10
> extra bytes per message.

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.


>  * Use a better construction for the AEAD like Farfalle or some sort
> of "full-state keyed sponge".  This seems the best option eventually,
> since neither Strobe nore sponges are optimized for AEAD.  Given that,
> I'm skeptical it's worth complicating things for such a small
> optimization in the short term.

That might be a good idea in term of just having something you can swap around.
I'll admit I haven't looked at Farfalle at all.

David