New key type (ed25519) and private key format

Aris Adamantiadis aris at badcode.be
Sun Dec 8 02:00:35 EST 2013


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




More information about the openssh-unix-dev mailing list