[noise] Ciphertext-indistinguishability from random noise with Poly1305?

[Trevor Perrin]

On Wed, Feb 14, 2018 at 6:23 PM, Marian Beermann <public at enkore.de> wrote:
>>
>
> Specifically in the context of noise the message sizes are very small
> (<64k), though. Therefore the latency reduction you can get by streaming
> decryption on a partial ciphertext is small as well.
>
> And then there is the general problem with streaming AEAD, namely, that
> it incentivises applications to process bits of plaintext that are not
> authenticated (possibly in the belief they are authenticated).


Good points: streaming decryption of an individual Noise message
probably isn't much of a performance advantage.  So putting the
tag/SIV at the beginning is not that helpful and might encourage
implementations to release plaintext without authentication.

Tony additionally points out that putting the Synthetic IV (aka tag)
at the end is more convenient for in-place operation.

I'd assumed "Synthetic IV" nonces would come before the ciphertext,
since that's how Rogaway and Shrimpton defined it in their papers and
AES-SIV, and it seemed natural if you think of IVs.

But AES-GCM-SIV puts it at the end, and calls it a "tag", so maybe
that's the direction things are going?  Or should go?


Anyways, here's a few options for our AEAD functions:

(1) Require a 16-byte tag at the end, with the previous data encrypted
using a cipher (Keziah's proposal).

(2) Impose an indistinguishability requirement on the entire
ciphertext, including the tag/SIV, where ever it is.

(3) If the first 32 bytes of output from calling ENCRYPT() on 32 bytes
of zeros *aren't* indistinguishable, then you're required to supply a
REKEY() function.


I think I still prefer (2) because:
 - it's what we're currently doing
 - it enables us to easily define REKEY() or build
unfingerprintable/indistinguishable protocols, with any
Noise-compatible AEAD
 - the indistinguishability requirement doesn't seem that onerous

?

Trevor