On Tuesday 05 February 2008 12:35, Michael Rogers wrote:
> Matthew Toseland wrote:
> > NewPacketFormat assumes that we can generate as many keys as we want from
JFK
> > securely. Is this true? JFK uses an HMAC with 0, 1, or 2, to generate the
> > session key or the 2 internal keys it uses, but does not explicitly
document
> > the option to generate more keys by incrementing that number - and it
refers
> > to IKE key extension if you need more bits (it does *not* say increment
the
> > number and stick them together, as you might expect). Is it safe to do
what
> > we have planned, to get separate keys for each direction and in
> > NewPacketFormat for the IV key and HMAC key?
>
> Here's how Ferguson and Schneier do it in Practical Cryptography:
>
> K is the master key for the channel
>
> KeySendEnc = HASH (K || "Enc Alice to Bob")
> KeyRecEnd = HASH (K || "Enc Bob to Alice")
> KeySendAuth = HASH (K || "Auth Alice to Bob")
> KeyRecAuth = HASH (K || "Auth Bob to Alice")
>
> if (I am Bob) {
> swap (KeySendEnc, KeyRecEnc)
> swap (KeySendAuth, KeyRecAuth)
> }
>
> Chapter 8 of that book is really worth reading if you're starting work
> on NewPacketFormat.
JFK is:
Session key = H_<secret> { alice exponential, bob exponential, "2" }
K_a = H_<secret> { alice exponential, bob exponential, "1" }
K_e = H_<secret> { alice exponential, bob exponential, "2" }
Where K_a and K_e are temporary keys used in phase 3 and 4.
It's the same principle, it's just a question of whether it's safer to derive
further keys from the session key or from the secret key (= g^xy).
And no sadly there is no time to do that now, but it came up in discussions
with kryptos.
>
> Cheers,
> Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080205/0d4684da/attachment.pgp>
