On 07/22/2016 07:03 PM, Andrew David Wong wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 2016-07-22 08:15, TheFactory wrote:
Another good use for this feature is that you can pre-program in some
landmines to destroy the drive and overcome brute force. Since the LUKS
password prompt on my install of 3.2 has little to no delay between
password attempts one could use a mid range gpu to try millions of
passwords. The drive itself can be copied dozens of times to increase the
chances of getting the password.
You can configure the iteration time manually by following the instructions
here:
https://www.qubes-os.org/doc/encryption-config/
Remember that the actual number of iterations depends on the speed of your
hardware. The cryptsetup default is one second (1000 milliseconds).
However if
If you had a limit of 10 or 20 tries before drive wipe.
And had a dozen or more fake passwords that would induce drive wipe.
And had some sort of delay in each password attempt built in.(veracrypt
takes forever to process your password input for instance)
Using tpm ontop of this would also at least frustrate their attempts at
mirroring the drive.
You could be reasonably certian that even powerful attempts at getting the
drive open will be hopeless. Though, you may get yourself in some physical
trouble.
I have wanted features like the above ones for some time.
As Andrew pointed out, offline brute forcing doesn't work this way. Attackers
wouldn't attempt to brute force your encrypted drive using your hardware and
software. They would just take a copy the ciphertext and attempt to decrypt it
with their own software on their own (much more powerful) hardware. (However,
the use of a TPM would make a difference here, for the reason Andrew points
out.)
- --
Although adding TPM support for LUKS is desirable, the suggested 'LUKS
nuke' feature is separate and suffers from a poor understanding of the
threat model.
As you point out, the main use case is when the user wants to initiate
destruction of the encrypted volume before it falls into the wrong
hands. But there is no need to patch LUKS to accomplish this, and using
only passphrases as the trigger mechanism is probably too cumbersome in
some situations anyway.
This could be scripted with better results and flexibility for the end
user, obviating any need to meddle with LUKS code.
If there is already an issue# for a 'panic button' type of feature
request, I'd suggest linking this thread to it.
Chris
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/8950a388-9383-6091-0b1a-8f8f4b2d9477%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.
