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

[@Kolyuchkin]

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

[@grossws]

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

[@Kolyuchkin]

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

[@dtestyk]

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

[@xaizek]

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

[@khim]

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

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

[@grossws]

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

[@Turbo]

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

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

[@ru_crypt]

Берете блочный шифр в режиме счетчика, например. Т.е. шифруете последовательность 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]

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

[@dimarick]

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

[@Turbo]

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

#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]

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

[@Turbo]

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

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