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

[Trevor Perrin]

On Mon, Nov 20, 2017 at 6:33 PM, David Wong <davidwong.crypto at gmail.com> wrote:
>
> OK I removed the DiscoSecureChannel and it is now just re-defining the
> CipherState object.

I'm still questioning the rationale for both an "in-order" transport
and a (standard Noise)  "out-of-order" approach.

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


I could imagine a performance argument for in-order, but that also seems weak:

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.

If average message size > 1000 bytes, this is less than a 1% speed
difference.  But if that's a concern you could optimize further:

 * Encode the nonce as a "varint", so it takes fewer than 10 bytes -
if your protocol sends under a million messages, then the cost is
reduced from encrypting 10 extra bytes per message to <= 5 bytes.

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

Trevor