The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

В результате аудита EncFS выявлено 11 слабых мест в организации процесса шифрования

16.01.2014 12:08

Тейлор Хорнби (Taylor Hornby) представил результаты независимого аудита популярной системы шифрования файлов EncFS, выполненной в форме FUSE-модуля, работающего в пространстве пользователя. В результате проверки выявлено 7 проблем различной степени опасности и ещё 4 потенциальные проблемы, требующие дальнейшего изучения. В итоге сделан вывод, что в EncFS игнорируются многие современные приёмы для обеспечения надёжного шифрования, поэтому в текущем виде EncFS не рекомендуется для защиты критически важных данных.

  1. Главная ссылка к новости (http://sourceforge.net/mailarc...)
Лицензия: CC-BY
Тип: Проблемы безопасности
Короткая ссылка: https://opennet.ru/38869-encfs
Ключевые слова: encfs, crypt
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (77) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, A.Stahl (ok), 12:32, 16/01/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –46 +/
    Некто (впервые слышу о так человеке) провёл аудит нечто (впервые слышу о такой программе) и выявил некоторое количество недоработок.
    Надеюсь некто, пишущие нечто, обратят внимание на аудит некоего человека и произведут некоторые исправления.
     
     
  • 2.22, pavlinux (ok), 14:34, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Тейлор Хорнби - это такая чебурашка, которая сказала Торвальдцу, что он криптолох
    и что инструкция RDRAND в процах Intel (возможно) с бэдором, и которая сваливает
    нагенерённые ПСЧ прямо в пул энтропии, а не добавляет к общему.
    Тут drivers/char/random.c с комментами от этой чебурашки http://pastebin.com/A07q3nL3

     
     
  • 3.35, BSA (?), 17:50, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Чебурашка не чебурашка, а все-таки он дельную идею сообщил. На мой взгляд, его идея о том, что не следует слепо доверять RDRAND, не лишена разумности.
     
     
  • 4.36, ананим (?), 18:12, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    В линухе ему и не доверяли. И это не его идея.
    Со вчерашнего дня и в бсд тоже.
     
     
  • 5.51, Аноним (-), 19:01, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > И это не его идея.
    > Со вчерашнего дня и в бсд тоже.

    хорошо сказал

     
     
  • 6.60, ананим (?), 19:31, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Нормально сказал. Идея то не его.
    Ну попиарился человек, бывает.
     
  • 3.48, Аноним (-), 18:56, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > и что инструкция RDRAND в процах Intel (возможно) с бэдором, и которая
    > сваливает нагенерённые ПСЧ прямо в пул энтропии, а не добавляет к общему.

    Не, там идея в том, что байты из RDRAND XORятся с байтами из других источников энтропии, но эти байты находятся в кэше CPU, а значит, злобный интель может и их тоже ослабить (обнулить, например).

     
     
  • 4.61, pavlinux (ok), 19:31, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Не, злобный Интель может увидеть что просят операцию XOR Там зырь какая фигня ... большой текст свёрнут, показать
     
     
  • 5.62, Аноним (-), 20:12, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    То бишь, gcc будет инициализировать элементы hash.l в ноль? А как же их перекрытие с hash.w (это ж union, а не struct)?
     
     
  • 6.67, pavlinux (ok), 20:18, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > То бишь, gcc будет инициализировать элементы hash.l в ноль?

    По идее великого феншуя - там должен быть неизвестный мусор.
    А GCC уже давно обнуляет, если там не сказать volatile (и то не уверен).
      
    > А как же их перекрытие с hash.w (это ж union, а не struct)?

    А вот это уже зависит как этот пул дальше использовать.
    Если в пуле пропустить 5 штук (__u32), то получим 10 лонгов от Интеля :)

     
     
  • 7.69, Аноним (-), 20:20, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    А, LONGS(EXTRACT_SIZE) > 5? Тогда да, ССЗБ.
     
     
  • 8.70, pavlinux (ok), 20:28, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    define EXTRACT_SIZE 10 define LONGS x x sizeof unsigned long - 1 size... текст свёрнут, показать
     
     
  • 9.71, Аноним (-), 20:31, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    include stdio h define EXTRACT_SIZE 20 define LONGS x x s... текст свёрнут, показать
     
     
  • 10.72, pavlinux (ok), 20:36, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    И дальше развивай мысль ... текст свёрнут, показать
     
     
  • 11.73, Аноним (-), 20:41, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Если я правильно понимаю, __u32 - это 4 байта 5 4 20 Соответственно, EXTRACT... текст свёрнут, показать
     
     
  • 12.76, pavlinux (ok), 21:25, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Ой пля, там же union чёй-то я туплю Пойду ещё стакан выпью D... текст свёрнут, показать
     
     
  • 13.82, Аноним (-), 23:02, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    А я еще в 62 намекал Собственно, суть утверждений этого параноика в том, что... текст свёрнут, показать
     
     
  • 14.87, pavlinux (ok), 04:02, 17/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Ну и ладно, зато drivers char random c еще разок поизучали Изменения-то видел,... текст свёрнут, показать
     
  • 3.49, Аноним (-), 18:58, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > http://pastebin.com/A07q3nL3

    А что с его коментами к коду не так? Написано "does not use the hw random", а оно таки использует, хотя преимуществ именно такого теоретического бекдора не понял. В http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/c гите слегка не так - это поправили? Но похрен же, если rng может xor в известное число, то хешировать его без толку.


     
     
  • 4.53, Аноним (-), 19:06, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Либо известное, либо неизвестное. Зависит от того, как компилятор соптимизирует, и процессор закеширует.
     
  • 4.64, pavlinux (ok), 20:14, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >> http://pastebin.com/A07q3nL3
    > А что с его коментами к коду не так? Написано "does not
    > use the hw random", а оно таки использует, хотя преимуществ именно
    > такого теоретического бекдора не понял. В http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/c
    > гите слегка не так - это поправили? Но похрен же, если
    > rng может xor в известное число, то хешировать его без толку.

    После

    for (i = 0; i < LONGS(20); i++) {
    unsigned long v;
    if (!arch_get_random_long(&v))
    break;
    hash.l[i] ^= v;
    }

    c массивом hash.l[] нужно чё-нить сотворить

     
     
  • 5.84, Аноним (-), 23:57, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > нужно чё-нить сотворить

    http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers

    Нашел коммит. Все же без кеширования пула _перед_ вызовом rng бекдор не прокатит. Правда вызов не один, да и вообще, инструкция перед исполнением в кеше есть, значит..(здесь и далее рассуждения не читавшего код параноика). Вот в комменте явно указано not use, а парой функций глубже use больше паранои. Ну, можно списать на NSA^Wзабыли и всем настирать на комменты.

     
     
  • 6.88, pavlinux (ok), 04:12, 17/01/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Угу, ещё спинлоком прикрыли, чтоб мусор случайно АНБшниками не попал Чесна... большой текст свёрнут, показать
     

  • 1.2, brzm (?), 12:33, 16/01/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Оюшки... Господа знатоки, какие есть удобные альтернативы?
     
     
  • 2.16, chkconfig (?), 13:37, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Неудобный eCryptFS :)
     
     
  • 3.89, Аноним (-), 07:08, 17/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Подождите, он ещё и аудит ecryptfs проведёт.
     
     
  • 4.90, Аноним (-), 07:10, 17/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Подождите, он ещё и аудит ecryptfs проведёт.

    А разработчики encfs, уверен, прислушаются и допилят всё что нужно.

     
  • 2.23, an0 (?), 14:35, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    geli во фришке. И просто и удобно. И исходник можно поправить немного чтобы не выводил что я там подсоединяю/отсоединяю.
     
     
  • 3.34, ананим (?), 17:07, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    И гловное что всякие тейлоры не доё..капываются.

    Вчерась бац, https://www.opennet.ru/opennews/art.shtml?num=38865 — эту новость можно читать и так — синдром сноудена приходит к фряшникам на год позже, чем к линуксоидам.

     
     
  • 4.85, Аноним (-), 00:57, 17/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    К линуксоидам он вообще не приходил, только собирался. И то на порог не пустили.
     

  • 1.3, Forth (ok), 12:39, 16/01/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    TrueCrypt.
    LUKS.
     
     
  • 2.4, anonymous (??), 12:46, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    EncFS предоставляет шифрование на уровне ФС, а не блочных устройств. Только вот зачем кому-то нужно именно на уровне ФС - не понятно.
     
     
  • 3.6, Аноним (-), 12:53, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    А как держать данные на дропбоксе?
     
     
  • 4.39, Аноним (-), 18:44, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > А как держать данные на дропбоксе?

    Практически у всех облачных хранилищ шифрование запрещено лицензионным соглашением.

     
     
  • 5.46, Аноним (-), 18:52, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >> А как держать данные на дропбоксе?
    > Практически у всех облачных хранилищ шифрование запрещено лицензионным соглашением.

    Закон - как дышло. Я их имел в виду, у меня принцитиально всё зашифорованное, даже фотки котиков :) Пока в суд не подали :))

     
     
  • 6.54, Аноним (-), 19:08, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >>> А как держать данные на дропбоксе?
    >> Практически у всех облачных хранилищ шифрование запрещено лицензионным соглашением.
    > Закон - как дышло. Я их имел в виду, у меня принцитиально
    > всё зашифорованное, даже фотки котиков :) Пока в суд не подали
    > :))

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

     
     
  • 7.55, Crazy Alex (ok), 19:13, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Сейчас этих облаков столько, что хранить в одном, без дублирования - даже странно как-то. Так что не страшно ни разу. Тем более, что новый аккаунт создаётся за пару минут. Можно даже на том же сервисе.
     
     
  • 8.65, Аноним (-), 20:15, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Угу С полной утратой всех халявных гигов, полученных раньше, да еще и с перспек... текст свёрнут, показать
     
     
  • 9.77, Crazy Alex (ok), 21:59, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Кто как, а я в халявные гиги не играюсь - смысла ни малейшего Мне того, что даё... текст свёрнут, показать
     
  • 5.58, Crazy Alex (ok), 19:19, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Кстати - сюрприз - такие аккаунты обычно еще и создаются с левыми данными, что тоже лицензионными соглашениями запрещено. Только как-то наплевать.
     
     
  • 6.66, Аноним (-), 20:18, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Кстати - сюрприз - такие аккаунты обычно еще и создаются с левыми
    > данными, что тоже лицензионными соглашениями запрещено. Только как-то наплевать.

    Ага, один такой как-то наплевал на правила IANA.
    http://habrahabr.ru/company/prostopleer/blog/186314/

     
     
  • 7.78, Crazy Alex (ok), 22:01, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Разницу между доменом и одним из нескольких акков, на которые бекапятся одни и те же данные понимаешь? Писал же выше - хранить свои данные в ЛЮБОМ облаке без дублирования - маразм по нынешним временам.
     
  • 5.75, Аноним (-), 21:14, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Разве яндекс, к примеру, не изменил этот пункт в лучшую сторону?
     
  • 5.86, Аноним (-), 00:58, 17/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Практически у всех облачных хранилищ шифрование запрещено лицензионным соглашением.

    Ну ладно, нальем им просто вывода /dev/random, нехай NSA расшифровывает. А когда не получится - сделаем козью морду :)

     
  • 5.94, А. Н. Оним (?), 15:47, 18/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >> А как держать данные на дропбоксе?
    > Практически у всех облачных хранилищ шифрование запрещено лицензионным соглашением.

    Можно пруф? У дропбокса в соглашении не нашёл.

     
  • 3.18, хрюкотающий зелюк (?), 14:18, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Только вот зачем кому-то нужно именно на уровне ФС - не понятно.

    Чтоб не хрюкнулись все данные, лучше такое шифрование поверх проверенной ФС.

     
     
  • 4.38, Аноним (-), 18:43, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Чтоб не хрюкнулись все данные, лучше такое шифрование поверх проверенной ФС.

    Что мешает держать блочное устройство в файле поверх проверенной ФС (если уж вам так хочется вводить лишние слои)?

     
     
  • 5.59, Crazy Alex (ok), 19:20, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Например, нежелание иметь дело с лишним кодом (поддержки блочного устройства) и лишними багами?
     
     
  • 6.63, Аноним (-), 20:13, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Например, нежелание иметь дело с лишним кодом (поддержки блочного устройства) и лишними багами?

    Хотите юзать ФС, не используя блочные устройства? Ну удачи вам.

     
     
  • 7.79, Crazy Alex (ok), 22:06, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Вариант encfs:
    нативное блочное устройство -> FS -> шифрование
    Вариант "контейнер поверх FS":
    нативное блочное устройство -> FS -> контейнер -> FS

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

     
     
  • 8.83, Аноним (-), 23:06, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Вот и я не понимаю, почему хрюкотающий зелюк хочет держать данные поверх пров... текст свёрнут, показать
     
  • 8.93, Аноним (-), 01:02, 18/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Так-то эти облака не всегда fs и не все операции позволяют выполнять Оналогия f... текст свёрнут, показать
     
  • 3.20, Аноним (-), 14:24, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Что бы синхронизировать не гигантский имидж диска, а только изменённые файлы.
     
     
  • 4.44, Аноним (-), 18:49, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Что бы синхронизировать не гигантский имидж диска, а только изменённые файлы.

    Что мешает синхронизировать содержимое смонтированных контейнеров?

     
     
  • 5.47, Аноним (-), 18:54, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >> Что бы синхронизировать не гигантский имидж диска, а только изменённые файлы.
    > Что мешает синхронизировать содержимое смонтированных контейнеров?

    А что лучше - С или С++? Exim или Postfix? Ну и т.д.
    Если звёзды зажигают ...

     
     
  • 6.52, Аноним (-), 19:02, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А что лучше - С или С++?

    Зависит от задачи.

    > Exim или Postfix?

    Если бы Debian не навязывал по умолчанию Exim, а Redhat - sendmail, Postfix давно бы уже стал абсолютным лидером, ввиду объективного превосходства.

    > Если звёзды зажигают ...

    Если велосипеды изобретают... значит, у кого-то NIH.

     
  • 5.56, Crazy Alex (ok), 19:15, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    То, что там меняться начинает черт знает что вместо одного единственного файла. И. соответственно, объем синхронизации гораздо больше. Да, я в курсе, что это слегка увеличивает безопасность. Нет, я не готов так заморачиваться.
     
     
  • 6.68, Аноним (-), 20:18, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > То, что там меняться начинает черт знает что вместо одного единственного файла.
    > И. соответственно, объем синхронизации гораздо больше.

    Нет.

     
     
  • 7.80, Crazy Alex (ok), 22:08, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Тот-то люди жаловались, что дропбокс при изменении любый файлов в truecrypt-контейнере его весь перезаливает. Может, это и клиент туп - мне до лампочки. Если есть способ тривиально указать единицу, с которой надо работать - один файл - на кой хрен мне контейнер? Чтобы словить ограничение на объем и морочить голову с расширением FS?
     
  • 3.29, Аноним (-), 15:41, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    за тем что с эьим меньше гемороя.
     

  • 1.14, Аноним (-), 13:22, 16/01/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ладно хоть в truecrypt всё стабильно.
     
     
  • 2.15, бедный буратино (ok), 13:25, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Ладно хоть в truecrypt всё стабильно.

    есть результаты аудита?

     
     
  • 3.17, Андрей (??), 14:17, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    "Стабильно" - это значит, никому в голову не пришло поковыряться палочкой в данной проге.
     
     
  • 4.21, Аноним (-), 14:30, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    её ващето гугл пользует и разрабатывает
     
     
  • 5.24, pavlinux (ok), 14:39, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > её ващето гугл пользует и разрабатывает

    А ещё гугл заставляют в принудительном порядке, организовывать заворачивание трафика на сервера АНБ/ФСБ/МИ6 ....  

     
     
  • 6.31, Аноним (-), 16:05, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >> её ващето гугл пользует и разрабатывает
    > А ещё гугл заставляют в принудительном порядке, организовывать заворачивание трафика на
    > сервера АНБ/ФСБ/МИ6 ....

    А еще гугп зачем-то добпвляет свой

     
  • 6.32, Аноним (-), 16:58, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Пруфы где, павлин?
     
  • 2.27, Аноним (-), 14:52, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    У TrueСrypt скоро будет свой аудит. Там и посмотрим на эту стабильность.
     

  • 1.19, zomg (?), 14:22, 16/01/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    LUKS же. EncFS не нужен.
     
     
  • 2.26, azure (ok), 14:40, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Мне вот нужен. Позволяет в отдельной папочке (лежащей будь то на публичном шаринге или на флешке\ноутбуке\внешнем винте, которые можно потерять или на свое) секурно хранить данные не предназначенные для чужих глаз и позволяет секурно же бекапить эти файлики. А LUKS - он решает другие задачи. И я убежден в том, что он может делать задачу шифрования данных на уровне блочного устройства хорошо и правильно. Просто мне не нужно весь раздел шифровать, я не страшусь попадания в третьи руки стандартных GNU компонентов моей системы :)
     
     
  • 3.40, Аноним (-), 18:45, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Откройте для себя понятие "монтирования".
     
     
  • 4.57, Crazy Alex (ok), 19:17, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Проблему инкрементного бекапа, например, это не решит. Да и вообще - что за манера предлагать вместо наиболее удобного инструмента - приблизительно похожий с костылями?
     
     
  • 5.74, Аноним (-), 20:43, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Проблему инкрементного бекапа, например, это не решит.

    Решит. Достаточно бэкапить смонтированную ФС, а не контейнер целиком (что вполне логично).

    > Да и вообще - что за манера предлагать вместо наиболее удобного инструмента - приблизительно похожий с костылями?

    Что за манера - лезть со своим синдромом утенка, развешивая ярлыки "костыль" на все, что не похоже на маму-утку?

     
     
  • 6.81, Crazy Alex (ok), 22:18, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не путай архитектурную кривизну пихания здесь блочного устройства с синдромами. Здесь наша единица, с которой работаем - файл. Не контейнеры, не иноды, не что-то еще - а файл. И нормальный бескостыльный способ - это работать с файлом. Контейнер здесь - именно что костыль.

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

     

  • 1.33, vsespb (ok), 17:01, 16/01/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Есть же encfs --reverse. Очень удобная штука. Ничего не шифруем, все данные лежат в нормальной файловой системе. А если нужно сделать их бэкап - видим их зашифрованными через FUSE. Можно делать инкрементальный бэкап.

    И чем его заменить теперь?

     
     
  • 2.41, Аноним (-), 18:46, 16/01/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Есть же encfs --reverse. Очень удобная штука. Ничего не шифруем, все данные
    > лежат в нормальной файловой системе. А если нужно сделать их бэкап
    > - видим их зашифрованными через FUSE. Можно делать инкрементальный бэкап.
    > И чем его заменить теперь?

    Бэкапиться внутрь шифроконтейнера, например.

     

  • 1.92, бедный буратино (ok), 15:32, 17/01/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    2014-01-17 / NEW PACKAGE (1.7.4)
          security/encfs
               COMMENT: fuse-based cryptographic filesystem

    Ура! Теперь она достаточно безопасна и для openbsd :)

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру