Как создать криптоконтейнер linux

huh-muh

ламер с дебианом aka обезьяна с гранатой

воскресенье, 8 июня 2014 г.

Linux: создаём зашифрованный контейнер

Наверно, в жизни каждого человека происходят случаи, которые можно охарактеризовать одним словом: «невезуха». Например, ты заказал себе жесткий диск для хранения бэкапов, но твой компьютер не дождался и сгорел за день до получения покупки. Или ты сменил работу, а через месяц твоя новая фирма разорилась. Или ты купил дачу, а рядом с ней с наветренной стороны построили свиноферму. Или ещё что-нибудь.

В середине весны у меня на служебном компьютере умер очередной винчестер, и стало ясно, что так продолжаться не может. Хоть я потерял и не сильно критичные файлы — какие-то старые бэкапы и пиратские дистрибутивы — но это событие всё равно оказалось, что называется, close call. Поэтому было принято стратегическое решение: упорядочить свои данные и работу с ними. Сделал я это следующим образом.

Во-первых, был выполнен аудит имеющейся в моём распоряжении информации и произведено её разделение на три неравные части:

1) Критически важная: продукты моего труда (исходники программ, какие-то запросы, заметки, уникальные документы и т.п.), логины-пароли и т.д.

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

3) Не важная: дистрибутивы, скачанные с инета, временные файлы и т.д. В общем, всё, что можно восстановить или не сильно жалко потерять.

Во-вторых, принят регламент дальнейшей работы:

1) В качестве операционной системы использовать Linux.

2) Те задачи, которые не могут быть перенесены под линукс и которые нужно решать по долгу службы (в частности, у нас существенно используются .NET приложения, часть из которых разрабатывал я сам), будут жить на виртуальной машине под управлением Oracle VM VirtualBox.

3) Не раскидываться по компьютерам. Не должно быть такого: что-то дома, что-то на работе, что-то вообще непонятно, где. Всё, что я делаю, должно храниться в одном месте.

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

Лучшим решением, наверно, было бы переселиться на ноутбук. Но, во-первых, тупо нет лишних денег, и, во-вторых, лень таскать его с работы домой и обратно. Поэтому в качестве паллиатива был прикуплен внешний жесткий диск (3Q 500Гб USB 2.0) за 1800 рублей. Дальше предполагалось следующее:

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

2) копировать их ежедневно на свой домашний компьютер

3) криптоконтейнер с критически важной информацией закидывать в DropBox (это, кстати, накладывает ограничение на объем этого криптоконтейнера — 2 Гб и служит одной из причин наличия приставки «крипто-» во всей этой истории вообще)

И всё получилось как нельзя лучше, но дальше началась та самая «невезуха». В качестве средства для создания криптоконтейнеров я выбрал знакомый мне с незапамятных виндовских времён TrueCrypt 7.1a. Это было в конце апреля. В конце мая вышеуказанный проект начало как-то подозрительно колбасить, и это заставило меня начать поиск альтернатив.

И тут выяснилась поразительная вещь. Оказывается, всё это время у меня под носом тихо лежало всё необходимое для создания полноценных криптоконтейнеров! Я имею в виду cryptsetup с LUKS. Удивительная всё-таки штука этот линукс. Делается подобное, как я понял, так:

1) Создаётся файл myContainer нужного размера:

2) Этот файл превращается в криптоконтейнер:

3) Просматривается список занятых loopback-устройств:
и находится первое свободное, скажем, /dev/loop0. Либо это можно сделать сразу командой:

4) Криптоконтейнер ассоциируется с этим свободным устройством:
либо, опять-таки, минуя п.3 всё это делается сразу:

5) Открывается криптоконтейнер командой:

6) Содержимое криптоконтейнера форматируется командой:

7) Теперь можно примонтировать криптоконтейнер к заранее созданной точке myMountpoint:

То есть в итоге получается такая цепочка:
файл myContainer -> устройство /dev/loop0 -> устройство LUKSmyContainer -> точка монтирования myMountpoint

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

После того, как работа завершена, можно отключить этот криптоконтейнер, выполнив последовательность команд:

Кстати, ещё один приятный момент: cryptsetup всю работу с loopback-устройствами может взять на себя. Так что, если мне потребуется примонтировать криптоконтейнер, я могу воспользоваться более простым вариантом:
(Кстати, в убунте вторая команда не требуется — устройство подхватывается и монтируется автоматически.)

Соответственно, при отключении криптоконтейнера в этом случае понадобятся всего две команды:
(И снова кстати — в убунте при отключении тома через файловый менеджер Thunar никаких дополнительных команд не требуется вообще.)

Ну и напоследок: чтобы посмотреть все подключенные в данный момент устройства, включая и криптоконтейнеры, достаточно выполнить команду:

Источник

cryptopunks

Краткое описание

Существует огромное кол-во мнений по поводу небезопасности использования TrueCrypt, мы эти домыслы поддерживать не будем, но расскажем о достойной альтернативе под ОС Linux. Сегодня поговорим о технологии LUKS (Linux Unified Key Setup).
LUKS умеет шифровать как сами диски так и создавать криптоконтейнеры непосредственно в файлах. Поговорим о последнем варианте, т.к. первый обычно умеют все современные инсталляторы популярных дистрибутивов, а если вы гик и хотите сделать всё сами, то вероятнее всего найдёте необходимый мануал самостоятельно.
К слову: LUKS поддерживает огромное кол-во шифров и шустрее TrueCrypt, т.к. работает на уровне ядра ОС.

Необходимые шаги

1) Ставим пакет cryptsetup:

$ sudo apt-get install cryptsetup

2) Создаём пустой файл для будущего контейнера (например 200Мб):

$ fallocate -l 200M /home/user/darkthrone.avi

(слабая, но хоть какая-то маскировка; под видеоклип)

3) Создаём в этом файле криптоконтейнер:

$ sudo cryptsetup -y luksFormat /home/user/darkthrone.avi

Отвечаем утвердительно набирая в большом регистре YES, повторив два раза пароль.

4) Открываем контейнер:

$ sudo cryptsetup luksOpen /home/user/darkthrone.avi decrypt_data

5) Создаём на нём файловую систему:

$ sudo mkfs.ext4 /dev/mapper/decrypt_data

6) Создаём каталог для монтирования:

$ sudo mkdir /mnt/data

7) Монтируем расшифрованный контейнер:

$ sudo mount /dev/mapper/decrypt_data /mnt/data

8) Записываем необходимые файлы в /mnt/data, после чего его можно отмонтировать:

$ sudo umount /mnt/data

9) Извлекаем контейнер:

$ sudo cryptsetup luksClose /dev/mapper/decrypt_data

Источник

Создание и использование в «облаке» криптоконтейнера LUKS (dm-crypt)

Содержание

LUKS (Linux Unified Key Setup) — спецификация шифрования диска (или блочного устройства), изначально предложенная для Linux, но сейчас поддерживаемая и в ряде других операционных систем.

Особенности

—- Данные сохраняются по блокам, как в обычном файле/файловой системе. То есть :

—- В отличие от EncFS

—- В отличие от Truecript

Создание контейнера

и проверяем (должен быть вывод «kernel/drivers/md/dm-crypt.ko»)

Размечаем контейнер, как luks-систему с ключом

или — без ключа, с набором пароля при каждом открытии контейнера

Будет предупреждение WARNING! Данные на /home/user/.private/container.crt будут перезаписаны без возможности восстановления. Are you sure? (Type uppercase yes), надо набрать YES.

смотрим, появился ли в устройствах, и информация о нем

Форматируем содержимое контейнера, в данном примере в ext4, с установкой метки и отключением «резерва рута»

монтируем и выдаем права пользователю (себе)

и проверяем «занятые» ключами слоты (их должно быть два, если мы задали ключ и пароль, Key Slot 0: ENABLED и Key Slot 1: ENABLED)

Использование контейнера

Если уж мы этим занялись, сделаем «кнопку» и «раскрасим» ее подобающим образом. Мы же не будем работать с контейнером из командной строки? Выбираем любую приглянувшуюся нам картинку в /usr/share/app-install/icons/ — там их больше 2000, например, cryptkeeper.png и копируем к себе в профиль

В даше появляется кнопка по имени «Контейнер», выносим ее на панель ланчера. По нажатию на нее -выводится сообщение о статусе (состоянии) контейнера. По ПКМ — выбираем пункт меню:

По вызову «Открываем с паролем» — не используется файл-ключ, в окне терминала будет выдан запрос на ввод пароля.

—-Создадим скрипты для выполнения действий с контейнером. Для проверки статуса — проверяем монтирование. Создаем файл privatestatus.sh

Для открытия — останавливаем службу dropbox и проверяем, не был ли уже открыт контейнер, и открываем. При открытии или проверке статуса, если контейнер открыт, сообщение дополняется информацией о размере (в процентах) использованного места, например: «Занято: 64%»

Для открытия с запросом ввода пароля потребуется вызов окна терминала.

Для закрытия — проверяем, не был ли уже закрыт контейнер, закрываем и стартуем службу dropbox.

Даем права на выполнение

В завершение, создадим ссылку для помещения в dropbox каталога .private под именем dropboxcript

Увеличение размера (контейнера)

Посмотреть, сколько места использовано (занято файлами) в нашем контейнере, можно так:

Если заканчивается свободное место, увеличим размер контейнера. Например, на 50M. Перед этим — убедимся, что «контейнер закрыт».

Источник

Шифруемся по полной

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

Т.е. в обоих случаях возможен «терморектальный криптоанализ TM » по факту наличия шифрованой инфы на компьютере.

Что привело меня к написанию небольшого скрипта.
Его можно запустить даже с LiveCD, он не создает шифрованых файлов или разделов, но и конечно же имеет следующие проблемы:

• контролировать целостность данных прийдется вручную;

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

Суть всех телодвижений состоит в том чтобы создать криптоконтейнер на используемом диске в неиспользуемой области используя только встроенные команды стандартного Ububntu LiveCD.

Тестировал его только в песочнице (на отдельном разделе размером 200Мб создавал криптоконтейнер 50Мб со смещением 50Мб) мд5 суммы файлов на физическом разделе (20Мб) и внутри криптоконтейнера (10 Мб) сошлись с оригиналами.

Все делаем под рутом (sudo su).
устройство, место(Смещение), размер заменяем на свои. Размер и смещение от начала диска везде указанно в Мегабайтах байтах.

Создаем

/mnt1
mount -t tmpfs

/mnt1
dd if=/dev/urandom of=

/mnt1/file bs=1M count=размер
losetup -e aes /dev/loop2

/mnt1/file
// вводим пароль
mkfs -t ext2 /dev/loop2
dd if=/dev/loop2 of=устройство bs=1M seek=место count=размер

losetup -e aes /dev/loop1 &ltустройство> -o &ltместо> —sizelimit &ltразмер>
// вводим пароль
mount /dev/loop1
mkfs -t ext2

Монтируем

modprobe cryptoloop
modprobe aes

/mnt2
mount -t tmpfs

/mnt1/file if=устройство bs=1M skip=место count=размер
losetup -e aes /dev/loop2

/mnt1/file
// вводим пароль
mount /dev/loop2

/mnt2

losetup -e aes /dev/loop1 &ltустройство> -o &ltместо> —sizelimit &ltразмер>
// вводим пароль
mount /dev/loop1

Размонтируем

umount /dev/loop2
dd if=/dev/loop2 of=устройство bs=1M seek=место count=размер

umount /dev/loop1

Примечание

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

P.S.: Как продолжение данного метода в небольшой контейнер созданный данным способом можно положить полноценную программу для шифрования, например тот же Truecrypt. Или же придумать что-то свое использующее похожий принцип, но уже более удобное и более безопасное.

Читайте также:  Майкрософт net framework для windows 10

UPD: Раннее был молод и глуп, все делается намного легче, нежели было представленно изначально, собственно поправил статью.

Источник

Наследники «Энигмы». Обзор современных криптосредств в Linux

Содержание статьи

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

Введение

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

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

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

В статье будет описана настройка следующих методов криптозащиты:

• dm-crypt/LUKS — создание криптоконтейнера с помощью device-mapper и CryptoAPI ядра;
• eCryptfs — шифрование на уровне файловых систем;
• EncFS — аналогично описанному выше, но не требует загрузки модулей ядра.

dm-crypt/LUKS

Существует два вида настройки dm-crypt — plain и LUKS. Отличие в том, что в случае использования LUKS в начале криптотома присутствуют метаданные, позволяющие использовать несколько ключей и изменять их. В то же время наличие подобного заголовка в некоторых случаях само по себе компрометирующе — впрочем, в большинстве подобных случаев будет компрометирующей и область с высокой степенью энтропии.

Настройка plain dm-crypt с файлом ключа и парольной фразой

Посмотрим, как настроить комбинацию из тома plain dm-crypt, зашифрованного с помощью ключевого файла, в свою очередь содержащегося в LUKS-контейнере. Для начала стоит определиться, как именно будут размещаться разделы. Существует три основных варианта:

• просто крипто-том;
• сперва крипто-том, затем поверх него LVM;
• сперва крипто-том, затем RAID, затем LVM.

И всяческие комбинации. Давай попробуем второй вариант. Первым делом создадим контейнер LUKS для хранения ключевого файла, чтобы использовать этот файл вместе с ключевой фразой. В этом случае вероятность криптоанализа тома, зашифрованного с помощью plain dm-crypt, снижается:

Первая команда подготавливает файл контейнера, вторая этот контейнер создает, третья подключает, четвертая генерирует ключевую информацию. Стоит заметить, что опция —align-payload=1 нужна для того, чтобы размер метаданных LUKS составлял не 4096 512-байтовых блоков, а всего лишь 2056. Таким образом, на собственно ключевую информацию остается 512 байт.

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

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

Генерация ключа и настройка криптотома
Создание LVM поверх криптотомов

И далее потребуется настроить подключение этого тома при загрузке. Для этого мы будем использовать initramfs. Запишем имена нужных модулей в файл /etc/initramfs-tools/modules:

Создадим файл /etc/initramfs-tools/hooks/cryptokeys примерно следующего содержания (служебная часть скрипта опущена):

И файл /etc/initramfs-tools/scripts/local-top/cryptokeys (служебная часть опять же опущена):

Эти два файла должны быть исполняемыми. Затем создаем initrd:

При следующей перезагрузке будет запрошен пароль для LUKS-контейнера.

В случае использования plain dm-crypt есть еще одна возможность — общий нижний слой, что позволяет сделать нечто наподобие скрытых томов TrueCrypt. Проще привести пример:

Размер и смещение указываются в 512-байтовых блоках.

Настройка двух plain dm-crypt томов на общем устройстве

Xakep #200. Тайная жизнь Windows 10

Расширенные возможности LUKS

Давай посмотрим также и на расширенные возможности использования LUKS-контейнеров. К ним можно отнести смену ключей. Это необходимо при компрометации или создании политики смены ключей. Первым шагом для этого будет создание резервной копии заголовка контейнера. Если все нормально, после смены ключа ее можно уничтожить. Делаем мы ее, понятно, на нешифрованный раздел:

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

Наконец, добавляем новый ключ в систему:

Отключаем-подключаем том, дабы убедиться, что мы ничего не сломали, и удаляем старый ключ:

Рассмотрим и процедуру восстановления томов LUKS. Самый простой вариант, разумеется, когда есть копия заголовка. В этом случае для восстановления требуется всего одна команда:

После этого подключаем том, используя старые пароли/ключи.

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

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

Длина итогового файла варьируется от параметров, заданных при создании тома LUKS. Чаще всего — 32 байта. После извлечения мастер-ключа нужно отключить LUKS-том и проинициализировать его заново с использованием данного мастер-ключа и теми же самыми параметрами, что использовались при первой инициализации, например, так:

EncFS

Посмотрим, как настроить EncFS для автоматического монтирования при входе в систему. Для начала поставим нужные пакеты:

Затем нужно выбрать, будет ли происходить автомонтирование при входе или же чуть позже, с помощью gkeyring. Здесь будет описан первый способ из-за его универсальности. Настроим сначала ФС.

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

Начало создания EncFS

Следом нужно отредактировать файл /etc/security/pam_encfs.conf:

И файл /etc/fuse.conf:

И добавим пользователя в группу fuse:

После выхода-входа каталог private можно будет использовать как хранилище для личных данных. Стоит, однако, отметить, что аудит выявил некоторые (достаточно серьезные) проблемы с безопасностью, из-за чего данную систему крайне не рекомендуется использовать для хранения действительно важных данных.

eCryptFS

Известно, что eCryptFS применяется в Ubuntu как средство по умолчанию для защиты домашних каталогов. Посмотрим, как оно работает, — создадим шифрованный каталог вручную. Установим пакеты:

Как и в случае с encfs, создадим два каталога:

И смонтируем ФС (при первом монтировании создаются все необходимые метаданные):

Будет запрошена парольная фраза (всего один раз, повторный ввод не реализован, что выглядит не очень хорошим решением, учитывая, что она должна быть длинной), затем будет запрошен тип шифра (AES, Blowfish, 3DES, Twofish, CAST6 и CAST5), размер ключа, задан вопрос, разрешить или запретить нешифрованные файлы в каталоге с зашифрованными, шифровать ли имена файлов. и в финале спросит, действительно ли желаем подмонтировать и сохранить ли сигнатуру в определенный файл. Вопрос не настолько глупый, как может показаться сначала: в данном ПО при отсутствии сигнатуры не существует возможности отличить правильный пароль от неправильного.

Создание eCryptFS

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

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

Шифрование домашнего каталога пользователя
Предупреждение о необходимости запомнить парольную фразу
Парольная фраза

Посмотрим, как его восстанавливать. Предположим, что парольная фраза не записана и восстановление идет с Live CD. Подразумевается, что ФС подмонтирована. Переходим в каталог home/.ecryptfs/rom/.ecryptfs и набираем команду:

ecryptfs-unwrap-passphrase ./wrapped-passphrase

Затем передаем полученную парольную фразу в ecryptfs-add-passphrase:

И, запомнив токены и создав каталог, подмонтировать данную зашифрованную ФС к нему:

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

Процесс ручного восстановления eCryptFS

dm-verify

Модуль dm-verify предназначен для проверки целостности блочных устройств. Верификация ведется с помощью hash tree, где «листья» — хеш-суммы блоков, а «ветви» — хеш-суммы наборов «листьев». Таким образом, для верификации блочного устройства (будь то раздел или диск) достаточно проверить всего одну контрольную сумму.

Этот механизм (вкупе с цифровой подписью) применяется в некоторых Android-устройствах для защиты от модификации системных разделов, а также в Google Chromium OS.

Заключение

Linux содержит действительно немало средств для криптографической защиты информации. Из трех описанных средств как минимум одно присутствует во всех современных дистрибутивах Linux. Но что же выбрать?

dm-crypt/LUKS стоит применять в тех случаях, когда есть возможность быстро отключить зашифрованный том и когда резервные копии либо не нужны, либо засекречиваются иным путем. В этом случае данное решение более чем эффективно, особенно с учетом того, что шифровать можно каскадом произвольной вложенности и типа (например, AES-Twofish-AES), — настоящий рай для параноиков.

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

EncFS же — старичок примерно десятилетней давности, базирующийся на еще более древних работах. К настоящему времени не рекомендован к использованию из-за потенциальных дыр в безопасности, но может применяться в качестве кросс-платформенного средства для защиты несенситивных данных в облаках.

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

Источник