На практиці він майже такий же стійкий до шифрування, як і без нього, доки ви правильно створюєте резервну копію головного ключа та метаданих .
Крім метаданих, пошкодження вплине лише на блок пошкодженого біта, у більшості випадків - лише на 16 байт.
У більшості ситуацій з пошкодженням даних, за допомогою ключа та інструментів (наприклад, вашого пароля та Veracrypt / LUKS), ви маєте такий самий доступ, як і незашифрований диск, як і зазвичай у звичайному використанні зашифрованого диска. Шифрування додало б лише додатковий крок (відкрити зашифрований розділ), ніж звичайний. Тож у цьому випадку вона поводиться так само, як і незашифровані дані.
За допомогою Veracrypt або Luks вам потрібно зберегти головний ключ на диску, зашифрованому вашим паролем. Пошкодження цього сектора призведе до втрати постійних даних. Це можна легко вирішити за допомогою резервного копіювання головного ключа (розміром декілька кілобайт), що легко зробити з обом програмним забезпеченням, і це дуже рекомендується для всіх.
Деталі про немета-дані
І Veracrypt, і Luks сьогодні використовують XTS. У цьому режимі обчислюється ключ для кожного блоку. Для спрощення для шифрування блоку iви використовуєте ключ, згенерований за допомогою головних ключів та номера блоку. Отже, шифрування одного блоку незалежно від іншого. Якщо ви пошкодили деяку інформацію, вона буде обмежена цим блоком.
У XTS він розбиває блок на підблоки (зазвичай 16 байт) і створює ключ і шифрує цей підблок разом з ним. Це означає, що якщо ми трохи змінимо його, це вплине лише на ці 16 байт.
Як і тест, змінюючи один біт в томі Luks, він змінює 16 байт оригінального файлу на химерний, але інші 496 залишаються незмінними. У файлі 7zip він використовує метод потоку, що всі байти є ланцюговими, тому одна зміна байтів вплине на всі решта - це не так.
Деякі вважають це проблемою, оскільки ви можете точно знати 16 байт, коли і де ви змінюєте звичайний текст, порівнюючи лише зашифровані дані.
Більш цікаву інформацію про це можна знайти за цими посиланнями:
/crypto/6185/what-is-a-tweakable-block-cipher
/security/39306/how-secure-is-ubuntus-default-full-disk-encryption
https://en.wikipedia.org/wiki/Disk_encryption_theory
Детальніше про Master Key
ЛУКС
LUKS має кілька секторів на початку розділу (або диска) з метаданими, що зберігають методи шифрування, інші параметри та 8 ключових слотів. Для шифрування та розшифровки диска він використовує головний ключ , велике випадкове число, що генерується при створенні контейнера LUKS. Щоб зберегти його, він зашифрує головний ключ своїм паролем, повторивши функцію криптографічного хешу багато разів над паролем та генеруючи певний ключ для цього слота. На одному диску можна мати 8 різних паролів, кожен з яких шифрує головний ключ з іншим паролем у слоті. Коли ви змінюєте пароль, це так само просто, як шифрувати головний ключ, а не змінювати весь розділ.
Отже, коли цей слот і метадані пошкоджені, ви не можете відновити головний ключ, який реально використовується для розшифровки, втрачаючи всі дані на диску. Це простий спосіб швидко знищити всі ваші дані. Але якщо у вас є резервна копія заголовка гучності, відновити її досить просто.
Нижче наведено копію LUKS FAQ про резервну копію, вилучену з https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#6-backup-and-data-recovery
6.2 Як створити резервну копію заголовка LUKS?
Хоча ви могли просто скопіювати відповідну кількість байтів з початку розділу LUKS, найкращим способом є використання командного параметра "luksHeaderBackup" з cryptsetup. Це захищає також від помилок, коли для створення розділів LUKS були використані нестандартні параметри. Приклад:
cryptsetup luksHeaderBackup --header-backup-file <file> <device>
Для відновлення використовуйте зворотну команду, тобто
cryptsetup luksHeaderRestore --header-backup-file <file> <device>
Якщо ви не знаєте про відновлення заголовка, спершу зробіть резервну копію поточного! Ви також можете протестувати файл заголовка, не відновлюючи його, скориставшись опцією --header для окремого заголовка, як це:
cryptsetup --header <file> luksOpen <device> </dev/mapper/ -name>
Якщо це розблокує ваші партії ключів, ви добре. Не забудьте знову закрити пристрій.
За певних обставин (пошкоджений заголовок) це не вдається. Потім виконайте наступні дії:
Спочатку визначте розмір головного ключа:
cryptsetup luksDump <device>
дає рядок форми
MK bits: <bits>
з бітами, рівними 256 для старих значень за замовчуванням і 512 для нових значень за замовчуванням. 256 біт дорівнює загальному розміру заголовка 1'052'672 байт, а 512 біт - один 2MiB. (Див. Також пункт 6.12) Якщо luksDump виходить з ладу, припустіть 2MiB, але врахуйте, що якщо ви відновите це, ви також можете відновити перший 1M або близько файлової системи. Не змінюйте файлову систему, якщо вам не вдалося визначити розмір заголовка! З цим відновлення занадто великої резервної копії заголовка все ще безпечно.
По-друге, скиньте заголовок у файл. Є багато способів зробити це, я віддаю перевагу наступному:
head -c 1052672 <device> > header_backup.dmp
або
head -c 2M <device> > header_backup.dmp
для заголовка 2MiB. Перевірте розмір дамп-файлу, щоб бути впевненим. Щоб відновити таку резервну копію, ви можете спробувати luksHeaderRestore або зробити більш базовий
cat header_backup.dmp > <device>
Веракріпт
Веракріпт схожий на LUKS. Я не звик до цього, як це було з Truecrypt, але загальна ідея справедлива.
У Veracrypt просто один слот для ключів, тому ви не можете мати більше одного пароля одночасно. Але ви можете мати прихований том: він зберігає метадані в кінці розділу (або диска чи файлу). У прихованому томі є інший головний ключ, і він буде використовувати кінець розділу як перекритий простір. Ідея, що вам слід створити резервну копію, однакова. Це можна зробити за допомогою Tools -> Backup Volume Headerі Tools -> Restore Volume Header. При системному шифруванні він створював завантажувальний диск із резервним копією ключа, який відновлює завантажувач Truecrypt і ключі, якщо трапляються пошкодження. Це робиться, перш ніж щось шифрувати, і наскільки я знаю, Веракріпт продовжує робити те саме.
Детальніше дивіться за цим посиланням https://veracrypt.codeplex.com/wikipage?title=Program%20Menu
Міркування щодо безпеки резервних ключів
Якщо у вас є, наприклад, пароль, що просочився, і ви зміните пароль гучності на новий, надійний та надійний, хтось із доступом до резервної копії все одно зможе розшифрувати файли зі старим паролем. Резервна копія - це головний ключ, зашифрований паролем (старий). Отже, змінюючи паролі, потрібно також зробити нову резервну копію та знищити старіші. І знищення даних назавжди може бути дуже хитрою.
Для кожного резервного копіювання, що маєте цей пароль, є можливим способом розшифрувати дані за допомогою цього пароля. Наприклад, це можна використовувати у Веракріпті, використовуючи "Універсальний пароль" (наприклад, у корпорації), створити резервну копію та змінити інший пароль. Тож відділ ІТ може відновити доступ до цього тома, навіть якщо хтось втратив пароль (подумайте як головний пароль, але не плутайте його з головним ключем раніше).
Фінальні думки (TL; DR)
Ймовірність пошкодження конкретного сектору за допомогою головного ключа є меншою, ніж у вас повний збій диска. Отже, якщо ці дані важливі, вам слід мати резервну копію, а не лише заголовки гучності (Master Key).
А корупція даних поширюється мало (16 байт), що сприймає більшість застосувань.
Так що поганий блок посеред розділу чи диска вплине лише на цей блок. І декілька бітових помилок у секторі обмежені цим сектором, і навіть не вплинуть на сектор 512 байт.
Оновлення (23.01.2017): додайте більше інформації на основі коментарів до ОП.