The ANSI documents are not on line, but there is a short description of the
KDF in section 3.8 of:
http://csrc.nist.gov/encryption/kms/summary-x9-63.pdf
Is this the one you're proposing?
Paul
-----Original Message-----
From: William Whyte [mailto:WWhyte(_at_)baltimore(_dot_)com]
Sent: Monday, February 19, 2001 1:58 AM
To: Russ Housley; stephen(_dot_)farrell(_at_)baltimore(_dot_)ie
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: RE: WG Last Call:draft-ietf-smime-rcek-01.txt
William suggests byte reversal instead, which seems ok from both
perspectives.
Okay. So, since bitwise-NOT and bit-reversal both have shortcomings, what
are you going to use as the mandatory to implement transform?
As Stephen says, I've suggested byte reversal. In fact, what I
would most like to see as the mandatory to implement transform
is X9.63 key derivation (the key derivation function referred
to as KDF2 in IEEE P1363a), but to the best of my knowledge there's
no stable, freely-available description of this that we could
reference. If anyone fancied writing it up as an RFC that'd
be very nice...
(I have to say I'm uncomfortable with the hacky use of PKCS#5
here. But at least PKCS#5 is referenceable).
Cheers,
William
----------------------------------------------------------------------------
-
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