Re: On 5.5 key agreement

Hi Amir,

The KM function is a standard mechanism used by ANSI 9.42 (and others)
and from there by IETF documents (e.g., RFC 2631); although, as pointed
out by Yongge Wang, we have the shared info ordered in a nonstandard
manner.

Merlin

r/AMIR@newgenpay.com/2001.08.30/12:58:08
>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
>


-----------------------------------------------------------------------------
Baltimore Technologies plc will not be liable for direct,  special,  indirect 
or consequential  damages  arising  from  alteration of  the contents of this
message by a third party or as a result of any virus being passed on.

In addition, certain Marketing collateral may be added from time to time to
promote Baltimore Technologies products, services, Global e-Security or
appearance at trade shows and conferences.

This footnote confirms that this email message has been swept by
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.
   http://www.baltimore.com

Received on Thursday, 30 August 2001 06:42:19 UTC