well, i will take that flaw into account for now
thanks to both of you for your quick replies!
Topic: deriving chaincode from root privkey (Read 1314 times)
haha, i just spent 2 hours of debugging and came here to post that i can reproduce armorys chaincode when using SHA256_DIGEST_LENGTH instead of SHA256_BLOCK_LENGTH for the buffers in my HMAC implementation, just to read the same observation was made already! damnit
well, i will take that flaw into account for now
thanks to both of you for your quick replies!
well, i will take that flaw into account for now
thanks to both of you for your quick replies!
Wow! You're absolutely right. I have no idea how that got by me. I just tested it against a test vectors and found that the default hash sizes are half what they are supposed to be. I even remember looking up test vectors at the time... but I guess I didn't apply them? I guess the other factor is that that code has never had to interoperate with anything else expecting the same HMACs. Otherwise we would've noticed.
Well, we'll have to mark those functions as "special" (and keep using them for the old wallets), then update the parameters properly. The new wallets actually use HMAC from the Crypto++, and already pass all the test vectors. If I had tried doing CKD function with the python HMAC, I would have noticed.
From RFC4231:
Well, we'll have to mark those functions as "special" (and keep using them for the old wallets), then update the parameters properly. The new wallets actually use HMAC from the Crypto++, and already pass all the test vectors. If I had tried doing CKD function with the python HMAC, I would have noticed.
From RFC4231:
Code:
4.2. Test Case 1
Key = 0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b
0b0b0b0b (20 bytes)
Data = 4869205468657265 ("Hi There")
HMAC-SHA-224 = 896fb1128abbdf196832107cd49df33f
47b4b1169912ba4f53684b22
HMAC-SHA-256 = b0344c61d8db38535ca8afceaf0bf12b
881dc200c9833da726e9376c2e32cff7
HMAC-SHA-384 = afd03944d84895626b0825f4ab46907f
15f9dadbe4101ec682aa034c7cebc59c
faea9ea9076ede7f4af152e8b2fa9cb6
HMAC-SHA-512 = 87aa7cdea5ef619d4ff0b4241a1d6cb0
2379f4e2ce4ec2787ad0b30545e17cde
daa833b7d6b8a702038b274eaea3f4e4
be9d914eeb61f1702e696c203a126854
4.3. Test Case 2
Test with a key shorter than the length of the HMAC output.
Key = 4a656665 ("Jefe")
Data = 7768617420646f2079612077616e7420 ("what do ya want ")
666f72206e6f7468696e673f ("for nothing?")
HMAC-SHA-224 = a30e01098bc6dbbf45690f3a7e9e6d0f
8bbea2a39e6148008fd05e44
HMAC-SHA-256 = 5bdcc146bf60754e6a042426089575c7
5a003f089d2739839dec58b964ec3843
HMAC-SHA-384 = af45d2e376484031617f78d2b58a6b1b
9c7ef464f5a01b47e42ec3736322445e
8e2240ca5e69e2c78b3239ecfab21649
HMAC-SHA-512 = 164b7a7bfcf819e2e395fbe73b56e0a3
87bd64222e831fd610270cd7ea250554
9758bf75c05a994a6d034f65f8f0e6fd
caeab1a34d4a6b4b636e070a38bce737
Key = 0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b
0b0b0b0b (20 bytes)
Data = 4869205468657265 ("Hi There")
HMAC-SHA-224 = 896fb1128abbdf196832107cd49df33f
47b4b1169912ba4f53684b22
HMAC-SHA-256 = b0344c61d8db38535ca8afceaf0bf12b
881dc200c9833da726e9376c2e32cff7
HMAC-SHA-384 = afd03944d84895626b0825f4ab46907f
15f9dadbe4101ec682aa034c7cebc59c
faea9ea9076ede7f4af152e8b2fa9cb6
HMAC-SHA-512 = 87aa7cdea5ef619d4ff0b4241a1d6cb0
2379f4e2ce4ec2787ad0b30545e17cde
daa833b7d6b8a702038b274eaea3f4e4
be9d914eeb61f1702e696c203a126854
4.3. Test Case 2
Test with a key shorter than the length of the HMAC output.
Key = 4a656665 ("Jefe")
Data = 7768617420646f2079612077616e7420 ("what do ya want ")
666f72206e6f7468696e673f ("for nothing?")
HMAC-SHA-224 = a30e01098bc6dbbf45690f3a7e9e6d0f
8bbea2a39e6148008fd05e44
HMAC-SHA-256 = 5bdcc146bf60754e6a042426089575c7
5a003f089d2739839dec58b964ec3843
HMAC-SHA-384 = af45d2e376484031617f78d2b58a6b1b
9c7ef464f5a01b47e42ec3736322445e
8e2240ca5e69e2c78b3239ecfab21649
HMAC-SHA-512 = 164b7a7bfcf819e2e395fbe73b56e0a3
87bd64222e831fd610270cd7ea250554
9758bf75c05a994a6d034f65f8f0e6fd
caeab1a34d4a6b4b636e070a38bce737
inf,
I think you've uncovered a bug in Armory's HMAC implementation. I very well could be (and in fact I hope I'm) wrong though....
In particular, this doesn't produce what I'd expect:
Here's the definition of HMAC256 in ArmoryUtils.py:
I believe the problem is that this HMAC function takes and uses the hash size as a parameter (256 bits for SHA256), but it should be taking and using the block size instead (512 bits for SHA256).
Could someone verify this, or hopefully correct me?
I think you've uncovered a bug in Armory's HMAC implementation. I very well could be (and in fact I hope I'm) wrong though....
In particular, this doesn't produce what I'd expect:
Code:
import hmac, hashlib
from armoryengine.ArmoryUtils import HMAC256
# Test vector case 1 from RFC 4231
key = "0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b".decode("hex")
data = "Hi There"
expected = "b0344c61d8db38535ca8afceaf0bf12b881dc200c9833da726e9376c2e32cff7".decode("hex")
print "RFC 4231 HMAC-SHA256: ", expected .encode("hex")
print " Python HMAC-SHA256: ", hmac.new(key, data, hashlib.sha256).digest().encode("hex")
print " Armory HMAC-SHA256: ", HMAC256(key, data) .encode("hex")
from armoryengine.ArmoryUtils import HMAC256
# Test vector case 1 from RFC 4231
key = "0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b".decode("hex")
data = "Hi There"
expected = "b0344c61d8db38535ca8afceaf0bf12b881dc200c9833da726e9376c2e32cff7".decode("hex")
print "RFC 4231 HMAC-SHA256: ", expected .encode("hex")
print " Python HMAC-SHA256: ", hmac.new(key, data, hashlib.sha256).digest().encode("hex")
print " Armory HMAC-SHA256: ", HMAC256(key, data) .encode("hex")
Here's the definition of HMAC256 in ArmoryUtils.py:
Code:
def sha256(bits):
return hashlib.new('sha256', bits).digest()
def HMAC(key, msg, hashfunc, hashsz=None):
""" This is intended to be simple, not fast. For speed, use HDWalletCrypto() """
hashsz = len(hashfunc('')) if hashsz==None else hashsz
key = (hashfunc(key) if len(key)>hashsz else key)
key = key.ljust(hashsz, '\x00')
okey = ''.join([chr(ord('\x5c')^ord(c)) for c in key])
ikey = ''.join([chr(ord('\x36')^ord(c)) for c in key])
return hashfunc( okey + hashfunc(ikey + msg) )
HMAC256 = lambda key,msg: HMAC(key, msg, sha256, 32)
return hashlib.new('sha256', bits).digest()
def HMAC(key, msg, hashfunc, hashsz=None):
""" This is intended to be simple, not fast. For speed, use HDWalletCrypto() """
hashsz = len(hashfunc('')) if hashsz==None else hashsz
key = (hashfunc(key) if len(key)>hashsz else key)
key = key.ljust(hashsz, '\x00')
okey = ''.join([chr(ord('\x5c')^ord(c)) for c in key])
ikey = ''.join([chr(ord('\x36')^ord(c)) for c in key])
return hashfunc( okey + hashfunc(ikey + msg) )
HMAC256 = lambda key,msg: HMAC(key, msg, sha256, 32)
I believe the problem is that this HMAC function takes and uses the hash size as a parameter (256 bits for SHA256), but it should be taking and using the block size instead (512 bits for SHA256).
Could someone verify this, or hopefully correct me?
I just ran the same calculation using armoryengine and got the chaincode you were expecting:
Usually these kinds of issues are endianness related. For instance, the first line k=hex_to_binary(...) interprets the strings as little-endian. You have to explicitly pass in a second arg with BIGENDIAN if you want to interpret it that way. When I first started learning Bitcoin, a significant amount of time was spent guessing and checking endianness switches for calculations with known outputs. That might be what you have to do here.
Code:
>>> from armoryengine.ALL import *
>>> k = hex_to_binary('C263A3ED1351B0E07D57B788688C3BD8EA0DE54788739093880AAEC2DFF21BCF')
>>> binary_to_hex(hash256(k))
'a7941f148f0537ddb2794c923a9ef15a9eada511f7ee5aad851e86ecb86d3b0a'
>>> binary_to_hex(HMAC256( hash256(k), "Derive Chaincode from Root Key"))
'90ced6c81a642182660c91a0418cdaf1165ae311378a3862723aed81d48a767e'
>>> k = hex_to_binary('C263A3ED1351B0E07D57B788688C3BD8EA0DE54788739093880AAEC2DFF21BCF')
>>> binary_to_hex(hash256(k))
'a7941f148f0537ddb2794c923a9ef15a9eada511f7ee5aad851e86ecb86d3b0a'
>>> binary_to_hex(HMAC256( hash256(k), "Derive Chaincode from Root Key"))
'90ced6c81a642182660c91a0418cdaf1165ae311378a3862723aed81d48a767e'
Usually these kinds of issues are endianness related. For instance, the first line k=hex_to_binary(...) interprets the strings as little-endian. You have to explicitly pass in a second arg with BIGENDIAN if you want to interpret it that way. When I first started learning Bitcoin, a significant amount of time was spent guessing and checking endianness switches for calculations with known outputs. That might be what you have to do here.
hi,
i have a problem with deriving the chaincode from the root key in my own code, i tried different private keys differently in c, php and python and i always get the same digest, but that digest does not fit the provided chaincode in the wallet generated by armory which i am checking against.
as far as i understand, i simply get it like that:
basically, i can treat the message the same as hex
right? however, i tried it both as char * and uint8_t *.
let my example be:
all my sample programs, including the following python-script (sry, i really suck at python), deliver me
while the wallet file says the actual chaincode is
can someone please elaborate what i am getting wrong?
thanks
inf
python code:
edit: i am using armory 0.92.1, generating wallets version 1.35.
i have a problem with deriving the chaincode from the root key in my own code, i tried different private keys differently in c, php and python and i always get the same digest, but that digest does not fit the provided chaincode in the wallet generated by armory which i am checking against.
as far as i understand, i simply get it like that:
Code:
hmac_sha256( key=sha256(sha256(ROOTKEY)) , ascii_message="Derive Chaincode from Root Key")
basically, i can treat the message the same as hex
Code:
0x44657269766520436861696E636F64652066726F6D20526F6F74204B6579
right? however, i tried it both as char * and uint8_t *.
let my example be:
Code:
ROOTKEY = 0xC263A3ED1351B0E07D57B788688C3BD8EA0DE54788739093880AAEC2DFF21BCF
hash256(ROOTKEY) = 0xa7941f148f0537ddb2794c923a9ef15a9eada511f7ee5aad851e86ecb86d3b0a (yes, its double-hashed)
hash256(ROOTKEY) = 0xa7941f148f0537ddb2794c923a9ef15a9eada511f7ee5aad851e86ecb86d3b0a (yes, its double-hashed)
all my sample programs, including the following python-script (sry, i really suck at python), deliver me
Code:
chaincode = 0x52c4ec3cd49b4af3c944f498e8d08fce2f3c432687408577ff6ae307d9ef1e6f
while the wallet file says the actual chaincode is
Code:
chaincode_wallet = 0x90CED6C81A642182660C91A0418CDAF1165AE311378A3862723AED81D48A767E
can someone please elaborate what i am getting wrong?
thanks
inf
python code:
Code:
#!/usr/local/bin/python2.7
import hmac
import hashlib
k = bytearray([0xa7,0x94,0x1f,0x14,0x8f,0x05,0x37,0xdd,0xb2,0x79,0x4c,0x92,0x3a,0x9e,0xf1,0x5a,0x9e,0xad,0xa5,0x11,0xf7,0xee,0x5a,0xad,0x85,0x1e,0x86,0xec,0xb8,0x6d,0x3b,0x0a]);
x = hmac.new(k, "Derive Chaincode from Root Key", hashlib.sha256);
print x.hexdigest()
import hmac
import hashlib
k = bytearray([0xa7,0x94,0x1f,0x14,0x8f,0x05,0x37,0xdd,0xb2,0x79,0x4c,0x92,0x3a,0x9e,0xf1,0x5a,0x9e,0xad,0xa5,0x11,0xf7,0xee,0x5a,0xad,0x85,0x1e,0x86,0xec,0xb8,0x6d,0x3b,0x0a]);
x = hmac.new(k, "Derive Chaincode from Root Key", hashlib.sha256);
print x.hexdigest()
edit: i am using armory 0.92.1, generating wallets version 1.35.
Jump to: