[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Снова о ZFS




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 большой, что, конечно,
> неприятно.
> 
А зачем так?


Reply to: