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