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

Re: comments on draft 03 of SKIP

>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.