Subject: RE: updated GSSAPI draft and summary of the off-list discussions

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 2 Sep 2003 21:53:16 -0700

I would expect designers for future checksums will do the diligence to
check against all known attacks, or have their designs properly
peer-reviewed.

Therefore I am not in favor of adding protection to kcrypto for just
this class of attacks.

Larry

-----Original Message-----
From: Joel N. Weber II [mailto:[email-masked]] 
Sent: Tuesday, September 02, 2003 9:43 PM
To: Ken Raeburn
Cc: Liqiang(Larry) Zhu; [email-masked]
Subject: Re: updated GSSAPI draft and summary of the off-list
discussions

> Under what circumstances can these message extension attacks be
> performed?  Should we be worried about any of our existing
> cryptosystems being unsuitable for general use?

``Section 6.3.1 Length Extensions'' of Schneier + Ferguson's Practical
Cryptography describes the attacks.  Basically, the problem is that,
with the way md5 and sha1 are defined, if you know the hash for a
block of data, you can take that hash plus data you want to add to the
end of the block of data and calculate a hash for the new whole.  This
is particularily interesting if some of the data hashed in the initial
block of data is data Eve doesn't know, such as a key being used for
integrity checking.

(Those hash functions do add the length and some filler after the
data, so I believe doing this attack would require that the
application data happen to tolerate that length and filler data being
there.)

That book doesn't go into a detailed analysis of exactly when you can
get away with not worrying about this, because it takes a very
conservative attitude.  They do recommend using HMAC to avoid this
problem.

I suspect if the data you feed into the integrity function includes a
length in a fixed location near the beginning of the data being fed to
the hash function, that is sufficient to prevent these attacks, even
if you don't use hmac.  So I think we can either make sure that gssapi
and krb-safe and krb-priv use a length value in that fashion, or else
make sure that the kcrypto framework has requirements language that
requires the integrity check to somehow protect against message
extension attacks.

---

From: "Joel N. Weber II" <[email-masked]>
Date: Wed, 03 Sep 2003 12:34:43 -0400

> check against all known attacks, or have their designs properly

So, what documentation is currently publicly available that peer
review has happened to make sure that 3des, aes, and rc4 don't have
length extension vulnerabilities?  (aes's security considerations
don't say anything explicitly about this, although the use of hmac is
presumably quite sufficient.  Though in skimming that document, I
don't think I actually see an explicit statement that hmac is used as
the checksum function.  I do see a comment in the simplified profile
that there are two checksum algorithms defined, one for each key size,
and I see that the hash is sha1 and that there's a length of hmac
output being used, and there's discussion of using hmac with the
string to key function.  Hopefully this means I'm missing some text
that's there.)

We've recently seen in the ssh working group that an assumption that a
design is digilently checked and peer reviewed doesn't really imply
the level of security some of us would have assumed, which suggests to
me that striving for more explicit documentation has at least a little
bit of value.

> Therefore I am not in favor of adding protection to kcrypto for just

You can protect against length extension attacks either by assuming
that a checksum algorithm that meets the requirements of kcrypto will
protect against such attacks, or you can assume that a
kcrypto-conforming checksum algorithm may not protect against these
attacks, and be careful about how you use a checksum algorithm.  We
really ought to have a clear, explicit decision as to which module is
responsible for protecting against these attacks.