Time for key stretching in encrypted private keys?
Damien Miller
djm at mindrot.org
Fri May 24 13:32:16 EST 2013
On Thu, 23 May 2013, alexs wrote:
> In 0.9.7 the private key encryption was switched from 3DES to AES,
> (https://bugzilla.mindrot.org/show_bug.cgi?id=1550) the motivation for this
> being that 128-bits of security is better than the 112 or so you get from
> 3DES these days. Interestingly that bug is about upgrading to AES-256, but
> we ended up with AES-128. Presumably due to the Solaris crippling?
Right :(
> However ssh-keygen still uses a relatively weak KDF of MD5(IV[:8] . PWORD)
> which makes dictionary attacks quite feasible and means you need a much
> longer password to mitigate them. Seems like it might be useful if OpenSSH
> at least had the option of using an encoding with some decent key
> stretching to me. Is there any good reason not to, and to not have it as
> the default?
>
> OpenSSH seems quite happy to accept PKCS8 keys with PBKDF2 currently, it
> just doesn't generate them. You just need to do it yourself e.g.
> http://martin.kleppmann.com/ssh-keys.html The keys generated in that
> article are also 3DES unfortunately but that's only because it's the
> default cipher here.
Ideally OpenSSL would make some PEM extension that uses a good KDF.
I don't include PBKDF2 with an inner hash of SHA* in this set :)
Barring that We'll probably roll a simple key format that uses bcrypt
as a KDF and includes some space to optionally bundle certificates.
-d
More information about the openssh-unix-dev
mailing list