[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: key processing for manual and dynamic SA

> As an example, I need to prompt the UI for a DES session key for an ESP SA.
> DES only actually requires a 56bit stream to do the calculation - although
> this 56bits is expanded to include parity-bits (probably for historic
> reasons - pre parity memory?).

The reason for the parity bits, apparently, was to help protect "sealed
box" crypto engines from attacks based on inducing one-bit errors by
running them in extreme conditions (heat, voltage, electrical noise,
etc.).  It turns out that if you can induce such errors in the key, even
randomly, then cryptanalysis of DES becomes quick and easy.  With the
parity bits, the crypto hardware can detect and reject keys with one-bit
errors, which makes this attack vastly more difficult. 

> Should the UI ask for 56bits (14 hexadecimal digits) and then expand with 
> parity bits and check against the weak-key list,  or should the UI ask for
> 64bits.

The user interface is not specified in the RFCs/drafts.  However, there is
overwhelming consensus among implementors that it is easiest to use a
64-bit UI, and have the interface to the crypto engine fix the parity bits
as needed.  Note that the IKE specs for DES specifically call for IKE to
supply 64 random bits, so such an interface already has to be present. 

> For the sake of interop,  I think we need to decide on a common way of 
> presenting keying material at the UI...

We already have, de facto, although it's not exactly well documented.  The
test keys used at the interoperability workshops invariably are 64 bits
with no attempt to supply correct parity.

> It sounds easiest (to me), if we could agree on using the non-parity version
> of the required key...

This would probably have been the best solution -- supply 56 bits and let
the implementations provide any necessary error protection -- but it's a
lost battle now. 

> 2) Dynamic Mode SA ...
> Question:  What do I do if the constructed 64bit key is weak?  Do I:
> a) reject the establishment
> b) move on one byte in the keying material and try again
> c) move on one-block (64bits) and try again?

It takes some searching to find any mention of this.  The ciph-cbc draft
appears to say that when you discover you have been given a weak key, you
reject it and require that a new SA be generated.  For the poorly-named
"ISAKMP SA" (the communication path between the IKE daemons), the
isakmp-oakley draft says that the first N non-weak bytes are used, which
would seem to imply moving on one byte and trying again.

> Again, the process needs to be standard.

Given how rare weak keys are, it is quite possible that we will never know
whether most implementations interoperate in this area.  Other forms of
rare error leading to communications failure will probably be more common.

                                                          Henry Spencer
                                                       henry@spsystems.net
                                                     (henry@zoo.toronto.edu)
Follow-Ups: References: