![]() |
|
Message-ID: <20240607184459.GA12998@openwall.com> Date: Fri, 7 Jun 2024 20:44:59 +0200 From: Solar Designer <solar@...nwall.com> To: yescrypt@...ts.openwall.com Subject: Re: yescrypt && mmap(,,,,MAP_HUGETLB) && oom-kill Matthias, On Wed, Jun 05, 2024 at 07:03:21AM +0200, Matthias Apitz wrote: > I'm assuming (even if the man pages of crypt_gensalt(3), crypt(3) and > crypt(5) don't say this exactly, that a higher value for count gives > "better" or more "secure" hashes. What is the exact benefit of a higher > count value? Maybe even this should be explained somewhere. I hope I > haven't overlooked it. My latest revision of libxcrypt's crypt(5) ("man 5 crypt") page says: Most of the hashing methods are also deliberately engineered to be slow; they use many iterations of an underlying cryptographic primitive to in- crease the cost of each guess. The newer hashing methods allow the num- ber of iterations to be adjusted, using the "processing cost" parameter to crypt_gensalt(3). For memory-hard hashing methods such as yescrypt, this parameter also adjusts the amount of memory needed to compute a hash. Having this configurable makes it possible to keep password guess- ing attacks against the hashes slow and costly as hardware improves. So the intent is "to increase the cost of each guess." When we increase not only time but also memory usage, we reduce the number of guesses that can be tested concurrently on specialized hardware or (to a limited extent) also on GPUs. So the cost per guess increases (or number of guesses per cost unit decreases) as (up to) square of libxcrypt's count setting for yescrypt. In other words, count=11 hashes are between ~64 and ~4096 times more costly or slower to crack than count=5 ones by (eventual) GPU implementations or specialized hardware. Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.