Re: Argon2 limits choice

--===============4617000017759317232==
Content-Type: multipart/alternative; boundary="000000000000d6f8cc05cd810873"

--000000000000d6f8cc05cd810873
Content-Type: text/plain; charset="UTF-8"

Thank you for the explanation!

On Mon, 4 Oct 2021, 07:25 Milan Broz, <[email protected]> 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... :-)
>

--000000000000d6f8cc05cd810873
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div dir=3D"auto">Thank you for the explanation!<br></div=
></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr"=
>On Mon, 4 Oct 2021, 07:25 Milan Broz, &lt;<a href=3D"mailto:gmazyland@gmai=
l.com">[email protected]</a>&gt; wrote:<br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">On 04/10/2021 00:30, Dmitry Dmitry wrote:<br>
&gt; Hi,<br>
&gt; <br>
&gt; I am wondering if there are objective reasons for such conservative **=
*upper** **hard** limits* for Argon?<br>
&gt; <br>
&gt; } else if (!strcmp(kdf, &quot;argon2i&quot;) || !strcmp(kdf, &quot;arg=
on2id&quot;)) {<br>
&gt; =C2=A0 =C2=A0limits-&gt;max_iterations =3D UINT32_MAX;<br>
&gt; =C2=A0 =C2=A0limits-&gt;max_memory =C2=A0 =C2=A0 =3D 4*1024*1024; /* 4=
GiB */<br>
&gt; =C2=A0 =C2=A0limits-&gt;max_parallel =C2=A0 =3D 4;<br>
&gt; }<br>
&gt; <br>
&gt; (well, apart from UINT32_MAX, which makes sense, kind of)<br>
&gt; <br>
&gt; Just to reiterate, I am not talking about minimum values, or default v=
alues. The question is about *upper limits*.<br>
<br>
The memory limit is because LUKS2 format should be multiplatform - you shou=
ld be able to open<br>
container created on 64bit machine on old 32bit (where you have limit per p=
rocess; of course it will take longer).<br>
<br>
Moreover, higher limits causes very often OOM killer action and workarounds=
 did not work<br>
in reality (there were reports for cryptsetup killing the machine by trigge=
ring OOM;<br>
such report have the exactly opposite effect on using encryption - people w=
ill not trust it if<br>
it kills machine on open, or see Google search full of such reports.... so =
the lower limit is sometimes better.)<br>
I think this is slightly improving, but still overallocating does not work =
for memory-hard algorithms.<br>
<br>
<br>
The thread limit is more artificial - primary target was laptop where you c=
an expect quadcore.<br>
(And my minimal &quot;model&quot; configuration for LUKS2 (with defaults) w=
as Raspberry Pi with 1G memory.)<br>
<br>
And because we rely on embedded Argon lib, I just set high limits it very c=
onservatively.<br>
Once the Argon is implemented in OpenSSL (my former colleague still working=
 on it; it need to bring<br>
full threading support there - patches exists already).<br>
Once that ahppens, I think we need to increase the limit here - but only af=
ter checking that threads<br>
are really adding some protection - my guess is that with many threads we h=
it some cache flushing issues.)<br>
<br>
(Using OpenSSL code will also improve performance of Argon as it introduces=
 optimized implementations<br>
for more platforms as we default to slow non-optimized implementation on so=
me platforms.<br>
TBH, I expected that happens several years ago...)<br>
<br>
(Also there is problem with parallel LUKS devices activation, but it is ano=
ther story.)<br>
<br>
&gt; I was personally thinking about using ~32 threads and ~128GiB of RAM a=
s KDF parameters...<br>
<br>
Do not do that. As Arno said, much more important is strong passphrase here=
.<br>
<br>
The memory-hard KDF is another layer for security, but current limits are g=
ood enough to prevent<br>
easy brute-force.<br>
(Search for master thesis &quot;Argon2 security margin for disk encryption =
passwords&quot; for some cost attack<br>
numbers we tried to calculate.)<br>
<br>
Milan<br>
p.s.<br>
Saying that as someone who introduced memory-hard KDF to LUKS and fighting =
for it since 2015... :-)<br>
</blockquote></div>

--000000000000d6f8cc05cd810873--

--===============4617000017759317232==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
dm-crypt mailing list -- [email protected]
To unsubscribe send an email to [email protected]

--===============4617000017759317232==--