Полнодисковое шифрование с LUKS2
Значимость и проблема FDE
Дела с шифрованием запоминающих устройств обстоят забавным образом: оно повсюду и нигде одновременно. Начиная от мобильных устройств, где оно играет особо важную роль (причем большинство пользователей об этом даже не догадываются), и заканчивая большими дата-центрами. В то же время исследования, проведенные за последние десять лет в разных странах, включая Великобританию, Германию и США, показывают, что не только обычные пользователи, но и корпорации не сильно пекутся о личных данных.
К сожалению, на этом проблемы не заканчиваются. Большинство нынешних систем полнодискового шифрования (Full Disk Encryption — FDE) обеспечивают конфиденциальность данных, но не их целостность. Это означает, что злоумышленник может физически изменить байт информации на диске и пользователь не сможет обнаружить, что и где изменилось и откуда сбои. Все потому, что сектор открытого текста равняется сектору шифротекста, а метаинформацию хранить негде.
Искажение данных может произойти не только в результате прямого воздействия злоумышленником, но и по чистой случайности: неплотно воткнутый кабель, перезапись данных утилитой, которая не распознает формат LUKS, и так далее.
Проблему целостности данных решает аутентифицированное шифрование (Authenticated Encryption with Associated Data — AEAD). Это не новая тема, и активные исследования вместе с конкурсами на лучший алгоритм (см. CAESAR) ведутся десятки лет. Но для реализации AEAD в полнодисковом шифровании нужно придумать, где хранить дополнительные данные (те самые AD).
Зачем шифровать
Если вы еще сомневаетесь, что полнодисковое шифрование — нужная штука, то подумайте вот о чем: оно не только помогает сохранить в тайне вашу очень важную инфу и пикантные фоточки, защищая вас от разного рода мошенничества и шантажа, но и предохраняет диск от изменений. Например, вас могут на какое-то время разлучить с вашим компьютером, и речь не только о «маски-шоу», но и, например, о дотошном погранконтроле. Как в таких случаях убедиться, что на диске не появилось чего-то нового? Ну и последний, чисто эмоциональный аргумент: просто представьте, какой неистовый баттхерт будет у кого-то, когда он не сможет получить доступ к вашим данным, — даже если там нет ничего интересного!
Решение
Ребята из Чехии несколько лет разрабатывали решение для Linux, которое сможет предоставить FDE с функцией AEAD. Главными критериями для этого были:
- обеспечить работу без дополнительного оборудования;
- сделать возможным применение на самых обычных дисках, которые доступны в магазине, а не по спецзаказу;
- использовать родной размер сектора;
- реализовать возможность восстановления данных в случае перебоя питания;
- использовать (и писать) только свободный код и алгоритмы.
Результатом разработки стали новые объекты (targets) для device mapper: dm-integrity, обновленный dm-crypt с аутентифицированным шифрованием и формат LUKS2. Их поддержка включена в ядро Linux начиная с версии 4.12, а новые шифры AEGIS и MORUS (финалисты CAESAR) доступны с 4.18.
Подробнее о dm-integrity, dm-crypt и LUKS2
dm-integrity
Эмулирует блочное устройство с дополнительными тегами в каждом секторе и использует их для хранения метаинформации. Поддерживает журналирование, которое можно опционально включить — например, чтобы можно было восстановить данные после сбоя питания.
Применяется как в паре с dm-crypt для предоставления AEAD, так и отдельно — для контроля целостности данных без шифрования. Управляется утилитами cryptsetup, если нужно шифрование, или integritysetup, соответственно, без него.
dm-crypt
Здесь добавили поддержку режимов AEAD для шифров и рандомизацию вектора инициализации (Initialization Vector). На каждую запись в сектор ядром генерируется случайный Initialization Vector.
К примеру, в режиме XTS вектор шифруется хитрым образом, что позволяет брать для него предсказуемый номер сектора (plain или plain64).
LUKS2
Это вторая версия формата LUKS с расширенными возможностями. Были устранены некоторые проблемы и ограничения, однако большинство идей LUKS1 остались. Среди новых возможностей:
- поддержка затратных для памяти функций формирования ключа (key derivation function — KDF);
- новый вид заголовка (бинарный + JSON), добавлен механизм контрольных сумм, дублирован (кроме области ключей);
- ключам можно назначать приоритет;
- JSON позволяет расширять возможности формата, не модифицируя бинарную структуру;
- в заголовке реализованы токены, которые связаны со слотами для ключей и описывают, где взять пароль. Токены могут быть использованы для поддержки механизмов внешнего хранения ключей.
Посмотреть формат заголовка LUKS2 полностью и изучить каждое поле можно в спецификации.
Argon2 — та самая, затратная для памяти и центрального процессора KDF. В Linux доступны два варианта: Argon2i и Argon2id.
На данный момент шифры AEAD, которые есть в ядре (AES-GCM и ChaCha20-Poly1305), имеют короткий (96-bit) одноразовый код (nonce). Это означает, что вероятность коллизии слишком большая (с точки зрения криптографии) и ее нельзя игнорировать, так как использование одноразового кода дважды (nonce reuse) фатально для AES-GCM. На всякий случай отмечу, что это не касается шифрования информации, передаваемой по сети.
Для обеспечения AEAD в FDE сейчас стоит использовать новые AEGIS или MORUS. Или же AES-XTS + HMAC, если нет доступа к 4.18. Проблема этой конструкции в том, что нужно хешировать сектор, а хеширование 4 Кбайт данных занимает какое-то время. Другими словами: это долго.
Поддержка dm-integrity включается в ядре опцией CONFIG_DM_INTEGRITY. В Arch Linux проверить, включена ли она у тебя, можно командой
$ zgrep -E "CONFIG_DM_INTEGRITY|CONFIG_BLK_DEV_INTEGRITY" /proc/config.gz CONFIG_BLK_DEV_INTEGRITY=y CONFIG_DM_INTEGRITY=m
В Ubuntu список конфигов ядра находится в разделе /boot, файл config-версия_ядра — грепай его, и узнаешь всю правду.
Стоит упомянуть, что авторы не пытаются переизобрести велосипед и придумать невиданную ранее концепцию. Подобное решение, но с другим подходом существует во FreeBSD и называется GELI. Здесь для обеспечения целостности данных используется HMAC.
Полнодисковое шифрование с LUKS2 на практике
Итак, у нас в арсенале скоро появятся новые алгоритмы и новые фичи. Но попробовать их не терпится уже сейчас, чем я и занялся.
Работа над форматом LUKS2 еще не завершена, так что не рекомендуется использовать его в продакшене!
Тут же нас встречает первая проблема: поддержки со стороны загрузчиков просто-напросто нет. На данный момент ни GRUB, ни другие не умеют работать с LUKS2.
Отсутствие возможности грузиться с раздела LUKS2 при этом не конец света: /boot зашифруем в LUKS1. Кто-то возразит, что /boot — главный раздел и злоумышленнику, который получил доступ к нему, уже все равно, что у тебя в /. И это правда. Но к сожалению, пока что приходится работать с тем, что есть. LUKS1, конечно же, неплох, но мы сюда пришли новые фичи тестить. В любом случае LUKS2 находится в стадии допила напильником развития и модификации, поэтому о деплое в продакшен речи в любом слу��ае не идет.
Тем временем сзади подкрался второй подвох: это ядро 4.18, которое, как ты помнишь, нужно для AEGIS и MORUS и которого на момент написания статьи нет ни в одном live-установщике. Единственная идея, которая мне приходит в голову, — это кастомный archiso, так как ежемесячный билд содержит только версию 4.17.11.
Модификация archiso
Процесс хорошо описан в Arch Wiki. В двух словах: нужно скачать официальный образ live-установщика, распаковать, внести свои изменения и запаковать обратно.
Если ты читаешь статью, когда на свете уже есть установщик с ядром 4.18, пропускай эту подглаву — ты живешь в прекрасном будущем и тебе все это не пригодится.
На странице загрузки выбирай наиболее подходящее зеркало и качай:
$ curl -q -OL "http://mir.archlinux.fr/iso/2018.08.01/archlinux-2018.08.01-x86_64.iso{,.sig}"
Не забудь проверить целостность файла .iso:
$ gpg --recv-keys 9741E8AC && gpg --verify archlinux-2018.08.01-x86_64.iso.sig
# mkdir /mnt/archiso # mount -t iso9660 -o loop archlinux-2018.08.01-x86_64.iso /mnt/archiso
Так как образы ISO монтируются в режиме только для чтения, скопируй содержимое в другую директорию. Перед копированием удостоверься, что директории ~/customiso не существует, и выполни 1
$ cp -a /mnt/archiso ~/customiso; sync
Далее нужно распаковать airootfs.sfs утилитой unsquashfs, она есть в составе пакета squashfs-tools ($ sudo pacman -S squashfs-tools):
$ cd ~/customiso/arch/x86_64/ $ unsquashfs airootfs.sfs
Для обновления ядра понадобится… ядро. Копируй:
$ cp ../boot/x86_64/vmlinuz squashfs-root/boot/vmlinuz-linux
Теперь можно делать chroot в систему, для этого используй скрипт arch-chroot из пакета arch-install-scripts:
$ sudo arch-chroot squashfs-root /bin/bash
Для установки пакетов нужно сначала инициализировать ключи для pacman внутри chroot:
# pacman-key --init # pacman-key --populate archlinux
Обнови все пакеты:
# pacman -Syu --force archiso linux
В файле /etc/mkinitcpio.conf замени HOOKS=(...) на
HOOKS=(base udev memdisk archiso_shutdown archiso archiso_loop_mnt archiso_pxe_common archiso_pxe_nbd archiso_pxe_http archiso_pxe_nfs archiso_kms block filesystems keyboard)
Пересобери initramfs:
# mkinitcpio -p linux
По окончании нужно создать список пакетов, почистить кеш менеджера пакетов и выйти из окружения chroot:
# LANG=C pacman -Sl | awk '/\[installed\]$/ {print $1 "/" $2 "-" $3}' > /pkglist.txt
# pacman -Scc
# exit
Перенеси свежее ядро и список пакетов, а также удали запасной образ (fallback), так как он не используется установщиком:
$ mv squashfs-root/boot/vmlinuz-linux ~/customiso/arch/boot/x86_64/vmlinuz $ mv squashfs-root/boot/initramfs-linux.img ~/customiso/arch/boot/x86_64/archiso.img $ rm squashfs-root/boot/initramfs-linux-fallback.img $ mv squashfs-root/pkglist.txt ~/customiso/arch/pkglist.x86_64.txt
Создай новый airootfs.sfs, почисти мусор и сгенерируй контрольную сумму:
$ rm airootfs.sfs $ mksquashfs squashfs-root airootfs.sfs $ sudo rm -r squashfs-root $ sha512sum airootfs.sfs > airootfs.sha512
Чтобы можно было грузиться в режиме UEFI, надо обновить загрузочный образ:
$ mkdir mnt ## Для монтирования FAT файловых систем нужен пакет dosfstools $ sudo mount -t vfat -o loop ~/customiso/EFI/archiso/efiboot.img mnt $ sudo cp ~/customiso/arch/boot/x86_64/vmlinuz mnt/EFI/archiso/vmlinuz.efi $ sudo cp ~/customiso/arch/boot/x86_64/archiso.img mnt/EFI/archiso/archiso.img
Последнее, что нужно, — это запаковать все в новый ISO. Читай метку старого .iso при помощи lsblk -f или blkid.
$ iso_label="ARCH_201808"
## xorriso есть в пакете libisoburn (sudo pacman -S libisoburn)
$ xorriso -as mkisofs \
-iso-level 3 \
-full-iso9660-filenames \
-volid "${iso_label}" \
-eltorito-boot isolinux/isolinux.bin \
-eltorito-catalog isolinux/boot.cat \
-no-emul-boot -boot-load-size 4 -boot-info-table \
-isohybrid-mbr ~/customiso/isolinux/isohdpfx.bin \
-eltorito-alt-boot \
-e EFI/archiso/efiboot.img \
-no-emul-boot -isohybrid-gpt-basdat \
-output arch-custom.iso \
~/customiso
$ sudo umount mnt
$ sudo rm -r mnt
Все готово, записывай arch-custom.iso на диск или флешку и грузись: 1
$ sudo dd if=arch-custom.iso of=/dev/xxx bs=1M status=progress
Установка Arch Linux на LUKS2
Если модификации прошли успешно и удалось загрузиться, то первая строчка на экране сообщит версию ядра.
Подробно расписывать, как устанавливать Arch Linux, нет смысла — этой информации полно в интернете. Затрону главные моменты, которые касаются LUKS2 и «прикручивания» шифрования в целом.Установка проводится на чистый, новый или пустой диск, желательно SSD. Если у тебя есть другие разделы, то придется их нюкнуть. Также нужен UEFI, который, скорее всего, твоя машинка поддерживает.
Если ставишь на виртуалку, то главное — включить поддержку EFI и пробросить флешку.
Данные ОПАСНОСТЕ!!1 Единственный способ расшифровать их — это ключ-файл на флешке. Выбирай понадежней или оставь возможность ввести пароль.
Чтобы в один прекрасный день не лишиться данных из-за испорченной или утерянной флешки, сразу добавлю возможность открывать парольной фразой. Из-за этого у меня будут задействованы два слота в заголовке: пароль (слот 0) и ключ-файл (слот 1), который я добавлю потом. Если любишь риск, то можешь парольный слот уничтожить после добавления файла.
Топология диска у меня:
/dev/sda1— раздел для образов .efi, не зашифрован, FAT32;/dev/sda2— раздел/boot, зашифрован, LUKS1;/dev/sda3—/, зашифрован, LUKS2.
GPT — таблица разделов. Отдельный /boot нужен, как ты помнишь, из-за того, что загрузчики пока не умеют открывать LUKS2. По большому счету можно избавиться от sda1 и хранить образ GRUB в файле .efi на той же флешке: для этого нужен раздел с FAT (по спецификации UEFI), и вспомнить кое-какие дополнительные ключи (--removable) для grub-install.
Смотрю диск:
root@archiso ~ # fdisk -l Disk /dev/sda: 119.2 GiB, 128035676160 bytes, 250069680 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: BA18A20B-089C-47EC-A88C-096FE6A5A7EE Device Start End Sectors Size Type /dev/sda1 2048 411647 409600 200M EFI System /dev/sda2 411648 821247 409600 200M Linux filesystem /dev/sda3 821248 21792767 20971520 10G Linux filesystem
И создаю LUKS2 на /dev/sda3:
# cryptsetup luksFormat --type luks2 --pbkdf argon2id --cipher aegis256-random --integrity aead --integrity-no-journal /dev/sda3
Чтобы использовать контроль целостности данных (--integrity), на устройство сначала нужно записать контрольные суммы. Поэтому, если у тебя большой диск, придется запастись терпением.
А вот сравнение скорости работы алгоритмов на SSD, приведенное разработчиками. Линейная запись и чтение.
- В качестве PBKDF я использую Argon2id. Если установка идет на одном железе, а система будет использоваться на другом, то дополнительно можно указать, сколько памяти, процессорных потоков и итераций использовать. Ключи:
--pbkdf-memory <number>; --pbkdf-parallel <number>;--pbkdf-force-iterations <num>.
Если не указывать их, то будет проведен бенчмарк текущего железа и цифры взяты оттуда.
Шифр — aegis256-random. Для LUKS2 доступны следующие алгоритмы AEAD:
- aegis128-random;
- aegis256-random;
- morus640-random;
- morus1280-random.
Суффикс -random здесь указывает на вектор инициализации. Более подробное сравнение смотри в спецификации и магистерской диссертации.
Как видно из графиков, журнал уменьшает скорость, поэтому отключаю его. На ноутбуке он, в принципе, не нужен, так как внезапная потеря питания в большинстве случаев ему не грозит.
Смотрю, что получилось, и открываю:
# cryptsetup luksDump /dev/sda3 # cryptsetup open /dev/sda3 crypto_root # lsblk -f
То самое эмулированное промежуточное устройство crypto_root_dif, с дополнительным местом под метаданные. Для пользователя оно прозрачно, и работа проходит с обычным блочным устройством, в данном случае crypto_root.
Подготовлю раздел /boot в LUKS1 и также открою его:
# cryptsetup luksFormat -h whirlpool -i 5555 /dev/sda2 # cryptsetup luksDump /dev/sda2 # cryptsetup open /dev/sda2 crypto_boot
Тут ничего нового: любимая хеш-функция и чуть больше итераций.
Окей, разделы готовы. Обрати внимание: после открытия я работаю только с эмулированными устройствами /dev/mapper/crypto_boot и /dev/mapper/crypto_root, а не с физическими /dev/sda2 и /dev/sda3.Создаю файловые системы:
# mkfs.vfat -F32 -n "ESP" /dev/sda1 # mkfs.ext2 -L "arch_boot" /dev/mapper/crypto_boot # mkfs.ext4 -L "arch_root" /dev/mapper/crypto_root
Монтирую:
# mount /dev/mapper/crypto_root /mnt # mkdir /mnt/boot # mount /dev/mapper/crypto_boot /mnt/boot # mkdir /mnt/boot/efi # mount /dev/sda1 /mnt/boot/efi
Всегда используй только свежие зеркала:
## Переименовать список старых
# mv /etc/pacman.d/mirrorlist{,.old}
## Скачать новые
## FR в ссылке можешь заменить на код своей страны или той, что рядом
# curl -q -sSL 'https://archlinux.org/mirrorlist/?country=FR&protocol=https' | sed -e 's/^#S/S/g' >/etc/pacman.d/mirrorlist
Для аутентификации по флешке нужно добавить дополнительный ключ. Ты можешь сделать его из последовательности битов на ней и указать GRUB использовать их при помощи следующего параметра ядра: cryptkey=device:offset:size, где
device— блочное устройство, на котором хранится ключ;offset— смещение, по которому считывать байты;size— сколько байтов считать.
В качестве device можно использовать как /dev/sdX, так и UUID=, например:
cryptkey=/dev/sda:0:512` или `cryptkey=UUID=1234-5678:0:512
В моем случае это будет обычный файл. Поэтому воспользуюсь немного другим форматом: cryptkey=device:fstype:path и просто укажу путь к нему.
fstytpe— тип файловой системы, можно использоватьauto;path— путь к файлу.
Если флешка чистая, без разделов, то придется их создать. Какую именно файловую систему использовать — дело твое. Для экономии времени воспользуюсь установочной флешкой. Создам директорию и примонтирую в нее:
# mkdir /flash # mount /dev/sdb2 /flash
Сгенерирую ключ-файл:
<span class="com"># dd if=/dev/urandom of=/flash/root_key.bin bs=1024 count=2</span>
Статья и интересное обсуждение для тех, кто думает, что чуть выше я совершил акт кощунства.
Добавлю ключ:
# cryptsetup luksAddKey --pbkdf argon2id /dev/sda3 /flash/root_key.bin
Экстремалы могут удалить парольный слот командой cryptsetup luksKillSlot /dev/sda3 0, где 0 — номер слота.
Все готово к установке:
# pacstrap /mnt base base-devel vim grub efibootmgr dialog wpa_supplicant
Генерирую fstab:
# genfstab -U /mnt >> /mnt/etc/fstab
Далее буду проводить настройки системы изнутри. Для этого использую chroot: arch-chroot /mnt. Первым делом — GRUB. В файле /etc/default/grub раскомментируй GRUB_ENABLE_CRYPTODISK=y и замени строки
GRUB_CMDLINE_LINUX_DEFAULT="quiet" GRUB_CMDLINE_LINUX=""
на вот такие:
GRUB_CMDLINE_LINUX_DEFAULT="verbose" GRUB_CMDLINE_LINUX="cryptdevice=UUID=7a40a90f-2533-41e0-bb94-fd30f4026544:crypto_root cryptkey=UUID=5F6A-991B:auto:/root_key.bin root=/dev/mapper/crypto_root"
Обрати внимание, что GRUB_CMDLINE_LINUX="..." — одна строка, никаких переносов нет.
Идентификаторы UUID смотри через # blkid.
- Примерная схема работы:GRUB запросил пароль от раздела
/boot. - Пароль подходит? Открыл, прочитал его, нашел initramfs, передал ему управление.
- Закончил работу, все закрыл и забыл.
Параметр ядра cryptkey=UUID=5F6A-991B:auto:/root_key.bin указывает initramfs, где взять ключ от / — корневого раздела (LUKS2). Если флешка недоступна, он об этом сообщит и запросит пароль. А если ты удалил слот с паролем, то загрузиться не получится.
Файл /etc/crypttab работает схожим с /etc/fstab образом, только для зашифрованных дисков. В нем указываются все разделы (кроме корневого), которые должны быть открыты при загрузке системы. Конфиг crypttab читается перед fstab, но автомонтирование (уже открытых) разделов производит второй. Таким образом, crypttab — это то, что нужно для открытия /boot во время загрузки системы, так как GRUB, передав управление initramfs, его закрыл и забыл все ключи.
Чтобы не вводить пароль от него дважды (для GRUB и для crypttab), создай и добавь ключ-файл и для раздела /boot:
# mkdir /root/keys # dd if=/dev/urandom of=/root/keys/boot_key.bin bs=1024 count=2 # chmod -R 0 /root/keys/
Добавляй, как обычно:
# cryptsetup luksAddKey /dev/sda2 /root/keys/boot_key.bin
И теперь используй его для автоматического открытия. В конец /etc/crypttab допиши: 1
crypto_boot UUID=4d053fc0-ded6-4390-9e7c-a8abfa503cd5 /root/keys/boot_key.bin luks,timeout=15
Для большей надежности перепроверь UUID в /etc/fstab. Для корневого раздела и для /boot они должны соответствовать crypto_root и crypto_boot, а не sda2 и sda3.
Осталось добавить компоненты для initramfs с помощью скрипта mkinitcpio. Для этого подредактируй файл /etc/mkinitcpio.conf и в строку 1
HOOKS=(base udev autodetect modconf block filesystems keyboard fsck)
добавь encrypt, чтобы получилось
HOOKS=(base udev autodetect modconf block encrypt filesystems keyboard fsck)
В MODULES=() допиши dm_integrity и vfat:
MODULES=(dm_integrity vfat)
Иначе при загрузке получишь ошибку Kernel doesn’t support dm-integrity mapping. Модуль vfat нужен, так как раздел флешки с ключом — в FAT.
Пересобери initramfs:
# mkinitcpio -p linux
Последнее, что нужно сделать, — это установить GRUB и сгенерировать для него .cfg-файл командами 1
# grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=crypto_arch # grub-mkconfig -o /boot/grub/grub.cfg
## Задай пароль для root # passwd ## Выйди из chroot # exit ## Отмонтируй все # umount -R /mnt ## Последний раз все проверь и пиши # reboot
Поздравляю, твой свежий Arch Linux установлен на раздел LUKS2 с включенным контролем целостности данных!Парочка топорных тестов скорости дешевого SSD.
Проверка на прочност��
Это все замечательно, но, если твой диск попадет в руки злоумышленнику, насколько тяжело (или легко) тому будет достать данные? Сейчас проверим.
Стоит понимать, что есть множество способов похитить нужную инфу. LUKS защищает данные в офлайне — то есть диск (раздел, контейнер) или закрыт, или отключен от питания вовсе. Иными словами, не думай, что, установив LUKS, ты волшебным образом навсегда обезопасишь данные. Если оставляешь компьютер без присмотра с открытым разделом или пароль записан на стикере, то извини: никакой LUKS тут не поможет.
Для тестов я выбрал четыре продукта: два открытых и два коммерческих. Открытые — это John the Ripper и hashcat. Из коммерческих я знаю продукт ElcomSoft, но он не поддерживает даже LUKS1, поэтому сразу отпадает. Второй найденный мной вариант — это Passware. Никогда не слышал об этой конторе, нашел через поисковик. Список клиентов серьезный: NASA, министерства обороны и юстиции США и другие.
Все инструменты поддерживают GPU. Фермы для майнинга, к сожалению (или к счастью), у меня нет, и в качестве GPU использовалась моя GTX 1050 Ti. Посмотрим, что может эта старушка против LUKS и LUKS2. Для взлома не нужен диск или раздел полностью, достаточно заголовка. Извлекаю их на флешку:
# cryptsetup luksHeaderBackup /dev/sda2 --header-backup-file /flash/boot_header.bin # cryptsetup luksHeaderBackup /dev/sda3 --header-backup-file /flash/root_header.bin
John the Ripper
Ставлю свежую версию и смотрю, что есть в арсенале: 1
$ ./john --list=formats --format=opencl | grep -i luks
Нет вывода. Окей, как насчет CPU?
$ ./john --list=formats --format=cpu | grep -i luks lotus5, lotus85, LUKS, MD2, mdc2, MediaWiki, monero, money, MongoDB, scram,
Что поделать, придется довольствоваться CPU. Пробую:
$ ./luks2john.py /tmp/boot_header.bin
Ситуация та же, что и с hashcat, — нет поддержки whirlpool. Беру криптоконтейнер с SHA-256, добавляю брутфорс-атаку. Чтоб сократить время ожидания до минимума, явно указываю только цифры и длину пароля.
В результате получаю тринадцать паролей в минуту. Если верить программе, брутфорс шестизначного цифрового пароля займет месяц и 26 дней.
Итоги
Наивно было надеяться, что формат, который сейчас на стадии постоянной доработки, будет поддерживаться хоть каким-нибудь продуктом. На его реализацию нужно потратить время и ресурсы, а спецификация формата может измениться в следующем релизе.
Удивило отсутствие поддержки whirlpool. Она в LUKS давно, видимо разработчики не любят париться и отдают предпочтение дефолтным настройкам.
По результатам видно, что стандартная PBKDF2 неплохо справляется с задачей. Возможно, перед парой сотен или тысяч GPU она не устоит, но для этого есть новый Argon2.