Le 7/12/13 07:40, Damien Miller a ?crit : > Hi, > > 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. > Hi Damien, Markus, I do not understand why Ed25519 not being in Openssl couldn't let you use the pem-like format described in RFC4716. In fact that would have been a good occasion of getting rid of the complex PEM decoder from libcrypto and implement your own (with relevant subset of ASN.1 decoding). Maybe you did not want something as complex as PEM. When designing your new format, did you take in consideration some of the criticism over the existing PEM format to improve it ? One of the functionalities I could see useful would be to embed the public key authenticated but not encrypted into the key file. That way, it is always possible to determine if a key is useful before asking the passphrase to the user (current workaround needs the actual encrypted key and a cleartext public key file, which can be confusing). The key format of putty could have been a good candidate. Some food for thoughts on [1]. Did you publish some specs already ? I cannot find it yet on openssh.org. Regards and good week-end, Aris [1] http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/key-formats-natively.html
