ru_crypt 12 ноя 2015 в 21:38

Безопасное криптопрограммирование. Часть 2, заключительная

12 мин

19K

Информационная безопасность*Криптография*Программирование*

+19

Комментарии 17

НЛО прилетело и опубликовало эту надпись здесь

Kolyuchkin 13 ноя 2015 в 00:31

Замечание-уточнение по поводу очистки памяти от «секретных» данных: просто забить память нулями — это недостаточно! Наши «регуляторы» в области криптографии требуют, чтобы очищаемая память многократно (обычно 3-5 раз) «забивалась» качественным «шумом».

grossws 13 ноя 2015 в 13:54

Это относится к DRAM или дискам?
И нет ли ещё требования на использование membar в дополнение к этому, чтобы гарантировать инвалидацию этой части памяти в кэше?

Kolyuchkin 13 ноя 2015 в 15:13

Это относится к любой памяти, где находилась секретная или криптографически опасная информация.

dtestyk 13 ноя 2015 в 01:10

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

xaizek 13 ноя 2015 в 01:16

Именно такое с процессами не встречал, но по отклонению во времени есть, эти способы входят в группу под названием «Атаки по побочным каналам».

khim 13 ноя 2015 в 08:57

Да, конечно можно. Timing attacks лет десять назад начали обсуждать теоретически, а сейчас уже вроде какие-то практические демонстрации появились.

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

НЛО прилетело и опубликовало эту надпись здесь

grossws 13 ноя 2015 в 13:56

Работает в предположении, что собирается только gcc и пофиг на оптимизацию от слова совсем, может образоваться hot spot, так что при таком подходе надо ещё профилировать.

НЛО прилетело и опубликовало эту надпись здесь

Turbo 14 ноя 2015 в 12:34

Возможно глупый вопрос. А может кто-то посоветовать код сочетающий свойства:
1) Pure C код в одном файле, желательно просто функцию вида get_random()
2) Максимально рандомную
3) Мультиплатформенную

Пишу небольшое статистическое приложение, а просто rand() никуда не годится.

ru_crypt 14 ноя 2015 в 13:26

Берете блочный шифр в режиме счетчика, например. Т.е. шифруете последовательность a,a+1,a+2,… значение а устанавливаете тем же rand, только от системного времени. В качестве шифра возьмите Кузнечик. Реализаций полно github.com/MaXaMaR/kuznezhik tc26.ru/standard/draft/PR_GOSTR-bch_v3.zip github.com/mjosaarinen/kuznechik. A rand() — это же конгруэнтный генератор, он действительно плохой

Turbo 14 ноя 2015 в 15:03

Отлично, спасибо за наводку, попробую!

dimarick 14 ноя 2015 в 16:20

Попробуйте вихрь Мерсена(Mersenne Twister). Если не подойдет — то openssl, там есть генератор псевдослучайных и случайных чисел.

Turbo 15 ноя 2015 в 13:21

Похоже что-то вроде этого я сейчас и использую:

#define BITS_PER_CALL_GENERATOR 16
random_device rand_device;   // non-deterministic generator
mt19937 generator(rand_device());
uniform_int_distribution<> uniform_distribution(0, (1 << BITS_PER_CALL_GENERATOR) - 1);

khim 14 ноя 2015 в 20:54

А зачем вам для «небольшого статистического приложения» «pure C код»? На современных процессорах с поддержой AESNI использовать что-то другое без «уважительных причин» попросту глупо (пример «уважительной причины»: вы хотите генерировать одни и те же последовательности на ARM и на x86 и, разумеется, вас больше волнует скорость работы на ARM).

-1

Turbo 15 ноя 2015 в 13:19

Просто потому что у меня PureC код приложения. Сейчас я использую #include , который за собой тянет уже компилятор С++. И честно говоря даже там распределение хоть и лучше чем у rand(), но все равно не очень радует. )

P.S. Моё приложение чисто для PC.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Показать лучшие за всё время

Безопасное криптопрограммирование. Часть 2, заключительная

Комментарии 17

Публикации

Истории