Subject: Fwd: Generation of CHAP Secrets...

From: [email-masked]
Date: Wed, 21 Aug 2002 22:20:52 EDT

David,

I believe, the secret size does have a direct impact on the cryptograohic 
strength of the hash. If the secret size is less than the hashed value of the 
algorithm, then it makes it easier for an exhaustive search attack. For 
reference, here is a quote from the CHAP RFC page 3:

The CHAP algorithm requires that the length of the secret MUST be at
   least 1 octet.  The secret SHOULD be at least as large and
   unguessable as a well-chosen password.  It is preferred that the
   secret be at least the length of the hash value for the hashing
   algorithm chosen (16 octets for MD5).  This is to ensure a
   sufficiently large range for the secret to provide protection against
   exhaustive search attacks.

In a message dated 8/21/2002 9:50:42 AM Eastern Daylight Time, 
[email-masked] writes:

> There's no inherent upper limit on the size of the shared secret and it's
> not related to the output size of the hash algorithms.  128 bits is more
> than enough to get the job done, hence there's no need to require that
> implementations support more than that.  Generating more random bits and
> tossing some of them away is fine (e.g., IPsec ESP does exactly this to
> make its MD5 and SHA-1 HMACs fit in 96 bits), but they have to be *true*
> random bits - more below.
> 
> 

Subject: RE: Generation of CHAP Secrets...
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Date: Wed, 21 Aug 2002 09:50:08 -0400

> the iSCSI draft talks of up to 128 bits of shared secret.  While
performing 
> HASH, the MD5 will yield 128 bits, but SHA-1 (recommended Hashing
algorithm, 
> Sec 7.3.1) will generate 160 bits.  Seems to me that the shared secret
should 
> be allowed to be up to 160 bits..unless we allow MD5 for CHAP and then 
> possibly pad the hash? Or am I missing something here?

There's no inherent upper limit on the size of the shared secret and it's
not related to the output size of the hash algorithms.  128 bits is more
than enough to get the job done, hence there's no need to require that
implementations support more than that.  Generating more random bits and
tossing some of them away is fine (e.g., IPsec ESP does exactly this to
make its MD5 and SHA-1 HMACs fit in 96 bits), but they have to be *true*
random bits - more below.

While SHA-1 is the required hash for IPsec ESP, it does not work with
CHAP for historical reasons (one has to use MD5) - see, the IANA registry,
the PPP AUTHENTICATION ALGORITHMS section of:

    http://www.iana.org/assignments/ppp-numbers

While I'm sure Vijay did not mean to imply this, I want to warn
implementers away from a potentially disastrous implementation shortcut:

    **DO NOT** run a weak secret (e.g., password) through a hash
    or similar algorithm to generate something that appears to be
    a sufficiently-sized random CHAP secret.

The result of doing this is no stronger than the original weak
secret (e.g., password) - if this shortcut technique is used, the
result falls under iSCSI's "MUST enforce IPsec encryption" language.

This is a well-known implementation mistake (e.g.,
Netscape was publicly bitten by it several years ago).  A specific
example is that if one runs a password with 15 bits of randomness through
MD5, the resulting 128 bit output still has 15 bits of randomness - an
attacker need only run the dictionary words through MD5 [15 bit search
space] to mount an exhaustive attack, and the fact that the quantities
being checked are 128 bits in size does not improve security.

If one wants 128 bits of randomness, one needs to start with 128 random
bits - it really is that simple.  Using a hash does not increase the
amount of randomness.

Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449            FAX: +1 (508) 497-8018
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

---

From: Bill Studenmund <[email-masked]>
Date: Thu, 22 Aug 2002 11:48:23 -0700 (PDT)

> reference, here is a quote from the CHAP RFC page 3:

How is the size of the hash a magic number in terms of exhaustive search
attacks? Regardless of the size of the secret, you have to hash the I
value, the secret, and the challenge.

I see how making the secret longer is good, but I just don't see how
making the secret the size of the hash really changes the behavior. Once
we say have the secret at like 96 or 128 bits, do we really NEED more?
Sure, we can let folks choose more, but do we NEED it (a la we should
require it)?

Or do these hash functions (MD5, SHA-1) not stir all of the bits well, and
thus if you don't feed in about the number of bytes in the hash you get
poor results?

Take care,

Bill