What is Reddit's opinion of
LUKS?
From 3.5 billion Reddit comments
91 reviews of this app found across Reddit:
Its possible to have plausible deniability with dm_crypt.
Steps to do so:
blanket the entire device with crypto strong random data.
Put a vfat file system on the device.This file system is optimal because it is the most advanced among simple file systems.The file system will be added at offset 0 on the device.
Create a plain dm-crypt volume at a non zero offset.Example of how to create a plain dm-crypt at a 2MB offset is "cryptsetup -o 4096 create encrypted /dev/sdc6"
Put a file system on the created encryption mapper.
Now you have two file systems,one is "open/outer" and another is "hidden/inner". Just plug in your device to the computer and everybody will see the open/outer one.
To access the hidden file system,use cryptsetup tool to create the encryption mapper at the given offset using a proper password.This is how TrueCrypt works and the only different is that TrueCrypt saves the offset of the hidden volume in the header while you have to always provide it with cryptsetup.
This plausible deniability is better compared to the one offered by TrueCrypt because the exposed vfat file system that everybody will see "out of the box" will reduce considerably suspicions of hidden encrypted file system.
With plain dm-crypt at a non zero offset,you can access these hidden volumes through a GUI solution using zuluMount[3],a mounting tool that is shipping with zuluCrypt[1].
With zuluMount,start the process of mounting your volume and then click "options" button followed by "set volume offset" and you will be given an option to enter the offset and volume password.
Discussions on how to do plausible deniability with plain dm-crypt is somewhere towards the end of this cryptsetup bug report[2]
[1] http://mhogomchungu.github.io/zuluCrypt/
Anybody who is thinking about plausible deniability should read the cryptsetup FAQ about it: 5.18 What about Plausible Deniability? It may be not a so good idea.
LUKS is the "main" Linux solution for disk encryption.
Here's the Archlinux wiki page on disk encryption, you might find it helpful.
That's definitely disk encryption. Here's some more information.
Unfortunately, unless you can get the passphrase (yes - doesn't have to be a short password, it can be quite long - a phrase, song verse, or so on) from some other thing (guess? written down somewhere?) you're not going to get the data off of it.
The good news is you should be able to try as many times as you want, I don't believe it has any kind of a self-destruct mechanism.
I'm not sure what you're talking about. On Linux the de facto standard for disk encryption is LUKS and has been for years. It's very well integrated these days and is completely transparent in normal use.
LUKS does something similar in that you need to store something in addition to your ciphertext:
On encryption, LUKS derives the key via PBKDF2 from the password. The key is kicked through PBKDF2 one more time and saved as the "key checksum". On decryption, a password is only accepted if PBKDF2(PBKDF2(password)) == key checksum. See Page 11 https://gitlab.com/cryptsetup/cryptsetup/-/wikis/LUKS-standard/on-disk-format.pdf
This construction reuses the assumptions that PBKDF2 can't be inverted. I chose this because I felt that mixing in cipher primitives added unnecessary parts to the whole construction.
You have probably heard that to write fast SSDs need the free space initialized with zeroes. So SSDs are constantly erasing themselves in the background. That is called 'trim' or 'discard' operation.
​
If you properly initialize your encryption you will have the whole disk filled with random-looking data. Then when you use your disk you will replace this data with another random-looking data. The SSD will have to first initialize the area you want to write to with zeroes and then write new data you want to store. The preformance will drop at least two times killing the SSD advantages. You can expect SSD lifetime to drop two times too.
Also some controllers use compression to speedup operations, and will loose performance not being able to compress random-looking encrepted data.
​
To avoid that you can allow trim/discard to initialize empty space with zeroes, but then anyone looking at your SSD will know where and how much space are you using. Also forensics experts can determine what type of filesystem you are using (ext4, ntfs, etc.) So you trade some privacy for preformance.
​
Another aspect of SSDs is that they reserve some space for 'garbage collection'. When you see Kingston 480 GB disk it means that there is 512GB chip inside with 32 GB reserved for trim. Some manufacturers reserve more, some less, but they all do it. Firmware is in control of that area, and it doesn't disclose anything about it's algorythms. So on a magnetic HDD you can simply erase your LUKS header and be sure your data is safe. But you have no control over SSD. Even if you overwrite it multiple times - you cannot touch the reserved area.
​
Also please read answer 5.19 of this FAQ: https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions
>NOTE: You MUST have /boot on a separate, unencrypted partition
No, GRUB supports booting from encrypted boot. See http://www.pavelkogan.com/2014/05/23/luks-full-disk-encryption/ for an example.
>2. Overwrite your current disk with zeros Warning: obviously this will delete all data on the device :
dd if=/dev/zero of=devicename bs=4M
This protects against forensic attacks on old data that used to be on the drive, but wiping the drive with random data instead of zeros has some important advantages. Wiping the disk with random data disguises your partition table, filesystem types, where your data is, and the amount of data you have. Sometimes important information can be gleaned from these things alone. Of course, if you choose to use TRIM on an SSD this is also revealed. On the other hand, we know that writing from /dev/urandom is time consuming, but there is a solution! If you make your whole disk into an encrypted container and then write the whole container over with /dev/zero, you get pseudorandom "noise" filling the whole disk, with just minimal overhead versus writing from /dev/zero. I found this recommended on the cryptsetup wiki. See https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions. Also, here is how you would do this:
# cryptsetup open --type plain /dev/sda container # dd if=/dev/zero of=/dev/mapper/container # cryptsetup close container
>3. Setup LUKS:
cryptsetup -v --cipher aes-xts-plain64 --key-size 512 --hash sha512 --iter-time 5000 --use-random luksFormat device
You should not pass --use-random. It is a myth that will provide a better key. See http://www.2uo.de/myths-about-urandom/.
First, there's only one FDE in Linux (LUKS / Crypsetup), so there's no such thing as one full disk ecnryption packaged with Mint and one with Manjaro.
Still, from the top of my head, Mint will default to LVM when choosing FDE, while I'm pretty sure Manjaro doesn't. Can't tell if it makes any huge difference.
The screen with a countdown is GRUB. You can get rid of it (the Timeout) if you want by editing /etc/default/grub then run sudo update-grub.
You can't normally add second or third chances to enter your passphrase in this case. I know there are some very unnofficial patches (like creating a nuke fake passphrase), but I wouldn't recommend starting to mess around with it, especially since you seem to be in your early Linux stage.
While you at it, I'd suggest to explore Cryptsetup, starting with cryptsetup luksHeaderBackup :) . More over there
After loading the Linux kernel a minimal environment is loaded from initramfs (mkinitcpio). Initramfs uses cryptsetup to setup your block devices.
You probably want to patch cryptsetup and put your modified version into the initramfs image in /boot
Here is the source: https://gitlab.com/cryptsetup/cryptsetup/blob/master/lib/setup.c#L472
GPT is the partition table. The OS needs to be able to read that to have any idea what is on the disk, where the partitions are. It lets you have encrypted and unencrypted partitions and is widely understood by boot firmware (as a newer alternative to the Master Boot Record [MBR] specification).
The encryption is provided by LUKS. I believe Tails it uses an AES256 cipher for the encrypted data, though what ciphers are available depend on the Linux kernel and the setup options.
You can check it using cryptsetup luksDump
For more details: https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions
The main boot volume is unencrypted for several reasons, mostly that it gets copied to RAM anyway and stores nothing personally identifiable by design.
So, you have multiple backup copies of your LUKS header? Because if that gets corrupted, merely knowing the passkey isn't enough to decrypt your data.
And, no, there are no backup copies automatically created by any distro's installer. If you haven't manually created one, you're one bad disk sector away from being forever locked out of the entire LUKS device.
LUKS Is what 99.9999999999% of installers use when they say "Encrypt da hark disk"
You can use a tool to control luks to a more fine control such adding another usable password or a keyfile.
but one fun thing you can do with that tool is remove the header which contains all the information to decrypt and encrypt a LUKS system on a thimdrive or some other platform. and use it externally. therefor rending the disk useless without fucking up the bootloader.
gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#6-backup-and-data-recovery
But we'll jump straight to the bad news:
>6.9 What happens if I (quick) format a LUKS partition?
>I have not tried the different ways to do this, but very likely you will have written a new boot-sector, which in turn overwrites the LUKS header, including the salts, making your data permanently irretrievable, unless you have a LUKS header backup. You may also damage the key-slots in part or in full.
The downside of strong encryption is that it's very easy to lose everything. Sorry.
Thats because it isn't an option during the creation of your encrypted drive on windows 10, not on windows 8. On windows 8 it might be safe. However BitLocker is a bit controversial, most technical people don't use it for one or both reasons: It's proprietory and it's from microsoft.
Personally I trust LUKS to be secure enough.
This does not seem to be a good idea!
Please read the plausible deniability part (2.4 What is the difference between "plain" and LUKS format? and 5.18 What about Plausible Deniability?) of the LUKS FAQ!
>Second, there are two types of situations: Either they cannot force you to give them the key (then you simply do not) or they can. In the second case, they can always do bad things to you
(It is about plausible deniability, but it would work the same for wiping the drive, like "destroying evidence" or something like that.)
You can test the header by using the --header option when opening the LUKS device. If it's successful, this means that the header backup can be restored to the device and everything will work as expected.
Yes, persistence storage rely on LUKS which have such protection. See https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions, particularly 5.9 and following.
Can access on another desktop or server providing you have the pass key or file. Just unlock/read by unlocking using luks. https://gitlab.com/cryptsetup/cryptsetup
None
1 key for all of the array. But can have multiple keys and change keys. There are a finite amount of key slots. I forgot how many. Once you reach that limit you will have to remove keys to add new ones but I personally do not see a need for more than one since it’s array wide
There's no rescue disk. You'll have to use cryptsetup to create a backup of the LUKS header (see the FAQ about that and all sorts of useful details). That's similar to one of the Veracrypt rescue disk purpose but there's no "emergency decrypt" or things like that. The header is a small file that contains needed information to unlock the drive, if it's damaged, all is lost. That's something I'm still hopping installers would one day mention instead of "don't loose your passphrase".
To access the encrypted volume from another system, the usual way is, again, to use cryptsetup from command line and then mount the partition but nowadays most graphical file managers will just prompt you for the passphrase and work their magic.
As for updates, there won't be any issues but it can happen on rare occasions and specific conditions. I don't recall seeing anything that couldn't be easily solved though.
In any case, just remember that encryption can backfire and that backups here are even less an option than usual.
The LUKS header is entirely at the beginning of the block device. Overwriting 2MB should be sufficient. Don't forget to shred any header backups you may have made.
However, the way that SSDs reallocate sectors during normal operation may leave chunks of the header laying about. Personally, I wouldn't worry about it, but if you want to be completely secure you'll need to run an ATA Secure Erase on the entire drive.
Regarding LUKS Vs Veracrypt : dont worry about that the main difference is that VC can encrypt your Windows drive in-place while LUKS/cryptsetup/dm-crypt implies a full reformat and reinstall. Both are bulletproof as long as your passphrase is. (angry infosec people, dont scream, just keeping it simple here)
I won't blame you for trying and I'm saying this in a friendly way but you shouldn't "vaguely remember" how you encrypted "something". So first, if you're prompted for a password at boot, your drive is fully encrypted. Otherwise, only your Home is. It's not a bad thing, just means that only your personnal user stuff is encrypted, not the whole drive.
Wich brings us to the big questions :
Why did you chose to encrypt ?
Are you planning to have backups ? Because, well you know, encrypted data are meant to be ... well impossible to recover.
If your drive is fully encrypted, I strongly suggest that you take a look at cryptsetup luksHeaderBackup
fsck works only on the file system which is withing the encrypted partition. So no that won't work.
Good thing you have backups. Congrats!
https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#6-backup-and-data-recovery
Read the whole section (data and recovery). Doesn't look good.
I recommend you create an askubuntu.com question for your problem before you make irreversable changes. Just in case there is a known bug and your LUKS partition is fine (unlikely but possible).
Yes, it's most likely doable, you'd just have to configure your bootloader to recognize the Windows boot thingies. I'm not that familiar with Windows, but I don't imagine it would be very hard to configure. See the dual-booting section of the GRUB ArchWiki article, for example.
> I would like to encrypt the HDD as well but not sure if it's doable with half ext4 filesystem and half NTFS
You encrypt block devices (i.e. /dev/sda), not filesystems. Thus, if you have two partitions, e.g. /dev/sda1 and /dev/sda2, the first can be encrypted and formatted to ext4 without the other being affected.
However, SSDs with LUKS can be weird. See the LUKS FAQ section 5.19 about this.
Edit - fixed links.
> simply because LUKS wasn't updated for years now, it's still version 1.0 which might become obsolete as computing power increases
The latest version of LUKS/Cryptsetup is 2.0.2. See LUKS/Cryptsetup Project homepage. The Project is well maintained and being regularly updated.
No. Having the masterkey would make a brute force attack on the other passwords possible, but not practical. The algorithms/methods used with the keyslots are essentially the same ones used to encrypt the data.
For general reference: Cryptsetup and LUKS.
>Additionally, what are the default settings for the full disk encryption in Ubuntu?
>I know that VeraCrypt can do cascading algorithms but dm-crypt/LUKS can't.
Cascading algorithms is of dubious utility. Re: security.stackexchange.com/questions/35835/cascading-encryption-algorithm-using-mcrypt-or-gnugp/35846#35846
> the installation … doesn't mention the default settings, much less allow you to change them.
IIRC, you can specify the encryption settings when using the Ubuntu Server installer. So, AFAIK, you could start w/ Ubuntu Server and then simply install the package xubuntu-desktop on it.
>With VeraCrypt I'm using cascading algorithms AES(Twofish(Serpent)), XTS, HMAC-SHA-256. Can dm-crypt/LUKS be configured to use the same?
Why the same? Is there not any other cipher/mode/iv combination that will meet your needs?
You can also use LUKS/dm-crypt.
Interfaces nicely with Ubuntu/Unity/nautilus (I'm not sure what actually handles it, it just worked for me).
Windows support will be less official and possibly more work... https://github.com/t-d-k/LibreCrypt (I haven't used it on Windows myself, so someone please tell me if it's absurd to even consider).
It's an encrypted block device, not filesystem. Presumably it's LUKS, for which header backups are recommended but not automatic. Re: gitlab.com/cryptsetup/…/FrequentlyAskedQuestions.
> I should have mentioned that I used pbkdf2 explicitly when setting up my luks2 partition.
Got it, so you (knowingly?) decreased the security of your key derivation function to prevent a mostly theoretical (for most people) attack.
There's a reason argon2(i)(d) is the default for LUKS2. From the cryptsetup wiki:
>There is some discussion that a hash-function should have a "large memory" property, i.e. that it should require a lot of memory to be computed. This serves to prevent attacks using special programmable circuits, like FPGAs, and attacks using graphics cards. PBKDF2 does not need a lot of memory and is vulnerable to these attacks. However, the publication usually referred in these discussions is not very convincing in proving that the presented hash really is "large memory" (that may change, email the FAQ maintainer when it does) and it is of limited usefulness anyways. Attackers that use clusters of normal PCs will not be affected at all by a "large memory" property. For example the US Secret Service is known to use the off-hour time of all the office PCs of the Treasury for password breaking. The Treasury has about 110'000 employees. Assuming every one has an office PC, that is significant computing power, all of it with plenty of memory for computing "large memory" hashes. Bot-net operators also have all the memory they want. The only protection against a resourceful attacker is a high-entropy passphrase, see items 5.9 and 5.10. > >That said, LUKS2 defaults to Argon2, which has a large-memory property and massively reduces the advantages of GPUs and FPGAs.
I'd much rather have a stronger (more resistant) key derivation function than an encrypted boot if I had to choose one. Namely because it's much more likely that a laptop is stolen and people try to crack the encryption of the disks.
That is strange. If the formatting overwrote anything it should probably fail to decrypt at all.
You can check the cryptsetup wiki but I'd still think a reinstall from backup would be easier.
Unlocking a LUKS device takes very long. Why?
It's a security feature. If you artificially slow down key unlocks so that every attempt to check a key takes multiple seconds then you are guaranteed that nobody has the computing resources to crack your key.
This timely… the author pans ZFS as buggy and recommends LUKS as an alternative. Meanwhile, a critical vulnerability has been discovered in the latest LUKS that ALLOWS AN ATTACKER TO DECRYPT YOUR DATA.
https://gitlab.com/cryptsetup/cryptsetup/-/commit/0113ac2d889c5322659ad0596d4cfc6da53e356c
/luks you had one job…
This timely… the author pans ZFS as buggy and recommends LUKS as an alternative. Meanwhile, a critical vulnerability has been discovered in the latest LUKS that ALLOWS AN ATTACKER TO DECRYPT YOUR DATA.
https://gitlab.com/cryptsetup/cryptsetup/-/commit/0113ac2d889c5322659ad0596d4cfc6da53e356c
/luks you had one job…
https://gitlab.com/cryptsetup/cryptsetup/-/commit/0113ac2d889c5322659ad0596d4cfc6da53e356c
​
Fixed CVE-2021-4122
The patch notes shed a bit more light on the vuln: https://gitlab.com/cryptsetup/cryptsetup/-/commit/0113ac2d889c5322659ad0596d4cfc6da53e356c
Particularly this line may relieve some tension:
>The decryption step is performed after a valid user activates the device with a correct passphrase and modified metadata.
Basically, someone would need to access your server while it's offline, modify some metadata to simulate a failure to decrypt data, and then they need to access your server again after you put the encryption key back in and start everything back up. In the event of theft or seizure, your data is still secure.
hello here i found new driver for firecuda 520 1gb on this link firmware version STNSC016,
maybe this driver help you?
https://gitlab.com/cryptsetup/cryptsetup/-/issues/639#note_645659810
Q: No Pop_OS-oldkern.conf to boot?
Try unlocking the drive with "Disks" gnome-disks
If the device path is correct
sudo blkid -sPTTYPE -sTYPE /dev/sd* /dev/nvme*
it sounds like the header is damaged or changed?
You should build a new 21.10 ISO on a new USB and try unlocking with that.
Frequently Asked Questions Cryptsetup/LUKS 6. Backup and Data Recovery
As always: before doing this like this READ THE LUKS FAQ, and make sure you know the possible consequences:
​
>5.21 Why is there no "Nuke-Option"?
>
>If somebody can force you to reveal passwords, then they can also do bad things to you if you do not or if you enter a nuke password instead. Think locking you up for a few years for "destroying evidence" or for far longer and without trial for being a "terrorist suspect".
sudo cryptsetup status /dev/dm-1 /dev/dm-1 is active and is in use. type: LUKS2
https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions#6-backup-and-data-recovery
Yes you can change your password phrase to the master key.
Backup all your data first.
Boot from /recovery or the Live install ISO and use gnome-disks "Disks".
select the drive (/dev/sdx) then the encrypted partition (/dev/sdx3) then "Additional partition options" (under the gear icon)
select "Change passphrase"
This does not change the master key.
>6.15 Can I clone a LUKS container?
>
>You can, but it breaks security, because the cloned container has the same header and hence the same master key. Even if you change the passphrase(s), the master key stays the same. That means whoever has access to one of the clones can decrypt them all, completely bypassing the passphrases.
For fsck (to work filesystem must be unmounted state)
#~$ sudo cryptsetup luksOpen /dev/sda3 cryptdata #~$ sudo vgchange -ay #~$ sudo lvscan #~$ fsck -pf '<dev-path-from-lvscan>' # The default is '/dev/data/root'
​
For backup read https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions#6-backup-and-data-recovery
Yes, you can adapt the commands shown in this SE answer:
https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions#2-setup :
>LUKS2:
> cryptsetup luksFormat --type luks2 <target device>
>Just follow the on-screen instructions.
>
>For LUKS2, the parameters are more complex. ARGON2 has iteration, parallelism and memory parameter. cryptsetup actually may adjust the memory parameter for time scaling. Hence to use -i is the easiest way to get slower or faster opening (default: 2000 = 2sec). Just make sure to not drop this too low or you may get a memory parameter that is to small to be secure.
Note that GRUB doesn't have perfect LUKS support, so depending on what version Ubuntu/GRUB you're running, check up on which LUKS mode you can (and should) use. GRUB doesn't support LUKS2 with Argon, for example. To my limited knowledge, LUKS1 remains popular even in 2021.
Did it work? Did you confirm the data is encrypted? The LUKS FAQ says there's no way to do it, but does also say remaining data is left behind, so I'm curious if this works.
https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions#2-setup
>2.5 Can I encrypt an existing, non-empty partition to use LUKS?
>There is no converter, and it is not really needed. The way to do this is to make a backup of the device in question, securely wipe the device (as LUKS device initialization does not clear away old data), do a luksFormat, optionally overwrite the encrypted device, create a new filesystem and restore your backup on the now encrypted device. Also refer to sections "Security Aspects" and "Backup and Data Recovery". For backup, plain GNU tar works well and backs up anything likely to be in a filesystem.
> The header has changed in its structure, but the cryptography is the same.
> The legacy LUKS (referenced as LUKS1) will be fully supported forever as well as a traditional and fully backward compatible format.
> The LUKS2 is inspired by LUKS1 format and in some specific situations (most of the default configurations) can be converted in-place from LUKS1.
Source: release notes faq specification
So it seems that both version are secure, just that LUKS 2 has a few goodies baked in, which GRUB does not support yet.
Formatting my system drive is postponed until further notice. I just read the whole FaQ Cryptsetup/LUKS page and a saw a few guides on btrfs.
I'm about to use btrfs on luks for an hdd I'm going to use for backups. I was thinking about not Partitioning the drive and encrypting the whole drive with luk2. Then formatting the volume with btrfs and putting all the data in a subvolume. Does that sound fine? Would there be any reason to create a partition first?
I'm not an expert, but I've read that any sort of pattern is breakable. As you have now published this pattern, it will become part of the knowledge (if it wasn't already) and thus added to the hacking algorithms.
However, something else to note: As u/jarkum said, it might be better to stick with something that you can remember. You don't want to have to depend on a changeable standard. What I mean is this…
What if you have to use your password on a different keyboard? For example, I use a UK keyboard (that's where I live), but what if I had to type this on a US keyboard? The pattern would be different.
Stick to characters that are available on any keyboard that supports your language. The documentation for cryptsetup (used in Linux) recommends using only the 95 printable characters from the first 128 characters of the ASCII table. They'll always have the same binary (internal) representation on any computer regardless of keyboard.
Caveat: This applies to English and to languages that use a similar alphabet. But the principle applies to any language.
Source: cryptsetup documentation, 1.2 WARNINGS, "PASSPHRASE CHARACTER SET"
Also, the relevant printable set of characters.
This link (by the LUKS coder I think?) goes into detail about how secure LUKS is and what sort of passphrase you need.
Relevant blurb: > LUKS1 and LUKS2: Use > 65 bit. That is e.g. 14 random chars from a-z or a random English sentence of > 108 characters length. > If paranoid, add at least 20 bit. That is roughly four additional characters for random passphrases and roughly 32 characters for a random English sentence.
LUKS stores the same information on disk:
> For a key slot, all parameters how to decrypt its key material with a given user password are stored in the phdr (f.e. salt, iteration depth).
From: https://gitlab.com/cryptsetup/cryptsetup/-/wikis/LUKS-standard/on-disk-format.pdf
The access key is stored in the encryption header, rather than in the encrypted OS. If the key were stored in the filesystem being encrypted, then you'd run into a chicken-egg problem where you would be unable to decrypt the data (since the system needs access to the key to decrypt).
Instead you need to get the header itself which is accessible through cryptsetup.
First, you need to get the ID of your LUKS Volume. You can find this using cat /etc/crypttab | echo cryptdata. You want to copy all of the UUID=xxxx part, including the UUID=. Then you can run these commands to create a backup:
sudo cryptsetup luksHeaderBackup UUID=xxx --header-backup-file ~/headerbackup
sudo chown $USER:$USER ~/headerbackup
This will create a header backup in your home folder. Please note that this will allow decryption of your data, even if you change the decryption password, if someone gains access to it, so be careful about who gets access to this.
For more information, see: https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions https://linux.die.net/man/8/cryptsetup
Ah - in that case, not sure I can help you there. Since LUKS uses an encryption cipher known as PBKDF2, which is is part of the PKCS #5 suite of ciphers, it's very hard to break if a good password is used. It also has a number of other security measures to make sure it's cryptographically secure, so I'm not sure you'd have much luck breaking the actual encryption. You can read about it in LUKS's TKS1 compliance page on their GitLab.
Really, as long as you use a proper password it'd be pretty dang hard to actually decrypt your data.
Depends how sensitive the data is / how paranoid you are and what disk type you have.
You'll probably be OK, but check out the FAQs for LUKS, specifically 5.4, 5.7 and 5.19: https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions
As an aside, I would definitely look for the >6.6.0 bios, I didn't have an issue booting the r710 without a card in the storage slot.
As for your performance issues, you will have to do some troubleshooting to narrow the possible causes. One place to start would be to read here: https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions#user-content-2-setup
There's a section on considerations for LUKS on RAID storage and since LUKS isn't RAID-aware, there are a few ways to setup luks with ZFS and it seems they don't all perform the same.
According to the cryptsetup FAQ:
> * 2.4 What is the difference between "plain" and LUKS format? > > First, unless you happen to understand the cryptographic background well, you should use LUKS. It does protect the user from a lot of common mistakes. Plain dm-crypt is for experts. > > Plain format is just that: It has no metadata on disk, reads all parameters from the commandline (or the defaults), derives a master-key from the passphrase and then uses that to de-/encrypt the sectors of the device, with a direct 1:1 mapping between encrypted and decrypted sectors.
A plain dm-crypt volume has no metadata, i.e. it looks like a uniform blob of random bytes. Thus:
- The decrypted volume consists of random bytes and all-zero (or otherwise obviously non-random data). It is a red flag for the random bytes to be surrounded by structured data or all-zero data and strongly suggests as much.
- The decrypted volume consists of a filesystem, which is a more convenent subcase of (1). You can thus go down the filesystem and check for high-entropy files; all high-entropy files are credible candidates for encrypted data (few people store random garbage in files), though no strict proof.
- The decrypted volume consists of random bytes only. There is no way to tell if there is another, nested volume and if so, where.
>If you trust more then that is not an alternative.
I didn't catch your meaning ;)
You have been around Monero a long time. How do you secure your cold storage?
I am trusting LUKS and Moneromooo's JavaScript.
https://gitlab.com/cryptsetup/cryptsetup
"Cryptsetup is a utility used to conveniently set up disk encryption based on the DMCrypt kernel module.
These include plain dm-crypt volumes, LUKS volumes, loop-AES, TrueCrypt (including VeraCrypt extension) and BitLocker formats."
So some bitlocker formats will be available in linux.
Both filevault and bitlocker are proprietary and owned by big companies. Since their code is closed source you can only speculate as to whether there is a backdoor. They hire people to say that it is safe. Some companies will specialise in software to break the security of devices/computers for law enforcement etc. They may have discovered bugs that have not been reported yet.
If your computer is switched off, your bitlocker tech should be able to resist the average joe-blogs attempts if they switch it on, but it may be possible to get in for well-funded attackers. If you use veracrypt or other multi-platform encryptors you can make drives that are accessible from all OSs. But if someone gains root access to a linux/win/mac that uses a veracrypt partition they can compromise it. I'd just stay with bitlocker unless you have a good reason.
The three types are incorporated from the SCSI Block Commands-3 standard. The relevant information would seem to be in section 4.19 beginning on page 55 (pdf page 81).
If I'm reading it correctly, the difference between types has to do with what is contained in the LOGICAL BLOCK REFERENCE TAG, and an implementation would use all 3 types together to detect errors where the address is corrupted. In that case you'd get a matching block and checksum from the wrong place on the disk. So the integrity information must contain not only a checksum, but also a sequence number.
You can get similar functionality with dm-integrity (1, 2). Also the ZFS and btrfs filesystems do their own checksumming internally, although they're quite a bit slower than traditional filesystems. XFS has checksumming for metadata only, and is fast.
I have a hunch that the performance cost of dm-integrity might be less severe on NVME, because seeking isn't so expensive like it is on a mechanical disk, and NVME is known to scale well with queue depth.
I haven't used it. My important stuff is backed up and the original / replicated copy is stored with an offsite service (not self hosted obviously).
​
BUT - Apparently mdadm with dm-verity will be bitrot proof
https://gitlab.com/cryptsetup/cryptsetup/-/wikis/DMVerity
​
Also btrfs is also bitroot proof or so I'm told, but I've had poor experiences with it personally (perhaps user error).
> I couldn't find an answer anywhere so I though I'd ask here...
The cryptsetup team on GitLab can give you a definite answer. It's not yet answered in their FAQ, but that might change after you've asked them :)
>Is there a way it could “self destruct” if the password is entered wrong too many times?
Dont think that would help with anything.
Now think of the typical LUKS application scenario, i.e. disk encryption. Usually the ones forcing you to hand over your password will have access to the disk as well, and, if they have any real suspicion, they will mirror your disk before entering anything supplied by you. This neatly negates any Nuke-Option. Source:LUKS
Thanks for the link, I'll have a look. I ended up doing 'sudo gnome-system-monitor' which allowed me to see the same info. I also read in the cryptsetup FAQ about a way of writing random data with dm-crypt which is apparently also faster: https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions
There's lots of other interesting information on there as well.
No, i have not seen any problems with dislocker.
Cryptsetup is also working on adding dislocker support and when a version with the support is released, zuluCrypt will add a runtime option to switch between cryptsetup and dislocker to manage BitLocker volumes.
In my option BitLocker support from cryptsetup is better because it is a system tool and is installed by default in most distributions but it does not support all BitLocker options.
unsure about the specifics on encrypted drives, but you might find some useful info in wiki's, i.e arch or gentoo, or maybe off the gitlab FAQ
Yeah.. I would have thought that would be the better design. LUKS designers do mention that you should backup the header and the data: https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#6-backup-and-data-recovery
What do you mean by `easy change of password on the disk`? like based on how much time it would take?
Do you know if Veracrypt is based on the same idea? Or does a change in the password, decrypt and re-encrypt the entire drive? I would prefer this, even if it takes longer time to do so.
My first one is zuluCrypt. I bought a hard drive and i wanted to encrypted it because why not. I already knew about TrueCrypt but i didn't want to use it because i saw it as primarily a windows solution and i wanted to use a native solution for linux.
The native solution for linux is cryptsetup. Its a CLI tool and requires to be run from root's account and it got annoying pretty quickly using it and i started the problem to give cryptsetup a GUI tool for my own convenience.
SiriKali, my other project and a fork of zuluCrypt is there to offer GUI front end to CLI tools that deal with folder based encryption.
Using encrypted folders seems more convenient that using multiple large files when doing file based encrypted containers.
Yes, LUKS and very recently LUKS2. We'd been using the system-drive LUKS encryption baked into Linux installers for a while, but it took a while to switch over to LUKS for all other removable media housing data. The decryption isn't tedious, and typically is only required once per system boot.
Looks like it: https://wiki.archlinux.org/index.php/Dm-crypt/Device_encryption#Encryption_options_with_dm-crypt (scroll down to encryption options with LUKS mode)
You may be interested in the project FAQ as well: https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions
The release notes for version 2.0.0 say only a few are currently available. I tried: $ cryptsetup luksFormat --type luks2 <device> --cipher aes-xts-plain64 --integrity hmac-sha256 and $ cryptsetup luksFormat --type luks2 <device> --cipher chacha20-random --integrity poly1305 which resulted in very similar results. None of the newer release notes make any mention of additional algorithms being available.
>could you elaborate on LUKS?
It's full disk encryption implementation on linux. Not sure if you will be able to boot up on anything else. There are drivers for Windows for non-bootable LUKS volumes. Don't know about Mac.
https://gitlab.com/cryptsetup/cryptsetup/wikis/home
>I'm sure it's possible to make a software solution out of this.
Well those who make encryption systems do not guess, they actually know. You set iPhone as an example, but in case of San Bernardino shooters a private firm bruteforced the pin/pass. It made thousand attempts without erasing the phone because there are ways around the software protection. And what way yesterday available only to select parties will be everywhere tommorow.
​
>Also an SSD delete isn't as complex as everyone says. It's just logic - fill your drive with random data.
There's always 'reserved' space on SDDs. Your SDD is sold as 480Gb but the chip is actually 512. So there's 32Gb wear-levelling 'cache'. Some manifacturers have it larger, some smaller, but it's always there. And you cannot access it, without soldering directly to the chips inside.
​
I understand that what you encountered was different, that this kind of protecttion would've been sufficient. But I am trying to say that if you are going to prepare for the next time you should do it properly. For one thing, next time something like this happens, your record will be pulled and it will show that you were already searched once, which may flag you as a 'known offender' and a more thorough search this time.
For full system drive encryption, Linux uses LUKS, you have to choose the option during the install process. You can't use VC to encrypt a Linux OS (but it's fine for non system ones).
As for the comparison with VeraCrypt, in terms of "strength" and security, the LUKS settings are defined by the distribution but most (if not all) uses the same defaults as VeraCrypt (AES 256, XTS, PBKDF2 and SHA256). The only difference being that VC uses a fix iteration count for PBKDF while LUKS adjusts it after a CPU benchmark.
A few things that are good to know about LUKS before starting
There's no GUI for it, you can graphically encrypt drives from a partition / disk manager but maintenance is performed via command line (say, changing or adding new passphrases.)
That also means that while VC prompts you to create a rescue disk, containing a header backup, that's something you'll have to do yourself once you're done installing. Do not skip that part.
You can check the LUKS/Cryptsetup FAQ for guidance, just don't mind some sections that are not up to date (it's still mentions the use of SHA1 for instance even thought the default has been SHA256 for a while).
And that should be enough for the big picture :)
Adiantum encryption is already supported by cryptsetup v2.0.6 and later for full-disk encryption with dm-crypt, and by the git version of the fscrypt userspace tool for file-based encryption with fscrypt.
Eric Biggers pointed out to me that LUKS does now supports Adiantum https://gitlab.com/cryptsetup/cryptsetup/blob/master/docs/v2.0.6-ReleaseNotes#L55
This FAQ seems to address your question:
https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions
2.5 Can I encrypt an already existing, non-empty partition to use LUKS?
There is no converter, and it is not really needed. The way to do this is to make a backup of the device in question, securely wipe the device (as LUKS device initialization does not clear away old data), do a luksFormat, optionally overwrite the encrypted device, create a new filesystem and restore your backup on the now encrypted device. Also refer to sections "Security Aspects" and "Backup and Data Recovery". For backup, plain GNU tar works well and backs up anything likely to be in a filesystem.
Assuming your question is : is one better than the other ? Well, first, to encrypt a Linux system partition, you don't have much of a choice, you have to use LUKS/cryptsetup (it's technically possible to use VC but it's not supported and requires some handy work you probably don't want to get into.). You can use Veracrypt in Linux though, for non system volumes or file containers.
While there are a few differences (and features that one has and the other doesn't), at core, they work in very similar ways and you end up with the same level of encryption. Again, since you don't really have a choice, probably best not to overwhelm you with too many details.
An important one though : LUKS creates a file called a LUKS Header at the beginning of your drive (so does VC but it has 2 versions of it). It's very small but it's very important and if it's damaged you lose everything. Doesn't happen every other day but having a backup stored in a safe place is far from being a bad idea. See here or there. Oh yeah, that's another difference between LUKS and VeraCrypt, the former doesn't have any graphical interface :)
As a side note, since this is a topic often either overlooked or overhyped, people sometimes skips the drive erasure before encrypting, thinking that encryption will be enough. It's not, so if the drive ever contained important data, it will remain there until it eventually gets overwritten by new one. If you skipped that part and suddenly realize it was a mistake but don't want to start over, there are solutions.
Check the "Design Goals" section:
https://gitlab.com/cryptsetup/cryptsetup/blob/master/docs/on-disk-format-luks2.pdf
Personally, reading that, I wouldn't rush to upgrade. But at some point in the future, I may decide to make a backup and reinstall. Or make a backup and try the crypsetup convert routine. The benefits are good but slightly esoteric, although dropping SHA1 is a good thing. But this only likely to matter if a nation state or professional crime syndicate is after your data.
Your data should be gone. the best way to make sure of it is to simply run any recovery tool. Now, if you want to go the full blown "let's do encryption the right way", you're supposed to fill the drive with random data before encrypting it, not zeroes, which is what hdparm has done (unless the drive is self-encrypting in which case it may have perform a crypto scramble). The point being to make sure that used space is impossible to distinguish from free space, which can lead to some advanced forensic attacks (so it's a bit overkill for most people seems you seem concerned :) ). The Cryptsetup FAQ has a "tip" to do it slightly faster (see section 2.19) by, say "encrypting zeroes".
As for the differences between VeraCrypt and LUKS, there are a few, but TBH it's not like it's day and night and one is stronger or more vulnerable than the other. One difference is that LUKS can now be set to use Argon2 instead of PBKDF2 (on LUKS2) but with a 36 characters passphrase, you're pretty much covered. Both can be automatically unlocked and mounted at boot with the right entry in Crypttab (although I never tried it with VC but it's well documented online), something you might want if you have automated backups. LUKS can have up to 8 passphrases or Keyfiles, VC only one but if you ever need to plug that drive on a non Linux machine it will work. It also has hidden volumes but first, plausible deniability is always a debatable topic and second it doesn't fit your need
Personally I'd just stick with LUKS, especially if you're encrypting your system as well since VC can't do that on Linux.
2 quick reminders : encrypted drives must be backed up and whatever option you choose, you need to keep copies of the headers.
I suspect what you want is LUKS using dmcrypt: https://gitlab.com/cryptsetup/cryptsetup/
I personally use CryFS for an encrypted folder on Dropbox, however, they do have a good comparison page of some alternatives here: https://www.cryfs.org/comparison
Try:
cryptsetup --version
That will show you the version of cryptsetup you're currently using.
LUKS Version 1 refers to the on-disk format version, which has subsequently been renamed to LUKS1. Starting with cryptsetup version 2.0.0, a new on-disk format has been introduced called LUKS2, which is, as of this post, still experimental. See the in progress docs on LUKS2.
TrueCrypt and VeraCrypt on linux by default are nothing but a glorified on-disk parser. All they do is parse the header to get crypto properties and passes them along to dm-crypt where all the heavy lifting is taking place.
If you do not trust VeraCrypt,the binary application, you can use zuluplay to create and unlock VeraCrypt volumes. zuluplay is a CLI tool and zuluCrypt is its GUI front end.
cryptsetup can also unlock TrueCrypt/VeraCrypt volumes. cryptsetup is a native tool in linux for block device encryption and it too,like TrueCrypt/VeraCrypt and zuluplay is nothing but an on-disk parser and all the user data encryption/decryption is done by a kernel infrastructure known as "dm-crypt".
Regarding enabling more modes in kernel: Enabling cryptographic API functions (also see /proc/crypto)
https://wiki.gentoo.org/wiki/Dm-crypt
I would avoid using less known cryptos or combinations. As far as I know, the default configuration is solid and more focus should be put on protecting against evil made attacks and attacks on you password.
"The default cipher for LUKS is nowadays aes-xts-plain64, i.e. AES as cipher and XTS as mode of operation. This should be changed only under very rare circumstances. The default is a very reasonable choice security wise and by far the best choice performance wise that can deliver between 2-3 GiB/s encryption/decryption speed on CPUs with AES-NI."
https://wiki.gentoo.org/wiki/Dm-crypt_full_disk_encryption
https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions
May 4, 2016 page 7 from https://gitlab.com/cryptsetup/cryptsetup/wikis/LUKS-standard/on-disk-format.pdf
Also the reason it makes no sense is the verification should be a hash of the key. Since if it is harder to check then a password cracker will just decrypt part of the hard drive to see if it is a valid file system.
Note "masterKeyIterations" is not the same as "passwordIterations":
masterKey = decrypt(encryptedMasterKey, PBKDF2(password, passwordSalt, passwordIterations)) masterKeyHash == PBKDF2(masterKey, masterKeySalt, masterKeyIterations)
Never heard about it until now. I guess you mean this.
So I guess one would install a standard Linux distro and set up a partition as the secure disk. Pretty much as described above, unless I mistake you?
What I don't get is the HTTP part? How were you imagining we would read/write files on Windows/Linux if we did not mount the drive?
If you are using LUKS you don't have to do a complete secure wipe (it's still advice able but not necessary) but you should override the LUKS header.
https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#5-security-aspects
> # dd if=/dev/zero of=/dev/mmcblk0 bs=4M status=progress
>But may I ask why you do this?
Presumably OP wants to wipe the drive. In which case this might be more effective:
cryptsetup open --type plain -d /dev/urandom /dev/mmcblk0 to_be_wiped cat /dev/zero > /dev/mapper/to_be_wiped
Re: gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions.
Cryptsetup is generally superior to Truecrypt for FDE, IMO.
https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#5-security-aspects
That is a great primer on it and even covers things like plausible deniability. Highly recommended read.
If you have compliance needs regarding sensitive data, NIST 800-88 is a good read. So is the CryptSetup FAQ. If you skip to 5.19 there is a great little section on SSDs. Particularly about key management.
The latest SP 800-88 includes guidance for SSDs, and the ATA Secure Erase command that for magnetic HDDs counts as a "Purge" only counts as a "Clear" for SSDs. There's a new ATA Sanitize specification that works for "Purge" but I suspect it isn't widely implemented yet and I know little about it.
Bottom line for me: I always shred or Secure Erase (and verify) HDDs, and shred SSDs if they contain protected data and are leaving organization control. I don't want something in the future to come back to bite me for not following accepted guidance.
What're you looking to encrypt?
Messages/files being sent: GnuPG which is based on public key crpyto making it easier to send and receive messages as you can exchange public keys on an insecure channel.
Whole drive/folders only used by you: I would say Truecrypt, but the Windows driver was recently compromised. I've heard decent things about Veracrypt which is a Truecrypt fork. If you're on Linux, there's also LUKS.
(I was going to reply to the OP before it got deleted.)
See the cryptsetup FAQ, sections 2.9 and 5.12. Cryptsetup treats passphrases in a keyfile and on stdin differently. When you use a keyfile, the content of that file is used directly as the master key; there is no hash applied. What it's telling you is that the hash parameter is a no-op and likely to be confusing.
If you are using a keyfile containing random binary data, use --hash=plain. This is what cryptsetup does anyway, and it will make its behavior consistent whichever way it is run.
cryptsetup open --type=plain --hash=plain --key-file /dev/sdf
If your keyfile is just a human-readable passphrase in a file, keep the --hash=sha512 and either type it in manually or pipe it in with something like
cat /dev/sdf | cryptsetup open --type=plain --hash=sha512 ...
thats not an issue, its just a matter of updating packages.
so it looks like the nuke was not integrated into cryptsetup, but kali does a good walk through on how to set it up and use it.
I think the TrueCrypt developer meant the TrueCrypt application was the ones that was insecure,not the on-disk format.If they meant the on-disk format,i think they would have said "using TrueCrypt volumes" and not simply "using TrueCrypt"
The TrueCrypt on-disk format is a bit dated but its sound enough and it has multiple implementations so i think enough people have looked at it and document it as they implemented it.cryptsetup documentation of the on-disk format is here[1] for example.I his passes the on-disk format as being audited.
I know of one issue that TrueCrypt binary application has.If you know of a linux based computer out there with truecrypt installed and set up for the public to use to manage their truecrypt volumes,then you can use a "specifically crafted truecrypt volume" to gain root shell on that computer.The bug is in truecrypt mounting volumes with setuid option set.
i guess you meant cryptsetup hasnt had an audit yet when you said LUKS hasnt had one.LUKS is an on-disk format[2] and it also has multiple implementations so i guess enough people have looked at it as they implemented and i think this passes as being audited.
cryptsetup is the reference implementation of LUKS format and also is the most widely used implementor of the format.
i am not aware of any cryptsetup audit.
[1] https://gitlab.com/cryptsetup/cryptsetup/wikis/TrueCryptOnDiskFormat
[2] https://gitlab.com/cryptsetup/cryptsetup/wikis/Specification