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

> What should be implemented is feeding the keying material back to
> itself (in the PRF) to generate more bits (not more entropy).

Bad idea -- I think *all* the key bits should be random. Not derived from some smaller number of random bits.

> One barrier is the lack of entropy (bits of randomness) created in the
> Diffie Hellman key exchange. The obvious way to improve this is to
> implement stronger groups. The obvious ones to implement are the
> Oakley groups 3 and 4.

Rich, you generated the groups used in Oakley. Why are there no MODP groups strong enough to generate enough key bits for 3DES w/HMAC? Can you generate us one or two?

> draft-ietf-ipsec-ciph-3des-expiv-00.txt says 3 * 64 bits == 24 bytes
> of keying material are needed (it confusingly talks about 168 bits,
> but that is net of parity bits; they must be supplied, but are ignored
> -- thus they consume keying material, I think).

I think the right answer is that if parity bits are going to be checked on randomly-derived data, the parity bits should be *generated from* the data and should not use up entropy. I.e. for a DES key, you should use 56 bits of entropy, and generate the extra 8 parity bits based on those original 56. For a 3DES key, triple these numbers.

Actually the ciph-3des I-D says different things in two places. In section 3 it says, "The secret DES-EDE3 key shared between the communicating parties is effectively 168-bits long. This key consists of three independent 56-bit quantities used by the DES algorithm. Each of the three 56-bit sub-keys is stored as a 64-bit (8 byte) quantity, with the least significant bit of each byte used as a parity bit." But in section 5 it says "The key is taken from the first 192 bits of the keying material, where the first 64 bits represent the first key, the next 64 bits represent the second key and the last 64 bits represent the third key."

I think it should be fixed to say in all places that DES-EDE3 needs 168 bits (21 bytes) of keying material. If any implementation needs "parity" bits on its 56-bit keys, then it should locally generate parity bits for its keying material. Clearly the key-agreement layer can't do this before handing the keying material to 3DES, since it doesn't know exactly what the low-level encryption algorithm (3DES) will need. Why this I-D mentions how keys are "stored" is a good question; isn't that a local matter?

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

The I-D says, "Implementations of this transform SHOULD take into consideration the parity bits when initially accepting a new set of keys." It's not clear what this means. Perhaps it means that if fed strings of completely random bits, it should reject 255 out of every 256 random strings that are fed to it, since they do not arrive with correct parity? I hope not. (Kerberos had a bug like this; it resulted in a 255-out-of-256 chance of sending data encrypted with a key of all zeroes, because a DES implementation had rejected the key-setting operation that preceded the encryption.)

        John Received on Thu Mar 5 05:27:14 1998