[Bug libc/16522] On sha* password generation, select hash rounds to achieve given computation time based on hash computation speed

["jasa.david at gmail dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=16522

--- Comment #3 from David JaÅa <jasa.david at gmail dot com> ---
(In reply to Carlos O'Donell from comment #1)
> ...
> Agreed. Do you have a patch to make this work?

I prefer to leave code writing to people who can actually do it. :)

(In reply to Rich Felker from comment #2)
> I'm a bit concerned about this proposal. What happens when your hashes are
> shared between multiple machines (e.g. a very fast server and multiple thin
> clients) 

Very fast serve means these days a lot of cores, doesn't it? If so, then the
performance gap is still big, but manageable. I'd still prefer "reasonably
secure by default even if it causes noticeable nuisance on worst 10 % of
devices" over "it works everywhere b

> or when you're setting up a VE image for cpu-limited hosting or a
> system image to run on a lower-end machine using a higher-end one? 

Aren't you using ssh keys for such use cases anyway? What is their complexity
(time to verify login)?

> I think
> it's flawed to assume that the machine on which hashes will later be
> validated is as capable as the machine on which the original hashes are
> generated. Whether this is an acceptable flaw (i.e. whether the benefit is
> worth dealing with the side effects of this flaw) is a matter for discussion.

Consider partial disk encryption: on my system, cryptsetup uses PBKDF2 with
155-160k iterations to achieve 1s verification time. When I set maximum rounds
count for crypt/sha512 of 10M, the verification takes 16 s, yielding 650k
rounds to achieve 1 s running time, so 5k rounds should take 5/650 = 1/130 =
0.007 s. If the crypt/sha512 to pbkdf2 running time ratio is constant and users
choose the same password for disk encryption and user account verification, the
latter forms an avenue for side-channel attack to the former, reducing its
effective strenght by 2^7 bits...

IMO good target would be to have bearable performance on Raspberry Pi.
Cryptsetup FAQ [1] states:
> Note: Passphrase iteration is determined by cryptsetup depending on CPU
> power. On a slow device, this may be lower than you want. I recently
> benchmarked this on a Raspberry Pi and it came out at about 1/15 of the
> iteration count for a typical PC. If security is paramount, you may want to
> increase the time spent in iteration, at the cost of a slower unlock later.

So e.g. choosing 0.3 s target time on recent computer (= 195k rounds on my
system) would result in 4.5 s verification time on Raspberry Pi. Slow but
bearable and _way_ more secure than default 5k.

[1] http://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions#2._Setup

-- 
You are receiving this mail because:
You are on the CC list for the bug.