Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 20 Mar 2024 16:48:11 +0100
From: Solar Designer <solar@...nwall.com>
To: yescrypt@...ts.openwall.com
Subject: Re: yescrypt && mmap(,,,,MAP_HUGETLB) && oom-kill

Hello Matthias,

On Wed, Mar 20, 2024 at 07:00:14AM +0100, Matthias Apitz wrote:
> Thanks for your kind reply. As background: each of these application
> server run for a webbased user application which decrypts the patron PIN
> on login, i.e. yescrypt is carried out once at login. It seems now that
> the stress test execution called maybe in parallel such logins and in
> any case on very underpowered machine with only 3 GByte of memory.
> Normal production server have 32++ GByte of memory.

It sounds like normally login attempts are very infrequent.  So you
might not actually face this problem in production, unless there's
occasionally too large a number of concurrent login attempts, which is
something I recommend to guard against anyway.

> Said that, and as you say "you use yescrypt settings such that 1+ GiB",
> and as the strace shows that yescrypt is asking for 1075838976 bytes
> which is more than 1 GByte:
> 
> printf "0x%02x\n" 1075838976
> 0x40200000
> 
> where can the to be used memory be configured?

The amount of memory needed to compute a hash is a consequence of the
yescrypt settings encoded along with the hash.  So you can't change it
for the hashes you already have (except at the moment when you also have
the plaintext password and can re-hash, such as right upon a user's
successful log in).

For newly set passwords, I guess you probably configure it via
libxcrypt's crypt_gensalt*() function, where for yescrypt the "count"
parameter is in the range of 1 to 11.  The value 11 results in 1 GiB
memory usage like you observe.  It also provides the maximum (out of the
options available via that API) defense against offline attacks, so it's
not wasted memory, but it is a cost.

If you can afford 11 on your production servers and with actual and
anticipated login attempt rate, you may want to continue using it.  If
you can't afford that, you may choose a value in the range of 5 to 10.
These use a base-2 logarithmic scale, so e.g. 5 corresponds to 16 MiB.

Some of this is described in "man 5 crypt" and "man crypt_gensalt" on a
system with libxcrypt fully installed (the libxcrypt-devel subpackage on
Red Hat'ish systems, hopefully similar on yours).

I hope this helps.

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.