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

RE: key processing for manual and dynamic SA

Steven, 
I think this was discussed a long time ago (Detroit time frame?) and it
was decided that 64-bits of keying material would be used for DES, and
the code which received the 64-bits would modify the parity bits so each
byte has odd parity. 
If this is no longer true, I'd like to hear about it also!
-CJ

	-----Original Message-----
	From:	Stephen Waters [SMTP:Stephen.Waters@digital.com]
	Sent:	Friday, July 24, 1998 7:27 AM
	To:	ipsec@tis.com
	Subject:	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.