How long would you be willing to wait at boot for full disk encryption?

[Patrick]

Imagine - the longer you are willing to wait - the stronger the encryption can be.

How long would you be willing to wait at boot for full disk encryption?

Cryptographers think 50 seconds is excessive. For me personally, even 5 minutes or even longer are not nice but acceptable if I knew - just speculation if there was such an algorithm - a let’s say 6/7 diceware passphrase could be stretched to 256 bits (speak: best currently available) strength.

This is just a questionnaire.

Context:

• password stretching - https://www.whonix.org/pipermail/whonix-devel/2018-September/001255.html

password advice wiki page enhancements

That article needs more contents. Suggest different password per website. Not password1, password2, Password alike variations. Explain why that is. Attackers use passwords which were leaked in one website as templates so they don’t have to fall back on “totally” brute force attacks. Don’t use online password generators for anything but curiosity / learning. That is because there is a very good chance the server could log them. The only place where passwords should be generated is locally, id…

Passwords

PQCrypto

[0brand]

Hi Patrick

Personally I don’t think 5 minutes would be to long. If a high --iter-time ( ≥ 3000,000) became the norm most users would not even notice after while. Maybe some complaining at first. However, the problem lies with users not shutting down their box when they normally would.

“Maybe I’ll take my dog for a walk but leave my box running because I don’t have the time to boot up again”

I’m not sure most people would be committed to good OpSec. Maybe the 1% who really need it?

Edit:

Context:

• password stretching - whonix/pipermail link broken

[HulaHoop]

In my experiments 50 iterations was pretty slow - a whole minute delay before boot initiation. Its not like sha iterations which can be ramped up in the tens of thousands without a problem. It is a byproduct of a different design that slows down things a lot, on all hardware on purpose.

Also because of log scaling its a law of diminishing returns that quickly stacks up against usability.

Going up to 300K iterations will be insanely slow: if 50 iterations take ~ 1 minute then this number takes 100 hours to login. while only raising total argon2id entropy to 38. The same as adding 2 more words (post-quantum).

[Cottonwoodhill]

Hi Patrick

Personally I don’t think 5 minutes would be to long. If a high --iter-time ( ≥ 3000,000) became the norm most users would not even notice after while. Maybe some complaining at first. However, the problem lies with users not shutting down their box when they normally would.

“Maybe I’ll take my dog for a walk but leave my box running because I don’t have the time to boot up again”

I’m not sure most people would be committed to good OpSec. Maybe the 1% who really need it?

Edit:

Context:

• password stretching - whonix/pipermail link broken

+1 @0brand, so true

Here is an experienced fellow talking

So I would say everything in a range of 3-5 minutes is acceptable.

Edit by Patrick:
Off-topic moved here:

VM VirtualBox Disk Encryption secure?

No knowledge about it. (Split from How long would you be willing to wait at boot for full disk encryption?)

[Patrick]

password stretching - whonix/pipermail link broken

https://www.whonix.org/pipermail/whonix-devel/2018-September/001255.html works for me.

[0brand]

Going up to 300K iterations will be insanely slow:

I’m likely wrong but I was under the impression --iter-time 1 would equal 1 millisecond of iterations. So --iter-time 300000 would be 5 minutes. Your probably talking about something way over my head.

[chicken]

1-2 minutes.

[9jnc7]

I tested this idea on different distributions. Qubes couldn’t wait much more than 2 minutes before it called for a dracut timeout, and another 40-70 seconds for a rescue terminal to be brought up.

Debian and Fedora both accepted much longer iter times for partitions being mounted after boot, although I didn’t try 5 minutes. I tried those partitions on a mainstream performance-oriented OS, and they failed with a timeout in 20 seconds.

[Patrick]

I guess the timeouts are configurable?