0

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!

moritz1895
  • 3
  • 2
  • What about PBKDF1? Have you checked RFC 2898? One of it's parameter is the used hash algorithm. – Robert Aug 25 '21 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. – dave_thompson_085 Aug 26 '21 at 00:03
  • PS: I assume you know about this [recent](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8202590) Java [change](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8076190) (8u301, 11.0.12, 12 up) – dave_thompson_085 Aug 26 '21 at 00: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 '21 at 07:24

0 Answers0