переход от cryptoloop к dm-crypt
Имеется раздел, зашифрованный с помощью losetup
# losetup /dev/loop1 /dev/hda1 -e aes
# mount /dev/loop1 /mnt/1
Монтируется без проблем. Далее
# umount /dev/loop1 /mnt/1
# losetup -d /dev/loop1
Хочу шифровать не losetup, а через cryptsetup
# cryptsetup create 1 /dev/hda1 -c aes
# mount /dev/mapper/1 /mnt/1
Не монтируется. Парольную фразу ввожу одинаковую, а примонтировать не получается. Почему? Если алгоритмы шифрования иденичные.
комментариев: 11558 документов: 1036 редакций: 4118
А luks нет, не собираюсь использовать из-за "luks – позволяет хранить параметры шифрования в заголовке зашифрованного раздела", посмотрел на него, и вправду так, а я хочу как можно меньше следов от использования шифрования оставить.
Так в хелпе cryptsetup есть -h, --hash=STRING The hash used to create the encryption key from the passphrase (default: "ripemd160"), может то что нужно, стоит только узнать этот хеш от losetup.
Проблему решил.
Во-первых:
losetup -e aes использует 128 битный ключ
cryptsetup -c aes использует 256 битный
Поэтому если было по умолчанию losetup -e aes, тогда соответственно cryptsetup -c aes -s 128, если было losetup -e aes256, тогда можно задать просто cryptsetup -c aes, либо cryptsetup -c aes -s 256.
Во-вторых:
losetup по умолчанию использует -H 256, а cryptsetup -h ripemd160, отсюда монтировать так:
cryptsetup -c aes -s 128 -h sha256 /dev/hda1 /mnt/1
Поэтому переделаю все на dm-crypt.
Жаль dm-crypt с файлами (вроде) не может работать, хочется поддержку cryptoloop/loopback вообще из ядра убрать.
комментариев: 9796 документов: 488 редакций: 5664
cryptoloop действительно уязвим ко множеству атак и устарел как формат хранения шифрованных данных, есть правда альтернативная реализация – loop-aes.
Наличие файла, а тем более большого раздела с высокоэнтропийными данными уже свидетельствует об использовании шифрования, слишком наивно надеятся убедить кого либо в обратном.
В LUKS предусмотрен механизм безопасной смены паролей. Кроме того можно иметь до 8 паролей для одного раздела. Ключи, зашифрованные паролем распределены в большом массиве байтов. А ключ вычисляется от этого массива. Это позволяет быть уверенным, что при смене пароля ключ нельзя восстановить (многие винчестеры и флэши сохраняют копии секторов в скрытой области, RAID-массивы вообще распределяют данные; также затрудняются атаки с восстановлением по остаточному намагничиванию и т.д.). Также легко уничтожить шифрораздел – при удалении мастер ключа, также можно быть уверенным (с высокой долей вероятности), что он полностью затёрт и контейнер невосстановим с учётом всех технических ухищрений, которые может использовать противник.
А вот раздельное хранение ключа в виде простого файла на файловой системе в loop-aes может создавать проблемы.
Основное преимущество dm-crypt возможность работать не с разделами, а напрямую с логическими томами LVM: если кто-то ещё не знает что это, то почитайте, очень интересная вещь.
А работать с файлами dm-crypt дейтвительно может только через /dev/loop, но для этого cryptoloop не нужен.
комментариев: 8 документов: 2 редакций: 0
Возможно удастся убедить что просто "чистил" разделы dd if=/dev/urandom of=/dev/hda1
А с luks никаких шансов :)