kriswebdev / cryptsetup-deluks Goto Github PK

Will you merge your project with modern cryptsetup version?
It very difficult to use it without LUKS-2 support! But I can't merge code because don't know how.
I only wrote PKGBUILD for ArchLinux and added it to AUR repository (https://aur.archlinux.org/packages/cryptsetup-deluks/).

@kriswebdev
Thanks for this great work , and great idea
i tried sooooooo many times , on ubuntu 16.04 and Mint 18 ( i guess both are xenial xerus and they should be ok with grub crypto deluks and cryptsetup-deluks )

with real machine , and inside Vitual Machine
i read and followed the guides step by step
but it's not working.
When i press "c" at grub prompt , and type the command "cryptomout -x /"
i receive the message "SLOT 0 opened"
but when i check with command "ls"
there is only (crypto0)
But there is not any (crypto0,msdos2) or (crypto0,msdos1)
and so other commands like "set boot (crypto0,msdosX) and .... are not working

can some one please help me.

Is this compatible with BSD especifically with DragonFlyBSD?

As computing power grows in time and new exploits are discovered, it may be necessary to:

• Change the header and/or payload encryption & hashing algorithms when they become potentially unsafe
• Increase the number of password hash iterations (PBKDF2) based on the executing machine computing power
• Reencrypt the header or payload with the new settings when necessary

The difficulty, when using deniable encryption, is that those header encryption settings cannot be stored with the deniable payload, or they wouldn't be deniable. However, they can be given by the user as arguments each time the volume is decrypted, or must be stored/hard-coded in the executable as default settings.

The second solution is the most practical, and that's what Truecrypt does: it stores a long list of hash algorithm+cipher+keysize+etc. mix and tries them all. But as Truecrypt has to run on most machines, even the ones with limited computing power, it unnecessarily weakens the header encryption settings so that it doesn't take forever to open a Truecrypt volume on an weak machine.

On the other hand, LUKS uses by default:

• The default hash and cipher algorithms defined in a constant; This can evolve in time with newer cryptsetup versions, when the old default settings become obsolete.
• A number of hash iterations computed during the volume creation, and based on the executing machine CPU computing power.
  These settings are store unencrypted in the LUKS header. That's great, but not deniable.

I believe that the best solution is to use by default:

• The default hash and cipher algorithms defined in a constant, dependant on cryptsetup-deluks version. When the header can't be decrypted due to cryptsetup update, cryptsetup should try the hash/cipher algorithms of previous versions and warn the user that it should reencrypt the header and/or payload with newer, safer settings.
• A number of hash iterations determined during the executable compilation. This setting should be stored within cryptsetup-deluks and grub-crypto deluks executables at compilation time based on the compilation machine computing power. The user should be informed of the value of this setting (in a power of 2) everytime cryptsetup/cryptomount is run, in case the user needs to port the encrypted volume to another machine with different cryptsetup/cryptomount executables.

One last remark is that nowadays, crackers tends to use GPU or even APU instead of CPU for brute-forcing.
There are two challenges:

• Find a replacement to PBKDF2-HMAC-XXX that uses 100% GPU computing power to derive a key from 1 password, and that is slow to run on CPU.
• Leverage GPU power at boot time to run this algorithm and decrypt the volume key from the password. That's probably quite hard or possibly unpractical to leverage GPU power from grub.

Although this project aims to create deniability, by removing the header from the encrypted OS partition/disk, this won't really help in a torture/legal threats scenario.

The presence of a noise filled partition/disk creates an immediate suspicion that it will contain data. Even if it can't be proved, the suspicion is enough for judges that are inclined to believe agency 'suspicions'.

https://falkvinge.net/2012/07/12/in-the-uk-you-will-go-to-jail-not-just-for-encryption-but-for-astronomical-noise-too/

What would be really helpful is an encrypted fake os, with a real os in the free space of that same partition. Its much more palatable this way, and you've already given away the key to the fake os - so no evidence of a real os in the freespace.

Veracrypt seems to do this. Linux could do something similar using a mix of Luks for the fake os and plain dm-crypt for the real os in the freespace. Similar to how this article explains it:

https://blog.linuxbrujo.net/posts/plausible-deniability-with-luks/

If this could be incorporated in the future, this project would be almost perfect - once its incorporated into the main grub releases.

thanks