Search content
Sort by
Showing 12 of 12 results by plaprade
I wanted to add the following notes to this discussion if you find them relevant:
If you don't follow these elementary security practices, you will get hacked. Don't play with fire when your money is at stake.
- Security through obscurity is bad. Don't do it. You must always assume that an attacker knows your password generation schemes.
- In light of the previous point, the only correct way of generating a brain wallet is to pick character or words with sufficient entropy in a complete random fashion. For example a 12 word diceware (where the random process is the results of throwing dices). An attacker that knows you used diceware to generate your passphrase can not recover any information on it.
If you don't follow these elementary security practices, you will get hacked. Don't play with fire when your money is at stake.
I just wasted 20 minutes of my time reading through this thread without noticing how old the posts are.
Seriously though, be nice with the testnet and don't sell testnet coins
I think I'm entitled for some shameless self-promotion. Get your free test coins from:
testnet.mojocoin.com
Seriously though, be nice with the testnet and don't sell testnet coins
I think I'm entitled for some shameless self-promotion. Get your free test coins from:
testnet.mojocoin.com
Re: Isn't the output of SHA256 *slightly* too big to use for a private key?
If the output of the SHA256 is greater than n it will just "wrap around" and work.
Although, now that I think about it, if the output of your SHA256 was exactly n that would probably cause a problem.
But then, the probablity of the output of the SHA256 being exactly n is 1 / 2256.
Although, now that I think about it, if the output of your SHA256 was exactly n that would probably cause a problem.
But then, the probablity of the output of the SHA256 being exactly n is 1 / 2256.
You should not "wrap around" or reduce your integer modulo n.
If your integer is == 0 or or >= n, then you should discard it completely and generate a new private key using a new secret. Otherwise you would be introducing a bias towards lower-valued private keys.
Re: Isn't the output of SHA256 *slightly* too big to use for a private key?
If the order of the elliptic curve in Bitcoin is some number slightly less than 2^256, then why is it OK to use the SHA256 hash of some input as a private key? My (steadily growing) understanding of ECDSA is that the private key must be some integer between 1 and the order of the curve, which is :
Sorry if this has been asked 1000 times already...
Code:
n = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141
Sorry if this has been asked 1000 times already...
Valid private keys are integers between 1 and n-1. If you get an integer >= n when hashing some secret, then that integer is an invalid private key. It would be a mistake to reduce that integer modulo n as it would introduce a bias towards lower values. The probability of that happening is relatively low however.
Re: Deterministic Usage of DSA and ECDSA Digital Signature Algorithms (RFC 6979)
I'd like to contribute some test vectors of my own.
The test vectors are fully canonical signatures with S components <= order/2. They contain both vectors were the S component had to be flipped and not flipped.
The test vectors were generated with haskoin:
http://github.com/plaprade/haskoin-crypto/blob/master/src/Haskoin/Crypto/ECDSA.hs
The project is still experimental and I haven't announced it publicly yet, but the cryptography part should be relatively stable by now.
I hope it can help!
The test vectors are fully canonical signatures with S components <= order/2. They contain both vectors were the S component had to be flipped and not flipped.
Code:
"Haskoin test vectors for RFC 6979 ECDSA (secp256k1, SHA-256)"
"(PrvKey HEX, PrvKey WIF, message, R || S as HEX, sig as DER)"
( "0000000000000000000000000000000000000000000000000000000000000001"
, "KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU73sVHnoWn"
, "Everything should be made as simple as possible, but not simpler."
, "33a69cd2065432a30f3d1ce4eb0d59b8ab58c74f27c41a7fdb5696ad4e6108c96f807982866f785d3f6418d24163ddae117b7db4d5fdf0071de069fa54342262"
, "3044022033a69cd2065432a30f3d1ce4eb0d59b8ab58c74f27c41a7fdb5696ad4e6108c902206f807982866f785d3f6418d24163ddae117b7db4d5fdf0071de069fa54342262"
)
( "fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364140"
, "L5oLkpV3aqBjhki6LmvChTCV6odsp4SXM6FfU2Gppt5kFLaHLuZ9"
, "Equations are more important to me, because politics is for the present, but an equation is something for eternity."
, "54c4a33c6423d689378f160a7ff8b61330444abb58fb470f96ea16d99d4a2fed07082304410efa6b2943111b6a4e0aaa7b7db55a07e9861d1fb3cb1f421044a5"
, "3044022054c4a33c6423d689378f160a7ff8b61330444abb58fb470f96ea16d99d4a2fed022007082304410efa6b2943111b6a4e0aaa7b7db55a07e9861d1fb3cb1f421044a5"
)
( "fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364140"
, "L5oLkpV3aqBjhki6LmvChTCV6odsp4SXM6FfU2Gppt5kFLaHLuZ9"
, "Not only is the Universe stranger than we think, it is stranger than we can think."
, "ff466a9f1b7b273e2f4c3ffe032eb2e814121ed18ef84665d0f515360dab3dd06fc95f5132e5ecfdc8e5e6e616cc77151455d46ed48f5589b7db7771a332b283"
, "3045022100ff466a9f1b7b273e2f4c3ffe032eb2e814121ed18ef84665d0f515360dab3dd002206fc95f5132e5ecfdc8e5e6e616cc77151455d46ed48f5589b7db7771a332b283"
)
( "0000000000000000000000000000000000000000000000000000000000000001"
, "KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU73sVHnoWn"
, "How wonderful that we have met with a paradox. Now we have some hope of making progress."
, "c0dafec8251f1d5010289d210232220b03202cba34ec11fec58b3e93a85b91d375afdc06b7d6322a590955bf264e7aaa155847f614d80078a90292fe205064d3"
, "3045022100c0dafec8251f1d5010289d210232220b03202cba34ec11fec58b3e93a85b91d3022075afdc06b7d6322a590955bf264e7aaa155847f614d80078a90292fe205064d3"
)
( "69ec59eaa1f4f2e36b639716b7c30ca86d9a5375c7b38d8918bd9c0ebc80ba64"
, "KzmcSTRmg8Gtoq8jbBCwsrvgiTKRrewQXniAHHTf7hsten8MZmBB"
, "Computer science is no more about computers than astronomy is about telescopes."
, "7186363571d65e084e7f02b0b77c3ec44fb1b257dee26274c38c928986fea45d0de0b38e06807e46bda1f1e293f4f6323e854c86d58abdd00c46c16441085df6"
, "304402207186363571d65e084e7f02b0b77c3ec44fb1b257dee26274c38c928986fea45d02200de0b38e06807e46bda1f1e293f4f6323e854c86d58abdd00c46c16441085df6"
)
( "00000000000000000000000000007246174ab1e92e9149c6e446fe194d072637"
, "KwDiBf89QgGbjEhKnhXJwe1E2mCa8asowBrSKuCaBV6EsPYEAFZ8"
, "...if you aren't, at any given time, scandalized by code you wrote five or even three years ago, you're not learning anywhere near enough"
, "fbfe5076a15860ba8ed00e75e9bd22e05d230f02a936b653eb55b61c99dda4870e68880ebb0050fe4312b1b1eb0899e1b82da89baa5b895f612619edf34cbd37"
, "3045022100fbfe5076a15860ba8ed00e75e9bd22e05d230f02a936b653eb55b61c99dda48702200e68880ebb0050fe4312b1b1eb0899e1b82da89baa5b895f612619edf34cbd37"
)
( "000000000000000000000000000000000000000000056916d0f9b31dc9b637f3"
, "KwDiBf89QgGbjEhKnhXJuH7LrciVrZiib5S9h4knkymNojPUVsWN"
, "The question of whether computers can think is like the question of whether submarines can swim."
, "cde1302d83f8dd835d89aef803c74a119f561fbaef3eb9129e45f30de86abbf906ce643f5049ee1f27890467b77a6a8e11ec4661cc38cd8badf90115fbd03cef"
, "3045022100cde1302d83f8dd835d89aef803c74a119f561fbaef3eb9129e45f30de86abbf9022006ce643f5049ee1f27890467b77a6a8e11ec4661cc38cd8badf90115fbd03cef"
)
"(PrvKey HEX, PrvKey WIF, message, R || S as HEX, sig as DER)"
( "0000000000000000000000000000000000000000000000000000000000000001"
, "KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU73sVHnoWn"
, "Everything should be made as simple as possible, but not simpler."
, "33a69cd2065432a30f3d1ce4eb0d59b8ab58c74f27c41a7fdb5696ad4e6108c96f807982866f785d3f6418d24163ddae117b7db4d5fdf0071de069fa54342262"
, "3044022033a69cd2065432a30f3d1ce4eb0d59b8ab58c74f27c41a7fdb5696ad4e6108c902206f807982866f785d3f6418d24163ddae117b7db4d5fdf0071de069fa54342262"
)
( "fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364140"
, "L5oLkpV3aqBjhki6LmvChTCV6odsp4SXM6FfU2Gppt5kFLaHLuZ9"
, "Equations are more important to me, because politics is for the present, but an equation is something for eternity."
, "54c4a33c6423d689378f160a7ff8b61330444abb58fb470f96ea16d99d4a2fed07082304410efa6b2943111b6a4e0aaa7b7db55a07e9861d1fb3cb1f421044a5"
, "3044022054c4a33c6423d689378f160a7ff8b61330444abb58fb470f96ea16d99d4a2fed022007082304410efa6b2943111b6a4e0aaa7b7db55a07e9861d1fb3cb1f421044a5"
)
( "fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364140"
, "L5oLkpV3aqBjhki6LmvChTCV6odsp4SXM6FfU2Gppt5kFLaHLuZ9"
, "Not only is the Universe stranger than we think, it is stranger than we can think."
, "ff466a9f1b7b273e2f4c3ffe032eb2e814121ed18ef84665d0f515360dab3dd06fc95f5132e5ecfdc8e5e6e616cc77151455d46ed48f5589b7db7771a332b283"
, "3045022100ff466a9f1b7b273e2f4c3ffe032eb2e814121ed18ef84665d0f515360dab3dd002206fc95f5132e5ecfdc8e5e6e616cc77151455d46ed48f5589b7db7771a332b283"
)
( "0000000000000000000000000000000000000000000000000000000000000001"
, "KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU73sVHnoWn"
, "How wonderful that we have met with a paradox. Now we have some hope of making progress."
, "c0dafec8251f1d5010289d210232220b03202cba34ec11fec58b3e93a85b91d375afdc06b7d6322a590955bf264e7aaa155847f614d80078a90292fe205064d3"
, "3045022100c0dafec8251f1d5010289d210232220b03202cba34ec11fec58b3e93a85b91d3022075afdc06b7d6322a590955bf264e7aaa155847f614d80078a90292fe205064d3"
)
( "69ec59eaa1f4f2e36b639716b7c30ca86d9a5375c7b38d8918bd9c0ebc80ba64"
, "KzmcSTRmg8Gtoq8jbBCwsrvgiTKRrewQXniAHHTf7hsten8MZmBB"
, "Computer science is no more about computers than astronomy is about telescopes."
, "7186363571d65e084e7f02b0b77c3ec44fb1b257dee26274c38c928986fea45d0de0b38e06807e46bda1f1e293f4f6323e854c86d58abdd00c46c16441085df6"
, "304402207186363571d65e084e7f02b0b77c3ec44fb1b257dee26274c38c928986fea45d02200de0b38e06807e46bda1f1e293f4f6323e854c86d58abdd00c46c16441085df6"
)
( "00000000000000000000000000007246174ab1e92e9149c6e446fe194d072637"
, "KwDiBf89QgGbjEhKnhXJwe1E2mCa8asowBrSKuCaBV6EsPYEAFZ8"
, "...if you aren't, at any given time, scandalized by code you wrote five or even three years ago, you're not learning anywhere near enough"
, "fbfe5076a15860ba8ed00e75e9bd22e05d230f02a936b653eb55b61c99dda4870e68880ebb0050fe4312b1b1eb0899e1b82da89baa5b895f612619edf34cbd37"
, "3045022100fbfe5076a15860ba8ed00e75e9bd22e05d230f02a936b653eb55b61c99dda48702200e68880ebb0050fe4312b1b1eb0899e1b82da89baa5b895f612619edf34cbd37"
)
( "000000000000000000000000000000000000000000056916d0f9b31dc9b637f3"
, "KwDiBf89QgGbjEhKnhXJuH7LrciVrZiib5S9h4knkymNojPUVsWN"
, "The question of whether computers can think is like the question of whether submarines can swim."
, "cde1302d83f8dd835d89aef803c74a119f561fbaef3eb9129e45f30de86abbf906ce643f5049ee1f27890467b77a6a8e11ec4661cc38cd8badf90115fbd03cef"
, "3045022100cde1302d83f8dd835d89aef803c74a119f561fbaef3eb9129e45f30de86abbf9022006ce643f5049ee1f27890467b77a6a8e11ec4661cc38cd8badf90115fbd03cef"
)
The test vectors were generated with haskoin:
http://github.com/plaprade/haskoin-crypto/blob/master/src/Haskoin/Crypto/ECDSA.hs
The project is still experimental and I haven't announced it publicly yet, but the cryptography part should be relatively stable by now.
I hope it can help!
Re: Deterministic Usage of DSA and ECDSA Digital Signature Algorithms (RFC 6979)
This will be changed to the alternative I described.
Thanks! I'll update my code accordingly.
Re: Deterministic Usage of DSA and ECDSA Digital Signature Algorithms (RFC 6979)
I noticed that the problem came from the parity of 'S'. The 'S' component is odd in your last test vector.
Why should S be even? Any citation?
From the bitcoind reference implementation:
https://github.com/bitcoin/bitcoin/blob/master/src/script.cpp (line 295)
Code:
if (flags & SCRIPT_VERIFY_EVEN_S) {
if (S[nLenS-1] & 1)
return error("Non-canonical signature: S value odd");
}
if (S[nLenS-1] & 1)
return error("Non-canonical signature: S value odd");
}
However there's a flag to activate this check. Most of the unit tests in the reference implementation do not take even 'S' into account yet.
Re: Deterministic Usage of DSA and ECDSA Digital Signature Algorithms (RFC 6979)
Code:
# Test Vectors for RFC 6979 ECDSA, secp256k1, SHA-256
# (private key, message, expected k, expected signature)
(0xf8b8af8ce3c7cca5e300d33939540c10d45ce001b8f252bfbc57ba0342904181, "Alan Turing", 0x525A82B70E67874398067543FD84C83D30C175FDC45FDEEE082FE13B1D7CFDF1, "7063ae83e7f62bbb171798131b4a0564b956930092b33b07b395615d9ec7e15ca72033e1ff5ca1ea8d0c99001cb45f0272d3be7525d3049c0d9e98dc7582b857")
# (private key, message, expected k, expected signature)
(0xf8b8af8ce3c7cca5e300d33939540c10d45ce001b8f252bfbc57ba0342904181, "Alan Turing", 0x525A82B70E67874398067543FD84C83D30C175FDC45FDEEE082FE13B1D7CFDF1, "7063ae83e7f62bbb171798131b4a0564b956930092b33b07b395615d9ec7e15ca72033e1ff5ca1ea8d0c99001cb45f0272d3be7525d3049c0d9e98dc7582b857")
Thanks for the test vectors! They are really useful as none are provided for our curve in the RFC.
I had an issue with your last test vector. After some investigation, I noticed that the problem came from the parity of 'S'. The 'S' component is odd in your last test vector. I think that going forward, new code should produce fully valid and canonical signatures, which includes making the 'S' component even. Let me know if that is a reasonable statement or not.
For reference, here is my results for this test vector:
Code:
# Test Vectors for RFC 6979 ECDSA, secp256k1, SHA-256
# (private key, message, expected k, expected signature)
(0xf8b8af8ce3c7cca5e300d33939540c10d45ce001b8f252bfbc57ba0342904181, "Alan Turing", 0x525A82B70E67874398067543FD84C83D30C175FDC45FDEEE082FE13B1D7CFDF1, "7063ae83e7f62bbb171798131b4a0564b956930092b33b07b395615d9ec7e15c58dfcc1e00a35e1572f366ffe34ba0fc47db1e7189759b9fb233c5b05ab388ea")
# (private key, message, expected k, expected signature)
(0xf8b8af8ce3c7cca5e300d33939540c10d45ce001b8f252bfbc57ba0342904181, "Alan Turing", 0x525A82B70E67874398067543FD84C83D30C175FDC45FDEEE082FE13B1D7CFDF1, "7063ae83e7f62bbb171798131b4a0564b956930092b33b07b395615d9ec7e15c58dfcc1e00a35e1572f366ffe34ba0fc47db1e7189759b9fb233c5b05ab388ea")
The motivation there is that the ECC homomorphism based public derivation has that highly surprising backwards enumeration property. In some use-cases it could easily cause a total loss. E.g. I export a private key from my wallet and give it to you, and you already have the extended key for that chain for auditing... oops now you have all the coins on that chain.
I'm probably missing something here, but if I wanted to allow auditing of any branch without worrying about knowledge of a private key compromising other addresses can't I just generate another key pair, x,X, and derive all public addresses for that branch by using the group operation (i.e. point addition) on any public key K derived on that branch by defining the public addresses as X+K (here +is point addition) for all addresses generated on that branch. That way I could give away individual private keys x+k (and the extended key for generating K (and auditor easily generates X+K) without compromising any other private keys.
Why couldn't you do this for each branch adding extra protection against loss of the master extended key? Is it because of the extra key management? Or have I missed something?
Why couldn't you do this for each branch adding extra protection against loss of the master extended key? Is it because of the extra key management? Or have I missed something?
In BIP32, say you have a master public key (Kpar, Cpar) which has an associated private key (kpar, cpar).
You derive a child private key (number i) through non-prime derivation using:
Code:
1) (L, R) = HMAC( Cpar, Kpar || i )
2) ki = L + kpar (mod n)
3) return (ki, R)
2) ki = L + kpar (mod n)
3) return (ki, R)
Looking at equation 2) you notice that the L component can be computed if you know (Kpar, Cpar). So, knowing any derived private key ki and the master public key Kpar completely leaks kpar:
Code:
kpar = ki - L (mod n)
Essentially, this means that if you gave M/i' to an auditor and you additionally give him m/i'/0 then you are essentially leaking m/i' and any keys derived from it.
For both CKD functions, it is okay for IL to be 0.
My bad. IL can be equal to 0 indeed.
ki = IL + kpar (mod n).
I'm independently implementing BIP32 in Haskell on a private repo for now. It'll pop up on my github page when I'm happy with it in a few days.
I understood the above documentation line as follows: You need to treat IL as an EC private key. If it is
It is considered a standard notation to put the order of the field in parenthesis when writing operations within that field.
For example:
2 + 3 = 2 (mod 3)
3 + 8 = 4 (mod 7)
Cheers!
Edit: IL can be equal to zero
Hi There,
I'm developing libraries to increase Bitcoin support in Haskell. My github profile:
https://github.com/plaprade
I'm also hosting the testnet Mojocoin faucet together with Xeno-Genesis:
http://testnet.mojocoin.com
I'm developing libraries to increase Bitcoin support in Haskell. My github profile:
https://github.com/plaprade
I'm also hosting the testnet Mojocoin faucet together with Xeno-Genesis:
http://testnet.mojocoin.com