[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Another slicing and dicing issue.
In DOI-07 the Key Length attribute does not state what
units (bits or octets) it represents.
Assuming it's bits (for the following argument), when
someone negotiates a key length that's not a multiple
of 8 (say for CAST or Blowfish), when the key material
that IKE provides is sliced and diced, should the
amount of key-material for non-octet sized keys be
rounded to next octet boundary?
(Whew!) For example, I negotiate a 123 bit key length
for CAST with HMAC-SHA1. When slicing the key material
up, should CAST be 128 bits (while dropping the 5 least
significant bits) and the remainder for HMAC-SHA1 or
123 bits for CAST and the rest (appropriately shifted
to compensate for the 5 bits in the middle octet not
used by CAST)?
I think the former would be simplier (when slicing and
dicing, and therefore when generating key material,
each slice needs to rounds to the octet boundary) and
should be specified in the cipher document.
--
Matt Thomas Internet: matt.thomas@altavista-software.com
Internet Locksmith WWW URL: <coming eventually>
AltaVista Internet Software Disclaimer: This message reflects my own
Littleton, MA warped views, etc.
References: