RE: shared secret vulnerability

["Randy Chou" <rchou@arubanetworks.com>]

Yes, you're right.  I also missed that the first time I read Paul's
draft.  Entropy would only be increased if the possible number of
outputs increased.  Since the salt is fixed (and known anyways based on
PKCS#5), the number of possible outputs only depends on the precursor
secret itself.  The representation of the output increased so that would
make it harder to brute force.  But that's not to say that someone would
not be able to find a faster way to reach the result besides the brute
force method.  It just seems very very difficult.

So Paul, the following comment may need to be revised depending on
interpretation:

> Differently stated, 20 
   bits of effective entropy are added to a secret when hashed one 
   million times; thus, a secret with 40 bits of entropy provides 60 
   bits of effective entropy after amplification


Regards,

--
Randy

-----Original Message-----
From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org]
On Behalf Of Clint Chaplin
Sent: Wednesday, August 04, 2004 2:00 PM
To: jwright@hasborg.com; radiusext@ops.ietf.org
Subject: Re: shared secret vulnerability


My impression is that hashing doesn't add any more entropy than was
already present in the input.  Yes, hashing adds time to the
calculation, but the output itself isn't any more entropic than the
input was.  Am I incorrect?

Clint (JOATMON) Chaplin
>>> Joshua Wright <jwright@hasborg.com> 08/04/04 13:54 PM >>>
Paul Funk wrote:
 > The idea is that you take an ordinary secret, hash it many times,  >
and get a resulting "amplified" shared secret that multiplies the  >
difficulty of attack by the number of times it has been hashed. The  >
draft suggests 0x100000 (~ one million) iterations, adding 2 ^ 20  >
bits of effective entropy to the secret.

While I believe this algorithm is effective at adding entropy to a 
password such as the RADIUS secret, it does not resolve the issue of a 
widespread shared secret distributed throughout an organization. Without

a mechanism in place to regularly change the secret, the use of shared 
secrets in this fashion is reminiscent of WEP pre-shared keys. As most 
people are painfully aware, shared secret do not stay secretive.

That being said, I like Paul's idea for effectively adding entropy to 
the shared secret that will prolong a brute-force attack.  However, I do

not believe that this is effective at resolving weak authentication 
between the RADIUS authentication server and NAS.

-Joshua Wright
jwright@sans.org or
jwright@hasborg.com

-- 
-Joshua Wright
jwright@hasborg.com
http://home.jwu.edu/jwright/

pgpkey: http://home.jwu.edu/jwright/pgpkey.htm
fingerprint: FDA5 12FC F391 3740 E0AE BDB6 8FE2 FC0A D44B 4A73

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

________________________________________________________________________
This email has been scanned for computer viruses.


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>