Тейлор Хорнби (Taylor Hornby) представил (https://defuse.ca/audits/encfs.htm) результаты независимого аудита популярной системы шифрования файлов EncFS (http://www.arg0.net/encfs), выполненной в форме FUSE-модуля, работающего в пространстве пользователя. В результате проверки выявлено 7 проблем различной степени опасности и ещё 4 потенциальные проблемы, требующие дальнейшего изучения. В итоге сделан вывод, что в EncFS игнорируются многие современные приёмы для обеспечения надёжного шифрования, поэтому в текущем виде EncFS не рекомендуется для защиты критически важных данных.URL: http://sourceforge.net/mailarchive/message.php?msg_id=31849549
Новость: http://www.opennet.me/opennews/art.shtml?num=38869
Некто (впервые слышу о так человеке) провёл аудит нечто (впервые слышу о такой программе) и выявил некоторое количество недоработок.
Надеюсь некто, пишущие нечто, обратят внимание на аудит некоего человека и произведут некоторые исправления.
Тейлор Хорнби - это такая чебурашка, которая сказала Торвальдцу, что он криптолох
и что инструкция RDRAND в процах Intel (возможно) с бэдором, и которая сваливает
нагенерённые ПСЧ прямо в пул энтропии, а не добавляет к общему.
Тут drivers/char/random.c с комментами от этой чебурашки http://pastebin.com/A07q3nL3
Чебурашка не чебурашка, а все-таки он дельную идею сообщил. На мой взгляд, его идея о том, что не следует слепо доверять RDRAND, не лишена разумности.
В линухе ему и не доверяли. И это не его идея.
Со вчерашнего дня и в бсд тоже.
> И это не его идея.
> Со вчерашнего дня и в бсд тоже.хорошо сказал
Нормально сказал. Идея то не его.
Ну попиарился человек, бывает.
> и что инструкция RDRAND в процах Intel (возможно) с бэдором, и которая
> сваливает нагенерённые ПСЧ прямо в пул энтропии, а не добавляет к общему.Не, там идея в том, что байты из RDRAND XORятся с байтами из других источников энтропии, но эти байты находятся в кэше CPU, а значит, злобный интель может и их тоже ослабить (обнулить, например).
Не, злобный Интель может увидеть что просят операцию XORТам зырь какая фигня
hash - это юнион
union {
__u32 w[5];
unsigned long l[LONGS(EXTRACT_SIZE)];
} hash;....
дальше распердолили энтропию,
....перемешиваем
hash.w[0] ^= hash.w[3];
hash.w[1] ^= hash.w[4];
hash.w[2] ^= rol32(hash.w[2], 16);
for (i = 0; i < LONGS(EXTRACT_SIZE); i++) {
unsigned long v;
if (!arch_get_random_long(&v))
break;// hash.l[] - не инициализирован, пустой,
// при (gcc -O2) с вероятностью 99.999999% он нулевой.// тут делаем волшебную вещь
hash.l[i] ^= v;
// Это равносильно hash.l[i] = (0 ^ v) или просто (hash.l[i] = v);
}То есть пул энтропии от софтварных способов лежит отдельно в hash.w[5],
от хардварного - в hash.l[8]И да, троян RDRAND может определить адрес последней записи в кэш,
оттуда вынуть, сделать с ним нужную операцию, и поместить в массив hash.l[8].
Тем самым пул энтропии будет являться сам для себя ключом!
То бишь, gcc будет инициализировать элементы hash.l в ноль? А как же их перекрытие с hash.w (это ж union, а не struct)?
> То бишь, gcc будет инициализировать элементы hash.l в ноль?По идее великого феншуя - там должен быть неизвестный мусор.
А GCC уже давно обнуляет, если там не сказать volatile (и то не уверен).
> А как же их перекрытие с hash.w (это ж union, а не struct)?А вот это уже зависит как этот пул дальше использовать.
Если в пуле пропустить 5 штук (__u32), то получим 10 лонгов от Интеля :)
А, LONGS(EXTRACT_SIZE) > 5? Тогда да, ССЗБ.
> А, LONGS(EXTRACT_SIZE) > 5?#define EXTRACT_SIZE 10
#define LONGS(x) (((x) + sizeof(unsigned long) - 1)/sizeof(unsigned long))сейчас сделали LONGS(20)
> Тогда да, ССЗБ.Размер особо и не важен, уже известно, что первые 5 это __u32
#include <stdio.h>#define EXTRACT_SIZE 20
#define LONGS(x) (((x) + sizeof(unsigned long) - 1)/sizeof(unsigned long))int main () {
printf("LONGS(EXTRACT_SIZE=%d)=%d\n", (unsigned int) EXTRACT_SIZE, (unsigned int) LONGS(EXTRACT_SIZE));
return 0;
}Результат:
LONGS(EXTRACT_SIZE=20)=3
> Результат:
> LONGS(EXTRACT_SIZE=20)=3И дальше ... развивай мысль.
Если я правильно понимаю, __u32 - это 4 байта. 5*4 = 20. Соответственно, EXTRACT_SIZE (который задает размер выборки в байтах) тоже заменяют на 20. Так где тут чистый RDRAND?
Ой пля, там же union ..... чёй-то я туплю ... Пойду ещё стакан выпью .... :D
А я еще в #62 намекал :)Собственно, суть утверждений этого параноика в том, что intel может контролировать hash, если он попадет в кэш процессора (и тем более - если в регистр). Например, занулить его. И тогда все пойдет так, как ты говорил.
> А я еще в #62 намекалНу и ладно, зато drivers/char/random.c еще разок поизучали.
> Например, занулить его. И тогда все пойдет так, как ты говорил.
Изменения-то видел, там же рокировку сделали, RDRAND идёт с начала,
потом уже __mix_pool_bytes() и XOR_ы
> http://pastebin.com/A07q3nL3А что с его коментами к коду не так? Написано "does not use the hw random", а оно таки использует, хотя преимуществ именно такого теоретического бекдора не понял. В http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g... гите слегка не так - это поправили? Но похрен же, если rng может xor в известное число, то хешировать его без толку.
Либо известное, либо неизвестное. Зависит от того, как компилятор соптимизирует, и процессор закеширует.
>> http://pastebin.com/A07q3nL3
> А что с его коментами к коду не так? Написано "does not
> use the hw random", а оно таки использует, хотя преимуществ именно
> такого теоретического бекдора не понял. В http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...
> гите слегка не так - это поправили? Но похрен же, если
> 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[] нужно чё-нить сотворить
> нужно чё-нить сотворитьhttp://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...
Нашел коммит. Все же без кеширования пула _перед_ вызовом rng бекдор не прокатит. Правда вызов не один, да и вообще, инструкция перед исполнением в кеше есть, значит..(здесь и далее рассуждения не читавшего код параноика). Вот в комменте явно указано not use, а парой функций глубже use больше паранои. Ну, можно списать на NSA^Wзабыли и всем настирать на комменты.
>> нужно чё-нить сотворить
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...
> Нашел коммит.Угу, ещё спинлоком прикрыли, чтоб мусор случайно АНБшниками не попал!!! :)
Чесна говоря, этот цикл ещё выше нужно поднять, перед или после sha_init(hash.w);
и двумя разными спинлоками отрезать, ибо нефиг блокировать чужие пулы,- сам генери.
static void extract_buf(struct entropy_store *r, __u8 *out)
{
int i;
union {
__u32 w[5];
unsigned long l[LONGS(20)];
} hash;
__u32 workspace[SHA_WORKSPACE_WORDS];
__u8 extract[64];
unsigned long flags;/*
* If we have a architectural hardware random number
* generator, mix that in, too.
*/
spin_lock_irqsave(&r->lock, flags);
for (i = 0; i < LONGS(20); i++) {
unsigned long v;
unsigned long rdrand_array[LONGS(20)]; // в свою кучу сваливай
if (!arch_get_random_long(&v))
break;
rdrand_array[i] = v;
}
spin_unlock_irqrestore(&r->lock, flags);/* Generate a hash across the pool, 16 words (512 bits) at a time */
sha_init(hash.w);
spin_lock_irqsave(&r->lock, flags);
for (i = 0; i < r->poolinfo->poolwords; i += 16)
sha_transform(hash.w, (__u8 *)(r->pool + i), workspace);for (i = 0; i < LONGS(20); i++)
hash.l[i] ^= rdrand_array[i]; // а тут уже объединить/*
* We mix the hash back into the pool to prevent backtracking
* attacks (where the attacker knows the state of the pool
* plus the current outputs, and attempts to find previous
* ouputs), unless the hash function can be inverted. By
* mixing at least a SHA1 worth of hash data back, we make
* brute-forcing the feedback as hard as brute-forcing the
* hash.
*/
__mix_pool_bytes(r, hash.w, sizeof(hash.w), extract);
spin_unlock_irqrestore(&r->lock, flags);
...Как-то так
Оюшки... Господа знатоки, какие есть удобные альтернативы?
Неудобный eCryptFS :)
Подождите, он ещё и аудит ecryptfs проведёт.
> Подождите, он ещё и аудит ecryptfs проведёт.А разработчики encfs, уверен, прислушаются и допилят всё что нужно.
geli во фришке. И просто и удобно. И исходник можно поправить немного чтобы не выводил что я там подсоединяю/отсоединяю.
И гловное что всякие тейлоры не доё..капываются.Вчерась бац, http://www.opennet.me/opennews/art.shtml?num=38865 — эту новость можно читать и так — синдром сноудена приходит к фряшникам на год позже, чем к линуксоидам.
К линуксоидам он вообще не приходил, только собирался. И то на порог не пустили.
TrueCrypt.
LUKS.
EncFS предоставляет шифрование на уровне ФС, а не блочных устройств. Только вот зачем кому-то нужно именно на уровне ФС - не понятно.
А как держать данные на дропбоксе?
> А как держать данные на дропбоксе?Практически у всех облачных хранилищ шифрование запрещено лицензионным соглашением.
>> А как держать данные на дропбоксе?
> Практически у всех облачных хранилищ шифрование запрещено лицензионным соглашением.Закон - как дышло. Я их имел в виду, у меня принцитиально всё зашифорованное, даже фотки котиков :) Пока в суд не подали :))
>>> А как держать данные на дропбоксе?
>> Практически у всех облачных хранилищ шифрование запрещено лицензионным соглашением.
> Закон - как дышло. Я их имел в виду, у меня принцитиально
> всё зашифорованное, даже фотки котиков :) Пока в суд не подали
> :))Просто забанят и халявные гигабайты отнимут. А могут и даже проплаченные отнять.
Уже были прецеденты, когда всякие гугли и пейсбуки банили аккаунт без объяснения причин, и отказывались даже дать бэкапы слить.
Сейчас этих облаков столько, что хранить в одном, без дублирования - даже странно как-то. Так что не страшно ни разу. Тем более, что новый аккаунт создаётся за пару минут. Можно даже на том же сервисе.
> Сейчас этих облаков столько, что хранить в одном, без дублирования - даже
> странно как-то. Так что не страшно ни разу. Тем более, что
> новый аккаунт создаётся за пару минут. Можно даже на том же
> сервисе.Угу. С полной утратой всех халявных гигов, полученных раньше, да еще и с перспективой быстрого забана (если IP тот же, например).
Кто как, а я в халявные гиги не играюсь - смысла ни малейшего. Мне того, что даётся в любом гуглоакке, допустим - выше крыши. А по IP такие сервисы банят только в исключительных случаях.
Кстати - сюрприз - такие аккаунты обычно еще и создаются с левыми данными, что тоже лицензионными соглашениями запрещено. Только как-то наплевать.
> Кстати - сюрприз - такие аккаунты обычно еще и создаются с левыми
> данными, что тоже лицензионными соглашениями запрещено. Только как-то наплевать.Ага, один такой как-то наплевал на правила IANA.
http://habrahabr.ru/company/prostopleer/blog/186314/
Разницу между доменом и одним из нескольких акков, на которые бекапятся одни и те же данные понимаешь? Писал же выше - хранить свои данные в ЛЮБОМ облаке без дублирования - маразм по нынешним временам.
Разве яндекс, к примеру, не изменил этот пункт в лучшую сторону?
> Практически у всех облачных хранилищ шифрование запрещено лицензионным соглашением.Ну ладно, нальем им просто вывода /dev/random, нехай NSA расшифровывает. А когда не получится - сделаем козью морду :)
>> А как держать данные на дропбоксе?
> Практически у всех облачных хранилищ шифрование запрещено лицензионным соглашением.Можно пруф? У дропбокса в соглашении не нашёл.
> Только вот зачем кому-то нужно именно на уровне ФС - не понятно.Чтоб не хрюкнулись все данные, лучше такое шифрование поверх проверенной ФС.
> Чтоб не хрюкнулись все данные, лучше такое шифрование поверх проверенной ФС.Что мешает держать блочное устройство в файле поверх проверенной ФС (если уж вам так хочется вводить лишние слои)?
Например, нежелание иметь дело с лишним кодом (поддержки блочного устройства) и лишними багами?
> Например, нежелание иметь дело с лишним кодом (поддержки блочного устройства) и лишними багами?Хотите юзать ФС, не используя блочные устройства? Ну удачи вам.
Вариант encfs:
нативное блочное устройство -> FS -> шифрование
Вариант "контейнер поверх FS":
нативное блочное устройство -> FS -> контейнер -> FSПричем код контейнера всяко более сложен, чем код encfs - как минимум, там дополнительные метаданные держать надо, следить за пустым местом и т.п.
> Вариант encfs:
> нативное блочное устройство -> FS -> шифрование
> Вариант "контейнер поверх FS":
> нативное блочное устройство -> FS -> контейнер -> FSВот и я не понимаю, почему "хрюкотающий зелюк" хочет держать данные поверх "проверенной ФС".
Но если ему так хочется - пожалуйста.> Причем код контейнера всяко более сложен, чем код encfs - как минимум,
> там дополнительные метаданные держать надо, следить за пустым местом и т.п.Может, более сложен, а может, более прост (на надо заниматься трансляцией имен файлов, можно оперировать блоками одного размера и т.д.). Неважно. Главное - что он не так уязвим.
Так-то эти облака не всегда fs и не все операции позволяют выполнять. Оналогия ftp.
Так и хочется сказать "держи свое облако". Хотя у меня все с собой на внешнем диске и доступ к этому всему через любой толщины интернет невозможен на публичных облаках (разорятся они)
Что бы синхронизировать не гигантский имидж диска, а только изменённые файлы.
> Что бы синхронизировать не гигантский имидж диска, а только изменённые файлы.Что мешает синхронизировать содержимое смонтированных контейнеров?
>> Что бы синхронизировать не гигантский имидж диска, а только изменённые файлы.
> Что мешает синхронизировать содержимое смонтированных контейнеров?А что лучше - С или С++? Exim или Postfix? Ну и т.д.
Если звёзды зажигают ...
> А что лучше - С или С++?Зависит от задачи.
> Exim или Postfix?
Если бы Debian не навязывал по умолчанию Exim, а Redhat - sendmail, Postfix давно бы уже стал абсолютным лидером, ввиду объективного превосходства.
> Если звёзды зажигают ...
Если велосипеды изобретают... значит, у кого-то NIH.
То, что там меняться начинает черт знает что вместо одного единственного файла. И. соответственно, объем синхронизации гораздо больше. Да, я в курсе, что это слегка увеличивает безопасность. Нет, я не готов так заморачиваться.
> То, что там меняться начинает черт знает что вместо одного единственного файла.
> И. соответственно, объем синхронизации гораздо больше.Нет.
Тот-то люди жаловались, что дропбокс при изменении любый файлов в truecrypt-контейнере его весь перезаливает. Может, это и клиент туп - мне до лампочки. Если есть способ тривиально указать единицу, с которой надо работать - один файл - на кой хрен мне контейнер? Чтобы словить ограничение на объем и морочить голову с расширением FS?
за тем что с эьим меньше гемороя.
Ладно хоть в truecrypt всё стабильно.
> Ладно хоть в truecrypt всё стабильно.есть результаты аудита?
"Стабильно" - это значит, никому в голову не пришло поковыряться палочкой в данной проге.
её ващето гугл пользует и разрабатывает
> её ващето гугл пользует и разрабатываетА ещё гугл заставляют в принудительном порядке, организовывать заворачивание трафика на сервера АНБ/ФСБ/МИ6 ....
>> её ващето гугл пользует и разрабатывает
> А ещё гугл заставляют в принудительном порядке, организовывать заворачивание трафика на
> сервера АНБ/ФСБ/МИ6 ....А еще гугп зачем-то добпвляет свой
Пруфы где, павлин?
У TrueСrypt скоро будет свой аудит. Там и посмотрим на эту стабильность.
LUKS же. EncFS не нужен.
Мне вот нужен. Позволяет в отдельной папочке (лежащей будь то на публичном шаринге или на флешке\ноутбуке\внешнем винте, которые можно потерять или на свое) секурно хранить данные не предназначенные для чужих глаз и позволяет секурно же бекапить эти файлики. А LUKS - он решает другие задачи. И я убежден в том, что он может делать задачу шифрования данных на уровне блочного устройства хорошо и правильно. Просто мне не нужно весь раздел шифровать, я не страшусь попадания в третьи руки стандартных GNU компонентов моей системы :)
Откройте для себя понятие "монтирования".
Проблему инкрементного бекапа, например, это не решит. Да и вообще - что за манера предлагать вместо наиболее удобного инструмента - приблизительно похожий с костылями?
> Проблему инкрементного бекапа, например, это не решит.Решит. Достаточно бэкапить смонтированную ФС, а не контейнер целиком (что вполне логично).
> Да и вообще - что за манера предлагать вместо наиболее удобного инструмента - приблизительно похожий с костылями?
Что за манера - лезть со своим синдромом утенка, развешивая ярлыки "костыль" на все, что не похоже на маму-утку?
Не путай архитектурную кривизну пихания здесь блочного устройства с синдромами. Здесь наша единица, с которой работаем - файл. Не контейнеры, не иноды, не что-то еще - а файл. И нормальный бескостыльный способ - это работать с файлом. Контейнер здесь - именно что костыль.В другой ситуации, когда есть необходимость работать с чем-то как с блочным устройством (мало ли - RAID там поверх него сделать, или грузиться с него, или использовать скрытые тома, или отдать чему-то, что ожидает именно устройство) - вот тогда и придется создавать это самое устройство. беря на себя риски с его возможным не совсем стандартным поведением, необходимостью решать, сколько оно займет места и тому подобным. Принцип предельно прост - задействовать как можно больше мейнстримного кода в противовес специализированному. По мейнстриму лучше поддержка (банально опыта работы больше), с ним меньше непредсказуемости, он лучше отлажен.
Есть же encfs --reverse. Очень удобная штука. Ничего не шифруем, все данные лежат в нормальной файловой системе. А если нужно сделать их бэкап - видим их зашифрованными через FUSE. Можно делать инкрементальный бэкап.И чем его заменить теперь?
> Есть же encfs --reverse. Очень удобная штука. Ничего не шифруем, все данные
> лежат в нормальной файловой системе. А если нужно сделать их бэкап
> - видим их зашифрованными через FUSE. Можно делать инкрементальный бэкап.
> И чем его заменить теперь?Бэкапиться внутрь шифроконтейнера, например.
2014-01-17 / NEW PACKAGE (1.7.4)
security/encfs
COMMENT: fuse-based cryptographic filesystemУра! Теперь она достаточно безопасна и для openbsd :)