*** Артём Н. [2018-01-10 15:31]: >Ну и ok: тогда, если даже она потеряется, ничего особо не случится (да, в >итоге я всё-же куплю 2-й SSD)?
Если потеряется ZIL (эта short-term область), то это равносильно тому что записи не было произведено, хотя программа получила успешное завершение fsync и убеждена что данные сохранены. >Почему? Возможно хранить список векторов в метаданных, шифрованных на >фиксированном ключе. >Собственно, там же, где хранится реальный ключ шифрования диска. Для каждого блока диска где-то хранить вектор? Если взять 2 TiB диск с 4KiB секторами, то вектора будут занимать (если считать что у нас 128-битный шифр и IV занимает один блок) 16 * (2 * 1024 * 1024 * 1024 * 1024 / 4096) / 1024 / 1024 / 1024 = 8 (GiB). Что много. Просто так ключи занимают считанные десятки байт. Но на практике в LUKS конечно не нулевой вектор используется, а ESSIV (encrypted salt-sector initialization vector), что уже не предсказуемо для злоумышленника. >Вопрос-то в другом: кроме просадки по скорости, атаку на целенаправленное >изменение данных, >без знания ключа для AES (он же использует AES по умолчанию) сложно >реализовать? На практике вообще не сложно: https://packetstormsecurity.com/files/124571/Practical-Malleability-Attack-Against-CBC-Encrypted-LUKS-Partition.html Это для CBC режима конечно же. С XTS сделать *осознанное* изменение plaintext-а уже не получится. >Да, ещё конечно имеется вариант сделать geli/luks поверх ZFS, но он мне >кажется весьма сомнительным. Как вариант. У меня один гигабайтный диск так и сделан: ZFS поверх GELI поверх ZVOL-а на другом ZFS :-). Просто overhead большой, что, конечно, неприятно. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
