@agl @filippo I am trying to persuade Oracle not to add half-assed support for PKCS#8 password-encrypted private keys to their draft PEM encoder API. I notice that Go has not implemented such support yet either.
Is support planned for Go? And if so, do you have thoughts on what the API should look like?
My preference is if they are going to implement it, to not allow a user-specified password at all but instead to generate a secure one and set the iteration count to 1.
@neilmadden @filippo Filippo would have a much better sense of the demand (or not) for this in Go. I never implemented it because it seems like a bit of a trap and I don’t recall people shouting enough for it.
If you lose an encrypted private key, but it’s only encrypted with a human-set password, are you really not going to consider it compromised?
And if you have a way to transfer a random passphrase securely, can’t you just transfer the private key itself that way? They’re not big these days!
So yes: random passphrase > human-set here, but still a questionable facility in general.
@agl @filippo Thanks, makes sense. I agree re compromise - even with large iteration counts, most password-based encryption with human-chosen passwords barely reaches even (single) DES security levels.
I did suggest they only support reading such PEMs, not creating them - they are still quite popular with some old-school CAs I think and OpenSSL’s CLI. At the moment, Oracle’s preview implementation just YOLOs it with 4096-iteration PBKDF2...
@neilmadden pretty much what @agl said: not many people ever asked, so we didn't implement it.
The one exception is for x/crypto/ssh, before OpenSSH switched to their own encrypted format.
People seem to really like human-password-protected SSH keys, which I fully don't understand the threat model of for the same reasons as above. I think they are just uncomfortable with the "important file" not being more protected than a regular file.
Neil Madden
Adam Langley
Filippo Valsorda