review of Projects/replay_cache_collision_avoidance, ending Jan. 12

Tom Yu tlyu at MIT.EDU
Mon Dec 29 08:11:46 EST 2008

Sam Hartman <hartmans at MIT.EDU> writes:

> However please see the thread from July 2008 on ietf-krb-wg titled
> "Replays and ciphertext Comparison."  In that thread Ken and I discuss
> whether RFC 3961 gives you strong enough guarantees that changes to
> the ciphertext will be detected.
> Quoting Ken:
>     Ken> On Jul 10, 2008, at 13:59, Sam Hartman wrote:
>     >> However, I don't think that this is guaranteed to be safe.
>     >> Consider for example an encryption system based on CBC that
>     >> stores length information about the message so that the
>     >> application does not need to do so.  Also, assume that the
>     >> encryption system MACs the plaintext not the ciphertext.
>     >> 
>     >> An attacker could change final padding with this encryption
>     >> system, changing the ciphertext, but not the plaintext.
>     Ken> The specification of the decrypt function in 3961 says,
>     Ken> "verifies the integrity of the supplied ciphertext".  That
>     Ken> suggests that changing the ciphertext, even if the only
>     Ken> effect in decrypting is to alter some padding bytes added on
>     Ken> the end of the encoded ASN.1 message or other blob, should be
>     Ken> detected and treated as an error.
> While I didn't read RFC 3961 that way originally, I find Ken's reading
> compelling.  I believe that current Kerberos crypto systems meet that
> invarient.

> So, I believe storing a hash of the encrypted text is appropriate and
> sufficient.

I agree.  Relatedly, I think we should consider reworking RFC 3961 to
use terminology and concepts better aligned with current research in
provably secure cryptography, but that's for another time.

More information about the krbdev mailing list