Re: Keyed-MD5, ITAR, and HTTP-NG

All your individual answers make sense.

Taken together, tho, they make HTTP-NG worrisome on the crypto front.

For example, it's probably a real bad idea to replace DES with something
commonly called RC4.  The former has been under public scrutiny for years,
the later still has not formally emerged from the shroud of trade secret.
The keyed MD5 responses also don't inspire confidence.

With all due respect, I strongly encourage you to leave crypto out of
HTTP-NG for the time being.  Wait to see what happens from the various
IPng security, SSL, S-HTTP, the W3C work, et cetera.  Leave some "holes"
in the protocol, but don't tie anything down now.  For better for the
Web to wait six to 12 months for HTTP-NG, then for mistakes to occur
in this area.
	/r$

>For example, it's probably a real bad idea to replace DES with something
>commonly called RC4.  The former has been under public scrutiny for years,
>the later still has not formally emerged from the shroud of trade secret.
>The keyed MD5 responses also don't inspire confidence.

I disagree. Basically Simon simply has to stick in some parameters so that
the crypto alg can change with time. There should be slots for the following 
algs :-

Symmetric cipher	IDEA, RC4, 3DES
Keyed Digest		KD* (paper to follow, there are 7 to chose from).

Key exchange		Diffie-Helleman, El Gammal, RSA
Signature		RSA, El Gammal, Rabin (Shamir variation), DSS
Hash functions		MD5, SHA

I don't think that we are intending to tap Simons skill in designing 
ciphers. We have Ron Rivest and Taher El Gamal for that, plus help from
Adi Shamir and if we get stuck I'll bang on some other doors. I really don't 
think we have a problem lacking cryptographers. Simon is putting in security 
input which is different. We have an equally star studded cast for that side of 
things (and if we get stuck I'll e-mail some more characters).

	Phill

On Mon, 30 Oct 1995 23:27:36 -0500, you wrote:

> Hash functions		MD5, SHA

I presume you mean SHA-1.

I would prefer to see MD5 deleted.  A 128 bit hash simply seems too
marginal in length for long term use in most hash applications.  I
would much rather see something like Haval as a second hash algorithm.
It can be faster than MD5, and can easily be tailored to the hash
width you want.  If 128 bit hashes are really needed, use Haval's
128-bit option.

>I would prefer to see MD5 deleted.  A 128 bit hash simply seems too
>marginal in length for long term use in most hash applications.  I
>would much rather see something like Haval as a second hash algorithm.
>It can be faster than MD5, and can easily be tailored to the hash
>width you want.  If 128 bit hashes are really needed, use Haval's
>128-bit option.

MD5 is pretty well entrenched in IETF circles and since RSAREF only
provides Md2, MD4 and MD5 there has to be an option to use at least 
one of them. MD5 is the best of that set IMHO.

For Phil Rogaway's comments on keyed MD5 see :-

http://wwwcsif.cs.ucdavis.edu/~rogaway/papers/draft-rogaway-ipsec-comments-00.tx
t

Unfortch much of the information he gave in his talk appears not to be there. 
C'est la vie as they say in Canada.

Also the cryptobytes article Miclael found an online for is well worth 
a look. http://www.rsa.com/rsalabs/cryptobytes/spring95/md5.htm
I would have quoted it but I didn't know it was avaliable in e-form. The
cryptobytes articles are well worth reading in general.

Also on Phil's page:
http://wwwcsif.cs.ucdavis.edu/~rogaway/papers/list.html

 Mihir Bellare, Roch Guerin and Phillip Rogaway
     XOR MACs: New methods for message authentication using finite pseudorandom 
functions,
     Crypto '95. 


	Phill

On Tue, 31 Oct 1995 13:55:34 -0500, you wrote:


> MD5 is pretty well entrenched in IETF circles

Agreed, but that doesn't make it appropriate here.

> and since RSAREF only
> provides Md2, MD4 and MD5 there has to be an option to use at least 
> one of them.

Why?  Is there some REAL requirement that HTTP-NG be implementable
using only RSAREF for crypto?

> MD5 is the best of that set IMHO.

No argument -- but it's still too short for most hash applications.
I'd much rather see hashes that everyone agrees are more than long
enough for the forseeable future  -- and I don't think you'll find
that consensus for MD5.

Of course, whether a particular hash is as secure as it can be for a
given length is a separate question.

  <references snipped>

Thanks for the pointers.

Isn't this what the GSS-API is about?  Couldn't HTTP-NG just convey GSS
"tokens", and do something about getting both sides to agree on which GSS
"mechanism" is to be used, and on what Principals are involved?