search

bitpay / bitcore

A full stack for bitcoin and blockchain-based applications
https://bitcore.io/
MIT License
4.85k stars 2.09k forks source link

Implement RFC 6979 - deterministic k #311

Closed ryanxcharles closed 9 years ago

ryanxcharles commented 10 years ago

See: https://github.com/bitpay/bitcore/pull/309#issuecomment-41955087

yrashk commented 9 years ago

:+1:

oleganza commented 9 years ago

+1

oleganza commented 9 years ago

Should be relatively easy to port from bitcoinjs (provided they actually have a correct RFC6979 implementation)

https://github.com/bitcoinjs/bitcoinjs-lib/blob/5b6249e6f9f255d96f22816c8714f35b66cfa920/src/ecdsa.js#L9

karlkeefer commented 9 years ago

:+1:

taariq commented 9 years ago

@martindale Maybe it's time?

braydonf commented 9 years ago

elliptic.js ecdsa, which is the crypto for v0.8, supports a deterministic k (RFC6979) exclusively, we should probably use it. However, in the RFC it states "This document is not an Internet Standards Track specification; it is published for informational purposes." Thus if there is a high-quality randomness available, we should likely default to it?

maraoz commented 9 years ago

I think we should default to deterministic k. As greg maxwell states on the linked thread, bitcoin private keys have been revealed due to bad randomness several times in the past (one very recently, by the bc.i wallet, and I remember that Android had a similar problem). It's very hard to secure DSA if you rely on randomness, especially because on most platforms you don't control the source of randomness, you rely on the operating system, which may be broken.

maraoz commented 9 years ago

please add tests that assert specific signatures for some transactions and private keys before closing this issue

eordano commented 9 years ago

Backported from @ryanxcharles' fullnode, tests for deterministic signatures already in place. Closing