[dm-crypt] Several issues with cryptsetup 2.0.0

[dm-crypt] Several issues with cryptsetup 2.0.0

[curve25519]

Hi everyone,

I've played around with lots of the new stuff in cryptsetup 2.0 (except
AEAD) a little bit and encountered some weird behavior.

First of all I don't claim to be an expert and some of the behaviour I'm
going to describe may well be intended and/or my own fault. So please
excuse and correct any false assumptions I might have made.

For one I just wanted to play with it a bit, so I couldn't be bothered
to setup a working compile environment. So I used just used the Debian
experimental packages and the dependencies which are required in newer
versions than were already installed on the up-to-date Ubuntu 16.04 test
machine.

That's why I'd be rather happy if someone with a properly compiled and
working trunk version could (in)validate my findings.

Some of the dodgy behaviour might be because of this, but certainly not
all of it.

A short description of the underlying system (idling the whole time) and
the partitioning scheme:
- Athlon X2 6000+ (2 cores @ 3000MHz); 8GB of RAM
- 4k aligned gpt partition created with parted:
   sudo parted --align optimal /dev/sdd
   in parted:
     - create GPT partition table with "mklabel gpt"
        - create partition of maximum size with minimal free space at
beginning and end for alignment: "mkpart primary 0% 100%"
        - check if alignment of the partition we just created is
correct: "align-check optimal 1"
        - exit parted with "quit"

But first I have a question related to the mailing list:
How is it possible that the dm-crypt mailing list web interace and admin
panel can't be accessed via a secure TLS or at least some broken old
SSL connection? As in: can somebody please fix this?


The following comments refer to varitions of this command, but I
verified most of my findings by using only minimal options in addition
to those which seemed to have caused the issues:

"sudo cryptsetup luksFormat --type luks2  --verbose -q /dev/sdd1
--use-random --cipher aes-xts-plain64 --key-size 512 --hash sha512
--label DATA_crypt --subsystem "" --key-file keyfile"

The keyfile is just a bit of randomness from /de/urandom.

1. The output of "sudo luksDump /dev/sdd1" looks pretty ok, except that
Argon2i uses only the absolute minimum amount of RAM 131072 KiB/128MiB.
I read in one of Milans last posts on this list that --iteration-time
takes precedence over the memory setting. But as I used the default
options with 8GB of RAM I would have expected something way more in line
with the examples on parameter choice from the IRTF Argon Draft paper
(p. 12f).


2. luksFormat fails with -1 if aes-xts-essiv is used
This is probably expected, but I wanted to mention it anyways, as a poor
mans version of the ESSIV+random IV Milan mused about in
http://www.saout.de/pipermail/dm-crypt/2017-December/005778.html
Anyways: is there something I can do to use aes-xts-essiv as a slight
improvement over aes-xts-plain64? Or is this a stupid idea altogether?


The following comments refer to using  --pbkdf argon2id --iter-time 2500
--pbkdf-memory 1048576 --pbkdf-parallel 4 in additon to the settings
from the example above:


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?


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?


5. No matter if I explicitly force the use of Argon2i or Argon2id,
digests are still hardcoded to use pbkdf2.

6. However it seems much more concerning to me that only 1000 rounds of
pbkdf2 are applied to digests when --pbkdf-force-iterations is used
(independent of --pbkdf parameter).


7. I did encounter some silent failures in my first tests (luksFormat
finished fine, but device couldn't be mounted later) when using high
values for --iter-time (working: up to ~2500, definately failing:
5000-10000) or --pbkdf-force-iterations (working: up to ~4, definately
failing: 10, 12). However this was before I swapped the existing 6 GB of
normal RAM with 8GB of ECC RAM. This might either be explained by the
RAM beeing faulty or the lower amount. But as I couldn't verify this
anymore today, I won't bother you with more details on this.


Other comments:

8. From the ML:
I [Milan Broz] disagree with Argon2id as a default [decision by Argon2
authors]. [...] So final parameter set was decision after some test runs
on real systems.

Could you please elaborate on your decision? I couldn't notice any
performance issues with Argon2id in my (admittedly few) tests and I
personally don't feel that the default values should be so far removed
from the recommendations of the original authors who explicitly favor
Argon2id in an FDE scenario.

Together with the low defaults and especially the upper limits for
--pbkdf-memory and --pbkdf-parallel this doesn't really inspire
confidence. At the very least the reasoning which lead to the choice of
those defaults requires a coherent explanation in the man page.

The upper limits are a mystery to me tough and make me feel patronized.
Even if choosing too big values would make cryptsetup crash this would
at least be the consequence of a free decision of a (hopefully) informed
user. Nobody prevents me from rm -rf / either.


9. On luksDump output format:
- "Time:" below PBKDF algorithm seems to match the PBKDF iterations
instead of --iter-time...this should probably be renamed. This only
applies to Argon2, it's already called Iterations when using PBKDF2.


10. This is obviously a minor nitpick but it seems cryptsetup benchmark
still uses the 800ms default which afair was bumped up to 2000 as OOM
killer prevention. It would be nice if the default values were also used
for the benchmark.


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?


Kind regards


curve25519

Re: [dm-crypt] Several issues with cryptsetup 2.0.0

[Jordan Glover]

>1. The output of "sudo luksDump /dev/sdd1" looks pretty ok, except that
> Argon2i uses only the absolute minimum amount of RAM 131072 KiB/128MiB.
> I read in one of Milans last posts on this list that --iteration-time
> takes precedence over the memory setting. But as I used the default
> options with 8GB of RAM I would have expected something way more in line
> with the examples on parameter choice from the IRTF Argon Draft paper
> (p. 12f).

​Debian experimental is currently at 2.0.0~rc1 version released on 1st November.
There were some new commits after that, https://anonscm.debian.org/cgit/pkg-cryptsetup/cryptsetup.git/log/ i.e. default min memory cost for Argon was changed from 128MB to 1GB.
You may want to build and test updated version from debian git.

Jordan

Re: [dm-crypt] Several issues with cryptsetup 2.0.0

[Arno Wagner]

On Sun, Jan 14, 2018 at 02:21:52 CET, curve25519@mailbox.org wrote:
> Hi everyone,
... 
> But first I have a question related to the mailing list:
> How is it possible that the dm-crypt mailing list web interace and admin
> panel can't be accessed via a secure TLS or at least some broken old
> SSL connection? As in: can somebody please fix this?

You seem to be the first one that cares. As the admin 
functionality is accessible via email, do you actually 
have a credible attack model for this?

Regards,
Arno

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

Re: [dm-crypt] Several issues with cryptsetup 2.0.0

[curve25519]

>> But first I have a question related to the mailing list:
>> How is it possible that the dm-crypt mailing list web interace and admin
>> panel can't be accessed via a secure TLS or at least some broken old
>> SSL connection? As in: can somebody please fix this?
> 
> You seem to be the first one that cares. As the admin 
> functionality is accessible via email, do you actually 
> have a credible attack model for this?
> 
From a user perspective it's impossible to know if the admin actually
uses this feature. Additionally password reuse by the users could very
well be abused by a passive listener in a privilidged network position.

Considering the content and target audience password reuse may not be
extremely common, but the kind of parties interested in people
subscribing to such lists leads me to believe that at the very least
passive listening has to be assumed.

Another imo valid reason would be the impression it makes on others. How
can we as the security community credibly teach others and ask of them
to use Letsencrypt, encrypt their harddrives, protect their user data
etc. and then hold ourselves to such low standards?

Please don't take this as an attack, I just wanted to point something
out which appeared borderline ironic from an outsider perspective
considering the community and the amount of work needed to fix it.

Kind regards

Curve

Re: [dm-crypt] Several issues with cryptsetup 2.0.0

[Milan Broz]

Hi,

thanks for asking and please sent whatever another questions you have here.

We need feedback, and seems the community is the only way how to get it.

(After 3rd reject of a paper I am sure that storage conferences are
not good place to expect any relevant feedback on storage security.
Seem only performance matters these days in reviews...
ok, it is just my problem 8-]

Answers in text below, and because some of the decisions are based on my
pragmatic approach, I am of course open to change some LUKS2 defaults
if it makes sense and we have enough arguments.

The whole goal of LUKS2 is to go the way of improving security,
there will be mistakes and some corrections later, but seems nobody else
care, so I tried to push it forward...


And we should collect these comments somewhere (maybe FAQ), I plan to do it
but I am currently completely saturated by other things... sorry for that.


On 01/14/2018 02:21 AM, curve25519@mailbox.org wrote:
> Hi everyone,
 
> But first I have a question related to the mailing list:
> How is it possible that the dm-crypt mailing list web interace and admin
> panel can't be accessed via a secure TLS or at least some broken old
> SSL connection? As in: can somebody please fix this?

Jana Saout is running this. Jana, please do you have a plan to fix it?

I do not want to move the list to another provider, it worked here for years,
but the TLS issue is really concerning me as well (and I am not admin).

...

> 1. The output of "sudo luksDump /dev/sdd1" looks pretty ok, except that
> Argon2i uses only the absolute minimum amount of RAM 131072 KiB/128MiB.
> I read in one of Milans last posts on this list that --iteration-time
> takes precedence over the memory setting. But as I used the default
> options with 8GB of RAM I would have expected something way more in line
> with the examples on parameter choice from the IRTF Argon Draft paper
> (p. 12f).

Do you use system optimized libargon2 or cryptsetup compiled-in fallback
(that uses not optimized reference code)? Optimized code behaves better,
but it is not available in many distros (it is available in Debian).

But really, that is how the benchmark is designed, it prefers time.
If you want to really use more memory here, you have to increase the time cost as well...

But definitely expect that the benchmarks will have some tweaks once we have
more data how it behaves on users systems.

> 2. luksFormat fails with -1 if aes-xts-essiv is used
> This is probably expected, but I wanted to mention it anyways, as a poor
> mans version of the ESSIV+random IV Milan mused about in
> http://www.saout.de/pipermail/dm-crypt/2017-December/005778.html
> Anyways: is there something I can do to use aes-xts-essiv as a slight
> improvement over aes-xts-plain64? Or is this a stupid idea altogether?

Do not use ESSIV with XTS. Never.

First, there is a nasty bug with LUKS2 and ESSIV I just post info about.

But mainly using ESSIV instead of plain64 for XTS mode only slow downs
IV generation, it has no effect to security. The IV is just encrypted,
but because XTS run it through encryption block internally anyway,
I do not see any reason to use ESSIV here.

For the integrity-protected (authenticated) modes it is something different,
but I would prefer to go with random IV with modes that allows 128bit nonces/IVs in future.

 
> The following comments refer to using  --pbkdf argon2id --iter-time 2500
> --pbkdf-memory 1048576 --pbkdf-parallel 4 in additon to the settings
> from the example above:
> 
> 
> 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 know it limits the Argon2 use and I plan to increase it. Perhaps we should make
it configure time option.

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.

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

Also it will behave differently on different architectures (for example CPU
in Power systems is completely virtualized).

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.

> 5. No matter if I explicitly force the use of Argon2i or Argon2id,
> digests are still hardcoded to use pbkdf2.

Yes, and it is intentional. Using Argon in digest does not make any sense.

On input for PBKDF2 digest should be a random key, digest should only verify
that the key is correct and do not allow any brute force speed up.

Moreover, for brute-force search for volume key (for example is some flawed RNG is found)
attacker will not use digest comparison at all - he will try to decrypt one sector that contains
known plaintext (ext4 magic for example) and this will be always much faster than any digest check.

So we have possibility to upgrade digest algorithm in future for LUKS2, but I think
it really does not make any sense now. So I kept it compatible with LUKS1.


> 6. However it seems much more concerning to me that only 1000 rounds of
> pbkdf2 are applied to digests when --pbkdf-force-iterations is used
> (independent of --pbkdf parameter).

Yes, see above. This will not help attacker even if it has only 1 iteration.

The keyslot iterations matters. I used dynamic iteration count for keyslot later
(Clemens uses fixed 10 iteration in early LUKS headers) but because of attack mentioned
above (known sector plaintext decryption) it actually does not help anything.

More info about this attack is in the paper
Bossi, Visconti: "What Users Should Know About Full Disk Encryption Based on LUKS",
I think it should be available in some preprint for free.

> 7. I did encounter some silent failures in my first tests (luksFormat
> finished fine, but device couldn't be mounted later) when using high
> values for --iter-time (working: up to ~2500, definately failing:
> 5000-10000) or --pbkdf-force-iterations (working: up to ~4, definately
> failing: 10, 12). However this was before I swapped the existing 6 GB of
> normal RAM with 8GB of ECC RAM. This might either be explained by the
> RAM beeing faulty or the lower amount. But as I couldn't verify this
> anymore today, I won't bother you with more details on this.

Well, I need --debug log for these issues. But what you describe is strange,
if it was hw fault, then anything can happen...


> Other comments:
> 
> 8. From the ML:
> I [Milan Broz] disagree with Argon2id as a default [decision by Argon2
> authors]. [...] So final parameter set was decision after some test runs
> on real systems.
> 
> Could you please elaborate on your decision? I couldn't notice any
> performance issues with Argon2id in my (admittedly few) tests and I
> personally don't feel that the default values should be so far removed
> from the recommendations of the original authors who explicitly favor
> Argon2id in an FDE scenario.

This is just my (and some other people) opinion, but I am practitioner,
so I can be easily wrong.

The Argon2id was added after PHC ended because of some TMTO attacks
to Argon2i. Argon2d is data dependent, so it possible contains side-channels,
while Argon2i is data independent, but with possible memory-computation trade-offs.

So authors divided it 50/50 for Argon2id. I think that side channel attacks
are worse in LUKS context (imagine container opening some device watching it by another process).
To oversimplify it:
if attacker can use side channel to get the first half, we have only half cost for Argon2i,
that makes it is even worse.
So I decided to make default Argon2i, despite TMTO thing. (And it is configurable option.)
For more info see for example
 https://crypto.stackexchange.com/questions/48935/why-use-argon2i-or-argon2d-if-argon2id-exists

Actually I asked what we should do on some cryptography workshop and the answer was,
that we should wait for some better memory-hard algorithm and that PHC should be re-run in fact.
That is not the option. I understand it, but we should be better prepare to change later than wait
- PBKDF2 is so perfectly optimized on GPUs that we have problem already now.

PBKDF in LUKS2 header can be later changed by cryptsetup-reencrypt tool without touching data
(resp. this function will be there soon) so we will have way how to change it later in-place.

> Together with the low defaults and especially the upper limits for
> --pbkdf-memory and --pbkdf-parallel this doesn't really inspire
> confidence. At the very least the reasoning which lead to the choice of
> those defaults requires a coherent explanation in the man page.

Man page is not good place to explain this. But I would welcome some advice,
if you have strong arguments why Argon2id should not be default, I am listening and we could
change it later.

> The upper limits are a mystery to me tough and make me feel patronized.
> Even if choosing too big values would make cryptsetup crash this would
> at least be the consequence of a free decision of a (hopefully) informed
> user. Nobody prevents me from rm -rf / either.

ok, I understand.
Anyway, thanks for this opinion, there seems to be really contradiction with
basic philosophy of cryptsetup (it will let you to use ECB if you want for example).

Maybe we should print just some warning and let user shoot in the foot.

> 9. On luksDump output format:
> - "Time:" below PBKDF algorithm seems to match the PBKDF iterations
> instead of --iter-time...this should probably be renamed. This only
> applies to Argon2, it's already called Iterations when using PBKDF2.

Current code should display "Time cost", from Argon2 libray we use:

@param t_cost Number of iterations

While is is number of iteration for Argon, it can be something different in later
added PBKDF, my intention was not name it for every algorithm separately (PBKDF2 is exception)
(the usability problem that we have already -i /--iteration CLI option for it...)

Not sure if it is worth to change it now, these fields are used in scripts
and change will break them.

> 10. This is obviously a minor nitpick but it seems cryptsetup benchmark
> still uses the 800ms default which afair was bumped up to 2000 as OOM
> killer prevention. It would be nice if the default values were also used
> for the benchmark.

Yes, it is wrong. There will be more such small fixes.

> 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 :-)

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.

Thanks!
Milan

Re: [dm-crypt] Several issues with cryptsetup 2.0.0

[Arno Wagner]

On Sun, Jan 14, 2018 at 18:18:42 CET, Milan Broz wrote:
> Hi,
... 
> And we should collect these comments somewhere (maybe FAQ), I plan to do it
> but I am currently completely saturated by other things... sorry for that.
...

Hi Milan,

I will definitely write a LUKS2 section in the FAQ and possibly 
later a new FAQ. But things have to stabilize first.

Regards,
Arno

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

Re: [dm-crypt] Several issues with cryptsetup 2.0.0

[Sven Eschenberg]

Hi,

Just some minor thoughts ...

Am 14.01.2018 um 18:18 schrieb Milan Broz:
> Hi,
> 
> On 01/14/2018 02:21 AM, curve25519@mailbox.org 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

Re: [dm-crypt] Several issues with cryptsetup 2.0.0

[curve25519]

>> 1. The output of "sudo luksDump /dev/sdd1" looks pretty ok, except 
>> that Argon2i uses only the absolute minimum amount of RAM 131072 
>> KiB/128MiB. I read in one of Milans last posts on this list that 
>> --iteration-time takes precedence over the memory setting. But as
>> I used the default options with 8GB of RAM I would have expected 
>> something way more in line with the examples on parameter choice 
>> from the IRTF Argon Draft paper (p. 12f).
> 
> Debian experimental is currently at 2.0.0~rc1 version released on
> 1st November. There were some new commits after that, 
> https://anonscm.debian.org/cgit/pkg-cryptsetup/cryptsetup.git/log/ 
> i.e. default min memory cost for Argon was changed from 128MB to 1GB.
> You may want to build and test updated version from debian git.


Yes, I knew the default was updated to 1GB and 2000ms respectively
(which I mentioned later on).

I also know in our Argon2 implementation time cost takes precedence over
memory cost.  What struck me as weird is that while 1GB appears to be
the new considered safe minimum, it's also the default as well as the
maximum. I would have expected this parameter to be dynamically
calculated similar to the iterations setting.

But admittedly I could have phrased this better. Nonetheless, thank you
for your contribution.

Kind regards

Curve