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?
In my opinion all wallets are generated with the bad HMAC.
https://github.com/goatpig/BitcoinArmory/blob/dev/armoryengine/ArmoryUtils.py#L1941Ah 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.
Because you use the same wrong size (32 instead of 64):
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.
