Topic: How to convert the backup phrases to a standard HD extended private key? (Read 737 times)

Ah I see my mistake now. I didn't think etotheipi's home baked HMAC was still in use. My code relied on cryptopp and now libbtc, which have correct hmac implementations. etotheipi one's botches the pad xoring indeed.


My code uses a proper HMAC implementation (cryptopp/libbtc). I've never ran into this issue because my code rips the chaincode along with the root key from the python wallets in order to convert them to the new format. I went ahead and assumed it generated the chaincode from the root instead, which is why I mistakenly concluded the old python code was using a proper HMAC.

Turns out the new code only generates chaincodes at wallet creation (wouldn't affect preexisting wallets) and when restoring from the root. I have yet to restore python wallets with the new code (they're converted on the fly atm), at which point I'll face this bug directly.

In my opinion all wallets are generated with the bad HMAC.

This is how armory works:


If instead of 32 I use 64

HMAC256 = lambda key,msg: HMAC(key, msg, sha256, 32) -> HMAC256 = lambda key,msg: HMAC(key, msg, sha256, 64)

I get:


that is equal to the result of the correct HMAC:


then Armory uses a different HMAC function.


Because you use the same wrong size (32 instead of 64):

https://github.com/goatpig/BitcoinArmory/blob/dev/armoryengine/ArmoryUtils.py#L1941

I'm not too sure what's going on here, this was prior to me era of involvement. Armory went through a change in its chaincode generation from v1.35 to v1.35c. Prior to 1.35c, the chaincode was generated as its own PRNG value, with no relation to the root value. As a result, paper backups had to carry 4 strings (64 bytes worth of data).

In 1.35c, etotheipi figured he could generate the chaincode from a HMAC of the root, which led to the current 2 strings backups (32 bytes of data). I have no recollection of ever using wallets with a chaincode generated from the bad HMAC (I've been actively contributing the Armory since September 2014). I'm guessing there is a narrow window during which users have generated wallets with the bad HMAC?

Armory in my dev branch is running off of libbtc instead of cryptopp, and it manages to recover older wallets with the expected data, so I wouldn't be too worried about implementing support for the botched HMAC. I'd just leave that as an unsupported edge case and deal with it when I'd actually run into it, if ever. Keep in mind that the current state of master most likely can't deal with these "bad" chaincodes.

Hi,

etotheipi was talking about a problem in the computation of the chaincode:

https://bitcointalksearch.org/topic/m.8890498

How does it work now?

Old wallets and new wallets are using different HMAC functions?

Armory is set to never grab the same address twice. Generating a change address means to increment the use counter and grab the underlying address. You'd need user action to break this behavior, like using the wallet across several processes or restoring the wallet from a backup.

The 'next unused' means the next address in the chain or the first address without tx?

Example: I press "Receive Bitcoins" and I get the address A, then I press it again and I get the address B and someone sends bitcoins to the address B. If I spend bitcoin from B, A is still available as change address or Armory grabs another address C?

Grab the next unused address in the chain


Scan all 1k addresses in the lookup.

I'm trying to understand in more detail how it works the Armory's derivation scheme.

Let  

be the Root Key printed on a paper backup (obviously I use it only to understand the mechanism ...)

'astr' and 'kkku' should be only to check errors at the end of each line, then I remove them and convert from the easy16 to hex format:


I derive the chaincode from the Root Key:


To pass from a private key (index N) to the next one (index N+1) I have to do a multiplication a * b mod n, where:


The parameter 'a' (together the related address) is stored in the multipliers.txt file in .armory directory.
 
'a' is like a sort of private key of the address N+1 computed respect to the previous public key N instead of the generator G.
In this way the wallet offline can generate these particular private keys (multipliers) only from the first (root) public key and the chaincode. We get all the public keys (as multiples of the root public key) and then all the addresses without using the real private keys (because to get an address we need only a public key, the private key is not necessary).

public keys   chain:  root public key P1 -> a1*P1 = P2 -> a2*P2 = P3 -> a3*P3 = P4 -> ...
private keys chain: root private key a  -> a*a1  % n  ->  a*a1*a2 % n -> a*a1*a2*a3 % n --> ...

If only one private key N and the chaincode are revelead, then
 
Returning to the computations, in my particular case:



Then the first private key (and address) of this wallet is:

If I apply again the same scheme, I get the other addresses:

I noted that Armory at the start generates a pool of 100 addresses. Each time I press the button "Receive Bitcoins", it generates another address (then there are always at least 100 empty addresses in the Address Pool).


2 questions:

1) how does Armory generate the change addresses?

2) when you restore a wallet from its Root Key, how many addresses are checked to retrieve the total balance? Maybe it tries until it finds at least 100 consecutive addresses without tx, or more?  I did a test, it stops after 1000 consecutive addresses.

Thank you for the clarification.

Those are pointing to the dev branch, which is in constant flux. You can look at the code in the master branch:

https://github.com/goatpig/BitcoinArmory/blob/master/cppForSwig/EncryptionUtils.cpp#L749


Private key N with the chaincode will let you compute all private keys beyond N. To compute private keys prior to N, you need all public keys preceding N as well. Both chaincode and public keys are considered known data (as they lay on online computers), hence the generalization that revealing a private key within the chain is as good as revealing all private keys in the wallet.

Keep in mind that you shouldn't treat soft derived BIP32 private keys with any less care, as the same property applies:


It is good practice to not reveal your wallet's private keys, regardless of the derivation scheme. Consider the wallet compromised if you did, and move the funds out.

https://github.com/goatpig/BitcoinArmory/blob/dev/cppForSwig/EncryptionUtils.cpp#L825
https://github.com/goatpig/BitcoinArmory/blob/dev/cppForSwig/EncryptionUtils.cpp#L749

-->  that file has only 727 lines, there is no line #825.

You confirm that if a single private key was revelead the entire wallet is compromised?


EDIT:
I think I found the code:

https://github.com/goatpig/BitcoinArmory/blob/dev/cppForSwig/EncryptionUtils.cpp#L490
https://github.com/goatpig/BitcoinArmory/blob/dev/cppForSwig/EncryptionUtils.cpp#L427

That quote gives you links directly to the code.

Where is the exact procedure now to derive the private key chain from the wallet's root private key? I use a wallet created in 2013.
I'd like to see an article that explains how it works.

I read this answer too:

https://bitcointalksearch.org/topic/m.8570465

and I found out that a wallet is compromised if I reveal a single private key!

Cool, thank you both.

I'll take a look into the code, goat.

It is the wallet's root private key, a 32 bytes binary string, from which Armory wallets are derived.


Armory HD wallets predate BIP32. As a matter of fact, the design in Armory was part of the inspiration for BIP32. Now, I am in the process of adding BIP32 support to Armory, and that is scheduled for the next major release. For now though, there is no such functionality available in Armory.

To compute chained addresses, Armory first derives what is called the chaincode from the wallet's root private key. You can see the Python code here:

https://github.com/goatpig/BitcoinArmory/blob/dev/armoryengine/ArmoryUtils.py#L3489

Using the chain code, Armory can then derive the address chain sequentially, each new key pair N+1 resulting from the exponentiation of the key pair N and the chaincode. The exact procedure can be seen in the code here:

https://github.com/goatpig/BitcoinArmory/blob/dev/cppForSwig/EncryptionUtils.cpp#L825
https://github.com/goatpig/BitcoinArmory/blob/dev/cppForSwig/EncryptionUtils.cpp#L749

It uses an entirely different algorithm that was developed before BIP 32.

Hi! Armory doesn't use the standard derivation path or it uses a different algorithm altogether?

Hi Goat, thanks for the response.
So, I have 2 lines with 36 hexadecimal characters each after I convert them.

What is that exactly? I'm learning everything related to Bitcoin coding using NBitcoin, so I kinda grasp the most important concepts but not all.

Thank you!

You won't get the same addresses since Armory does not use BIP 32.

They're encoded in base16 with a different alphabet.

You can see most of the code here:

https://github.com/goatpig/BitcoinArmory/blob/master/armoryengine/ArmoryUtils.py#L2244