Re: linux-ipsec: Re: Elliptic-curves...

| From: John Gilmore <gnu@toad.com>
|
| > What should be implemented is feeding the keying material back to

I think that it is reasonable to think of entropy and keying bits separately.

• entropy bits cost. They cost time in the D-H process. Besides the obvious cost, it adds to the danger of denial of service.
• The key length is often much longer than the entropy without the entropy being the "weak link"

This presumes that the PRF successfully spreads the entropy throughout the keying material. I trust that it does (I haven't got much choice).

If the PRF isn't good enough, ISAKMP/Oakley is in trouble since the keying material always goes through it, even if it doesn't need stretching.

If I understand correctly, and if the PRF is good, I think that more entropy can be delivered using the PRF feedback! What I mean is, without feedback, the amount of entropy in the keying material is limited by the size of the PRF output. Since the feedback process re-uses the exponential, if the exponential has more entropy than fit in the first output, new entropy will be delivered in the new output.

| > One barrier is the lack of entropy (bits of randomness) created in the

This is an excellent question -- the MODP groups don't seem to have enough entropy to satsify minimal recommendations in the draft (if I remember correctly). I wonder if they should just be dropped.

Scroeppel/Orman/O'Malley points out that EC2N is a lot faster at generating entropy than MODP. The paper also explains why one should care.

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.freeswan.org Links 1998-fall 1998-spring 1998-summer 1998-winter 1999-winter announce briefs bugs design freeswan-list hipsec ietf-sectest users users-admin Request more information about Pantek

| > draft-ietf-ipsec-ciph-3des-expiv-00.txt says 3 * 64 bits == 24 bytes

That would make sense, but it isn't what was intended, so we would have an interoperability problem. Besides, if you smear the entropy throughout the keying material, nothing is lost by wasting bits of keying material.

| Actually the ciph-3des I-D says different things in two places. In

I think that this is clearly stating what you don't want. Maybe not stating it well.

| I think it should be fixed to say in all places that DES-EDE3 needs

One issue confusing everything is weak keys. It seems that the job of generating non-weak keys is given to "key-agreement layer". These weak keys are listed with parity bits.

If the key-agreement layer doesn't know about parity, it will incorrectly pass on some keys that will become weak (when parity is corrected).

If we move in your direction, this ought to change -- at least the parity bits would have to be removed from the catalogue of weak keys.

Do you need more help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.freeswan.org Links 1998-fall 1998-spring 1998-summer 1998-winter 1999-winter announce briefs bugs design freeswan-list hipsec ietf-sectest users users-admin Request more information about Pantek

I think that weak key issues make a mess of separating the key-agreement layer from the encryption layer.

Hugh Redelmeier
hugh@mimosa.com voice: +1 416 482-8253 Received on Thu Mar 5 16:42:14 1998