[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
key processing for manual and dynamic SA
Hi,
I have an 'interop' issue for keying material that I would like to hear some
views on:
1) Manual Mode 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?).
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 problems with asking for 64bits are :
a) either the use is expected to get the parity bit right
b) or the management code applies the parity automatically
a) is too much to ask and b) changes the key.
For the sake of interop, I think we need to decide on a common way of
presenting keying material at the UI. If one end of the link takes 56bits,
and the other takes 64bits, converting between the two over the 'phone
is not straightforward!
For example, if one end gets a 56bit key at the UI of:
23fe45de56ab78
Given low-order-bit parity and auto-parity at the 64bit UI end, this key
would
be 'communicated' as:
22f790bae4b4acf0 (or something like that!).
It sounds easiest (to me), if we could agree on using the non-parity version
of
the required key, where parity is an issue. Then I can easier 'communicate'
manual keys without worrying about parity.
2) Dynamic Mode SA
I am assuming the following process for generated keying material:
Using DES as an example again, I strip 64bits from the generated keying
material, apply parity bit logic and check the weak-key listings (again,
this had
better happen the same way on both systems).
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?
Again, the process needs to be standard.
Thanks, Steve.
Follow-Ups: