[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on draft 03 of SKIP
Ashar:
At SPYRUS, we have always included MD5 within our commercial PCMCIA crypto
token, the LYNKS Privacy Card. We originally put the MD5 hash into the
card to support digital signature applications, and it would be a trivial
modification to use it for key update in the manner that I suggested in my
original note. In fact, we already have plans to add the X9.42 scheme once
the ANSI X9.F.1 committee comes to consensus on the remaining open
details.
I think the SKIP users and developers will be better served by the hash
approach.
Russ
______________________________ Reply Separator _________________________________
Subject: Re: comments on draft 03 of SKIP
Author: ashar@osmosys.incog.com (Ashar Aziz) at internet
Date: 11/13/95 11:45 AM
>From: "Housley, Russ" <housley@spyrus.com>
>
> The ANSI X9.F.1 committe is looking at a variant of Diffie-Hellman that may
> help. The shared secret is computed in the normal way. I guess SKIP calls
> that Kij.
>
> The ANSI X9.F.1 variant hashes the shared secret with randoms that are
> provided by each party and a counter. Each value of the counter yields a
> different traffic key. To support e-mail, a constant is used instead of a
> random for the recipient.
>
> For SKIP, constants could be used for both parties or they could be
> omitted. The idea of hashing Kij concatenated with a counter should be
> more efficient than the multiply associated with the current Kijn. Also,
> with the hash-based scheme you do not need Kij(n-1) to efficiently compute
> Kijn.
>
> To summarize the alternative:
>
> Kijn = hash (Kij || n)
>
Russ,
Thanks for your comments. In fact, an earlier draft of SKIP,
(and the SKIP paper we presented at INET '95) has precisely this
mechanism for computing Kijn. Also, this is the same Kijn scheme
that is used in SKIP when relying on manual Kij distribution.
I think that your suggestion has a lot of merit. As you note,
it doesn't require the (n-1)th value to be efficient.
Let me explain the reason why we went to the g^ijn scheme, instead of
the hash based scheme. This was to not pose an implementation burden on
smart cards vendors. It was problematic for some smart cards to implement
MD5 in the card (limited code space, etc.).
We figured that a simpler alternative would be to use the key-agreement
algorithm (in this case DH) to update the master key. Since a card has
to implement the key-agreement algorithm in any case, we thought it might
be easier to rely on the key-agreement algorithm for the Kijn calculation.
However, I am open to changing this mechanism to rely only
on a hash based approach, as you suggest. Let's keep
in mind that the tradeoff is that any smart card implementing
this will also have to implement the hash algorithm (e.g. MD5)
inside the smart card. If this is an acceptable tradeoff, (given
Spyrus's product line, you are especially qualified to give
feedback on this) and the rest of the WG concurs, then I will
modify the draft to reflect this. The other SKIP implementors
have also indicated that they prefer this approach as well.
Kind regards,
Ashar.