Before posting this question about ed25519, I learned that there are two formats for storing a private ed25519 key,

  • PKCS#8
  • OpenSSH Format

Why did OpenSSH create its own format rather than use PKCS#8? Please include any relevant citations from mailing list discussions or the like.

  • 6
    Those are far from the only formats. There's a JWK form in rfc8037, a PKCS11 form in PKCS11 3.0, a PGP form defined by GnuPG but not standardized (registered) AFAICT, and undoubtedly more. Closer to home PuTTY uses its PPK format for all (SSH) keytypes including ed25519, and it wouldn't surprise me if ssh.com/Tectia uses their own format as well. Jan 18 at 2:49

1 Answer 1


Because the lead developer felt a new format was necessary for Ed25519 support within OpenSSH:

Ed25519 is not supported in OpenSSL, so we used a public-domain implementation (from SUPERCOP). Unfortunately this means that we could not use the PEM key format that we have used for RSA, DSA and ECDSA keys until now, so Markus made a new one.

The new key format looks a lot like the old one (a blob of base64 encoded key material with beginning and end markers), but offers quite a bit more protection to the key from offline attacks against the passphrase. The new format uses a bcrypt-based key derivation function that makes is brute-force attacks against stolen private keys far slower.

So far, it is only required for Ed25519 keys but it is possible to request it for other key types too by adding the '-o' flag to ssh-keygen when generating a key. It's also possible to convert existing keys to the new format by specifying the -o flag when changing the passphrase ('-p').

The PEM handling code is nasty and OpenSSH relies on OpenSSL to do most of that heavy lifting. OpenSSH would have had to roll its own PEM code to support that, so the lead developer (Markus Friedl) decided to introduce a new format that not only was backwards compatible with PEM and supported Ed25519, but also came with some other features.

This is not without precedent: Putty implements the PPK format and is quite opinionated about it.

Here are a few links to the technical details of the new format:

  • 2
    When you say ed25519 is not supported in OpenSSL, I'm confused, isn't it though? What does this do openssl genpkey -algorithm ed25519 -out private.pem? Jan 17 at 15:41
  • 20
    @EvanCarroll The quote is from December 2013. ED25519 support appeared in OpenSSL in September 2018, 5 years too late to solve the problem OpenSSH was facing
    – Ben Voigt
    Jan 17 at 16:56
  • 1
    The format is basically undocumented. The documentation you've linked to is not official and the first one which I've read had some mistakes in it when I looked at it a while ago. But that's the easy part anyway. The hard part is when the private key is encrypted. The encryption scheme seems to have no documentation at all except the source code itself. When I looked at the "bcrypt-based" KDF I found that it was similar but different from bcrypt (at least that's how it looked when I gave up). Existing bcrypt code could not be reused. Roll your own, fine, but source code is not documentation. Jan 19 at 2:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .