http://www.nilsschneider.net/2013/01/28/recovering-bitcoin-private-keys.htmlпочитав статью, понял, что в клиенте необходимо сделать базу с хранящимися выходными подписями, и при генерации новой, проверять со всеми старыми, чтобы тем самым исключить возможность перехватат приватного ключа через две одинаковые подписи. Насколько я понял из статьи, поправьте пожалуйста если не прав, с помощью подписи ECDSA можно восстановить ключ, даже через 10 лет, если через этот период был сгенерирован(случайно, либо не случайно) повторно одинаковая подпись.
С учетом того, что по сути все ГСЧ = ПСЧ, то такая проверка как минимум обезопасила бы.
Ты понял неправильно.
В алгоритме генерации сигнатуры используется некий параметр 'k' - 256-битное число, которое должно оставаться секретом.
Если известен приватный ключ, дайджест сообщения и подпись - то это число 'k' можно восстановить, то есть для того, кто подписывает сообщение это число не является тайной.
В классическом варианте подписи число 'k' просто генерируется рандомом. Хорошим рандомом.
Потому что две подписи двух разных дайджестов с одним и тем же приватным ключом и одним и тем же 'k' позволяют стороннему человеку найти приватный ключ.
Сейчас постепенно все склоняются к deterministicECDSA - в этом случае число 'k' вычисляется каким-то криптографически-надежным способом из дайджеста и приватного ключа. На мой взгляд достаточно SHA256 ( privKey | digest ) // где 'палка' - это конкатенация, а вовсе не 'булевское или'. Там по rfc еще HMAC накатывают поверх, но я не очень понял чем это лучше
Строить базу всех известных 'k' - это абсолютно то же самое, что строить базу всех известных приватных ключей.
Вероятность того, что случайно выбранное 'k' будет встречаться в этой базе где-то порядка 2
-256(Ну и умножить на размер базы. Сколько вам отсыпать миллиард? Сто миллиардов? Триллион?)
В криптографическом мире этим пренебрегают.
Используйте deterministicECDSA по rfc и спите спокойно.
