Re: SAFE Forum--some comments

At 08:44 PM 7/2/96 -0700, Martin Minow wrote:

>It's not quite that bad. Here are a few (more or less strong) crypto
>products you might not know you have:
>
>1. Every Macintosh made since at least 1988 has a secure authentication
>   client module in the AppleShare Chooser dialog. When you use it to
>   connect to a remote server, it notes that the user information
>   is "two-way scrambled." (The server sends a random number challenge
>   that the client uses to encrypt the username and password. The
>   encrypted information is sent to the server.) All Macintosh systems
>   running System 7 or later have the corresponding server software.
>   What is interesting about this is that the encryption is completely
>   invisible to the user.

I hear this as the server sends out a key which the client uses to encrypt
the username/password.  This algorithm makes less sense than the one I
thought I heard at the SAFE forum on Monday which was:

(1) The server sends out a challenge/salt (different each time)
(2) The client uses a secure hash to compute hash(salt||password) and
returns the username and the hash.
(3) The server computes hash(salt||password) and compares the hashes.

Given that there is still some interest in algorithms and protocols on this
list, can you describe what is really happening?

Thanks - Bill


-------------------------------------------------------------------------
Bill Frantz       | The Internet may fairly be | Periwinkle -- Consulting
(408)356-8506     | regarded as a never-ending | 16345 Englewood Ave.
frantz@netcom.com | worldwide conversation.    | Los Gatos, CA 95032, USA

-----BEGIN PGP SIGNED MESSAGE-----

On Wed, 3 Jul 1996, Bill Frantz wrote:

> I hear this as the server sends out a key which the client uses to encrypt
> the username/password.  This algorithm makes less sense than the one I
> thought I heard at the SAFE forum on Monday which was:

True.  That algorithm is completely useless.

> 
> (1) The server sends out a challenge/salt (different each time)
> (2) The client uses a secure hash to compute hash(salt||password) and
> returns the username and the hash.
> (3) The server computes hash(salt||password) and compares the hashes.
> 
> Given that there is still some interest in algorithms and protocols on this
> list, can you describe what is really happening?

That one makes more sense.  If the salt is completely random, then an attacker
will not be able to use a replay attack.  Since the password is hashed, there
is no way to find it out given the output.  This does require the server to
maintain a list of cleartext passwords, but that's not any worse then Kerberos
which requires a KDC store everyone's DES key.

- -- Mark

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
markm@voicenet.com              | finger -l for PGP key 0xe3bf2169
http://www.voicenet.com/~markm/ | d61734f2800486ae6f79bfeb70f95348
"Freedom is the freedom to say that two plus two make four.  If that
is granted, all else follows."  --George Orwell, _1984_


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3
Charset: noconv

iQCVAwUBMeAGBrZc+sv5siulAQEzGwQAp6rB1eJ5DIzn9Zs5LlEDFu3K7XFRcl7S
/9MQ5ykCmvgnOqgN1Pud/KYLsZuY2x+G5W68EF0kTVfwarS2ZCT2wYVhH5cMaEQs
2YfxtoK9opB73GiMP3OJUTZlNPnwCCe/y/iHJN7HqAv/YLi+gdIc9rGXtfegE/eY
sASbbC7C1oY=
=NJSu
-----END PGP SIGNATURE-----