В целом, ответ будет 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
Теперь, если вы на самом деле разрабатывая подписание чего-то, что стоит миллиарды долларов, пожалуйста, сделайте себе менеджера и наняйте эксперта (& слушайте эксперта).
Я бы не использовал случайные числа, независимо от того, из какого CSPRNG, для 'k' вообще. IMO хэш секретного ключа и сообщения намного безопаснее. См. [RFC6979 - Детерминированное использование алгоритма цифровой подписи (DSA)] (http://tools.ietf.org/html/rfc6979) для полной спецификации. – CodesInChaos
@CodesInChaos Автор: Thomas Pornin, я чувствую себя более безопасным :) Что вы думаете, Коды, если я смотрю на реализацию генератора случайных чисел, я не вижу никакого существенного метода поддержания состояния (более 32 бит). И хотя я обычно не читаю Haskell, это может быть даже 30 бит. Это я не считаю безопасным. –
Случайность * критическая * для (EC) DSA. Если энтропии недостаточно, вы будете пропускать свой секретный ключ, когда будете подписывать что-либо. https://www.imperialviolet.org/2013/06/15/suddendeathentropy.html – ntoskrnl