В данной статье будет затронута тема создания криптоконтейнеров с помощью различного опенсорсного софта. Коснемся TrueCrypt и VeraCrypt, рассмотрим все с самых азов. Разберемся как создать простой том, том с двойным дном, как создать ключи шифрования и прочее. Все это проделаем под линуксом в консольном режиме.
С чего все начиналось?
Начнем сначала. В далеком 2004 году группа разработчиков энтузиастов выкатила первую релизную версию программы для работы с криптоконтейнерами под названием TrueCrypt. Она была основана на опенсорсном ПО для шифрования на лету под названием Encryption for the Masses (E4M), поддержка которой была прекращена с приходом нового тысячелетия в 2000 году. На тот момент TrueСrypt была единственным опенсорсным софтом, обладающим этим функционалом. Первые версии программы были доступны только для Windows 98(ME) и 2000(XP), но начиная с TrueCrypt 4.0 была добавлена поддержка Linux и x86-64 платформ. В течение следующих 10 лет после появления первой версии программы разработчиками постоянно выкатывались обновления, была добавлена версия для работы под MacOS, появилась поддержка параллельного шифрования/дешифрования. Одним из последних крупных новшеств стало аппаратное ускорение AES шифрования в версии TrueCrypt 7.0 2010 года, которое позволило увеличить быстродействие в 8 раз, а также появление поддержки томов с размером блоков 1024, 2048 и 4096 байт. В 2013 на почве громких разоблачений Сноудена начался сбор средств для проведения независимого аудита TrueCrypt 7.1a. Одной из причин этого стала анонимность разработчиков TrueCrypt, а как следствие возникновение жарких споров на просторах интернета, о том кем финансируется проект и не наложили ли спецслужбы свою руку на все это дело. В итоге на благие цели аудита получилось собрать более 60.000 USD, которые были переданы некоммерческой организации Open Crypto Audit Project, которая в последующем и проводила проверку. 28 мая 2014 года произошло то, что до сих пор трудно однозначно оценить - релиз TrueCrypt 7.2, который поддерживал лишь часть функций для работы с уже созданными криптоконтейнерами, создавать новые тома было невозможно, а на каждом шаге всплывало настойчивое уведомление о том, что TrueCrypt небезопасен и разработчики настоятельно рекомендуют использовать BitLocker - проприетарный софт от Microsoft, который сама же команда TrueCrypt постоянно высмеивала на протяжении предыдущих 10 лет. Все предшествующие версии программы были стерты из репозиториев, а на официальном сайте сообщалось, что разработчиками была найдена критическая уязвимость, которую они не в состоянии исправить и опять же ссылка на вышеупомянутый BitLocker. Но несмотря на все это аудит версии TrueCrypt 7.1a не прекращался, и в апреле 2015 года был завершен, при этом не было выявлено никаких серьезных уязвимостей или недостатков и был сделан вывод, что TrueCrypt 7.1a - хорошо спроектированная криптографическая программа, но при этом она все же не лишена недостатков. На основе отчета полученного в ходе аудита, был начат новый проект, в основание которого лег TrueCrypt 7.1a, и получил название VeraCrypt. По заявлениям разработчиков, в VeraCrypt реализованы обновления, которые дают ему превосходство над своим предшественником в области безопасности. Соответственно, зашифрованные данные должны быть более устойчивы к брутфорс атакам.
TrueCrypt
На просторах сети есть куча мануалов для приведенных выше утилит в графическом режиме. Мы же попробуем повторить все в консоли. Для начала установим TrueCrypt обязательно версии 7.1a. Для этого запускаем: git clone https://github.com/AuditProject/truecrypt-verified-mirror.git Переходим в директорию truecrypt-verified-mirror/Linux. Здесь необходимо проверить хеш пакета, чтобы нам не подсунули вредонос: md5sum truecrypt-7.1a-linux-x64.tar.gz. Сверяем хеш с приведенным в статье за 2014 год (ссылки), если совпадает раcпаковываем и ставим пакет. Можно приступать к созданию криптоконтейнера: используем флаг -t(text) и флаг -c (create): truecrypt -t -c
На данном этапе выбираем обычный, а не скрытый том. Далее необходимо выбрать путь к тому, алгоритм шифрования и алгоритм хеширования.
Далее, программа попросит вас выбрать файловую систему. Если вы создаете том размером меньше 4Gb, то рекомендуется выбрать FAT, так как с ней будет проще работать в том случае, если вам вдруг понадобиться примонтировать ваш контейнер под виндой. Если же вы уверены, что такого точно не произойдет, то можете смело выбирать ext4.
Затем, вас попросят ввести пароль. Рекомендуемая длина пароля - не менее 20 символов. После этого можно указать путь до ключей, если вы их уже создали, если нет можно оставить вариант none. И завершающим этапом необходимо рандомно натыкать на клавиатуре 320 символов. Это необходимо для того чтобы повысить криптостойкость ключей шифрования.
Если все опции были выбраны корректно, мы получим примерно такую картину:
Мы создали криптоконтейнер! Можно сделать все покороче:
truecrypt -t -c --volume-type=Normal --size=5000000 --encryption=AES --hash=RIPEMD-160 --filesystem=FAT -k="keys" --random-source=/dev/urandom my_volume.
Теперь поместим туда какие-нибудь данные. Для этого примонтируем его командой truecrypt my_volume /path/to/your/dir. Далее, после ввода верного пароля в уже примонтированный контейнер перемещаем необходимую информацию, после этого отмонтируем контейнер командой truecrypt -d my_volume или truecrypt -d /path/to/your/dir, либо же командой truecrypt -d можно разом отмонтировать все примонтированные в данный момент контейнеры. Для того чтобы узнать сколько в системе примонтировано криптоконтейнеров и куда они примонтированы, можно вызвать утилиту с опцией -l.
Криптоконтейнер с двойным дном.
Так что же все-таки такое это ваше двойное дно? Двойным дном обычно называют скрытый том внутри обычного тома криптоконтейнера. То есть сначала мы создаем обычный, ничем не примечательный криптоконтейнер, помещаем туда какие-нибудь не сильно важные данные, которые не страшно потерять, а уже потом создаем в этом томе скрытый раздел. Этот раздел невозможно обнаружить в непримонтированном состоянии, если о нем не знать. Если вас заинтересует почему это так работает, то можно почитать про недоказуемость криптоконтейнеров. После создания двойного дна у нашего контейнера пробуем его примонтировать. На этапе ввода пароля, если мы вводим новый пароль от только что созданного скрытого тома, то соответственно он и примонтируется. Но если же ввести пароль от хронологически первого контейнера, в системе как ни в чем ни бывало примонтируется обычный том, и для стороннего человека будет совершенно неочевидно, что его где-то обхитрили и подсунули не те данные. Посмотрим как это все выглядит на практике. Возьмем my_volume и создадим внутри него скрытый том.
На этом этапе необходимо указать путь до уже существующего контейнера, который мы возьмем за основу. Ну а дальше действуем по уже описанному алгоритму.
Теперь у нас есть криптоконтейнер с двойным дном. Давайте попробуем в нем что нибудь спрятать. Для этого примонтируем его. Я создал поддиректорию ~/justdir/point, в которую я и буду монтировать. При этом вводим пароль от скрытого тома.
Убеждаемся что контейнер пуст и кладем туда любые данные, которые хотим спрятать. Я пложу туда справочную страничку для утилиты GPG и для пущей достоверности сразу посчитаю ее md5 хеш.
Теперь отмонтируем скрытый раздел и примонтируем обычный.
Теперь, если кто-то просит нас показать, что лежит в этом хранилище, мы смело вводим пароль от обычного тома и демонстрируем какие-то данные, не имеющие для нас стратегического значения. А когда интерес настырной личности к вашим данным будет удовлетворен, можно будет уже и действительно извлечь свои данные.
Но есть один небольшой нюанс, если при уже созданном скрытом томе начать запись в родительский том, то появляется риск перетереть свои данные, так как контейнер, который находится на верхнем уровне не знает о существовании скрытого раздела. Поэтому, если вы решили изменить легенду и поменять данные в обычном томе, то его нужно монтировать специальным образом. При монтировании необходимо выбрать опцию Protect hidden volume... и ввести данные для монтирования скрытого тома. В таком случае можно смело помещать данные в первый контейнер, данные второго контейнера не затрутся.
Если работаем без иксов, то получилась бы примерно такая картина:
Шифрование с ключами.
Если мы действительно хотим чтобы наши данные не достались никому, то, конечно, нельзя относиться к самому шифрованию спустя рукава. Будем ипользовать ключи, которые к слову генерируются с помощью того же самого TrueCrypt. Ключей можно создать столько, сколько вы посчитаете нужным, поместить их в одну директорию или хранить каждый ключ отдельно на съемном носителе это уже дело сугубо субъективное. Давайте приступим. Для того чтобы сгенерировать ключи, программа попросит вас превнести рандома хаотичными движениями курсора или набором 320 различных символов на клавиатуре. Также присутствует возможность указать источник --radom-source=..., в качестве которого можно например указать /dev/urandom, но не рекомендуется из соображений криптостойкости генерируемых ключей. Создадим ключи, для этого запустим: truecrypt --create-keyfile (можно еще добавить --radom-source=/dev/urandom если нет душевных сил долбить по клавиатуре).
Второй ключик создадим другим способом:
Можно создать еще несколько ключей, поместить их в отдельную директорию, а при создании контейнера указывать путь уже к ней. Если вы не использовали ключи на этапе создания криптоконтейнера, а также в случае, если ваш ключ скомпрометирован, возникает необходимость поменять (добавить) ключи уже существующему криптоконтейнеру.
В руководстве пользователя (к которому утилита нас настойчиво отсылает) указывается, что при смене пароля и ключей важно не забыть про пересоздание диска восстановления, если вы, конечно, его используете.
VeraCrypt
Как уже было сказано выше, VeraCrypt это прямой потомок TrueCrypt версии 7.1a, такой же опенсорсный как и его предшественник. В нем был исправлен ряд недостатков, это позволило использовать более современную дял 32-битных систем хеш-функцию - SHA-256. Также было увеличено количество итераций для алгоритма, формирующего ключ на основе пароля - PBKDF2. Драйвера VeraCrypt подписаны цифровой подписью Microsoft, это позволяет утилите без проблем работать под Win 10. Кроме того, был исправлен ряд ошибок и уязвимостей, связанных с утечками памяти и еще некоторыми проблемами в безопасности. Так как корни программы уходят в сторону TrueCrypt, синтаксис утилиты практически не изменился. Скачиваем и ставим софт (ссылки), не забывая сверить хеши пакетов, и приступаем к шифрованию.
Заметно, что изменениям подверглись алгоритмы шифрования, добавился кузнечик. Также, выкатили поддержку NTFS, exFAT и Btrfs. Кроме того, добавилась такая неизведанная фича как PIM. PIM дословно переводится как множитель персональных итераций. Предполагается, что PIM такое же секретное значение как пароль и используется с ним в связке. Очевидно, что с увеличением PIM повышается и криптостойкость зашифрованных данных. Осталось понять, как грамотно выбрать само численное значение. На официальной сайте продукта (ссылки) указаны минимальные удовлетворительные значения количества итераций для различных случаев. Так, при использовании короткого пароля в сочетании с хеш функциями SHA-512 и Whirlpool минимальное значение будет 485, а при остальных хеш функциях - 98. Можно, конечно, и оставить значение по умолчанию, но не рекомендуется так поступать из соображений безопасности. Кажется, что хорошая идея выбирать значение PIM, не сильно отличающиеся от рекомендованного разрабами. В таком случае специалисту, который будет пытаться расшифровать ваши данные, придется перебирать не просто пароли, а еще и количество итераций. Это заметно снижает вероятность взлома.
Так чем же все-таки шифровать?
У каждого специалиста свои предпочтения. Но если бы мне пришлось выбирать между этими двумя утилитами, то я бы остановил свой выбор на VeraCrypt. Этот софт более новый и там исправлены ошибки, которые были найдены при аудите TrueCrypt. Но, независимо от ПО, которым вы пользуетесь, рекомендуется поделить данные на разные категории и хранить в различных контейнерах. Так, при работе с одной категорией в системе примонтирован только один контейнер, а остальные, следовательно, находятся в безопасности. Но даже умея грамотно защищать свои данные, необходимо помнить, что ни одна система не является надежной и всегда есть обходные пути и лазейки.
P.S.
Ссылки:
Комментарии (31)
olegtsss
06.09.2023 23:57"Кажется, что хорошая идея выбирать значение PIM, не сильно отличающиеся от рекомендованного разрабами. В таком случае специалисту, который будет пытаться расшифровать ваши данные, придется перебирать не просто пароли, а еще и количество итераций" - почему вы считаете, что выбрав не сильно отличающийся от рекомендованного PIM, вы значительно повышаете сложность перебора (в отличии от ситуации, когда PIM наоборот, сильно отличается от рекомендуемого)?
avost
06.09.2023 23:57почему вы считаете, что выбрав не сильно отличающийся от рекомендованного PIM, вы значительно повышаете сложность перебора
Видимо, имелось в виду - не слишком отличающийся по порядку величины в меньшую сторону - по крайней мере мне так удалось расшифровать эту фразу, чтобы она имела смысл :).
olegtsss
06.09.2023 23:57Интересно узнать, каким оно может вообще быть (это число PIM), каковы требования к его выбору и чем они обусловлены?
MrSmitix
06.09.2023 23:57+1Более чем уверен что ситуация аналогичная с циклическим (возможно это так называется) хешированием паролей, к примеру, на разных сайтах. Для исключения использования радужных таблиц. Если условно итерации 10, то нужно будет потратить на каждый из возможных паролей: кол-во_паролей * 10 единиц времени. В случае если итераций 100, уже кол-во_паролей * 100. А вот если не знать PIM (и он не установлен как по умолчанию), тут уже одному богу известно сколько времени на это уйдет. Могу предположить что минимальные значения рассчитывались из того на сколько сильно возрастет время перебора пароля и как сильно упадет время доступа к данным.
Из документации, хоть автор и упомянул об этом:Когда указано значение PIM, количество итераций рассчитывается следующим образом:
Для системного шифрования, которое не использует SHA-512 или Whirlpool: Итерации = PIM x 2048
Для системного шифрования, использующого SHA-512 или Whirlpool, несистемное шифрование и файловые контейнеры: Итерации = 15000 + (PIM x 1000)
До версии 1.12 безопасность тома VeraCrypt основывалась только на надежности пароля, потому что VeraCrypt использовала фиксированное количество итераций.
С введением PIM, VeraCrypt имеет 2-мерное пространство безопасности для томов, основанных на паре (пароль, PIM). Это обеспечивает большую гибкость для настройки желаемого уровня безопасности, а также контроля производительности операции монтирования/загрузки.
Чуть более подробнее тут
Wakeonlan
06.09.2023 23:57Немного не по теме: а нет ли средства шифровать на лету данные в Яндекс диске, не создавая костыли из отдельного тома и локальной синхронизации с папкой Яндекса ?
Sergey78
06.09.2023 23:57Я с dropbox использовал encfs. В папке dropbox находится контейнер, а когда нужны данные, он монтируется куда-то вне этой папки. Было очень удобно, что под андроид было приложение, которое умело работать с контейнерами encfs из dropbox. Но, к сожалению, приложение это забросили, а dropbox сменил api видимо и перестало работать.
Я думаю вы и описанный выше truecrypt можете так же использовать - зашифрованный контейнер в папке я.диска, а монтируете вы его куда-то вне этой папки.
TrickyBestia
06.09.2023 23:57Есть rclone. Умеет и в шифрование и в сжатие и в объединение нескольких удалённых хранилищ в одно.
Wakeonlan
06.09.2023 23:57Я правильно понимаю, что они может вместо программы яндекс диска самостоятельно подгружать данные в облако яндекса?
aborouhin
06.09.2023 23:57Может. Но несколько лет назад Яндекс специально ломал у себя поддержку rclone (и заодно стандарта WebDAV), чтобы народ, не дай Бог, не использовал в коммерческих целях дешёвый Диск вместо более дорогого хранилища Яндекс.Облака. Не знаю, как так сейчас с этим, давно не использовал.
Wakeonlan
06.09.2023 23:57настроил, работает, но скорость стремится к нулю :(
Получается, Яндекс принципиально против подобных решений, с шифрованием
aborouhin
06.09.2023 23:57Они не против шифрования, а против того, чтобы мелкий бизнес вместо объектного хранилища в Яндекс.Облаке, где 1 Тб получается в среднем тысячи 3 (в зависимости от исх. трафика по-разному) в месяц, покупал Диск по 400 рублей в месяц за тот же 1 Тб :) Поэтому и блокируют инструменты, дающие возможность просто примонтировать Диск на сервер или использовать его для автоматизированных бекапов с сервера.
P.S. Вообще, если нужно нормальное облачное хранилище, работающее по стандартным протоколам, но при этом дешёвое, - посмотрите на Backblaze B2. Поддерживает как S3, так и свой протокол B2, который много каким софтом тоже реализован. Если возможность оплаты зарубежных сервисов есть (уж за полтора года, надеюсь, все этот вопрос решили) - то отличный вариант.
b63ccbb
06.09.2023 23:57+2До сих пор на хабре создаются статьи с инструкцией как шифровать что-то с помощью truecrypt.
LiquidBlasted
06.09.2023 23:57Диски, зашифрованные TrueCrypt/VeraCrypt, теряют производительность в сравнении с шифрованием в DiskCryptor
aborouhin
Для адекватной защиты информации шифрование должно быть полнодисковым. Как минимум на десктопе точно. Иначе очень сложно предсказать, какие хвосты от информации, хранящейся в зашифрованном контейнере, у нас останутся в незашифрованной части системы (временные файлы, кэши, резервные копии, куски данных в файлах подкачки и гибернации и т.д. и т.п.)
VeraCrypt, кстати, умеет шифровать загрузочный диск аж из EFI, делал такое один раз, давно, правда, и вот про это, к сожалению, не написано.
Единственное преимущество Vera/TrueCrypt перед LUKS (или встроенным шифрованием ZFS, если её используем) - это те самые скрытые контейнеры для обеспечения plausible deniability. Но в реальной жизни, чтобы обеспечить эту plausible deniability, надо постоянно, помимо работы с реальными данными в скрытом контейнере, ещё и обновлять данные в фейковом. И не просто формально, а так, чтобы они выглядели убедительно. Тем более это малореально, если мы шифруем не весь диск (см. п. 1), т.к. тут нас выдадут тупо списки последних открытых файлов, история открытых папок и т.п. Я вижу очень мало сценариев, когда кто-то будет так заморачиваться.
Pest85
Потдерживаю LUKS. Есть неплохая статья про монтирование LUKS диска автоматически без сохранения ключа на машине. Решает проблему автоматического монтирования и безопасности при физическом воровстве девайса.
https://withblue.ink/2020/01/19/auto-mounting-encrypted-drives-with-a-remote-key-on-linux.html#commento-login-box-container
dartraiden
У LUKS, к слову, есть один громадный недостаток, который я обнаружил, когда на днях мне в голову пришла мысль "а не спрыгнуть ли мне с Windows и BitLocker?". LUKS не умеет шифровать таким образом, чтобы для расшифровки нужно было несколько факторов одновременно.
Поясню: BitLocker позволяет настроить шифрование таким образом, что для расшифровки потребуется наличие ключевого файла на внешнем накопителе и пин-кода (который знает пользователь). Если одного из этих факторов не будет (ключевой файл уничтожен / не удалось выбить пин-код из пользователя), расшифровать накопитель не получится.
LUKS тоже позволяет добавить и пароль, и ключевой файл, но они действуют как независимые друг от друга предохранители. Накопитель можно будет расшифровать ключевым файлом или паролем. Атакующему достаточно завладеть одним из двух.
Это какой-то позор (с) У нас в вебе вовсю двухфакторная авторизация, а самое популярное средство для дискового шифрования в Linux двухфакторную авторизацию не умеет.
aborouhin
Можно доступ к ключу закрыть паролем. У меня эту задачу для тех случаев, когда я физически сам разблокирую зашифрованный диск (не удалённо), решает флэшка с аппаратным шифрованием (Datashur), на которой и лежат ключики. Для удалённой разблокировки тем более масса вариантов.
P.S. Нагуглился ещё один вариант, сам не пробовал. Вместо ключа сохранить заголовок LUKS на отдельном носителе (detached header, так, оказывается, можно). А в password slot записать пароль. В результате этот заголовок будет выполнять роль ключа, который вы должны иметь, чтобы потом ввести пароль.
dartraiden
Флешка с шифрованием это вариант, но насколько оно там шифрование, вот в чём вопрос. Я помню историю с приложением под Android, автор которого заявлял шифрование AES-256, все дела, а в реальности данные шифровались обычным XOR...
Отсоединённый заголовок это хорошо, по описанию - прямо то, что надо. Вот бы ещё это всё через GUI, было бы вообще счастье.
Хотя, вот, Ubuntu двигается в нужном направлении: они хотят в инсталляторе предлагать не только LUKS с паролем, но и добавить опцию "LUKS с авторасшифровкой с помощью TPM".
aborouhin
Ну эти ребята уже много лет на рынке, ничего компрометирующего про них не слышно. Ну и, опять же, вопрос к модели рисков. Если основная угроза - российский товарищ майор, который ноут вместе с этой флэшкой изымет, - маловероятно, что в штате РОВД по Nскому району найдутся специалисты, умеющие эксплуатировать уязвимости экзотической заморской железки, даже если таковые в ней есть.
Pest85
Пароль можно разделить на составные части и собирать из них скриптом.
Тут ограничено только фантазией - напримар 1/3 aws, 1/3 azure, 1/3 esp которая висит где-нибудть дома на wifi и отдает пароль по запросу.
Если ноут/PC физически изьят то часть по wifi будет недоступна. Плюс можно отрубить облака чтобы не отдавали их части пароля
Ограничение этого метода - не для загрузочного диска.
M_AJ
Только если используется Windows. По крайней мере так было пару лет назад.
Существуют и холодные данные, хранение которых на зашифрованном разделе может выглядеть убедительно — то что выглядит как рабочая документация, сканы личных документов, личные неприличные фотографии :)
Но у True/VeraCrypt есть другой, на мой взгляд более серьёзный недостаток — принципиальный отказ от поддержки TPM, что означает хранение ключей в оперативной памяти, откуда, их теоретически проще вытащить, например с помощью уязвимостей Spectre.
makkarpov
Абсолютно любой софт, с поддержкой TPM или без, будет хранить мастер-ключ в оперативной памяти. Вы же не ожидаете, что крохотный TPM, подключенный к шине в 33 МГц, будет способен шифровать трафик современных дисков?
TPM всегда используется только для расшифровки мастер-ключа, которым уже шифруются данные.
M_AJ
Что ж, я был лучшего мнения о TPM, почему-то считал, что благодаря наличию надежного хранилища ключей, он позволяет генерировать, хранить и относительно часто менять ключи шифрования данных, что позволило бы даже в случае единовременно снятого дампа получить ключ только от части секторов диска. По крайней мере это выглядело как логичный и вариант того, как это могло быть устроено. А в итоге получается что TPM может защитить от брутфорса и манипуляций с EFI, но не от дампа участка памяти с ключом. Тоже конечно полезные вещи, но как-то маловато.
dartraiden
От дампа памяти защищает, например, политика Windows "отключать DMA-устройства, которые подключены, когда компьютер заблокирован". Но она работает только если включён BitLocker.
TPM усложняет атакующему жизнь, лучше его использовать, чем не использовать. Атакующий не сможет подменить прошивку, не сможет отключить Secure Boot. Если у вас не включён Boot Guard (а он мало где включен), то без TPM вы не выстроите цепочку доверия, у вас корня доверия не будет. Вы не можете гарантировать, что в ваше отсутствие не была подменена прошивка системной платы. Ну, все же помнят историю, как зарубежный исследователь безопасности, приехав в Москву на конференцию, обнаружил в номере отеля неизвестного, который крутился около его ноутбука?
TPM очень полезен, когда компьютером пользуются разные пользователи. Если использовать шифрование с паролем, то придётся сообщить пароль всем этим пользователям, после чего любой из них загрузится с LiveCD, расшифрует известным паролем системный накопитель и получит доступ к профилям остальных пользователей, а также сможет сделать себя администратором. C TPM накопитель расшифруется только при штатной загрузке, причем, можно даже настроить автоматическую расшифровку. А дальше уже в бой вступает авторизация в ОС, которая пускает каждого пользователя лишь в свою учётку.
makkarpov
Наличие IOMMU в системе должно защищать от любых DMA-атак. Более реалистичен сценарий с выключением питания и считываем планок с еще "горячей" информацией. Против этого на некоторых системах есть шифрование RAM, но оно должно вносить какой-то оверхед.
makkarpov
Очень сложно, знаете ли, конкурировать с инструкцией процессора, работающей на частоте в несколько ГГц и имеющей по экземпляру в каждом ядре. Лично у меня aes-xts работает на скорости 2.8 гигабайт в секунду на ядро.
С разделением ключей на области чисто теоретически такое реализовать можно (никаких принципиальных проблем нет), но я таких реализаций не видел. dm-crypt берет один мастер-ключ и реализует софтварное шифрование.
Про EFI и брутфорс - да, вы правы, именно такая модель угроз там и задумывалась.
aborouhin
Возможно, я именно для Windows и делал, но мне казалось, что на уровне EFI это не должно было зависеть от ОС. Наверное, ошибался.
dartraiden
TPM при полнодисковом шифровании вполне поддерживается, только настраивается не через GUI.
Если внимательно посмотреть код, то можно и другие неочевидные возможности обнаружить, например, автоматическую расшифровку при наличии USB-накопителя с заданными VID/PID/SERIAL или расшифровку с помощью нажатия мышью на определённые участки графического изображения.
M_AJ
А вот это реально удивительно, поскольку прямо на официальном сайте в разделе частых вопросов у них написано:
dartraiden
Этот абзац ещё из TrueCrypt тянется, только заменили TrueCrypt на VeraCrypt.
Поддержку TPM и прочих скрытых фич к EFI-загрузчику прикручивал доброволец, как видно, он даже поддержку TPM 2.0 не добавил, так что, видимо, это всё так и осталось полуофициально, а знание о том, как это настроить, вообще содержится на стороннем русскоязычном форуме. Проще заявить "поддержки нет", чем описывать эти шаманства и ограничения.
Официально-то и поддержки скрытой ОС на GPT-разметке нет, но технически она есть.
В общем, всё это реализовано на уровне "вроде, работает, но неофициально и через пляски с бубном". Впрочем, если пользователь сумел до этого знания добраться, вероятно, он готов.