linux-ipsec: "parity is for farmers"

An accidental spinoff of the discussion on syntax (on which, more soon) has been the realization that there has been no meeting of minds between Pluto and the kernel as to who handles parity in DES keys, and how.

Background: a DES key is really 56 bits, but just to be difficult, the DES spec says that it's written as 64 bits with a parity bit in each byte
(odd parity in the low bit, if you must know :-)). Worse, the IPSEC work
picked up this stupid convention unchanged.

The mechanics of random-key generation are not badly affected. Just pretending that the DES key is really 64 random bits incurs no great cost, and in fact that is what Pluto currently does.

The problem is whether anybody along the way through IKE, ESP, and DES should actually fix up the parity bits, and if so, who? This also ties in slightly to the issue of checking for weak keys (in the generic sense, including semi-weak keys etc.), since the usual weak-key tables have the parity bits fixed. (Pluto now simply does not do weak-key checking).

The DES FIPS itself does not address the issue of whether correct parity is mandatory. Nor does the ESP draft. The ciph-cbc-02 draft, which seems to be the current relevant one for 3DES, mumbles about how implementations "must consider" the parity bits but does not explain what that is supposed to mean. The des-expiv-01 draft says that the parity bits must be fixed, but does not say by who, and what should happen if they're not -- I *think* this is meant mostly as a preliminary to weak-key checking.

I find reasonably clear indications in assorted drafts that the two sides of IKE negotiate fully-random 64-bit keys, so at least we don't seem to have an IKE-level interoperability problem here -- any parity fixing happens after the IKE exchange and is purely a local matter.

I note that made-up DES keys for hand keying typically do not have parity set properly, and that requiring that they be fixed before entry would be annoying... although a utility could be provided to help.

There are two good ways of tackling this, I think. One is to say that the originator of the key is responsible for supplying good keys -- with parity set, weak keys excluded, etc. -- although that the user of the key
(i.e., the kernel) might want to check this just to be sure. The other is
to say that the user of the key is responsible for turning a supplied key into a good one, and rejecting it if this is not possible.

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

One argument in favor of supplier responsibility is that it avoids the need for back-and-forth interaction between supplier and user, because the key is known to be good before the supplier hands it to the user.

One argument in favor of user responsibility is that it centralizes the knowledge of what needs to be done (what keys are weak, how parity is defined, etc.) and leaves everybody else simply dealing with random bits.

A related argument is that there can be more than one user involved. In particular, both the kernel and Pluto have to know how to do DES, because the encryption used for IKE is currently done within Pluto. This line of argument is weakened considerably by the observation that both can just use the same library (as indeed they do, although at the moment they've got independent copies of it -- I'll try to fix that for the next release).

It seems to me that the best approach is to declare this parity nonsense to be a stupid mistake whose impact we will confine to the smallest possible area. That means that key suppliers (Pluto and the hand-keying interface) will ignore the issue and supply 64 random bits, and any key users (the kernel, and Pluto's internal encryption) who need the parity bits fixed for their own internal reasons must fix them.

Similarly, the primary onus for weak-key rejection should be on the key users, to minimize the possibility of unintentional disagreements due to uncoordinated updates. Key suppliers who need to be sure they've got a good key should consult the intended key user rather than duplicating the information about how to determine the goodness of keys.

(Note "the intended key user", not "a key user". This means that if Pluto
wants a key which the kernel will definitely accept, Pluto should confirm its acceptability by consulting the kernel about it. This minimizes any disruption which might arise if Pluto's internal cipher code somehow comes to disagree with the kernel's. I think that consultation needs doing anyway, because not all of the ciphers will exist within Pluto, and Pluto should not assume that kernel-only ciphers never have weak keys.)

                                                          Henry Spencer
                                                       henry@spsystems.net
                                                     (henry@zoo.toronto.edu)