Hi,
Just some minor thoughts ...
Am 14.01.2018 um 18:18 schrieb Milan Broz:
Hi,
On 01/14/2018 02:21 AM, curve25519@xxxxxxxxxxx wrote:
Hi everyone,
3. Why does cryptsetup luksFormat allow at max 1048576kb (~1GB) of
memory usage for Argon2? This seems incredibly low compared to the
parameter choice recommendations from the Argon2 RFC draft. Even if you
don't use those as defaults, why would you ever set an upper limit which
is way below the recommendations?
This is very good question. It was my decision to internally limit it until
we are sure how Argon2 behaves. It was introduced before the physical-memory
limits and perhaps should be increased now.
My major concern here is maintenance - there is a lot of systems that just will
not have >1GB memory available. Unfortunately, in reality we see that Linux systems
kill the process here (OOM) instead of returning -ENOMEM, so we cannot even print any
useful messages. People will complain.
I would also expect some strange process limits that various container or systemd
services (and discussion with people developing these is not something I really enjoy TBH).
I bet they are very insightful - Anyway, so basicly there is no safe and
sane way, to find if there's enough (physical) mem for cryptsetup's
purpose. Then (IMHO) setting sensible default and max is unavoidable.
I know it limits the Argon2 use and I plan to increase it. Perhaps we should make
it configure time option.
And then, configured with one system in mind and used on another system,
this becomes a pitfall. Adding extra options gives choice, I welcome
this, but I don't see how this will help with the actual problem.
I am not sure how the parameters in RFC draft were calculated, but IMO they are not
usable in general with many of systems today.
But you are right, this is something we should change.
Agreed, of course a solid mechanismn to capture the (available) size of
physical memory would be the better way, but I fear this won'T be easy
to do.
4. Similar to the memory setting the thread count seems to be capped at
the number of processor cores, even tough the IRTF Argon Draft paper
explicitly uses twice the amount of cores in ALL examples on parameter
choice. Again, this might be acceptable as a default, but why is it a
hard limit? Even if there is a good reason to do so (I can't imagine
one), why is the user input silently ignored instead of throwing an
error as with the memory setting?
The reason is similar to previous one - we set limits to be sane and if it works,
we can slightly slow down it later.
The user input should not be ignored if you have enough CPUs.
(And I do not think it is good idea to use twice many parallel cost as physical
CPUs, this will our bencmark calculate something completely different on systems
where it has enough CPU and were it causes thread switch craziness.)
When core really means corethen 2 * #cores would be reasonable for
hyperthreaded cores. But again, that would be with a specific
configuration in mind, IMHO there's no gain going way beyond the number
of physical cores, when they are not hyperthreaded.
Also it will behave differently on different architectures (for example CPU
in Power systems is completely virtualized).
True indeed.
So the truly answer: these were sane defaults I set, perhaps they are wrong and need
to be updated. Just we need more people to use it to be sure we did not break anything.
Maybe I am just too careful, dunno.
No, I don't think you are too careful. But that'S just my POV.
11. The default numbers for --pbkdf-memory compared with the
defaults/minimums claimed on this list (e.g. 131072 kB vs 128MB) don't
match up, which seems to indicate Kibibytes, and Mebibytes were meant.
However kilobytes is used in the manpage and output. Could you enlighten
me if the base unit is actually kB or KiB?
Every time I use SI term kibibytes, someone start to scream :-)
Honestly, the IEC/SI bin-prefix recommendations sound awfully indeed, no
wonder people tend to scream :-D.
I think all printd numbers are in 2^x (1024) and not SI units (10^x), so only
unit description is inconsistent. We should unify it in text.
When it comes to base 2 adressing, sizes with decimal prefixes are in
general rather unuseful. There's a reason JEDEC accepts kilo with 2^10
as a prefix, while SI and IEC get snotty about it.
But let's not start a flamewar on this, would not lead anywhere anyhow.
Let's rather define what is meat by KB (or whatever prefix/term should
be used) and then match all text up with it.
Thanks!
Milan
Regards
-Sven
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
