[Whonix-devel] 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.