10.01.2018 15:48, Sergey Matveev пишет: > *** Артём Н. [2018-01-10 15:31]: >> Ну и ok: тогда, если даже она потеряется, ничего особо не случится (да, в >> итоге я всё-же куплю 2-й SSD)? > > Если потеряется ZIL (эта short-term область), то это равносильно тому > что записи не было произведено, хотя программа получила успешное > завершение fsync и убеждена что данные сохранены. > Если же установлена опция sync=disabled, произойдёт ошибка записи?
>> Почему? Возможно хранить список векторов в метаданных, шифрованных на >> фиксированном ключе. >> Собственно, там же, где хранится реальный ключ шифрования диска. > > Для каждого блока диска где-то хранить вектор? Если взять 2 TiB диск с > 4KiB секторами, то вектора будут занимать (если считать что у нас > 128-битный шифр и IV занимает один блок) > 16 * (2 * 1024 * 1024 * 1024 * 1024 / 4096) / 1024 / 1024 / 1024 = 8 (GiB). > Что много. Просто так ключи занимают считанные десятки байт. > 0.4 % - не ахти, как много. > Но на практике в 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 большой, что, конечно, > неприятно. > А зачем так?
