Безопасность EncFS

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

Данные особой ценности не представляют.
Во-вторых, увидел совет о том, что в EncFS вместо AES лучше использовать Blowfish, а размер блока поставить равным 4096.

Это какие то параноидальные замарочки, которые тебе не важны.
AES ускоряется на процессоре (на интелах), и по сути является более проверенным алгоритмом.

Соответственно, первый вопрос: насколько надежна EncFS? Данные особой ценности не представляют

Тогда — вполне надёжно :)

truecrypt

Да вот как раз не очень хочется подобного. Создал я хранилище на 4 гигабайта, а через месяц оказывается, что уже не хватает. Ну ладно, можно придумать как его отресайзить, проблема тут больше в том, что придётся всё заливать заново, а это с моими 2 мегабитами на upload - не очень радужная перспектива. Если делать «на вырост», то теряется ценное место в облаке и увеличивается время на закачку.

Ну ладно, можно придумать как его отресайзить, проблема тут больше в том, что придётся всё заливать заново, а это с моими 2 мегабитами на upload - не очень радужная перспектива.

Вроде как тот же дропбокс не заливает все, а синкает, разве нет?
Трукрипт как бы работает с файлом как с блочным устройством, а потому перезаливать надо только измененные куски.

Вроде как тот же дропбокс не заливает все, а синкает, разве нет?

Синкает, да. Однако теоретически это будет сильно зависеть от того, как именно изменились файлы. На практике большие файлы не заливал, так что не знаю.

Тогда — вполне надёжно :)

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

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

Это сделано в целях безопасности. Чтобы при подмене $PATH пароль не утек.

Привет всем. Появилось желание зашифровать некоторые файлы. Например, чтобы их можно было закинуть на Dropbox для бекапа. Так как количество этих файлов будет увеличиваться со временем и, соответственно, суммарный их объем будет расти, EncFS выглядит логичным выбором.

ничего не понял. Вы собираетесь делать командой dd образ файловой системы и кидать его на dropbox? Какая разница для _уделённых_ бекапов, какая у вас _локальная_ файловая система?

лично я делаю просто: gpg --encrypt backup.txz, а потом заливаю этот архив в хранилище.

SquashFS + UnionFS + любой инструмент шифрования (например losetup + cryptsetup). Получается что-то вроде снапшотов, как раз для бэкапов.

Выше предложили tar.xz, но мне всегда казалось, что в архивах tar скорость доступа к файлам черепашья. Может, неправильно Gentoo скомпилил?

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

ничего не понял. Вы собираетесь делать командой dd образ файловой системы и кидать его на dropbox?

Нет, хочу зашифровать, грубо говоря, выбранные 3 файла, каждый по 30 Мб. При этом сделать так, чтобы при желании можно было зашифровать ещё и четвертый, и пятый, и так далее. Если я возьму какой-нибудь TrueCrypt и создам зашифрованную ФС объемом 100 Мб, то четвертый файл опять же размером 30 Мб просто так добавить туда не получится, так как не хватит места, и придется возиться с ресайзом.

А как в этом случае с ресайзом?

Вообще послушай в данном случае drBatty, шифруй просто сами файлы и не парься.

разве encfs не шифрует сами файлы по отдельности?
можно и на gpg + fuse похожее накостылять. просто encfs уже написана

gpg позволяет в некотором роде не париться о качестве шифрования и о багах реализации.

Может, юзать Wuala. Можно вместе с EncFS для пущей параноидальности

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

Нужно такое шифрование для того, что-бы в случае кражи вашего HDD врагами, они не смогли получить доступ к вашим файлам.

Может, юзать Wuala. Можно вместе с EncFS для пущей параноидальности

ну вот... ещё один... вам я порекомендую холодильник. что-бы для полного спокойствия. Причём тут холодильник? Не причём. Как и EncFS не имеет никакого отношения к файлам, которые лежат в облаке wuala.

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

azure

Wuala же дает дополнительную защиту уже зашифрованных файлов

даёт конечно. Вот только файлы в Wuala будут зашифрованы _только_ средствами wuala. Ну с вуалёй такой номер не пройдёт, а вот админы какого-нибудь drupbox'а могут с лёгкостью посмотреть ваши файлы. Точно также, как и вы сами, и ваша команда cp, которая читает и расшифровывает файлы перед тем, как передать их в хранилище.

Я просто хочу объяснить ТСу ту простую вещь, что шифрование на уровне ФС защищает данные исключительно от других юзеров, в том числе и от локального рута. Но для самого владельца эти файлы - самые обычные. Точнее не для него, а для программ, которые он запускает. Т.е. нет никакой разницы, зашифрован или нет файл внутри ФС - передаваться он будет в открытом виде, и удалённо хранится - тоже.

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

мы точно понимаем принцип работы encfs?

я думаю, прежде чем пояснять принцип работы, вам нужно самому его понять. Я расскажу вкратце как это выглядит для пользователя 1) устанавливаете encfs + cryptkeeper (гуи для удобного пользования шифрованными файлами, если он вам нужен) 2) mkdir ~/encrypted && mkdir ~/temp_encr 3) encfs /home/<your username>/encrypted /home/<your username>/temp_encr (попровит ввести пароль, который будет использоваться для шифрования): Введите пароль для доступа к файловой системе. Запомните пароль, так как в случае утери его, будетневозможно востановить данные. Тем не менее этот пароль можно изменить с помощью утилиты encfsctl.

4) когда вы ложите файлики в /home/<your username>/temp_encr в /home/<your username>/encrypted создаются ЗАШИФРОВАННЫЕ файлы, в т.ч. с измененными названиями

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

я думаю, прежде чем пояснять принцип работы, вам нужно самому его понять.

ничего не понял.

вы? вряд-ли...

man encfs

http://ru.wikipedia.org/wiki/EncFS

зачем мне ман? да ещё и от википедиков? Повторяю ещё раз:
1. либо вы будете использовать уже расшифрованные файлы с ecryptfs. 2. либо вы будете сохранять эту самую ФС целиком. (ну ладно, с некоторыми опциями монтирования можно и частично. Например можно сохранить имена файлов, а потом сохранить эти сами файлы из размонтированой ФС. Правда такой метод приведёт к тому, что расшифруются эти файлы, только после того, как вы их поместите именно в эту ФС. Т.е. смысла в таком «бекапе» нет никакого - файлы сохранятся, но расшифровать их будет нельзя, если зашифрованная ФС потеряется. В итоге бекапить вам придётся и файлы, и ключи, ибо и то и то бесполезно по отдельности. Такой способ потенциально является уязвимым, ибо, как я уже неоднократно повторял, секретный ключ никуда передавать нельзя, в идеале он вообще должен лежать на флешке, а флешка в сейфе).

Что за извращения? tar + gpg проще и удобнее, тем более что tar поддерживает инкрементальные архивы. Уже давно пользуюсь самодельной бэкапилкой, уже не раз выручала

секретный ключ никуда передавать нельзя

Он зашифрован. В открытом виде его можно получить только в RAM локальной машины.

Нет, вы все-таки не понимаете как работает encfs. На dropbox предполагается заливать файлы из зашифрованной директории. Там содержится xml-файл и дерево каталогов с зашифрованными именами файлов и зашифрованным содержимым. Без пароля эти данные почти бесполезны (известен только размер файлов). А пароль из головы пользователя никуда не денется.

anonymous

Что за извращения? tar + gpg проще и удобнее

дык и я о том говорю...

GotF

Он зашифрован.

а мужики-то не знали...

GotF

В открытом виде его можно получить только в RAM локальной машины.

иначе что, расстреляют? Если ты будешь раскидывать _секретные_ ключи где попало(особенно на всяких дропбоксах/ядисках), то и расшифровать его можно где угодно, и куда угодно. Достаточно знать пароль.

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

anonymous

Нет, вы все-таки не понимаете как работает encfs. На dropbox предполагается заливать файлы из зашифрованной директории. Там содержится xml-файл и дерево каталогов с зашифрованными именами файлов и зашифрованным содержимым. Без пароля эти данные почти бесполезны (известен только размер файлов). А пароль из головы пользователя никуда не денется.

повторяю свой вопрос - на кой хрен тут нужен ключ? Почему просто не шифровать файлы паролем?

man gpg на предмет опции --symmetric, как освоишь - продолжим дискуссию.

Достаточно знать пароль.

Ну так его никто и не знает, кроме владельца.

А теперь объясни, на кой хрен тебе этот ключ нужен, и что мешает тебе просто шифровать файлы паролем?

Ты впервые слышишь про шифрованные ФС и полнодисковое шифрование? Во-первых, ключ обычно имеет более высокую стойкость и берётся из /dev/random. Во-вторых, это даёт возможность менять пароли без необходимости шифровать содержимое заново.

повторяю свой вопрос - на кой хрен тут нужен ключ?

Ну, например чтобы зашифровать файл вообще не вводя пароль. Но при чем тут секретный ключ я вообще не понял, encfs использует симметричный ключ.

Dropbox

Кстати, их термс оф юз не запрещает хранить шифрованные файлы?

GotF

Во-первых, ключ обычно имеет более высокую стойкость и берётся из /dev/random.

да хоть из /dev/atsral

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

GotF

Во-вторых, это даёт возможность менять пароли без необходимости шифровать содержимое заново.

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

anonymous

Ну, например чтобы зашифровать файл вообще не вводя пароль.

в encfs так не получится. точнее получится, но смысла нет. Ты сейчас вообще о чём? О ФС или о gpg?

anonymous

Но при чем тут секретный ключ я вообще не понял, encfs использует симметричный ключ.

вот потому-то оно и не подходит для бекапов. повторяю в очередной раз: криптованные ФС нужны для _локального_ криптования данных одних юзеров, от других (в т.ч. и от локального рута). Например можно $HOME на ноуте закриптовать, а потом его с чистой совестью потерять. А вот бекапы так шифровать неудобно, проще gpg, тогда бекапы можно делать автоматически, без пароля, и без ключа, который этим паролем зашифрован. А например моим ключом, который у мну в профиле.

а покажи-ка её, может и мне пригодится

Ты сейчас вообще о чём?

Я с самого начала говорю об encfs.

криптованные ФС нужны для _локального_ криптования данных одних юзеров

Тем не менее, раз уже структура encfs такая удобная для бэкапов, то почему бы ее не использовать?

причём абсолютно не важно, что ты там шифруешь, ключ, или файл.

На самом деле есть такая вещь как PBKDF2, которая может сильно усложнить брутфорс.

вот потому-то оно и не подходит для бекапов

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

если у тебя пароль 123, то любой его с лёгкостью подберёт, причём абсолютно не важно, что ты там шифруешь, ключ, или файл

PBKDF2. Могу выложить дамп своего LUKS-блока, посмотрим, через сколько десятилетий ты подберёшь пароль, являющийся обыкновенным словом :)

тебе надо не только локально перешифровывать ключ, но ещё и удалённо

O_o

Вообще да, EncFS я бы тоже использовать не стал, а запилил бы dm-crypt в файле :)