review of Projects/replay_cache_collision_avoidance, ending Jan. 12

[Tom Yu]

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.