15

The question has been partly answered, but that's still not what I'm exactly looking for. See for Update 1 down bere

I'm planning to encrypt some filesystems with VeraCrypt and LUKS, but my fears are that if a single problem happens, I would not be able to mount the partitions again thus losing all the data stored inside them. (due to damaged sectors/blocks, power failure during a writing operation, file system errors, etc)

Also, VeraCrypt may have forked TrueCrypt's repair tools, but I'm not counting on it and looking more about real cases.

I also know about RAID and backups/vaults, but it's not what I'm looking for.

So the question is: How resilient are encrypted partitions themselves with VeraCrypt and LUKS ?

Update 1:

My question is more about the resilience of the encrypted partition and its data, rather than about saving the master key, metadata or headers. The problem is similar to a solid 7zip archive: if a single bit is damaged in the middle, then you lose the whole archive.

Will encrypted partitions be as vulnerable ? (excluding master key, metadata and headers)

PS: Sorry if I don't answer right away, I'm working and travelling around the world -thus making this post related- and I often face time-squeezing business. But, I will definitely answer back for sure.

13
+100

In practice, it's almost as resilient with encryption as without it, as long you backup the master key and metadata properly.

Apart of metadata, the corruption would affect just the block of the corrupted bit, in most cases just 16 bytes of it.

For most of the situations of data corruption, with the key and tools (like your password and Veracrypt/LUKS), you have the same access as a non encrypted disk, just like you do normally with everyday use of a encrypted disk. Encryption would only add a additional step (open a encrypted partition) than ordinary. So in this case, it behaviors just like non encrypted data.

With Veracrypt or Luks, you have to store the master key in the disk, that is encrypted with your password. Damaging this sector(s) would cause permanent data lost. This can be easily solved with master key backup (few kilobytes in size), something easy to do with both software, and it's highly recommended for everyone.

Details about non meta data

Both Veracrypt and Luks uses XTS today. In this mode, it's calculated a key for every block. In a simplification, to encrypt block i you use a key generated with the Master Keys and the block number. So, the encryption of one block in independent of another. If you corrupt some information, it will be restrict to that block.

In XTS, it breaks the block in sub-blocks (of 16 bytes usually) and creates a key, and encrypt that sub-block with it. That means that if we change a bit on it, only this 16 bytes would be affected.

As as test, changing a single bit in a Luks volume, it changes 16 bytes of the original file to gibberish, but the others 496 stills unchanged. In a 7zip file, it uses a stream method, that all bytes are chained, so one byte change would affect all the remaining ones - this is not the case here.

Some consider this a problem, as you can know with precision of 16 bytes when and where you change a plain text, comparing just the encrypted data.

More interesting information about this can be found on these links:

https://crypto.stackexchange.com/questions/6185/what-is-a-tweakable-block-cipher

https://security.stackexchange.com/questions/39306/how-secure-is-ubuntus-default-full-disk-encryption

https://en.wikipedia.org/wiki/Disk_encryption_theory

Details about Master Key

LUKS

LUKS have a few sectors in the beginning of the partition (or disk) with metadata, storing encryption methods, other parameters and 8 key slots. For encrypting and decrypting the disk, it uses a Master Key, a big random number generated when create a LUKS container. To store it, it encrypt the Master Key with your password, through iterating a cryptographic hash function many times over the password and generating a specific key for that slot. You can have 8 different passwords for the same disk, each one encrypting the master key with a different password in a slot. When you change the password, It's as simple as encrypting the Master Key, and not changing all the partition.

So, when this slots and metadata is corrupted, you can't recover the master key that is really used to decrypt, losing all data on disk. This is a easy way to fast destroy all your data. But if you have a backup of the Volume Header, it's pretty easy to recover it.

Below is a copy of LUKS FAQ about backup extracted from https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#6-backup-and-data-recovery

6.2 How do I backup a LUKS header?

While you could just copy the appropriate number of bytes from the start of the LUKS partition, the best way is to use command option "luksHeaderBackup" of cryptsetup. This protects also against errors when non-standard parameters have been used in LUKS partition creation. Example:

cryptsetup luksHeaderBackup --header-backup-file <file> <device>

To restore, use the inverse command, i.e.

cryptsetup luksHeaderRestore --header-backup-file <file> <device>

If you are unsure about a header to be restored, make a backup of the current one first! You can also test the header-file without restoring it by using the --header option for a detached header like this:

cryptsetup --header <file> luksOpen <device> </dev/mapper/ -name>

If that unlocks your keys-lot, you are good. Do not forget to close the device again.

Under some circumstances (damaged header), this fails. Then use the following steps:

First determine the master-key size:

cryptsetup luksDump <device>

gives a line of the form

MK bits:        <bits>

with bits equal to 256 for the old defaults and 512 for the new defaults. 256 bits equals a total header size of 1'052'672 Bytes and 512 bits one of 2MiB. (See also Item 6.12) If luksDump fails, assume 2MiB, but be aware that if you restore that, you may also restore the first 1M or so of the filesystem. Do not change the filesystem if you were unable to determine the header size! With that, restoring a too-large header backup is still safe.

Second, dump the header to file. There are many ways to do it, I prefer the following:

head -c 1052672 <device>  >  header_backup.dmp

or

head -c 2M <device>  >  header_backup.dmp

for a 2MiB header. Verify the size of the dump-file to be sure. To restore such a backup, you can try luksHeaderRestore or do a more basic

cat header_backup.dmp  >  <device>

Veracrypt

Veracrypt is similar to LUKS. I'm not used with it as I was with Truecrypt, but the general idea holds.

Veracrypt just have one key slot, so you can't have more than one password at the same time. But you can have a hidden volume: it's stores the metadata in the end of the partition (or disk or file). The hidden volume has a different Master Key and will use the end of the partition as overlapped space. The idea that you should backup is the same. This can be done with Tools -> Backup Volume Header and Tools -> Restore Volume Header. With system encryption, it used to create a bootable disk with key backup that recovers the Truecrypt loader and keys if any damage happens. It's done before it encrypt anything, and As far as I know Veracrypt continue doing the same way.

For more details see this link https://veracrypt.codeplex.com/wikipage?title=Program%20Menu

Security Considerations About Backup Keys

If you have a leaked password for example, and changes the volume password to a new, strong and secure one, someone with access to the backup would stills being able to decrypt the files with the old password. The backup is basically the Master Key encrypted with the (old) password. So, when changing passwords, it's also needed to make a new backup and destroy the older ones. And destroying data permanently can be very trick.

For every backup you have with that password, is a possible way to decrypt data with that password. This can be used in Veracrypt for instance, using a "Universal Password" (like in a corporation), backing it up and changing for another password. So the IT dept. could recover the access to that volume even if someone lost the password (think as a Master Password, but don't confuse with the Master Key from earlier).

Final Thoughts (TL;DR)

The probability of damaging the specific sector with the master key is less likely than you having a complete disk failure. So if this data is important, you should have a backup of it instead just the volume headers (Master Key).

And corruption of data spread little (16 bytes), resulting acceptable for most uses.

So a bad block in the middle of the partition or disk would affect only that block. And a few bits errors in a sector is restricted to that sector, and won't even affect totally a 512 bytes sector.

Update (23/01/2017): add more information based on the OP comments.

  • 1
    Wow, that was a very extensive and informative answer, thanks a lot ! However, my question is more about the resilience of the encrypted partition and the datas itselves, rather than the master key and metadata. The problem is similar to a solid 7zip archive: if a single bit is damaged in the middle, then you lose the whole archive. Will encrypted partitions will act the same ? (master key and metadata excluded) – X.LINK Jan 15 '17 at 17:38
4
+25

I have compiled below some information about the resiliency of VeraCrypt/TrueCrypt containers.

From Veracrypt data corruption :

TC/VC store the volume header at two place: at the start and at the end of volume. The one at the start is the main one and the one at the end is for backup. This mechanism is usually sufficient to enable access when a part of the drive is damaged or corrupted because the damage is often local. if the damage occur to both the start and the end of the drive, then the drive is almost certainly dead.

Please note that in case of a damaged or corrupted drive, you'll have the same data loss as when you don't use encryption. This means that even if you are able to mount the volume, there data read may be corrupted. So, always think about data backup because encryption doesn't protect from data corruption.

From the VeraCrypt FAQ :

What will happen when a part of a VeraCrypt volume becomes corrupted?

In encrypted data, one corrupted bit usually corrupts the whole ciphertext block in which it occurred. The ciphertext block size used by VeraCrypt is 16 bytes (i.e., 128 bits). The mode of operation used by VeraCrypt ensures that if data corruption occurs within a block, the remaining blocks are not affected.

What do I do when the encrypted filesystem on my VeraCrypt volume is corrupted?

File system within a VeraCrypt volume may become corrupted in the same way as any normal unencrypted file system. When that happens, you can use filesystem repair tools supplied with your operating system to fix it. In Windows, it is the 'chkdsk' tool. VeraCrypt provides an easy way to use this tool on a VeraCrypt volume: Right-click the mounted volume in the main VeraCrypt window (in the drive list) and from the context menu select 'Repair Filesystem'.

Small data corruption should then have only local effect and will not destroy the entire container. However, I advise against encrypting a whole volume/partition and especially the system drive, as recovery can then be more complicated. Take good backups, especially for the volume header. And remember that, just as for a real disk or folder, corruption in the disk/file headers may make data recuperation difficult and may require advanced utilities.

I believe that LUKS does not have a second header on disk, so you have to be even more careful about keeping a backup.

  • I've read those but this is still a bit confusing. Apart from recoveries made through containers' headers and filesystems inside containers, does it means that a bad sector right in the middle of a container itself won't make it completely dead and impossible to mount ? As I may understand it right, does a ciphertext block works exactly like inside a non-solid 7-zip archive/unencrypted ext3 still mountable have physical bad sectors ? – X.LINK Jan 18 '17 at 15:56
  • I can't speak for encrypted volumes, but changing a single bit in an encrypted cyphertext will just spit out garbage for the entire block. The block size might be 128 bytes or 256 bytes or 4kb. It won't prevent the rest of the cyphertext from being decrypted. There's no way for the encryption algorithm to know the garbage is bad. There is no checksum or anything (for AES-CBC). If that block was inside a text file, it will just look like garbage in Notepad. If it was part of the directory structure, then the file system will look garbled and require chkdsk. – Chloe Jan 18 '17 at 16:53
  • @X.LINK: A bad bit will corrupt its whole "sector" of 16 bytes. Depending of where that sector is located, the result can be nothing if it falls in an unused area, or garbage in that spot in the file or, in the worst case, bad directory structure requiring the use of recovery utilities. This is very similar to a physical disk where you have unused sectors, file data and disk tables, and your backup should follow similar guidelines. – harrymc Jan 23 '17 at 13:07
0

Thanks to all the answers people provided, the definitive answer is 100% complete.

I don't have much time these days, so i'll edit my "own" answer later. Since all the answers people gave here are completely useful, this will just be a recap of what they said, plus my findings too.

Anyway, here's one of my findings that will debunk a lot of confusion I met, and it mostly concerned... what block means, since it's a term that is overly and mistakenly used:

https://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/

Also, you'll find a "standard" way to talk about things here, and avoid the 'block' confusion:

https://superuser.com/questions/1176839/what-are-every-possible-names-of-hard-drives-structure-parts

In short terms, you can change an encrypted block containing the word "400" to be "800". This means encrypted block-level layer is completely non-solid, instead of believing that "this will act like a normal filesystem" (ie Veracrypt FAQ).

Also, I should have stumbled upon that link two months ago:

https://unix.stackexchange.com/questions/321488/full-image-of-internal-hdd-drive-dd-dd-rescue-with-truecrypt-bad-sectors/

Since VeraCrypt is a TrueCrypt's fork, it will certainly works the same.

PS:

Any additional answer is still welcome, and will be added to my "own" answer.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.