review of Projects/replay_cache_collision_avoidance, ending Jan. 12
Nicolas.Williams at sun.com
Mon Dec 29 23:25:22 EST 2008
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)".
> > 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.
More information about the krbdev