[dm-crypt] Argon2id security margin estimate and LUKS2 usage

[dm-crypt] Argon2id security margin estimate and LUKS2 usage

[procmem]

Hi Milan, Whonix (privacy distro) maintainer here. We are researching
the best password advice to give to our users and while diceware is a
great improvement over the status quo, the recommendation by
cryptographers in light of quantum computing is to choose pass phrases
with a length equivalent to 256 bits because Grovers will halve the bit
length. This requires phrases to be 20 words long for 256 bits which is
excessive IMO and the reason we are looking at key-stretching for
shorter ones instead.

* What is the time/sec margin added to a password with Argon2id's best
parameters?

* Have Argon's parameters been tweaked in the LUKS implementation, to
account for the 2 public attacks? [0]

* Are more cryptanalytic attacks expected against it in the future or is
it extremely unlikely for progress against to be made? (For example
modern hashes like BLAKE2 or block ciphers like AES are pretty robust
with no notable attacks for some time)

* Can you please give an example of cryptsetup re-encrypt command that
upgrades an existing LUKS1 system to one that uses Argon with its max
settings?


CC/d our ML so users can benefit from your reply.


[0] https://en.wikipedia.org/wiki/Argon2#Cryptanalysis

Re: [dm-crypt] Argon2id security margin estimate and LUKS2 usage

[Arno Wagner]

On Mon, Aug 20, 2018 at 15:33:00 CEST, procmem wrote:
> Hi Milan, Whonix (privacy distro) maintainer here. We are researching
> the best password advice to give to our users and while diceware is a
> great improvement over the status quo, the recommendation by
> cryptographers in light of quantum computing is to choose pass phrases
> with a length equivalent to 256 bits because Grovers will halve the bit
> length. This requires phrases to be 20 words long for 256 bits which is
> excessive IMO and the reason we are looking at key-stretching for
> shorter ones instead.

This is completely irrelevant for key derivation. No QC
will be able to do a few 1000 iterations of KDF this century,
and actually it would need to reverse them. Also, the size of
the QC needed is not the password-size, but the minimal memory
needed to compute the KDF on it. So with something like 
Argon2, the QC would need as many bits as the configured memory.

In addition, it is still completely unclear whether QC will 
ever scale. There is no indication that it will after now 
something like 40 years of intense research. This is just another
hype that will not die because too many people believe in magic
and normal computing has effectively stopped scaling half a 
decade back or so.

Well, actually, it is pretty clear at this time that QC does
not scale at all in practice and that its scale-up over time 
may well be inverse exponential. If so, it will never be of any use.


> 
> * What is the time/sec margin added to a password with Argon2id's best
> parameters?

There are no "best" parameters. It depends on your application and
target system. That said, computationally, it is bascially just 
the same as PBKDF2, ARGON2 just adds a minimal memory requirements 
or you get exponentially worse.

> * Have Argon's parameters been tweaked in the LUKS implementation, to
> account for the 2 public attacks? [0]

Forget about these. These are academic attacks with no practical
impact. KDFs like Argon2 have massive redundancy security-wise,
unlike most ciphers.
 
> * Are more cryptanalytic attacks expected against it in the future or is
> it extremely unlikely for progress against to be made? (For example
> modern hashes like BLAKE2 or block ciphers like AES are pretty robust
> with no notable attacks for some time)

This question is nonsense. Are you asking us to read the tea-leaves?

Just keep in mind that with a good passphrase, even a single, plain,
unsalted SHA-1 is unbroken at this time and even secure against the
mythical extreme powers (not) of a QC. There is really no need to 
fret over key derivation, the weaknesses are in entirely different 
places.

Regards,
Arno


> * Can you please give an example of cryptsetup re-encrypt command that
> upgrades an existing LUKS1 system to one that uses Argon with its max
> settings?
> 
> 
> CC/d our ML so users can benefit from your reply.
> 
> 
> [0] https://en.wikipedia.org/wiki/Argon2#Cryptanalysis
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> https://www.saout.de/mailman/listinfo/dm-crypt

-- 
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] Argon2id security margin estimate and LUKS2 usage

[procmem]

Arno Wagner wrote:
procmem wrote:
>> Hi Milan, Whonix (privacy distro) maintainer here. We are researching
>> the best password advice to give to our users and while diceware is a
>> great improvement over the status quo, the recommendation by
>> cryptographers in light of quantum computing is to choose pass phrases
>> with a length equivalent to 256 bits because Grovers will halve the bit
>> length. This requires phrases to be 20 words long for 256 bits which is
>> excessive IMO and the reason we are looking at key-stretching for
>> shorter ones instead.
> 
> This is completely irrelevant for key derivation. No QC
> will be able to do a few 1000 iterations of KDF this century,
> and actually it would need to reverse them. Also, the size of
> the QC needed is not the password-size, but the minimal memory
> needed to compute the KDF on it. So with something like 
> Argon2, the QC would need as many bits as the configured memory.
> 
> In addition, it is still completely unclear whether QC will 
> ever scale. There is no indication that it will after now 
> something like 40 years of intense research. This is just another
> hype that will not die because too many people believe in magic
> and normal computing has effectively stopped scaling half a 
> decade back or so.
> 
> Well, actually, it is pretty clear at this time that QC does
> not scale at all in practice and that its scale-up over time 
> may well be inverse exponential. If so, it will never be of any use.
> 

True. I've seen other cryptographers skeptical of QCs ever materializing
in practice excepting a black swan event. However they still support
development of PQ ciphers just in case this happens so we aren't caught
with our oants down in a cryptocalypse. Projects like Tor are working on
a PQ KEM just in case.

While I'd personally love to see quantum computing never succeed because
it only benefits institutions and not regular people, common sense says
its still a plausible scenario to consider until a mathematical proof
disproving the possibility of a large QC surfaces.

> 
>> 
>> * What is the time/sec margin added to a password with Argon2id's best
>> parameters?
> 
> There are no "best" parameters. It depends on your application and
> target system. That said, computationally, it is bascially just 
> the same as PBKDF2, ARGON2 just adds a minimal memory requirements 
> or you get exponentially worse.
> 

I've read arguments to the effect of LUKS1 PBKDF2 being a badly broken
Maginot Line in the face of adversaries with GPUs even if configured
with 10K iterations.

My reasoning was: An adversary who has a ton of GPUs can circumvent
legacy PBKDF2's key-stretching benefits and then in the event of
possessing a QC we then basically have nothing to rely on besides the
master key bit size.

But I'm getting the impression from you that Argon2 is merely a minor
improvement over the original PBKDF2 and that the latter is not
hopelessly defeated by GPUs?

Unlike symmetric key strength and passphrase entropy that I can easily
calculate, I have no idea how much PBKDF2 can delay bruteforcing by an
adversary with massive CPU let alone GPU power. Do you know where I can
read about this?

>> * Have Argon's parameters been tweaked in the LUKS implementation, to
>> account for the 2 public attacks? [0]
> 
> Forget about these. These are academic attacks with no practical
> impact. KDFs like Argon2 have massive redundancy security-wise,
> unlike most ciphers.
>  
>> * Are more cryptanalytic attacks expected against it in the future or is
>> it extremely unlikely for progress against to be made? (For example
>> modern hashes like BLAKE2 or block ciphers like AES are pretty robust
>> with no notable attacks for some time)
> 
> This question is nonsense. Are you asking us to read the tea-leaves?
> 
> Just keep in mind that with a good passphrase, even a single, plain,
> unsalted SHA-1 is unbroken at this time and even secure against the
> mythical extreme powers (not) of a QC. There is really no need to 
> fret over key derivation, the weaknesses are in entirely different 
> places.
> 
> Regards,
> Arno

Indeed. Hashing is quantum resistant and many PQ systems are based on
this premise like DJB's SPHINCS signing suite. I guess I didn't frame my
question properly and you thought I meant PBKDF2 being suddenly
vulnerable to QC rather than GPUs.

Thanks for your insight and work on LUKS. I learn something new every day.

Re: [dm-crypt] Argon2id security margin estimate and LUKS2 usage

[Arno Wagner]

On Tue, Aug 21, 2018 at 01:19:00 CEST, procmem wrote:
> 
> Arno Wagner wrote:
> procmem wrote:
> >> Hi Milan, Whonix (privacy distro) maintainer here. We are researching
> >> the best password advice to give to our users and while diceware is a
> >> great improvement over the status quo, the recommendation by
> >> cryptographers in light of quantum computing is to choose pass phrases
> >> with a length equivalent to 256 bits because Grovers will halve the bit
> >> length. This requires phrases to be 20 words long for 256 bits which is
> >> excessive IMO and the reason we are looking at key-stretching for
> >> shorter ones instead.
> > 
> > This is completely irrelevant for key derivation. No QC
> > will be able to do a few 1000 iterations of KDF this century,
> > and actually it would need to reverse them. Also, the size of
> > the QC needed is not the password-size, but the minimal memory
> > needed to compute the KDF on it. So with something like 
> > Argon2, the QC would need as many bits as the configured memory.
> > 
> > In addition, it is still completely unclear whether QC will 
> > ever scale. There is no indication that it will after now 
> > something like 40 years of intense research. This is just another
> > hype that will not die because too many people believe in magic
> > and normal computing has effectively stopped scaling half a 
> > decade back or so.
> > 
> > Well, actually, it is pretty clear at this time that QC does
> > not scale at all in practice and that its scale-up over time 
> > may well be inverse exponential. If so, it will never be of any use.
> > 
> 
> True. I've seen other cryptographers skeptical of QCs ever materializing
> in practice excepting a black swan event. However they still support
> development of PQ ciphers just in case this happens so we aren't caught
> with our oants down in a cryptocalypse. Projects like Tor are working on
> a PQ KEM just in case.
> 
> While I'd personally love to see quantum computing never succeed because
> it only benefits institutions and not regular people, common sense says
> its still a plausible scenario to consider until a mathematical proof
> disproving the possibility of a large QC surfaces.

For some ciphers, this makes some sense. But a KFD is not really
vulnerable to QCs, even if they eventually work and scale.
And with the large-memory property of Argon2, the QC even
able to work on it would need to be enormous.

 
> > 
> >> 
> >> * What is the time/sec margin added to a password with Argon2id's best
> >> parameters?
> > 
> > There are no "best" parameters. It depends on your application and
> > target system. That said, computationally, it is bascially just 
> > the same as PBKDF2, ARGON2 just adds a minimal memory requirements 
> > or you get exponentially worse.
> > 
> 
> I've read arguments to the effect of LUKS1 PBKDF2 being a badly broken
> Maginot Line in the face of adversaries with GPUs even if configured
> with 10K iterations.

Well, LUKS1 is at arond 500k iteration for a modern CPU, so that
is not a threat. Calling it "badly broken" is pretty much nonsense,
even for only 10k iterations. All a KDF does is lower the amount
of entropy in the passhrase somewhat, it does not prevent breaking
of really bad passphrases and that is not its purpose in the first
place. Its purpose is to shift the boder between "good" and "bad"
a bit and that is it.

> My reasoning was: An adversary who has a ton of GPUs can circumvent
> legacy PBKDF2's key-stretching benefits and then in the event of
> possessing a QC we then basically have nothing to rely on besides the
> master key bit size.

What makes you think a QC would be useful in breaking PBKDF2?
To the best of my knowledge, breaking PBKDF2 requires brute-forcing.
Again to the best of my knowledge, a QC has zero advantage
under these conditions. I may be wrong.

> But I'm getting the impression from you that Argon2 is merely a minor
> improvement over the original PBKDF2 and that the latter is not
> hopelessly defeated by GPUs?

The streteching effect is pretty much the same. The advantage 
is that GPUs cannot efficiently calculate Argon2.

> Unlike symmetric key strength and passphrase entropy that I can easily
> calculate, I have no idea how much PBKDF2 can delay bruteforcing by an
> adversary with massive CPU let alone GPU power. Do you know where I can
> read about this?

For GPU-power, nowhere, it is useless against Argon2, unless you
configure a tiny memory footprint. Obvously, you should not do that.
For CPU, it is pretty much "time to calculate hash" = "time for one
step brute-forcing attempt". This is a fundamental limitation, not
one of Argon2. 

[...]
> > Just keep in mind that with a good passphrase, even a single, plain,
> > unsalted SHA-1 is unbroken at this time and even secure against the
> > mythical extreme powers (not) of a QC. There is really no need to 
> > fret over key derivation, the weaknesses are in entirely different 
> > places.
> 
> Indeed. Hashing is quantum resistant and many PQ systems are based on
> this premise like DJB's SPHINCS signing suite. I guess I didn't frame my
> question properly and you thought I meant PBKDF2 being suddenly
> vulnerable to QC rather than GPUs.
> 
> Thanks for your insight and work on LUKS. I learn something new every day.

You are welcome. To sum this up, what Argon2 does is it
makes a configurable amount of memory mandatory to attack 
it. This is usually set to 1GB or so and makes GPUs completely
unusable as attack platform. CPU-based brute-forcing is not
impacted (if there is enough RAM) and nothing can be done there.
After all, the normal usage scenario also use a normal CPU.
So if a legitimate Argon2 hashing takes 1 sec on a normal
CPU, an attacker gets pretty much the same rate for brute-forcing.

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] Argon2id security margin estimate and LUKS2 usage

[Milan Broz]

Hi,

On 20/08/18 15:33, procmem wrote:
> Hi Milan, Whonix (privacy distro) maintainer here. We are researching
> the best password advice to give to our users and while diceware is a
> great improvement over the status quo, the recommendation by
> cryptographers in light of quantum computing is to choose pass phrases
> with a length equivalent to 256 bits because Grovers will halve the bit
> length. This requires phrases to be 20 words long for 256 bits which is
> excessive IMO and the reason we are looking at key-stretching for
> shorter ones instead.

As Arno said, QC is really not an issue here.

> * What is the time/sec margin added to a password with Argon2id's best
> parameters?

"Best" depends on the context and will change in time (there will be better
optimized implementations, some new problems appear).

The logic here is to provide as much protection to dictionary attacks
as possible, but without completely hurting user experience.
(If you are ok to wait 20minutes for unlocking - you can set it, but for
most of users it means unusable system, etc)

> * Have Argon's parameters been tweaked in the LUKS implementation, to
> account for the 2 public attacks? [0]

Partially yes:

- we use Argon 1.3 version (as implemented by authors)

- minimal iteration count (memory passes) is 4 (the first "attack")

- we cannot use minimal 10 (second "attack"), because on real systems
it would be incredibly slow.
You can use Argon2id though (combination of data dependent and independent
processing). I prefer Argon2i for key derivation, but opinions differ here.

- the reference values suggested in RFC draft are unusable in reality as well
(it could change with optimized implementation though)

(BTW RFC draft expired but Argon2 authors assured me that it is just because
of other priorities - it should be updated soon, I hope.)

> * Are more cryptanalytic attacks expected against it in the future or is
> it extremely unlikely for progress against to be made? (For example
> modern hashes like BLAKE2 or block ciphers like AES are pretty robust
> with no notable attacks for some time)

Always expect it to be broken in future and be prepared to reencrypt your data
and increase/change algorithms in future :-)

You can do both (offline) now with cryptsetup-reecrypt.

> * Can you please give an example of cryptsetup re-encrypt command that
> upgrades an existing LUKS1 system to one that uses Argon with its max
> settings?

I will always avoid describing something as "best" or "max" - it depends.

Cryptsetup set Argon2 internal limit to use maximal 1GB of memory and 4 threads,
but it is just safety margin to be able move device among various systems.

The time (iteration) count is limited only be 32bit integer, so if you wish,
you can set it very high. (And attacker the will just focus on different attack vector
like extracting key from active device or so :)

Keyslot upgrade can be done with the new luksConvertKey command
(you can do the same with cryptsetup-reecrypt if --keep-key option is used).

So, for your use case:

1) Backup your LUKS1 header (for recovery, if anything fails during conversion)

  # cryptsetup luksHeaderBackup --header-backup-file <backup_file> <device>

2) convert LUKS1 device to LUKS2, this will keep keyslot in current configuration,
just it updates metadata format.

  # cryptsetup convert --type luks2 <device>

3a) upgrade keyslot(s) to LUKS2 default and benchmarked parameters
    (it upgrades keyslot with provided password)

  # cryptsetup luksConvertKey <device>

OR

3b) upgrade to explicitly defined parameters (benchmark is skipped so it allows you
to setup very high iteration time or it allows to setup it for different system),
like example here:

  # cryptsetup luksConvertKey --key-slot 1 --pbkdf argon2id --pbkdf-force-iterations 50 --pbkdf-memory 1048576 --pbkdf-parallel 4 <device>

NOTE: cryptsetup will always decrease parameters if they are not possible to use
(more than half of physical memory or not enough cpu cores) or if the exceeds
internal limit (see cryptsetup --help, for now max memory limit is the same as default)

I think we need to change how is user informed here about parameter downgrade, it is only
visible in --debug mode, fro example:
  # Only 2 active CPUs detected, PBKDF threads decreased from 4 to 2.
  # Not enough physical memory detected, PBKDF max memory decreased from 1048576kB to 249392kB.

Milan

Re: [dm-crypt] Argon2id security margin estimate and LUKS2 usage

[procmem]

Thanks for your great reply Milan and your work on LUKS. Will definitely
document this info on our wiki.

Cheers.


Milan Broz:
> Hi,
> 
> On 20/08/18 15:33, procmem wrote:
>> Hi Milan, Whonix (privacy distro) maintainer here. We are researching
>> the best password advice to give to our users and while diceware is a
>> great improvement over the status quo, the recommendation by
>> cryptographers in light of quantum computing is to choose pass phrases
>> with a length equivalent to 256 bits because Grovers will halve the bit
>> length. This requires phrases to be 20 words long for 256 bits which is
>> excessive IMO and the reason we are looking at key-stretching for
>> shorter ones instead.
> 
> As Arno said, QC is really not an issue here.
> 
>> * What is the time/sec margin added to a password with Argon2id's best
>> parameters?
> 
> "Best" depends on the context and will change in time (there will be better
> optimized implementations, some new problems appear).
> 
> The logic here is to provide as much protection to dictionary attacks
> as possible, but without completely hurting user experience.
> (If you are ok to wait 20minutes for unlocking - you can set it, but for
> most of users it means unusable system, etc)
> 
>> * Have Argon's parameters been tweaked in the LUKS implementation, to
>> account for the 2 public attacks? [0]
> 
> Partially yes:
> 
> - we use Argon 1.3 version (as implemented by authors)
> 
> - minimal iteration count (memory passes) is 4 (the first "attack")
> 
> - we cannot use minimal 10 (second "attack"), because on real systems
> it would be incredibly slow.
> You can use Argon2id though (combination of data dependent and independent
> processing). I prefer Argon2i for key derivation, but opinions differ here.
> 
> - the reference values suggested in RFC draft are unusable in reality as well
> (it could change with optimized implementation though)
> 
> (BTW RFC draft expired but Argon2 authors assured me that it is just because
> of other priorities - it should be updated soon, I hope.)
> 
>> * Are more cryptanalytic attacks expected against it in the future or is
>> it extremely unlikely for progress against to be made? (For example
>> modern hashes like BLAKE2 or block ciphers like AES are pretty robust
>> with no notable attacks for some time)
> 
> Always expect it to be broken in future and be prepared to reencrypt your data
> and increase/change algorithms in future :-)
> 
> You can do both (offline) now with cryptsetup-reecrypt.
> 
>> * Can you please give an example of cryptsetup re-encrypt command that
>> upgrades an existing LUKS1 system to one that uses Argon with its max
>> settings?
> 
> I will always avoid describing something as "best" or "max" - it depends.
> 
> Cryptsetup set Argon2 internal limit to use maximal 1GB of memory and 4 threads,
> but it is just safety margin to be able move device among various systems.
> 
> The time (iteration) count is limited only be 32bit integer, so if you wish,
> you can set it very high. (And attacker the will just focus on different attack vector
> like extracting key from active device or so :)
> 
> Keyslot upgrade can be done with the new luksConvertKey command
> (you can do the same with cryptsetup-reecrypt if --keep-key option is used).
> 
> So, for your use case:
> 
> 1) Backup your LUKS1 header (for recovery, if anything fails during conversion)
> 
>   # cryptsetup luksHeaderBackup --header-backup-file <backup_file> <device>
> 
> 2) convert LUKS1 device to LUKS2, this will keep keyslot in current configuration,
> just it updates metadata format.
> 
>   # cryptsetup convert --type luks2 <device>
> 
> 3a) upgrade keyslot(s) to LUKS2 default and benchmarked parameters
>     (it upgrades keyslot with provided password)
> 
>   # cryptsetup luksConvertKey <device>
> 
> OR
> 
> 3b) upgrade to explicitly defined parameters (benchmark is skipped so it allows you
> to setup very high iteration time or it allows to setup it for different system),
> like example here:
> 
>   # cryptsetup luksConvertKey --key-slot 1 --pbkdf argon2id --pbkdf-force-iterations 50 --pbkdf-memory 1048576 --pbkdf-parallel 4 <device>
> 
> NOTE: cryptsetup will always decrease parameters if they are not possible to use
> (more than half of physical memory or not enough cpu cores) or if the exceeds
> internal limit (see cryptsetup --help, for now max memory limit is the same as default)
> 
> I think we need to change how is user informed here about parameter downgrade, it is only
> visible in --debug mode, fro example:
>   # Only 2 active CPUs detected, PBKDF threads decreased from 4 to 2.
>   # Not enough physical memory detected, PBKDF max memory decreased from 1048576kB to 249392kB.
> 
> Milan
> 

Re: [dm-crypt] Argon2id security margin estimate and LUKS2 usage

[Arno Wagner]

Hi procmem,

you may want to add a link to the FAQ here:

https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions

It has a lot of basic and advanced stuff people may want to know,
even if it is not updated for LUKS2 yet. 

Regards,
Arno

On Mon, Sep 03, 2018 at 16:35:00 CEST, procmem wrote:
> Thanks for your great reply Milan and your work on LUKS. Will definitely
> document this info on our wiki.
> 
> Cheers.
> 
> 
> Milan Broz:
> > Hi,
> > 
> > On 20/08/18 15:33, procmem wrote:
> >> Hi Milan, Whonix (privacy distro) maintainer here. We are researching
> >> the best password advice to give to our users and while diceware is a
> >> great improvement over the status quo, the recommendation by
> >> cryptographers in light of quantum computing is to choose pass phrases
> >> with a length equivalent to 256 bits because Grovers will halve the bit
> >> length. This requires phrases to be 20 words long for 256 bits which is
> >> excessive IMO and the reason we are looking at key-stretching for
> >> shorter ones instead.
> > 
> > As Arno said, QC is really not an issue here.
> > 
> >> * What is the time/sec margin added to a password with Argon2id's best
> >> parameters?
> > 
> > "Best" depends on the context and will change in time (there will be better
> > optimized implementations, some new problems appear).
> > 
> > The logic here is to provide as much protection to dictionary attacks
> > as possible, but without completely hurting user experience.
> > (If you are ok to wait 20minutes for unlocking - you can set it, but for
> > most of users it means unusable system, etc)
> > 
> >> * Have Argon's parameters been tweaked in the LUKS implementation, to
> >> account for the 2 public attacks? [0]
> > 
> > Partially yes:
> > 
> > - we use Argon 1.3 version (as implemented by authors)
> > 
> > - minimal iteration count (memory passes) is 4 (the first "attack")
> > 
> > - we cannot use minimal 10 (second "attack"), because on real systems
> > it would be incredibly slow.
> > You can use Argon2id though (combination of data dependent and independent
> > processing). I prefer Argon2i for key derivation, but opinions differ here.
> > 
> > - the reference values suggested in RFC draft are unusable in reality as well
> > (it could change with optimized implementation though)
> > 
> > (BTW RFC draft expired but Argon2 authors assured me that it is just because
> > of other priorities - it should be updated soon, I hope.)
> > 
> >> * Are more cryptanalytic attacks expected against it in the future or is
> >> it extremely unlikely for progress against to be made? (For example
> >> modern hashes like BLAKE2 or block ciphers like AES are pretty robust
> >> with no notable attacks for some time)
> > 
> > Always expect it to be broken in future and be prepared to reencrypt your data
> > and increase/change algorithms in future :-)
> > 
> > You can do both (offline) now with cryptsetup-reecrypt.
> > 
> >> * Can you please give an example of cryptsetup re-encrypt command that
> >> upgrades an existing LUKS1 system to one that uses Argon with its max
> >> settings?
> > 
> > I will always avoid describing something as "best" or "max" - it depends.
> > 
> > Cryptsetup set Argon2 internal limit to use maximal 1GB of memory and 4 threads,
> > but it is just safety margin to be able move device among various systems.
> > 
> > The time (iteration) count is limited only be 32bit integer, so if you wish,
> > you can set it very high. (And attacker the will just focus on different attack vector
> > like extracting key from active device or so :)
> > 
> > Keyslot upgrade can be done with the new luksConvertKey command
> > (you can do the same with cryptsetup-reecrypt if --keep-key option is used).
> > 
> > So, for your use case:
> > 
> > 1) Backup your LUKS1 header (for recovery, if anything fails during conversion)
> > 
> >   # cryptsetup luksHeaderBackup --header-backup-file <backup_file> <device>
> > 
> > 2) convert LUKS1 device to LUKS2, this will keep keyslot in current configuration,
> > just it updates metadata format.
> > 
> >   # cryptsetup convert --type luks2 <device>
> > 
> > 3a) upgrade keyslot(s) to LUKS2 default and benchmarked parameters
> >     (it upgrades keyslot with provided password)
> > 
> >   # cryptsetup luksConvertKey <device>
> > 
> > OR
> > 
> > 3b) upgrade to explicitly defined parameters (benchmark is skipped so it allows you
> > to setup very high iteration time or it allows to setup it for different system),
> > like example here:
> > 
> >   # cryptsetup luksConvertKey --key-slot 1 --pbkdf argon2id --pbkdf-force-iterations 50 --pbkdf-memory 1048576 --pbkdf-parallel 4 <device>
> > 
> > NOTE: cryptsetup will always decrease parameters if they are not possible to use
> > (more than half of physical memory or not enough cpu cores) or if the exceeds
> > internal limit (see cryptsetup --help, for now max memory limit is the same as default)
> > 
> > I think we need to change how is user informed here about parameter downgrade, it is only
> > visible in --debug mode, fro example:
> >   # Only 2 active CPUs detected, PBKDF threads decreased from 4 to 2.
> >   # Not enough physical memory detected, PBKDF max memory decreased from 1048576kB to 249392kB.
> > 
> > Milan
> > 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> https://www.saout.de/mailman/listinfo/dm-crypt

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