The assumption for the security of a
plaintext-feedback stream cipher (as stated in the
Helix paper) is that:

1) as with all stream ciphers, the key/nonce
combination must not be reused by the encryptor

2) but also, the *recipient* has to go to great
lengths to ensure that the nonce is not reused,
and the result of decrypting a ciphertext whose
MAC doesn't check out must be discarded (that is,
treated as sensitive, secret information and not
revealed).

Now normally the recipient doesn't have that
second restriction! And it's a tough one... for
efficiency, it's quite likely that the ciphertext
buffer is being decrypted in place, so before you
even get to check the MAC, the plaintext is lying
around in a place where it might subsequently be
found. Or if there's some weakness in the
protocol, you might convince the reciever that
there isn't any MAC attached at all.

On Mon, 14 Jul 2008 18:32:04 +0000 (UTC), ggr at (no spam) nope.ucsd.edu (Greg
Rose) wrote in Message-ID: <g5g634$fdc$1 at (no spam) ihnp4.ucsd.edu>:

[snip]
The assumption for the security of a
plaintext-feedback stream cipher (as stated in the
Helix paper) is that:

1) as with all stream ciphers, the key/nonce
combination must not be reused by the encryptor

2) but also, the *recipient* has to go to great
lengths to ensure that the nonce is not reused,
and the result of decrypting a ciphertext whose
MAC doesn't check out must be discarded (that is,
treated as sensitive, secret information and not
revealed).

Now normally the recipient doesn't have that
second restriction! And it's a tough one... for
efficiency, it's quite likely that the ciphertext
buffer is being decrypted in place, so before you
even get to check the MAC, the plaintext is lying
around in a place where it might subsequently be
found. Or if there's some weakness in the
protocol, you might convince the reciever that
there isn't any MAC attached at all.

Isn't the argument 2) also valid for blockcipher based combined
encryption / authentication modes like EAX (at least to some extend)?

With EAX and a given ciphertext/tag you can first do the authenticate
pass and if the tag is correct do the decryption phase.

But this would have severe implications for the "on-line" property of
EAX and the situation is even worse for one pass AEAD schemes. Or am I
missing something obvious?

Is there a solution other than using small packet sizes and not using
"on-line" or streaming APIs?

But this would have severe implications for the "on-line" property of
EAX and the situation is even worse for one pass AEAD schemes. Or am I
missing something obvious?

So, I didn't really make myself clear enough
above, sorry. Modes like EAX, CCM, et. al. should
also be used with the same sort of guidelines but
they are not nearly as fragile. If someone tampers
with an EAX-protected message, and the recipient
does something wrong like disclosing the recovered
plaintext anyway, really all that has happened is
that the attacker gets known ciphertext-plaintext
pairs (and obviously something that wasn't
supposed to be disclosed, is... but that wasn't
the mode's fault).

[snip}

Is there a solution other than using small packet sizes and not using
"on-line" or streaming APIs?

I'm not sure what you mean by this bit.

Thank you Greg for the statement above, which put into my question in