recently I had a look at the capabilities of the Java keytool to create PKCS#12 containers with a protected private key. According to the standard a private key is protected using a PKCS#8 shrouded key bag applying a PKCS#5 password-based encryption. I could not find any restrictions on the applicable algorithms in the PKCS#5 standard. However, it includes specifcations of some supported algorithms which more or less seem to be far from state of the art. Having a look at the popular implementations of openssl and Java keytool, it seems that the accepted default in practice is using PBEWithSHA1AndDESede. Since Triple-DES uses small keys and SHA-1 has a bad smell from other use-cases, I'm interested in using a more modern pbe-algorithm based on AES.

This led me to the Java JDK supporting algorithm identifiers like PBEWithHmacSHA256AndAES_256. While this sounds promising in practice, I was not able to find any specification or standard defining these algorithms properly.

So my question is: Where can I find the specification that defines these new algorithms and identifiers as an extension to PKCS#5? Did I miss something important in the specifications?

Thank you!

  • What about PBKDF1? Have you checked RFC 2898? One of it's parameter is the used hash algorithm.
    – Robert
    Aug 25, 2021 at 17:56
  • TripleDES doesn't use small keys (168 would be plenty if strength matched size) and SHA1 or even MD5 is safe in an iterated PBKDF, but: all PBEwithHmac{anyFIPS180hash}and{manyciphers} are PBES2-using-PBKDF2 in PKCS5v2 up; see RFC8018 6.2 and 5.2, referenced primitives in appendices B.1 and B.2, and parameter syntaxes in appendix A.2 and A.4. @Robert: PBKDF1 (and PBES1) does not use HMAC. Aug 26, 2021 at 0:03
  • PS: I assume you know about this recent Java change (8u301, 11.0.12, 12 up) Aug 26, 2021 at 0:16
  • @dave_thompson_085 Thanks, RFC8018 is the solution. I concentrated on RFC2898 and neither noticed that it is obsoleted nor did I find it by keyword search. Regarding TDES and SHA-1 I know what you mean but I didn't think it was that relevant for my question. So I wasn't very precise regarding my motivation. Of course TDES keysize is not equivalent to its security strength due to meet in the middle attack and SHA-1 issues mainly are about collision resistance and speed of a single application. But sometimes enterprise policies aren't that precise so it could be better to avoid attention.
    – moritz1895
    Aug 26, 2021 at 7:24


You must log in to answer this question.

Browse other questions tagged .