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
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?
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-0... 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.
participants (4)
-
hallam＠w3.org -
John Lull -
Mike_Spreitzer.PARC＠xerox.com -
Rich Salz