[dm-crypt] Argon2 limits choice

[dm-crypt] Argon2 limits choice

[Dmitry Dmitry]

[-- Attachment #1.1: Type: text/plain, Size: 686 bytes --]

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*.

P.S.
I was personally thinking about using ~32 threads and ~128GiB of RAM as KDF
parameters...


-- 
Dmitry
*Sent from my gmail*
GPG/PGP Key fingerprint = 1670 0E8A 4AEC 179D 326F  BECE 8B33 360D 8717 9711

[-- Attachment #1.2: Type: text/html, Size: 1336 bytes --]

[-- Attachment #2: Type: text/plain, Size: 147 bytes --]

_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de

[dm-crypt] Re: Argon2 limits choice

[Arno Wagner]

Hi,

I do not think these limits are "conservative".
You gain very little by raising them. Better just 
use a good passphrase.

Regards,
Arno

On Mon, Oct 04, 2021 at 00:30:13 CEST, 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.
>    P.S.
>    I was personally thinking about using ~32 threads and ~128GiB of RAM as
>    KDF parameters...
>    --
>    Dmitry
>    Sent from my gmail
>    GPG/PGP Key fingerprint = 1670 0E8A 4AEC 179D 326F  BECE 8B33 360D 8717
>    9711

> _______________________________________________
> dm-crypt mailing list -- dm-crypt@saout.de
> To unsubscribe send an email to dm-crypt-leave@saout.de


-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier
_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de

[dm-crypt] Re: Argon2 limits choice

[Milan Broz]

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@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de

[dm-crypt] Re: Argon2 limits choice

[Dmitry Dmitry]

[-- Attachment #1.1: Type: text/plain, Size: 2995 bytes --]

Thank you for the explanation!

On Mon, 4 Oct 2021, 07:25 Milan Broz, <gmazyland@gmail.com> 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... :-)
>

[-- Attachment #1.2: Type: text/html, Size: 3505 bytes --]

[-- Attachment #2: Type: text/plain, Size: 147 bytes --]

_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de