How resilient are VeraCrypt and LUKS encrypted volumes against data corruption?

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

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.

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.

The following relates to your section "Update 1".

Both Veracrypt and LUKS provide the same resilience towards random data sector failures assuming that you successfully mounted the partitions.

The reason is that they both act as an additional layer below the operating system read/write function of sectors. They provide sector-oriented encryption. Both encryption schemes do not change the on-disk structure layout.

This way of operation does not correspond to the limitations of the storage technique of a solid 7z archive. It even does not correspond to that of a normal 7z archive.

In addition to that please keep in mind the situation before mounting. The anti-forensic techniques of LUKS blow up metadata to 3 sectors (header) + 4000 (stripes) * 16 (assumed max key length) * 8 (key slots) bytes = 512003 bytes =~ 1000 sectors. There is no backup of this structure available.

Compare this to a standard Veracrypt header (only data, no hidden partition) with 512 byte = 1 sector. In addition to that, there is a backup header at the end of the file system.

The header resilience of LUKS compared to Veracrypt is about 0,1% as one bad sector used by the LUKS header can make the disk unreadable. I am writing "can" as I am unable to determine reading the on-disk format specification if such a shot will affect all 8 available key slots or just one.