review of Projects/replay_cache_collision_avoidance, ending Jan. 12

[Nicolas Williams]

On Mon, Dec 29, 2008 at 04:48:03PM -0500, Tom Yu wrote:
> 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)".

OK, good.

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

Because of confounders.

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

That's my understanding.  But as long as we leave out incidental
cleartext from EncryptedData I think we'll be pretty much fine.

Nico
--