review of Projects/replay_cache_collision_avoidance, ending Jan. 12

[Nicolas Williams]

On Mon, Dec 29, 2008 at 12:28:14PM -0500, Sam Hartman wrote:
> As I explain in another message, I think that RFC 3961 allows us to
> avoid this.  However, consider a stream cipher that integrity protects
> the plaintext, *not* the ciphertext.  I think changes to the
> confounder would be undetected.

Would a such a cipher have a confounder?  Or did you mean something like
a salt for deriving a message key?

In any case, as long as the ciphertext being used is that of an
Authenticator that was decrypted and integrity verified then there
should not be any problem, BUT:

 - Do make sure that ASN.1 DER cleartext bits are not included in the
   definition of "ciphertext" (i.e., no EncryptedData tag, length,
   etype, kvno, and cipher tags and length), because those might provide
   a way for an attacker to change the encoding without changing the
   actual ciphertext.

> It does not fall out of any of the standard definitions of security
> for symmetric ciphers--not even non-malleability--guarantees that it
> is hard given one ciphertext to construct another valid ciphertext
> with the same plaintext.

I would prefer hashing the cleartext of the Authenticator because
there's less to think about with respect to replay attacks, though it
does require that the client use a sub-session key in order to help with
the false positives issue, but then, I think that clients that reuse
ctime/cusec values [when generating multiple authenticators in the same
second] typically (if not always) also assert a sub-session key.

Nico
--