review of Projects/replay_cache_collision_avoidance, ending Jan. 12

[Tom Yu]

Nicolas Williams <Nicolas.Williams at sun.com> writes:

>  - 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.

That is what I was intending.  I would think that "ciphertext" would
unambiguously specify "bytes you input to an encryption scheme (as in
RFC 3961)".

> 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.

I prefer using the hash of the ciphertext because I believe it gives
us a higher chance of avoiding false positives, and the possible
attacks on that method require a large work factor on the part of the
attacker and that the target uses weak crypto.

If we are going to hash the cleartext of the authenticator, we need
some more information about the applications where the false positive
behavior is problematic.  Do such applications actually tend to have
clients that send subkeys?