[noise] Symmetric-crypto overhaul and stateful hashing

[Trevor Perrin]

On Mon, Nov 12, 2018 at 9:57 AM Loup Vaillant David
<loup at loup-vaillant.fr> wrote:
>
> Hi,
>
> Many of these changes will be much appreciated. I implemented HKDF to
> see how much it would cost (both in lines of code and in runtime), and
> it felt way overkill for cases where the hash was designed to be
> suitable for prefix-mac to begin with (such as keyed Blake2b).
>
>
> >  * The Encrypt/Decrypt operations will be possessed by some crypto
> > objects (like STROBE or other Sponge/Duplex objects).  In this case
> > we don't have to derive a key from the object and use it with an
> > AEAD, we can just ask the object to encrypt/decrypt things directly.
>
> Does this mean we'll be able to elide intermediate authentication tags
> (That is, tags occurring before the end of the handshake message)?

Interesting question, but I think somewhat orthogonal to the
stateful-hashing object:

 * A STROBE-like stateful-hashing object could do authenticated
encryption by Squeeze()-ing out the authentication tag after Encrypt()
or Decrypt().

 * We could take our current authenticated-encryption ciphers and
define non-authenticated variants (AESCTR for AESGCM; ChaCha for
ChaChaPoly).

The downside of skipping the authentication tag is that the recipient
might do processing on garbled/non-authenticated plaintext that
reveals something about that plaintext.

For example, imagine an implementation of ECDH that returns
immediately if given an all-zeros public key.  If an attacker
intercepts an AESCTR ciphertext encrypting Alice's static public key,
the attacker could test for Alice's identity by XOR'ing Alice's static
public key into the ciphertext,  then sending the message on to the
recipient and seeing if the recipient returns an error quickly.

So it's a good general practice to always do authenticated-encryption
when you want things to be confidential.

Trevor