Thank you for the explanation!
On Mon, 4 Oct 2021, 07:25 Milan Broz, <gmazyland@xxxxxxxxx> wrote:
On 04/10/2021 00:30, Dmitry Dmitry wrote:
> Hi,
>
> I am wondering if there are objective reasons for such conservative ***upper** **hard** limits* for Argon?
>
> } else if (!strcmp(kdf, "argon2i") || !strcmp(kdf, "argon2id")) {
> limits->max_iterations = UINT32_MAX;
> limits->max_memory = 4*1024*1024; /* 4GiB */
> limits->max_parallel = 4;
> }
>
> (well, apart from UINT32_MAX, which makes sense, kind of)
>
> Just to reiterate, I am not talking about minimum values, or default values. The question is about *upper limits*.
The memory limit is because LUKS2 format should be multiplatform - you should be able to open
container created on 64bit machine on old 32bit (where you have limit per process; of course it will take longer).
Moreover, higher limits causes very often OOM killer action and workarounds did not work
in reality (there were reports for cryptsetup killing the machine by triggering OOM;
such report have the exactly opposite effect on using encryption - people will not trust it if
it kills machine on open, or see Google search full of such reports.... so the lower limit is sometimes better.)
I think this is slightly improving, but still overallocating does not work for memory-hard algorithms.
The thread limit is more artificial - primary target was laptop where you can expect quadcore.
(And my minimal "model" configuration for LUKS2 (with defaults) was Raspberry Pi with 1G memory.)
And because we rely on embedded Argon lib, I just set high limits it very conservatively.
Once the Argon is implemented in OpenSSL (my former colleague still working on it; it need to bring
full threading support there - patches exists already).
Once that ahppens, I think we need to increase the limit here - but only after checking that threads
are really adding some protection - my guess is that with many threads we hit some cache flushing issues.)
(Using OpenSSL code will also improve performance of Argon as it introduces optimized implementations
for more platforms as we default to slow non-optimized implementation on some platforms.
TBH, I expected that happens several years ago...)
(Also there is problem with parallel LUKS devices activation, but it is another story.)
> I was personally thinking about using ~32 threads and ~128GiB of RAM as KDF parameters...
Do not do that. As Arno said, much more important is strong passphrase here.
The memory-hard KDF is another layer for security, but current limits are good enough to prevent
easy brute-force.
(Search for master thesis "Argon2 security margin for disk encryption passwords" for some cost attack
numbers we tried to calculate.)
Milan
p.s.
Saying that as someone who introduced memory-hard KDF to LUKS and fighting for it since 2015... :-)
_______________________________________________ dm-crypt mailing list -- dm-crypt@xxxxxxxx To unsubscribe send an email to dm-crypt-leave@xxxxxxxx
