RE: Key Derivation Functions for DH key agreement

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 03:00:45 UTC