Keyed-MD5, ITAR, and HTTP-NG

To summarise: the consensus is that using keyed-MD5 for authentication is 
ok under ITAR, but using it for confidentiality is out.

The reason I wanted to check is that I'm solidifying some of security 
paramaters for HTTP-NG so we can add them to the test implementation 
before the Dallas IETF. In addition to the slight problem of having half 
the development team on the other side of the Atlantic, I want to make at 
least a subset of the security schemes mandatory, and that means making 
the core stuff exportable.

At the moment, I'm thinking of making the mandatory schemes be Keyed MD5
for authentication, and weakened RC4 with an IV for confidentiality, with
the added stipulation being that the user must be informed when key
weakening is being used. I may swap RC4 for DES; they're both public 
domain, but RC4 is simpler. They're both shared key, but I don't make PK 
stuff mandatory. 

The other pre-defined schemes I'm planning on getting at least speced are 
3-DES and IDEA for confidetiality, SHA for hashing, and RSA & DH for 
key exchange, signatures, and authentication. Certificate format is 
currently X.509- PGP format will go in ASAP.


Simon

---
(defun modexpt (x y n)  "computes (x^y) mod n"
  (cond ((= y 0) 1) 	((= y 1) (mod x n))
	((evenp y) (mod (expt (modexpt x (/ y 2) n) 2) n))
	(t (mod (* x (modexpt x (1- y) n)) n))))

Simon,

	Do not spec Keyed MD5, it is a complete looser. It is actually weak
against a number of attacks. There are much better constructs for creating
a keyed digest. There are much better ways of creating a digest than using
a hash fuinction as the base.

	There is some work by Phil Rogaway on making keyed digest functions
which I strongly recommend people look at. I can post a paper on the subject if 
people are interested.

		Phill

On Mon, 30 Oct 1995 hallam@w3.org wrote:

> 	Do not spec Keyed MD5, it is a complete looser. It is actually weak
> against a number of attacks. There are much better constructs for creating

What I've heard is that there are some worries about using short 
constants with MD5; maybe you could fill us in on the naughty stuff 
(someone said there were a load of papers in Crypto '95 on the subject?)

> 
> 	There is some work by Phil Rogaway on making keyed digest functions
> which I strongly recommend people look at. I can post a paper on the subject if 
> people are interested.

Hey, you got a web-site? :-)

Simon

----
(defun modexpt (x y n)  "computes (x^y) mod n"
  (cond ((= y 0) 1) 	((= y 1) (mod x n))
	((evenp y) (mod (expt (modexpt x (/ y 2) n) 2) n))
	(t (mod (* x (modexpt x (1- y) n)) n))))

"h" == hallam  <hallam@w3.org> writes:

h> There is some work by Phil Rogaway on making keyed digest
h> functions which I strongly recommend people look at. I can post a
h> paper on the subject if people are interested.

There's also ``Message Authentication with MD5'' by Burt Kaliski and
matt Robshaw in RSA Laboratries' CryptoBytes,
http://www.rsa.com/rsalabs/cryptobytes/spring95/md5.htm,

michael

hallam@w3.org writes:
> 	Do not spec Keyed MD5, it is a complete looser. It is actually weak
> against a number of attacks. There are much better constructs for creating
> a keyed digest. There are much better ways of creating a digest than using
> a hash fuinction as the base.

What??? 

A keyed version of MD5 is the base authentication mechanism in IPSP
and it has been heavily examined by a number of very good
cryptographers.

Perry

>A keyed version of MD5 is the base authentication mechanism in IPSP
>and it has been heavily examined by a number of very good
>cryptographers.

Yes we reviewed it and said that it sucked.

Phil wrote a note to Ron and Ron sent in a series of comments. I suggested that
the idea of a keyed digest be stated as a separate concept from a hash function.
Functions of one variable are intrinsically different from functions of two 
variables.

The sequence of events I heard was that they asked Burt Kaliski for a suggestion,
he gave them one and they chose something different.

	
>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?

GSS is often brought up on occasions like this. I have never seen an architectural
overview of what it is trying to achieve for me or how. When I am provided 
with a clear definition of what it is I hope to arrive at a clear explanation 
of why I'm not using it. Unfortunately the RFC process strips the rationale
part out of the specs. 


		Phill

hallam@w3.org writes:
> 
> >A keyed version of MD5 is the base authentication mechanism in IPSP
> >and it has been heavily examined by a number of very good
> >cryptographers.
> 
> Yes we reviewed it and said that it sucked.
> 
> Phil wrote a note to Ron and Ron sent in a series of comments.

Phil was complaining largely because in spite of his apparent
cryptography credentials he's a lughead who can't have been bothered
to understand the architecture -- most of his comments reflected a
general ignorance of the process and of the discussions that had
preceeded. He also complained that the transforms weren't sufficiently
generic for his tastes. However, no complaints AT ALL were made about
Hugo's selection of cryptographic transform. We were assured by
everyone that it was the right thing to do, with people swearing up
and down that it was the appropriate idea. Do you want me to extract
the mailing list archives? Every last posting on this topic is on
line.

> The sequence of events I heard was that they asked Burt Kaliski for
> a suggestion, he gave them one and they chose something different.

Actually, Kaliski made an off-the-cuff suggestion that all the other
crypto folks ripped apart, largely because it was obvious even to me
how it could be attacked, and then he backed off.

Perry

Hello,

On Mon, 30 Oct 1995, Simon Spero wrote:

> The reason I wanted to check is that I'm solidifying some of security 
> paramaters for HTTP-NG so we can add them to the test implementation 
> before the Dallas IETF. In addition to the slight problem of having half 
> the development team on the other side of the Atlantic, I want to make at 
> least a subset of the security schemes mandatory, and that means making 
> the core stuff exportable.

  Since you deal with security issues maybe you can help me to learn 
about some issues with encryption.  I am talking with one of the 
administration people about putting PGP on the system for everyone to 
use, but there are issues for them (the admin) as they might be liable, 
even if they can't read the e-mail.  What other legal considerations 
should be evaluated?
  Is there any large organizations (like any other universities) that 
allow their students to use PGP, and have the system in place to make it 
easier for the students?  If it is offered here I might be the one to add 
to the mail program (pine) that is generally used to transparently use 
PGP, which is what I mean by having a system set up for the encryption. 
  Thanx for any help.  Take care and have fun.

James Black
black@suntan.eng.usf.edu

>  Since you deal with security issues maybe you can help me to learn 
>about some issues with encryption.  I am talking with one of the 
>administration people about putting PGP on the system for everyone to 
>use, but there are issues for them (the admin) as they might be liable, 
>even if they can't read the e-mail.  What other legal considerations 
>should be evaluated?
>  Is there any large organizations (like any other universities) that 
>allow their students to use PGP, and have the system in place to make it 
>easier for the students?  If it is offered here I might be the one to add 
>to the mail program (pine) that is generally used to transparently use 
>PGP, which is what I mean by having a system set up for the encryption. 
>  Thanx for any help.  Take care and have fun.
>
>James Black
>black@suntan.eng.usf.edu
>
>
We have approx 1000 machines and 5000 user accounts and have pgp installed.
I can't think of any reason not to have it installed, and lots of good
reasons for having it installed.

--
____________________________________________________________________________
Doug Hughes					Engineering Network Services
System/Net Admin  				Auburn University
			doug@eng.auburn.edu
	Apple T-shirt on Win95 - "Been there, done that"

On Mon, 30 Oct 1995, Doug Hughes wrote:

> >  Since you deal with security issues maybe you can help me to learn 
> >about some issues with encryption.  I am talking with one of the 
> >administration people about putting PGP on the system for everyone to 
> >use, but there are issues for them (the admin) as they might be liable, 
> >even if they can't read the e-mail.  What other legal considerations 
> >should be evaluated?
> >  Is there any large organizations (like any other universities) that 
> >allow their students to use PGP, and have the system in place to make it 
> >easier for the students?  If it is offered here I might be the one to add 
> >to the mail program (pine) that is generally used to transparently use 
> >PGP, which is what I mean by having a system set up for the encryption. 
> >
> We have approx 1000 machines and 5000 user accounts and have pgp installed.
> I can't think of any reason not to have it installed, and lots of good
> reasons for having it installed.

"Me too," except the numbers are higher.

I would think that you would worry more about your users getting a false
sense of security from storing secret keys on a large multiuser system
than about being held liable for naughty PGP-encrypted traffic. I don't 
see how you could be held liable anyway. How is PGP that much different 
from allowing your users to set a password on their account? It makes it 
harder for root to invade their privacy, but in general, we have very 
stringent requirements that must be satisfied before we'll read user 
directories or mail.

-rich

Hello,

On Mon, 30 Oct 1995, Rich Graves wrote:

> On Mon, 30 Oct 1995, Doug Hughes wrote:
> 
> I would think that you would worry more about your users getting a false
> sense of security from storing secret keys on a large multiuser system
> than about being held liable for naughty PGP-encrypted traffic. I don't 
> see how you could be held liable anyway. How is PGP that much different 
> from allowing your users to set a password on their account? It makes it 
> harder for root to invade their privacy, but in general, we have very 
> stringent requirements that must be satisfied before we'll read user 
> directories or mail.

  As a student I am concerned with the false security, and that was 
mentioned while we were talking (today).  As to liability, it is 
important that no one can come back and hold the school liable.  Once the 
messages can be encrypted then it is harder to read the messages, but not 
impossible, unless the students keep the key on a disk, and just ftp it 
into the account everytime.  The fact is that that won't be the rule, so 
the admin can still read messages, but there will need to be clear-cut 
reasons for them to do that (IMOHO).  I am curious what requirements must 
be met.  I guess there are more schools that allow this than I expected 
<g>.  Well thanx for replying.  Take care and have fun.

James Black
black@suntan.eng.usf.edu

According to rumor, Doug Hughes said:
> >  Since you deal with security issues maybe you can help me to learn 
> >about some issues with encryption.  I am talking with one of the 
> >administration people about putting PGP on the system for everyone to 
> >use, but there are issues for them (the admin) as they might be liable, 
> >even if they can't read the e-mail.  What other legal considerations 
> >should be evaluated?
> >  Is there any large organizations (like any other universities) that 
> >allow their students to use PGP, and have the system in place to make it 
> >easier for the students?  If it is offered here I might be the one to add 
> >to the mail program (pine) that is generally used to transparently use 
> >PGP, which is what I mean by having a system set up for the encryption. 
> >  Thanx for any help.  Take care and have fun.
> >
> >James Black
> >black@suntan.eng.usf.edu
> >
> >
> We have approx 1000 machines and 5000 user accounts and have pgp installed.
> I can't think of any reason not to have it installed, and lots of good
> reasons for having it installed.

We currently have PGP installed on our 2 central email servers that
have approximatly 20,000 users. We haven't integrated it at this
point into Pine, etc mostly due to time and resources. 

I don't know why inability to read e-mail would cause liability,
and moving 2 million messages a week, I don't think that anyone
could be expected to know what users are sending. We only respond
to complaints.

-- 
Kevin Prigge                        |  Holes in whats left of my reason, 
CIS Consultant                      |  holes in the knees of my blues,
Computer & Information Services     |  odds against me been increasin' 
email: klp@cis.umn.edu              |  but I'll pull through...

One important thing to note in an academic environment is that if you 
have foreign students who are on non-green card visas, you may need to 
get an export licence if they can access the server. I expect you'll 
probably get the licence without too much hassle, and you're unlikely to 
be indicted for this, but it's something to be aware of.

Simon
----
(defun modexpt (x y n)  "computes (x^y) mod n"
  (cond ((= y 0) 1) 
	((= y 1) (mod x n))
	((evenp y) (mod (expt (modexpt x (/ y 2) n) 2) n))
	(t (mod (* x (modexpt x (1- y) n)) n))))

Simon writes:
> I may swap RC4 for DES; they're both public domain, but RC4 is simpler. 

Er, at last report RSADSI was still claiming RC4 as a trade secret, in spite
of the posting of the (convincing) alleged RC4.

-Futplex <futplex@pseudonym.com>