[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

[Arno Wagner]

Post by 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.

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.

Post by procmem
* 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.

Post by procmem
* 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.

Post by procmem
* 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

Post by procmem
* 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
https://www.saout.de/mailman/listinfo/dm-crypt

[procmem]

Post by Arno Wagner

Post by 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.

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.

Post by Arno Wagner

Post by procmem
* 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?

Post by Arno Wagner

Post by procmem
* 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.

Post by procmem
* 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.

[Arno Wagner]

Post by procmem

Post by Arno Wagner

Post by 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.

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.

Post by procmem

Post by Arno Wagner

Post by procmem
* 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.

Post by procmem
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.

Post by procmem
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.

Post by procmem
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.

[...]

Post by procmem

Post by Arno Wagner
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

[Milan Broz]

Hi,

Post by 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.

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

Post by procmem
* 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)

Post by procmem
* 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.)

Post by procmem
* 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.

Post by procmem
* 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

[procmem]

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

Cheers.

Post by Milan Broz
Hi,

Post by 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.

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

Post by procmem
* 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)

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

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

Post by procmem
* 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.

Post by procmem
* 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).
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),
# 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
# 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

[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

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

Post by Milan Broz
Hi,

Post by 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.

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

Post by procmem
* 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)

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

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

Post by procmem
* 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.

Post by procmem
* 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).
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),
# 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
# 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
https://www.saout.de/mailman/listinfo/dm-crypt