You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Doing some "all combinations" testing for a CA tool that included export to various PEM flavours, I ran into an inconsistency in the BC encrypted PEM export for (non RSA/EC) private keys.
Short story:
If you export a (non RSA or EC) private key (e.g. EDDSA) using a MiscPEMGenerator with a PEMEncryptor provided, it encodes a PRIVATE KEY block containing the PrivateKeyInfo structure, then encrypts the contents using the RFC 1421 "traditional" encryption.
On import via a PEMParser, this is detected as an unencrypted PKCS8 encoded private key entry, which then fails to decode in various entertaining ways since the key data is encrypted.
Given it's unlikely that the "traditional" PEM encoding will ever be updated to support newer key types like EDDSA and XDH (openssl 3.0 stoically refuses to produce a traditional PEM encoding of EDDSA keys), I can't see this is as a bug (i.e. there's no point actually support traditional encrypted variants of these keys), but I wonder if we could tighten up the implementation a bit to clarify that.
e.g. in MiscPEMGenerator could simply disallow a PRIVATE KEY export with a PEMEncryptor and PrivateKeyParser could potentially sanity check for the traditional encryption PEM headers (although if the first change was made, this would be an unlikely occurrence).
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Doing some "all combinations" testing for a CA tool that included export to various PEM flavours, I ran into an inconsistency in the BC encrypted PEM export for (non RSA/EC) private keys.
Short story:
MiscPEMGenerator
with aPEMEncryptor
provided, it encodes aPRIVATE KEY
block containing thePrivateKeyInfo
structure, then encrypts the contents using the RFC 1421 "traditional" encryption.PEMParser
, this is detected as an unencrypted PKCS8 encoded private key entry, which then fails to decode in various entertaining ways since the key data is encrypted.Given it's unlikely that the "traditional" PEM encoding will ever be updated to support newer key types like EDDSA and XDH (openssl 3.0 stoically refuses to produce a traditional PEM encoding of EDDSA keys), I can't see this is as a bug (i.e. there's no point actually support traditional encrypted variants of these keys), but I wonder if we could tighten up the implementation a bit to clarify that.
e.g. in
MiscPEMGenerator
could simply disallow aPRIVATE KEY
export with aPEMEncryptor
andPrivateKeyParser
could potentially sanity check for the traditional encryption PEM headers (although if the first change was made, this would be an unlikely occurrence).Beta Was this translation helpful? Give feedback.
All reactions