W3C home > Mailing lists > Public > xml-encryption@w3.org > August 2001

Re: On 5.5 key agreement

From: merlin <merlin@baltimore.ie>
Date: Thu, 30 Aug 2001 11:41:29 +0100
To: Amir Herzberg <AMIR@newgenpay.com>
Cc: "Xml Encrypt (E-mail)" <xml-encryption@w3.org>
Message-Id: <20010830104129.D86A243BCE@yog-sothoth.ie.baltimore.com>

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


>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,
>  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.  
>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.
Received on Thursday, 30 August 2001 06:42:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:13:04 UTC