[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: allocation of key material into keys
In message <199610282029.PAA03172@thunk.orchard.medford.ma.us>, Bill Sommerfeld writes:
> Here's a rephrase which I think is more precise. Let me know if this
> is not what you intended..
>
> I'd like to propose that the key management protocol
> specifications only be responsible for generating a "blob" of
> key material at least N bits long containing at least K bits of
> entropy. For obvious reasons, K <= N.
>
> Each transform would need to specify minimum values for K and
> N, and precisely how to transform a variable-length "blob"
> of key material of at least N bits into the session keys, initial
> sequence numbers, and other shared state it needs.
The problem with this is that it doesn't cover the problem of creating
*independent* keys for multiple transforms, which is the concern Hugo
raised. I suspect that everyone will define simple keying material functions
such that one could (for example) derive the HMAC-MD5 key from a cracked DES
key.
As has been discussed, this is a key management layer issue. I'd modify your
statement to include that somehow, the "blobs" handed to different
transforms or algorithms must be 'independent' (i.e. it's cryptographically
hard to derive one key from another). They can still be generated from the
same key exchange, as long as the key manager runs an intermediate step to
obscure the source keying material.
--
C. Harald Koch | Senior System Developer, Secure Computing Canada Ltd.
chk@border.com | 20 Toronto Street, Suite 400, Toronto ON M5C 2B8
+1 416 368 7157 (voice) | "Madness takes its toll. Please have exact change."
+1 416 368 7789 (fax) | -Karen Murphy <karenm@descartes.com>
Follow-Ups:
References: