Title: Восстановление ключа из ECDSA Post by: Grumlin on February 22, 2015, 04:54:02 AM http://www.nilsschneider.net/2013/01/28/recovering-bitcoin-private-keys.html
почитав статью, понял, что в клиенте необходимо сделать базу с хранящимися выходными подписями, и при генерации новой, проверять со всеми старыми, чтобы тем самым исключить возможность перехватат приватного ключа через две одинаковые подписи. Насколько я понял из статьи, поправьте пожалуйста если не прав, с помощью подписи ECDSA можно восстановить ключ, даже через 10 лет, если через этот период был сгенерирован(случайно, либо не случайно) повторно одинаковая подпись. С учетом того, что по сути все ГСЧ = ПСЧ, то такая проверка как минимум обезопасила бы. Title: Re: Восстановление ключа из ECDSA Post by: amaclin on February 24, 2015, 09:15:37 PM 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 и спите спокойно. |