More UKM size in the SMIME Freeware Library v1.8

"Pawling, John" <[email protected]> Tue, 12 Dec 2000 13:55:18 -0500
Newsgroups gmane.ietf.sfl
Message-ID <[email protected]>
All,

Please note the additional change required to implement this fix.

=========================================== 
John Pawling, [email protected] 
Getronics Government Solutions, LLC 
===========================================

-----Original Message-----
From: Colestock, Robert
To: 'Ahmed Bhamjee '
Cc: Pawling, John
Sent: 12/12/2000 1:51 PM
Subject: FW: UKM size in the SMIME Freeware Library v1.8

Ahmed:

Since the 512 is a bit count, you must also modify the source in
sm_free3.cpp to divide by 8 for the random number call.  It ends up our
old value used 1024 bits (the parameter to the SMTI_Random(...) routine
takes a byte count).
in ./alg_libs/sm_free3/sm_free3.cpp
...
      SME(SMTI_Random(NULL, pUKM, SM_FREE_RA_SIZE/8));
...


Bob Colestock
VDA.
-----Original Message-----
From: Colestock, Robert 
Sent: Tuesday, December 12, 2000 12:41 PM
To: '[email protected]'; 'Ahmed Bhamjee '
Subject: RE: UKM size in the SMIME Freeware Library v1.8


Ahmed:

You are absolutely correct.  I had to dig up the rfc2631 specification
for DH to determine the actual UserKeyMaterial size.  128 byte length
works fine, but is not correct to the specification.  Thank you for
pointing this out.  If you wish to change your copy, simply update the
variable "SM_FREE_RA_SIZE" in ./alg_libs/sm_free3/sm_free3.h from 128 to
512 and re-build.  Our next release will have the updated size.  This
has been tested on ESDH operations and now produces the appropriate
sized PartyAInfo structures (only used for the wrap hash).

Thank you
Bob Colestock
VDA.

-----Original Message-----
From: Ahmed Bhamjee
To: [email protected]
Sent: 12/12/2000 6:18 AM
Subject: UKM size in the SMIME Freeware Library v1.8

I have been testing our product with the latest SFL version. More
specifically, I have performed tests using the Diffie-Hellman key
agreement
method. From the RFC (2631), the size of partyAInfo contained in the
OtherInfo sequence must be 512 bits in size. However, the SFL produces
keying material with partyAInfo set to 128 bytes. Should this not be 64
bytes? Perhaps I am missing something.

Thanks
Ahmed