Hi Anthony, Thanks for your reply. I'm only going to comment on the password-based encryption in detail below because I think that's the most important thing.
I would urge you to actually look at real-world use-cases for PEMs (the vast majority of which are going to be configuring TLS/JSSE) and thinking carefully about whether this is really a good API design for those use-cases. Given that the primary stated goal in the JEP is ease of use, and the primary use-case is very likely to be TLS, I'd have thought being able to use the existing javax.net <http://javax.net/>.ssl.trustStore etc system properties with a PEM file would be a high requirement. Any kind of PEM-specific API is clearly going to have worse usability. > On 23 Apr 2026, at 17:52, Anthony Scarpino <[email protected]> > wrote: > > Hi Neil, > > Thanks for taking the time to provide some feedback. > > On 3/24/26 4:37 AM, Neil Madden wrote: > > Hi, > > > > I'd like to provide some feedback on the 2nd preview of PEM support > > (JEP-524) in the recently released OpenJDK 26. > > > > Firstly, thanks for adding this support, it's very welcome as someone who > > works with PEM files on a pretty much daily basis. However, I think the > > functionality and API still need some work. > > > > From a security point of view, I am hesitant about more support for > > password-based encryption in 2026. It's just not secure and shouldn't be > > encouraged. For example, OpenSSL 3.6.1 27 Jan 2026 (Library: OpenSSL 3.6.1 > > 27 Jan 2026) on my machine will happily accept completely insecure > > passwords and then sets the default iterations to just 2048. The > > implementation in the JDK appears to default to just 4096 iterations for > > similarly insecure passwords ('changeme'). Many openssl examples on the > > internet still suggest using -des3 to encrypt the key. But really, any > > kind of password-based encryption is woefully inadequate to protect > > private key material as I wrote about on https:// > > neilmadden.blog/2023/01/09/on-pbkdf2-iterations/ after the LastPass > > breach. 4096 iterations is completely useless for protecting any kind of > > long- term secret like a private key unless the password is already > > cryptographically-strong (in which case you don't need iterated hashing). > > This is outside the PEM API’s control; those values are determined by the > crypto provider and the user’s input. The PEM API is designed for simpler use > cases. For more advanced scenarios, the JEP introduces new > EncryptedPrivateKeyInfo.encrypt() methods that let callers provide a Key and > explicitly configure the encryption parameters. I think that's a bit of a cop-out to be honest. The reality is that most people will use PEMEncoder.withEncryption (with the provider default settings), which are woefully inadequate to protect long-term secrets like private keys. Most user-selected passwords have an estimated entropy of about 40 bits or less (https://en.wikipedia.org/wiki/Password_strength#Human-generated_passwords) and the default of 4096 iterations of PBKDF2 only adds the equivalent of about 12 bits, resulting in an effective key strength that is less than DES. Do you honestly think that is defensible? Even the OWASP guidance for PBKDF2 (600,000 iterations - https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html) is only equivalent to about 19 bits of entropy, while being incredibly slow in Java. What is the point of supporting encryption that can be cracked in a few hours? This is why e.g. Google's Tink library doesn't support password-encrypted keys at all, instead forcing either unencrypted files or use of a proper key management service. And hence why I suggested that any convenience method should generate a secure password itself rather than allowing the developer to specify one. If you are not going to take this seriously then you shouldn't provide support for encryption at all. Providing a convenience method that has extremely poor default security, and then saying that developers instead need to be experts in cryptography and manually select algorithms and parameters themselves is a strategy that has repeatedly led to vulnerabilities. I find this attitude entirely irresponsible, and demonstrates a lack of serious security consideration in this design. -- Neil
