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 126.96.36.199.188.8.131.52.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.
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?
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.
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.
Marked the bug WONTFIX.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.