[noise] Notes from CRYPTO

[David Wong]

> In Strobe terms, would this be:
> KEY; AD; ENC; MAC;
> (from [1], section 5.2)?

Yes, with a few differences:

* the type of operation is not absorbed in SpongeWrap
* the padding is obviously different (and simpler in SpongeWrap)
* KEY permutes the state prior to absorbing the key, SpongeWrap does
not do that so the start would be more similar to AD than KEY
* the encryption phase absorbs the previous block of AD or plaintext
instead of the current block of plaintext. So the state doesn't become
the ciphertext as we encrypt, but the plaintext we want to encrypt

The last one is the important one, It'd be interesting to look at the
security proof of SpongeWrap to see if it can be translated to
Strobe's AD/KEY; AD; ENC; MAC.


> Is your efficiency concern that the key and nonce would occupy space in the "rate" at the start of each AEAD call, whereas if you use a duplex object that is stateful between AEAD calls then the full "rate" is available for application data, since the key gets absorbed into the "capacity" prior to the AEAD calls, and there's no nonce?

Here are a few concerns and some work-arounds:

* a half-duplex Strobe protocol is attracting → it can be done with an
AEAD as well
* if you use a nonce, you need to absorb it and permute every time
before encrypting. You also need to keep track of an 8-byte state →
ou need a permutation everytime as well with Strobe's ENC operation.
* you lose Strobe's RATCHET operation which can give you
forward-secrecy for free at every encryption → you could use a last
PRF call (after AD;AD;ENC;MAC) that would generate your next AEAD key
* you lose Strobe's continuous authentication of all previous messages
including the handshake → you could keep a continuous hash of these
and authenticate them in the AD part (but one more state to keep track
of) → on the other hand do we care about this property?
* doing it the Strobe's way would simplify the spec and the
implementations → it wouldn't add too much to the spec/implementation

> Losing nonce-based AEAD substantially limits the functionality of Noise, e.g. you couldn't implement WireGuard.  That's a big loss of functionality for a small optimization.

I think it would be nice to have Disco specify three types of
SymmetricState at the end: a half-duplex one, a full-duplex one and an
AEAD one. The first one allowing for great space saving, the last one
specifically targeting UDP protocols.


> If we wanted nonce-based AEAD *and* this optimization, couldn't we do something like encode the key and nonce directly into the SHAKE256 "capacity" (which is 512 bits, so could easily hold a 256-bit key and 64-bit nonce).  Then we'd get nonce-based AEAD plus the same efficiency, I think?  Or is that not allowed?

The problem here is that the nonce is public, so you would make a part
of your capacity public.

David