2013-11-09 8 views
1

Я пытаюсь использовать эту ECDSA реализации в Haskell, если вы посмотрите на линии 15, вы увидите, что значение к использует randomRIO, который использует global random number generatorgetter из которых использует theStdGen, который использует mkStdRNG что делает семя по:Is (количество пикосекунд времени процессора, используемое текущей программой + время синхронизации), семя, иммунизированное криптоанализом для генератора псевдослучайных чисел?

(текущие секунды на настенные часы) * 12345 + (текущие пикосекунд на настенные часы) + (количество пикосекунд времени процессора, используемого в текущей программе)

Является ли это достаточно хорошо подписание данных, стоимость которых составляет миллиарды долларов долларов США?

+1

Я бы не использовал случайные числа, независимо от того, из какого CSPRNG, для 'k' вообще. IMO хэш секретного ключа и сообщения намного безопаснее. См. [RFC6979 - Детерминированное использование алгоритма цифровой подписи (DSA)] (http://tools.ietf.org/html/rfc6979) для полной спецификации. – CodesInChaos

+0

@CodesInChaos Автор: Thomas Pornin, я чувствую себя более безопасным :) Что вы думаете, Коды, если я смотрю на реализацию генератора случайных чисел, я не вижу никакого существенного метода поддержания состояния (более 32 бит). И хотя я обычно не читаю Haskell, это может быть даже 30 бит. Это я не считаю безопасным. –

+0

Случайность * критическая * для (EC) DSA. Если энтропии недостаточно, вы будете пропускать свой секретный ключ, когда будете подписывать что-либо. https://www.imperialviolet.org/2013/06/15/suddendeathentropy.html – ntoskrnl

ответ

1

В целом, ответ будет no. Если вы рассматриваете вариант использования, единственным реальным вариантом является использование сертифицированного HIP FIPS или Common Criteria. Оценка FIPS и CC должна быть последней даты и должна быть действительной для ECDSA. Только эксперту следует разрешить создавать вокруг него протокол управления ключами. Другой эксперт должен проверить этот протокол и удобство использования HSM. Выбор именованных параметров ECDSA должен быть частью протокола и не должен восприниматься легкомысленно.

Теперь для вашего Haskell RNG. Вы не должны использовать текущую реализацию, так как генератор случайных чисел, конечно, не соответствует номиналу. Он может использовать небезопасные семена (как вы, возможно, уже нашли), и, похоже, не имеет достаточного состояния (все, что говорит, использует Целые числа, почему бы и нет, в комментариях не следует доверять). Я не вижу хеша или HMAC, которые используются для генерации новых случайных чисел или состояния, поэтому я не вижу, как эта реализация генерирует безопасные случайные числа вообще.

Быстрый взгляд на Интернет укрепило мои подозрения:

http://tommd.wordpress.com/2010/09/02/a-better-foundation-for-random-values-in-haskell/

Обратите внимание на экспериментальный тег на момент написания:

http://hackage.haskell.org/package/crypto-random-api-0.2.0/docs/Crypto-Random-API.html

Теперь, если вы на самом деле разрабатывая подписание чего-то, что стоит миллиарды долларов, пожалуйста, сделайте себе менеджера и наняйте эксперта (& слушайте эксперта).