The OpenNET Project / Index page

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

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

В результате аудита EncFS выявлено 11 слабых мест в организа..., opennews (ok), 16-Янв-14, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


48. "В результате аудита EncFS выявлено 11 слабых мест в организа..."  +/–
Сообщение от Аноним (-), 16-Янв-14, 18:56 
> и что инструкция RDRAND в процах Intel (возможно) с бэдором, и которая
> сваливает нагенерённые ПСЧ прямо в пул энтропии, а не добавляет к общему.

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

Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

61. "В результате аудита EncFS выявлено 11 слабых мест в организа..."  +/–
Сообщение от pavlinux (ok), 16-Янв-14, 19:31 
Не, злобный Интель может увидеть что просят операцию 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].
Тем самым пул энтропии будет являться сам для себя ключом!

Ответить | Правка | Наверх | Cообщить модератору

62. "В результате аудита EncFS выявлено 11 слабых мест в организа..."  +/–
Сообщение от Аноним (-), 16-Янв-14, 20:12 
То бишь, gcc будет инициализировать элементы hash.l в ноль? А как же их перекрытие с hash.w (это ж union, а не struct)?
Ответить | Правка | Наверх | Cообщить модератору

67. "В результате аудита EncFS выявлено 11 слабых мест в организа..."  +/–
Сообщение от pavlinux (ok), 16-Янв-14, 20:18 
> То бишь, gcc будет инициализировать элементы hash.l в ноль?

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

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

Ответить | Правка | Наверх | Cообщить модератору

69. "В результате аудита EncFS выявлено 11 слабых мест в организа..."  +/–
Сообщение от Аноним (-), 16-Янв-14, 20:20 
А, LONGS(EXTRACT_SIZE) > 5? Тогда да, ССЗБ.
Ответить | Правка | Наверх | Cообщить модератору

70. "В результате аудита EncFS выявлено 11 слабых мест в организа..."  +/–
Сообщение от pavlinux (ok), 16-Янв-14, 20:28 
> А, LONGS(EXTRACT_SIZE) > 5?

#define EXTRACT_SIZE 10
#define LONGS(x) (((x) + sizeof(unsigned long) - 1)/sizeof(unsigned long))

сейчас сделали LONGS(20)


> Тогда да, ССЗБ.

Размер особо и не важен, уже известно, что первые 5 это __u32  

Ответить | Правка | Наверх | Cообщить модератору

71. "В результате аудита EncFS выявлено 11 слабых мест в организа..."  +/–
Сообщение от Аноним (-), 16-Янв-14, 20:31 
#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

Ответить | Правка | Наверх | Cообщить модератору

72. "В результате аудита EncFS выявлено 11 слабых мест в организа..."  +/–
Сообщение от pavlinux (ok), 16-Янв-14, 20:36 
> Результат:
> LONGS(EXTRACT_SIZE=20)=3

И дальше ... развивай мысль.


Ответить | Правка | Наверх | Cообщить модератору

73. "В результате аудита EncFS выявлено 11 слабых мест в организа..."  +/–
Сообщение от Аноним (-), 16-Янв-14, 20:41 
Если я правильно понимаю, __u32 - это 4 байта. 5*4 = 20. Соответственно, EXTRACT_SIZE (который задает размер выборки в байтах) тоже заменяют на 20. Так где тут чистый RDRAND?
Ответить | Правка | Наверх | Cообщить модератору

76. "В результате аудита EncFS выявлено 11 слабых мест в организа..."  +/–
Сообщение от pavlinux (ok), 16-Янв-14, 21:25 
Ой пля, там же union ..... чёй-то я туплю ... Пойду ещё стакан выпью .... :D
Ответить | Правка | Наверх | Cообщить модератору

82. "В результате аудита EncFS выявлено 11 слабых мест в организа..."  +/–
Сообщение от Аноним (-), 16-Янв-14, 23:02 
А я еще в #62 намекал :)

Собственно, суть утверждений этого параноика в том, что intel может контролировать hash, если он попадет в кэш процессора (и тем более - если в регистр). Например, занулить его. И тогда все пойдет так, как ты говорил.

Ответить | Правка | Наверх | Cообщить модератору

87. "В результате аудита EncFS выявлено 11 слабых мест в организа..."  +/–
Сообщение от pavlinux (ok), 17-Янв-14, 04:02 
> А я еще в #62 намекал

Ну и ладно, зато drivers/char/random.c еще разок поизучали.

> Например, занулить его. И тогда все пойдет так, как ты говорил.

Изменения-то видел, там же рокировку сделали, RDRAND идёт с начала,
потом уже __mix_pool_bytes() и XOR_ы

Ответить | Правка | К родителю #82 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

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