Time for key stretching in encrypted private keys?

[alexs]

On Fri, 24 May 2013 13:32:16 +1000 (EST), Damien Miller <djm at mindrot.org>
wrote:
> On Thu, 23 May 2013, alexs wrote:
>> 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.
> 

It sounds like you have plans already :) Any idea what sort of time scale
this might occur on?

PBKDF2 seems like it has a better chance at being backward compatible with
existing installs, even if it's a few factors of 10 worse than [sb]crypt et
al. I assume the 3DES -> AES change didn't break backwards compat,
presumably with bcrypt you'll have to delay setting it as the default for a
few releases first?