Криптоконтейнеры и защита диска

В ходе создания нового контейнера PGPdisk мне предлагается на выбор зашифровать его открытым ключом или ключевой фразой. Что более надёжно?

Если выбирать для нового контейнера столь же надёжную ключевую фразу, как и у закрытого ключа, то с точки зрения безопасности разницы практически нет. С другой стороны, выбор зашифрования открытым ключом усложняет взлом контейнера атакой "по словарю" (особенно, при не очень стойкой ключевой фразе), поскольку взломщику придётся раздобыть копию вашего закрытого ключа. В то же время, если вы по какой-то причине утратите свои ключевые пары, то уже и сами не сможете открыть контейнер, что было бы не так, если воспользоваться только ключевой фразой.

Могу ли я дефрагментировать контейнер PGPdisk/TrueCrypt и проводить иные операции по его техническому обслуживанию?

Подключенный контейнер воспринимается операционной системой как обычный логический диск, а поскольку он содержит обычную (пусть и зашифрованную) файловую систему, то допускает проведение обычного технического обслуживания. Подключив контейнер, вы можете сканировать и дефрагментировать его содержимое и выполнять любые аналогичные мероприятия, используя для этого свои стандартные утилиты.

Возможно ли создать PGPdisk на USB Flash Drive, CD-RW или ином съёмном носителе? Какие есть рекомендации?

Создайте на жёстком диске новый PGP-контейнер, а затем перенесите его .pgd-файл на внешний носитель информации и всё будет отлично работать. Если это CD-RW, DVD-RW или иное аналогичное устройство, контейнер должен быть отформатирован под файловую систему FAT / FAT32, а подключаться в режиме read-only. Если вы планируете использовать контейнер на нескольких компьютерах (на всех должен быть установлен PGP с компонентом PGPdisk), стоит использовать для его защиты исключительно пароль (а не свою ключевую пару) либо же ключевую пару, размещённую на смарт-карте, если все компьютеры оборудованы считывающими устройствами и соответствующими драйверами.

Настоятельно рекомендую после всякого открытия контейнера на чужом компьютере менять пароль доступа и мастер-ключ (отключить контейнер, если он подключен, затем: PGPtray > PGPdisk > Edit Disk > выбрать файл-контейнер > File > Properties > Re-Encrypt).

PGPdisk нормально работал, но неожиданно перестал открываться (ошибка "not formatted" / "not a valid PGPdisk" и т.п.).

К ошибке "not formatted" обычно приводит попытка перенести файлы в контейнер, открытый на диске CR-RW или DVD-RW с правами на запись, т.е. не в режиме read-only. Этого не следует делать. Чтобы обновить содержимое контейнера, его нужно скопировать на жёсткий диск, добавить в него нужные файлы, а затем записать обновлённую копию на оптический диск. Также важно заметить, что необходимо отключать контейнер перед любыми манипуляциями с его файлом – копированием или переносом. Копирование подключенного контейнера приводит к повреждению его структуры. К тем же последствиям может привести дефрагментация жесткого диска, на котором размещен криптоконтейнер, если последний не был отключен: отключайте контейнер перед началом дефрагментации жесткого диска либо исключите файл контейнера из обработки утилитой дефрагментации, если она позволяет это сделать.

Любая из описанных проблем не поддаётся решению. Наилучший совет в такой ситуации – восстановить последнюю резервную копию контейнера. Если же у вас её (их) нет, мало чем можно помочь. Пока спецификации и формат контейнеров не будут опубликованы в виде RFC-подобного документа, локализация и решение подобных проблем останутся сильно затруднены.

Контейнер PGPdisk – очень хрупкая структура. Незначительное повреждение в неудачном месте, вызванное сбоем винчестера или некорректной работой ОС, может легко привести к потере симметричного ключа расшифрования или к поломке вложенной файловой системы. Последнее было бы не катастрофично для жёсткого диска, но это не так в связи с тем, что ФС контейнера зашифрована.

Как и с любым ценным материалом, такие проблемы легче предупреждать, чем пытаться разрешить, когда они случились. Не создавайте слишком больших контейнеров – такие более подвержены поломкам и их труднее резервировать, а это обязательная процедура, которую нужно выполнять регулярно, дабы в критической ситуации не пришлось возвращаться к слишком старому материалу. Храните несколько хронологических резервных копий и заменяйте новыми самые старые. Как часто резервировать контейнер и как много резервных копий хранить должны решить вы сами исходя из ценности информации и темпа её обновления / устаревания.

Перенёс / создал в PGP 7.x – 8.x контейнер PGPdisk, пароль на русском, не могу открыть – русские буквы не вводятся.

В PGP 7.x существует баг: при открытии контейнера программа не принимает национальные буквенные символы, хотя их можно вводить в ходе создания контейнера (как коварно! ;-) ). Точная причина проблемы с 8.x, где могут не вводиться лишь некоторые русские буквы, не выявлена по сей день, кроме того, что она проявляется только в Windows NT-совместимых системах. Причём часто получается так, что в разных диалоговых окнах не вводятся различные русские буквы, и вы можете совершенно благополучно создать контейнер, которым после закрытия не сможете открыть. Будет ещё хуже, если прежде чем обнаружить проблему, вы успеете перенести в контейнер все свои ценные файлы (как чаще всего и бывает).

Так или иначе, но единственный способ избежать этой проблемы – просто не использовать кириллицу в паролях. Если же ситуация уже зашла в тупик, и неработоспособность контейнера выяснилась уже после его закрытия со всей ценной информацией, перенесите его на другой компьютер с Windows 98 и установленным PGP 8.x и смените у контейнера пароль. Если контейнер зашифрован вашим открытым ключом, у которого установлена кириллическая ключевая фраза, просто замените её на чисто латинскую. Если контейнер импортировался в 7.x – 8.x из PGP 6.x, верните его на компьютер с ранней версией программы и, опять же, поменяйте пароль контейнера так, чтобы он не содержал кириллических и других национальных буквенных символов.

Запомните: для целей совместимости не рекомендуется использовать в любых паролях и ключевых фразах PGP ничего, кроме латиницы, цифр и служебных печатных символов. Следуя этому совету вы избежите ненужной головной боли от решения подобных проблем.

Контейнер PGPdisk создавался так, чтобы подключать как NTFS-директория, но неожиданно стал подключаться как логический диск.

Каталог, под которым подключается криптоконтейнер, должен быть пуст. Вероятно вы или операционная система сохранили что-то в этом каталоге, что привело к потере ассоциации между ним и контейнером. Чтобы вновь её восстановить, сделайте следующее:

1. Отключите контейнер, нажав на него правой кнопкой > PGP > Unmount PGPdisk.
2. Если парольная фраза контейнера находится в кэше, нажмите PGPtray > Purge Caches.
3. Дважды щёлкните на .pgd-файле контейнера, чтобы вызвать окошко ввода парольной фразы. Нажмите в этом окошке кнопку Options.
4. Отметьте опцию As a directory on an NTFS volume, укажите каталог, под которым должен подключаться контейнер (этот каталог должен быть пуст) и нажмите OK.

Настройки и прежнее поведение контейнера должны восстановиться.

Забыл пароль к PGPдиску. Как мне теперь его открыть?

Без правильной парольной фразы это невозможно. Если бы PGP имел лазейки или обходные пути, им бы не пользовались десятки и сотни тысяч людей. Единственный совет – постарайтесь вспомнить пароль.

Не удаётся создать новый PGPдиск – процесс прерывается на стадии форматирования.

Причины этой проблемы поражают своим разнообразием. Чаще всего (и это удалось воспроизвести искусственно) она вызвана физическим повреждением жёсткого диска, на котором создаётся контейнер PGP, или повреждением в его файловой системе. Эту причину можно устранить, прогнав полную проверку ФС и поверхности диска с помощью scandisk или подобной утилиты.

Помимо этого было отмечено, что иногда она возникает из-за конфликта драйверов, сервисов и установленного ПО. Так, в одном случае снять проблему позволило обновление драйвера к IDE-контроллеру. Работающее приложение WebWasher также, по-видимому, способно приводить к нестабильности PGPdisk – его закрытие позволяет нормально открывать/закрывать контейнеры и создавать новые. Самое уникальное сообщение, полученное инженерным отделом PGPCorp, связано с конфликтом PGPdisk и некоторых сервисов видео-карт ATI. Снять проблему лёгким хирургическим путём (но без ущерба для видеоподсистемы компьютера) позволила выгрузка фоновых приложений cli и atiptaxx при помощи утилиты msconfig.

Таким образом, если проверка диска scandisk'ом не привела к положительному результату, сделайте следующее:

1. В панели задач нажмите Пуск > Выполнить (Start > Run), в поле введите msconfig и нажмите OK.
2. Откройте вкладку Автозагрузка, снимите флажки с нескольких приложений, нажмите OK и перезагрузите компьютер.
3. Если попытка создать PGPдиск по-прежнему будет безуспешна, повторите шаги 1-2 и отключите ещё несколько приложений (только не отключайте ничего, связанного с PGP, т.е. pgptray, pgpsdksvc и т.д.).
4. Продолжайте, пока не обнаружите причину конфликта. Определив конкретное приложение, вызывающее сбой в PGPdisk, оставьте его выключенным, остальные верните в прежнее состояние.

Из контейнера PGPdisk, подключенного как папка, не удаляются каталоги и файлы – система говорит Access denied.

Согласно информации из базы знаний Microsoft проблема в том, что Корзина Windows не распознаёт подключенный таким образом логический раздел. В качестве обходного средства вы можете либо отключить Корзину совсем, либо использовать комбинацию Shift+Del, чтобы удалять файлы и папки "мимо" неё.

Мои диски были зашифрованы PGP Whole Disk. После переустановки системы при попытке доступа к этим дискам система сообщает, что они не отформатированы и предлагает отформатировать. Как восстановить ценные файлы?

Если переустановка системы не затронула зашифрованные разделы, ваша информация цела и процесс по ее восстановлению будет достаточно прямолинейным. Во-первых, Вам нужно убедиться, что PGP установлен. А теперь приступим:

1. Откройте консоль Windows и перейдите в каталог с установленным PGP. Для этого введите что-то вроде cd "c:\program files\pgp corporation\pgp desktop".
2. Введите команду pgpwde --enum. Она отобразит нумерованный список разделов.
3. Определите, какие разделы вам надо восстановить и затем введите pgpwde --status --disk 2 (при необходимости вместо цифры 2 подставьте номер нужного раздела).
4. Если все в порядке, и зашифрованный диск по-прежнему работоспособен, программа выдаст ответ Disk 2 is instrumented by Bootguard. Если ответ будет какой-то другой, все несколько усложнится, но пока будем исходить из положительного ответа.
5. Введите pgpwde --decrypt --disk 2 --passphrase Ваш_пароль. Это запустит фоновый процесс расшифрования. За прогрессом можно следить с помощью команды pgpwde --status --disk 2 — значение Highwater (число зашифрованных секторов) будет сокращаться.

По завершении проверьте, что содержимое раздела доступно и цело. Затем можете по желанию снова зашифровать диск с помощью Whole Disk.

Контейнер PGPdisk неожиданно перестал открываться: программа сообщает о неверном пароле или неизвестном формате файла. Что можно сделать? Возможно ли восстановить контейнер?

Это возможно, однако, успеха можно достичь лишь в определённых редких обстоятельствах. Краткая инструкция приведена в форуме. В общем случае, единственное решение подобных проблем — это восстановление резервной копии криптоконтейнера (если вы не забывали их делать).

Есть столько программ для дискового шифрования: PGP Whole Disk, TrueCrypt, DiskCryptor, FreeOTFE. Что выбрать, как разобраться в этом разнообразии?

Все названные программы открыты и, за исключением PGP, свободно доступны. Надёжность и безопасность их так же высока. Можно рассмотреть программы с точки зрения их применения в конкретных условиях.

• DiskCryptor — свободное ПО, распространяемое на условиях лицензии GPL. Программа создана с единственной целью полного шифрования носителей (включая системный раздел), не имеет избыточных элементов. Криптографические алгоритмы реализованы с высочайшей степенью оптимизации, благодаря чему обеспечивается наибольшая, в сравнению с другими средствами, скорость доступа к диску. DiskCryptor более всего подходит для Windows-систем, нуждающихся в максимальной производительности: работа с большими массивами данных при повышенных нагрузках на ЦП, например, работа с крупными базами данных, обработка видео и т.д. До версии 0.4 включительно формат зашифрованных данных DiskCryptor совместим с TrueCrypt, что позволяет читать зашифрованные диски из ОС GNU/Linux с помощью Linux-версии TrueCrypt.
• TrueCrypt — открытое ПО, выпускается в версиях для Windows, Mac OS X и Linux, поддерживает работу как с полностью зашифрованными носителями, так и с файлами-криптоконтейнерами, что делает его полезным в тех случаях, когда шифрование всего диска излишне. Имеет свойства "отрицаемого шифрования" (в виде скрытых разделов и скрытой ОС), пригодные при правовом давлении на пользователя с целью раскрыть секретные данные (стоит отметить, что при внеправовом воздействии, физическом принуждении "отрицаемое шифрование" может иметь обратный эффект, опасный для пользователя). Программа широко распространена, имеет значительную пользовательскую базу.
• FreeOTFE — свободная программа (по условиям GPL), совместимая с Windows, включая Windows Mobile, что делает её незаменимой на КПК под управлением этой ОС; не требует инсталляции, можно запускать с флэшки. Возможности программы включают полное шифрование дисков (за исключением системного раздела с ОС) и работу с криптоконтейнерами, при этом FreeOTFE поддерживает формат "родных" Linux-средств, таких как losetup и cryptsetup-luks, обеспечивая доступ к зашифрованным устройствам из Windows, чем весьма ценна. Формат контейнеров FreeOTFE имеет свойства "отрицаемого шифрования": есть поддержка скрытых разделов.
• PGP Whole Disk — единственная коммерческая программа с открытым исходным кодом для среды Windows и Mac OS X. Поддерживает работу с криптоконтейнерами, полное шифрование носителей и системного раздела диска. Зашифрованные данные легко идентифицируются (нет свойства отрицаемости), что является преимуществом в ряде ситуаций. Наибольшие преимущества достигаются в корпоративной среде за счёт мощнейших средств централизованного развёртывания и управления. За разработкой стоит компания и команда с высочайшей репутацией.

Очень удобно создавать криптоконтейнер в виде файла, ведь это даёт возможность легко делать резервные копии на различных носителях, просто скопировав этот файл. Также его легко отправить на сервер для пересылки или хранения. Почему однако не рекомендуется делать копии контейнеров таким образом?

Есть несколько причин, почему не стоит делать копии одного и того же контейнера или создавать его в виде файла поверх файловой системы.

Раньше для шифрования криптоконтейнеров в сответствующих програмах использовался обычный режим CBC (cipher block chaining – режим сцепления блоков, изобретённый для шифрования отдельных файлов) с простой привязкой IV (вектора инициализации) к номеру сектора файловой системы. Позднее выявились вполне практичные атаки multiscan – "атака уборщицы" (обнаружение фрагментов известного открытого текста без знания ключа в нескольких копиях контейнера или при доступе к одному и тому же закрытому контейнеру в разные моменты времени, когда его содержимое поменялось), watermarking (обнаружение подобранного открытого текста – доказательство наличия специально сформированных, незаметно помеченных и подброшенных пользователю файлов в контейнере без знания ключа – например при отправке их по электронной почте или при скачивании со специально созданного подставного сайта) и атаки на подмену (целенаправленная подмена с предсказуемым результатом фрагментов известных файлов путём изменения шифртекста контейнера без знания ключа).

Для борьбы с этими уязвимостями изобрели специальные более продвинутые режимы – CBC-ESSIV, LRW, XTS. В них постарались применить методы доказуемой безопасности для обоснования стойкости против подобных атак. Но эти доказательства пока признаны неполными и ограниченными, а качественный режим шифрования дисков так и не создан. Нет единого мнения – можно ли создать стойкий, но экономичный Narrow block режим шифрования или необходим обязательно Wide block режим.

Медленные Wide block режимы, перешифровывающие каждый раз при измении хотя бы одного бита весь сектор файловой системы, до сих пор практически не применяютя.

Доказательства стойкости Narrow block режимов ограничены. И их стойкость к атакам multiscan не рассматривалась, исследовались только ситуации противодействия атакам watermarking и против подмены. Возможно, в случае multiscan эти режимы будут уязвимы как к подмене и watermarking, так и к другим атакам.

Всё что пока удалось сделать исследователям – перенести эти атаки из достаточно практических в более теоретическую область. Но полноценный доверяемый стандарт на дисковое шифрование так и не создан.

Другая причина – управление ключами. Многие современные программы дискового шифрования предоставляют возможность изменить пароль контейнера или ключ, не перешифровывая весь контейнер (не изменяя его мастер-ключ). Кроме того, есть возможность хранить как дополнительные расшифрующие ключи, так и мастер-ключ в так называемом "хрупком" виде – в виде распределённого массива, большего по размеру чем сам ключ. Повреждение части битов этого массива намеренно усложняет восстановление ключа. Это позволяет сделать более надёжной процедуру смены и уничтожения ключа на винчестерах, флэш-накопителях и накопителях с возможностью восстановления данных (райд-массивах). При наличии нескольких копий одного и того же контейнера, наличии нескольких копий заголовочных блоков файла-контейнера, которые перемещались по файловой системе и других аналогичных ситуациях, этот метод управления ключами теряет свою надёжность.

Третья причина – наличие в некоторых программах вложенных скрытых контейнеров с функцией отрицаемого шифрования (возможность отрицать существование таких контейнеров по причине невозможности постороннему наблюдателю установить их количество). При наличии нескольких копий одного и того же контейнера стойкость отрицаемого шифрования против обнаружения снижается.

Четвёртая причина – при нахождении контейнера на удалённом недоверяемом сервере и регулярных его изменениях без полной перешифровки противник может осуществлять анализ трафика – общую интенсивность и объёмы изменямой информации без знания её содержимого.

На основании многих причин рекомендуется придерживаться следующей стратегии при работе с криптоконтейнерами.

1. Использовать шифрование, привязанное только к конкретному носителю (физическому или логическому разделу диска), но не в виде файла поверх файловой системы. Современные программы шифрования позволяют изменять размер шифрованных разделов без потери данных.
2. Не делать побитовые копии контейнеров. При необходимости делать резервную копию содержимого – создать контейнер на другом носителе (можно использовать тот же пароль – мастер-ключ шифрования всё равно сгенерируется другой) и перенести данные в него.
3. При невозможности создания нового контейнера на самом резервном носителе (CD, DVD, удалённые серверы, отправка по почте) – дополнительно для этой цели создавать новый одноразовый контейнер, каждый раз заново перед записью или отправкой и уничтожать его лишние копии (которые например остались на винчестере после записи или отправки) или использовать другой способ шифрования.
4. Не монтировать контейнеры с удалённых недоверямых серверов и не размещать их там для этой цели.

Эти требования могут быть ослаблены при наличии у пользователя достаточной квалификации в степени оценки угрозы безопасности его данным.

Как быстро заполнить устройство, раздел, том или файл случайными данными в Linux, чтобы подготовить его к шифрованию?

Поскольку при разметке раздела (а также физического или логического тома в Linux) как шифрованного и создании на нём файловой системы не происходит абсолютного заполнения, то на нём могут остаться обрывки предыдущих данных. Раздел (том) должен быть заполнен случайными данными, что также не даст противнику понять, насколько и в каких местах зашифрованный раздел заполнен полезным открытым текстом (например, чтобы не выявить отдельные файлы по заведомо известным размерам). Использование для генерации криптостойкого генератора случайных чисел /dev/urandom может быть слишком медленным процессом, а утилиты для затирания могут быть ненадёжны: содержать в себе быстрый, но некриптостойкий ГПСЧ или прерывать своё выполнение при генерации слишком больших объёмов случайных данных.

Способ затирания через зануление криптотома

Существует универсальная возможность поднять зашифрованный том, используя /dev/urandom только для генерации временного случайного ключа, не создавая затем файловую систему, а поднятый зашифрованный том заполнить потоком нулей из /dev/zero. При условии, что используемый шифр стоек и близок к идеальному, а режимы дискового шифрования обеспечивают достаточною рэндомизацию, знание противником факта содержания избытка нулей в открытом тексте не поможет криптоанализу.

Использование аппаратной поддержки AES в процессоре и модуля ядра для работы с ним сделает заполнение раздела практически равным скорости записи на носитель. Снаружи контейнер будет заполнен случайными числами с исходной стойкостью использованного шифра и выбранного режима шифрования.

cryptsetup -c aes-xts-plain64 -s 512 -d /dev/urandom create $DeviceName /dev/$DeviceToWipe

Также можно установить утилиту pv и смотреть показания счётчиков прогресса в конвейере команд (возможны индексы размера k, m, g, t).

dd if=/dev/zero bs=1M | pv -s [размер раздела в терабайтах]t > /dev/mapper/$DeviceName

После окончания закроем том:

cryptsetup remove $DeviceName

Примечание: при работе с носителями с избыточностью информации (Flash, SSD, некоторые типы RAID) частичное стирание данных с диска не гарантирует их уничтожение. Для затирания таких устройств рекомендуется выполнить процедуру заполнения случайными данными дважды.

Способ затирания через алгоритм HAVEGE

Алгоритм HAVEGE позволяет генерировать очень быстрые потоки псевдослучайных чисел на основе непредсказуемости колебаний времени исполнения некоторых операций на большинстве процессоров, что связано как с изменением загруженности процессора операционной системой, так и с особенностями внутренней работы самого процессора. Это потенциально позволяет выработать гораздо больше энтропии, чем при обычном перехвате системных прерывании и записи их параметров в пул /dev/random. При этом встроенный аппаратный генератор случайных чисел процессора не используется (во многих случаях ГСЧ в процессоре может отсутствовать или вызывать подозрение на наличие аппаратных закладок), а используется только таймер операций.

Установив соответствующий пакет haveged, а также команду pv для наблюдения за скоростью потока данных, можно быстро заполнить диск псевдослучайными данными:

haveged -n0 | pv -s [размер диска в терабайтах]t > /dev/[имя устройства]

Этот метод нежелательно использовать в виртуальных машинах и при наличии некоторых примитивных типов процессоров без ветвления операций (обычно встречающихся в миниатюрных устройствах). Хотя, с учётом того, что стойкость в плане неразличимости псевдослучайных данных от истинно случайных некритична на практике в процессе заполнения дисков, то этим методом можно пользоваться практически везде, как самым простым и быстрым.

Следует учитывать, что пакет haveged при установке в системе по умолчанию запускает специальный демон, который подкачивает по соответствующему алгоритму процессорную энтропию в пул /dev/random. При недоверии к этому алгоритму пакет можно удалить после заполнения диска, чтобы он больше не использовался системой для других целей.

Какой режим шифрования выбрать в cryptsetup/LUKS?

На данный момент рекомедуется использовать режим шифрования XTS-plain64 с ключом 512 бит (это два ключа по 256 бит: один для шифрования данных, другой для твик-вектора шифрования номеров секторов диска).

cryptsetup -s 512 -h sha512 -c aes-xts-plain64 luksFormat /dev/[имя устройства]

При этом полезно помнить следующее:

1. Ранее был реализован только режим xts-plain, но он не позволял шифровать данные размером более 2 терабайт, так как это приводило к повторению счётчика и утечке данных об открытом тексте.
2. Для замены xts-plain ранее предполагался xts-benbi — метод вычисления вектора инициализации сектора, позаимствованный из устаревшего LRW-режима. Сейчас его выбирать не рекомендуется. Помимо него, до появления 64-битного счётчика в plain-режиме мог применяться комбинированный режим xts-essiv, использование которого также не является оправданным.
3. Хотя режим XTS способен работать с любыми шифрами, у которых размер блока равен 128 бит (напр. Serpent или Twofish), при реализации он корректно проверяется только с шифром AES. Так, при выборе другого шифра возникнет предупреждение, что для данной конфигурации отсутствуют проверенные тестовые векторы, следовательно процедура проверки корректности шифрования выполнена не будет. Также это может вызвать проблемы в будущем, если программная реализация будет изменена, а поддержка расшифровки данных, зашифрованных в XTS не для AES не будет реализована или окажется несовместимой. На данный момент, в более современных версиях ядер поддержка тестовых векторов для разных шифров в XTS-режиме уже включена. Проверьте в своём дистрибутиве отсутствие предупреждений путём просмотра сообщений команды dmesg после инициализации шифрования.
4. Для режима XTS в настоящее время нужно выбирать ключ в два раза превышающий размер ключа в шифре (т.е. 256, 384 или 512 бит, но не 128 бит).

Альтернативой режиму XTS-plain64 является более старый и устоявшийся режим CBC-ESSIV, в котором устранены недостатки простого CBC путём использования шифрования совместно с хэшированием номера сектора. Этот режим не был создан профессиональными криптографами, не является оптимальным по скорости и др. ресурсам, но он получил широкое распространение, долгое время использовался во многих программах по умолчанию и никаких существенных уязвимостей в нём обнаружено не было. Его реализации без проблем позволяют использовать любой шифр, а не только AES (хотя использование шифров с размером блока 64 бит, таких как 3DES, Blowfish и др. вообще не рекомендуется для дискового шифрования). Ожидается, что он будет поддерживаться в будущем, что снимает проблемы совместимости.

В дальнейшем предполагается создание новых улучшенных режимов дискового шифрования, но не следует без крайней необходимости их использовать если не предполагается, что реализации этих режимов стабильны и будут поддерживаться с соблюдением совместимости.

$ pwgen -s -y 20 1