On 5.5 key agreement

Hi all, I have some questions and comments on section 5.5, Key Agreement. 

1. The keysize in the example is 80, while in the keying material
calculation example later on it appears (to me) to be specified as 40,
specifically: 
  SHA-256 ( Example:Block/AlgorithmZZ%01foo40 )
is this a small typo or did I misread?

2. The draft specifies a specific method for generating the keying material
from the shared secret sequence ZZ generated by the AgreementMethod, using
DigestAlg. I think that it is better to remove this specific method and
instead declare that the AgreementMethod is responsible to generate the
number of bits specified to it as a <KeySize> parameter (or given to it
otherwise). Let me explain why. 

The keying material really needs to be a pseudo-random sequence. Generation
of a pseudo-random sequence is an important and non-trivial cryptographic
decision. The spec defines a specific method, namely 

Keying Material = KM(1) | KM(2) | ...

where "|" is byte stream concatenation and

   KM(counter) = DigestAlg ( EncryptionAlg | ZZ | counter | Nonce | KeySize
).

This is a particular construction of a pseudo-random generator from a
DigestAlg function. My first and simplest concern is that the construction
clearly requires the DigestAlg function to have properties which are not
necessarily required from digest (hash) functions, namely that the output of
it is pseudo-random. Unfortunately I'm not sure even if there is a simple
definition of what is required here... 

Just to make my argument clear, notice that the particular construction uses
a one byte (octet?) counter; this means that the maximal value must be 255.
I don't really consider this a problem in practice (in fact in practice ZZ
is usually longer than the required keying material!), but this illustrates
a limitation of this particular construction. 

There have been many works on constructions for pseudo-random generators. So
we could add here a `PseudoRandomGeneratorMethod` to specify it instead of
`hard coding` a function as done now. However I think this is not necessary,
esp. as in practice ZZ is usually longer than the required keying material. 

My proposed solution, as I indicated above, is simply to have this aspect
covered by the AgreementMethod and removed from the spec. 

Best regards, 
Amir Herzberg
CTO, NewGenPay Inc.  
http://www.newgenpay.com/Amir/Herzberg.htm
SMS (urgent only!): _subject_ of email to aherzberg@walla.co.il

Received on Thursday, 30 August 2001 05:58:43 UTC