Re: Key Derivation Functions for DH key agreement

Hi Amir,

I don't actually think such things change very often.

Highly decomposed
composite protoocol messages orthogonally specifying everying under
the sun resulting in more verbose messages and complex software
modularization that frequently ends up being wasted for many
years...and usually, as in this case, there actually wouldn't be
any problem escaping when you finally did want to change it.

At your request I've already moved the keying material
generation algorithm from being quasi-globally specified to being
specified at the same level as the DH algorithm. How about if we just
change the URI for that to be
http://www.w3.org/2001/04/xmlenc#dh-kmgen1 or something, like we have
http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p. I would prefer fewer
lengthly W3C style URI rather than more.

This design decisions have nothing to do with whether anything is
hardwired, just with what the syntax change is to change the
algorithm.

Donald

From:  "Amir Herzberg" <AMIR@newgenpay.com>
Date:  Tue, 16 Oct 2001 09:00:20 +0200
Message-ID:  <078EE8822DCFD411AAA1000629D56ADC162E96@imp01.newgenpay.com>
To:  <xml-encryption@w3.org>
Content-Transfer-Encoding:  8bit

>I've already commented that the `hard wiring` of a specific algorithm
>for key derivation in the spec is not good practice. By now, it is
>widely understood that cryptographic algorithms should not be hard-wired
>into standards, but specified with an identifier, allowing their
>replacement if and when users feel the need. Of course, standards should
>specify at least one mandatory algorithm for interoperability. 
>
>XML DSIG follows this for most cryptographic algorithms, with the
>exception of key derivation. I can't quite understand this. Key
>derivation is a very important cryptographic operation and often the
>source of weakness. Furthermore, the specific technique used, while
>indeed following (roughly) an existing standard, is not necessarily the
>best, and may be found problematic (broken) in the future.
>The security of this construction seems to be based on heuristic
>properties of the `hashing` function  
>H(), rather than on any well-defined properties for which candidate
>crypto hashing functions are seriously cryptoanalysed. I'm not saying I
>have any clue to how one can break this construction with any widely
>used hashing algorithm such as SHA - but I do caution that I believe I
>can build counter example hashing functions that fulfill all the common
>definitions for a secure hash function, yet cause this construction to
>be insecure. 
>
>To summarize: I again strongly suggest that the key derivation method be
>made another one of the algorithms which the spec identifies, with the
>specific one in the spec (or the ANSI equivalent) as mandatory and
>default. 
>
>Best regards, 
>Amir Herzberg
>Please use my new e-mail: Amir.Herzberg@newmail.net
>
>> On Tuesday 31 July 2001 10:45, Yongge Wang wrote:
>> > Hi,
>> > I might missed some discussions on this issue. The 
>> following comments
>> > are for the "WG Working Draft 26 June 2001".
>> >
>> > In Section 5.5: Key Agreement, there are two functions:
>> >
>> > Keying Material = KM(1) | KM(2) | ...
>> > KM(counter)=DigestAlg(EncryptionAlg | ZZ | counter | Nonce |
>KeySize)
>> >
>> > In ANSI X9.42, ANSI X9.63, and IETF S/MIME, the first function
>"Keying
>> > Material = KM(1) | KM(2) | ..."
>> > is the same. However, the second function "KM(counter)" is a little
>> > different from the ANSI and IETF
>> > one: KM(counter) = H(ZZ||counter||SharedInfo)
>> > This difference is enough to produce incompatibility with ANSI/IETF
>
> 
>

Received on Tuesday, 16 October 2001 10:18:45 UTC