627631 - enhance softoken to support Sun's peculiar MD5 PBE key derivation for (3)DES

Status: RESOLVED WONTFIX

(NSS :: Libraries, enhancement, P3)

Description

[Nelson Bolyard (seldom reads bugmail)]

Sun defined its own flavor of PKCS#5-like PBE which uses MD5 to derive three
DES keys and an IV from a password and a PBE salt, for subsequent used with 
3DES.  This PBE algorithm has been given the OID 1.3.6.1.4.1.42.2.19.1

The key derivation proceeds as follows:
The 8-byte salt is split in half.  If the two 4-byte halves are identical, 
then the first half is run through an endian-swapping function, like htonl
on a little-endian machine.  Of course this has no effect if the 4-byte 
half is of the form ABBA or CCCC (where A, B, and C are byte values).

Then the first half salt is combined with the password using PKCS#5 PBE for
the specified number of rounds to provide the first 16 bytes of key material, 
and the second half salt is combined with the password using PKCS#5 PBE for
the specified number of rounds to provide the second 16 bytes of material. 
The material is then partitioned and distributed as follows:  The first 24 
bytes are used as the first, second, and third DES keys, and the last 8 bytes are used as the IV.

For 2-key 3DES, the PBE key derivation is the same, except that the first 
key is also used as the third key, and the derived third key is discarded.

For single-key DES, the method is ordinary PKCS5 (IINM), combining the entire salt with the password, with MD5, producing a 16-byte result that is then 
partitioned into key and IV.

At this point, I'm looking for Bob or Wan-Teh to approve or reject in principle the project of adding this to softoken.

Comment 1

[Wan-Teh Chang]

If this can be implemented using the pk11wrap and cryptohi functions,
that will be ideal.  Is that possible?

Is there a PKCS #11 mechanism for this PBE?

Comment 2

[Robert Relyea]

My initial thought is if it's a PBE, it should happen in a pkcs #11, but since it uses PKCS #5 with some manipulation of the password, then it may be possible to use the PKCS #5 mechanism in the softoken and use some the generic key derive mechanisms to glue things together.

If this code is added to pk11pbe.c, the use of that pbe should be transparent to all users.

Maybe 3.13 should make one of it's goals the ejections of non-FIPS algorithms into a separate token that can be updated outside of FIPS validations. In that case, that would be the perfect place for this algorithm.

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

Bob & Wan-Teh,  Thanks for your replies, which I didn't see until now 
(no bugzilla bugmail for your comments).  

Ignoring "SSL Bypass", which is not in PK11wrap, is there any precedent for 
this, for manipulating key material directly in pk11wrap, outside of the 
token, in a non-FIPS way, when it could be just as easily done in the token, 
even for a non-FIPS algorithm?  (OK, there is HandUnwrap... :()

I'm trying to promote FIPS-compliant design of code that uses PKCS#11 modules,
emphasizing the need to keep all CSP inside the token, even (initially) for
non-FIPS algs so that the eventual switch to all FIPS algs and HSMs will be
seamless, rather than seen as a rewrite.

Comment 4

[Wan-Teh Chang]

Marked the bug WONTFIX.