Is SecurePrint secure enough to make the paper wallet publicly available?

[pf]

Is SecurePrint secure enough to make the paper wallet publicly available?

I sort of hope so because otherwise I don't see the point, because we are assuming the printer could steal our data - which includes the possibility that the printer makes the paper wallet publicly available.

I understand it uses scrypt. What scrypt parameters does it use, and why can't I pick those scrypt parameters myself?

[1715585175]

1715585175

[1715585175]

1715585175

[1715585175]

1715585175

[1715585175]

1715585175

[goatpig]

The secure print passphrase comes from a HMAC512 of your wallet's root key, so it uses the same entropy.

[pf]

The secure print passphrase comes from a HMAC512 of your wallet's root key, so it uses the same entropy.

Can you elaborate? If the secure print passphrase is just a MAC-SHA512 of my wallet root's key, what was the actual key used to create the MAC? And if the secure print passphrase is just a MAC, why am I able to use that to decrypt the encrypted root key? I'm confused.

[goatpig]

https://github.com/etotheipi/BitcoinArmory/blob/master/armoryengine/ArmoryUtils.py#L3455

def hardcodeCreateSecurePrintPassphrase(secret) -> this method derives the SecurePrint password from your root key
def hardcodeMask(secret, passphrase=None, ekey=None) -> encrypts your root key with the passphrase using AES256 CBC

The code is pretty straight forward, speaks for itself.

[pf]

https://github.com/etotheipi/BitcoinArmory/blob/master/armoryengine/ArmoryUtils.py#L3455

def hardcodeCreateSecurePrintPassphrase(secret) -> this method derives the SecurePrint password from your root key
def hardcodeMask(secret, passphrase=None, ekey=None) -> encrypts your root key with the passphrase using AES256 CBC

The code is pretty straight forward, speaks for itself.

I'm still a bit puzzled because the SecurePrint password is 11 characters of upper and lowercase letters. That's essentially 52^11 possibilities. But I see it's base 58, so let's say it's 58^11. But that's roughly 2^64. 64-bit entropy. But SHA-512 it 512-bit. What am I missing? Is 64-bit entropy really enough?

[goatpig]

Brute forcing a SecurePrint key is pretty expensive.

The key is elongated through a scrypt precursor (ROMix): high RAM cost so it's expensive to parallelize a brute force attack. Just decrypting the encrypted root key with a candidate passphrase isn't enough to verify it, you still need at least 2 ECDSA public key exponentiation to get the first public key with potential balance.

Let's ignore the other operations, let's just look at the KDF. The key derivation function defaults to 16MB RAM. Assuming a recent high end computer can compute 2000 candidates per second, with 10000 machines attacking your SecurePrint passphrase simultaneously, you are looking at 2^24 attempt/s on a 7 bytes passphrase so you are left with 2^32 seconds worth of work to crack the passphrase, or about 130 years (unless I messed up somewhere).

Obviously this isn't as strong as the 128bits of actual security a 256bits EC offers, but I find it acceptable considering the economics of such attack.

If you are unsatisfied with this level of security, you can always use fragmented backups. In this case you can choose to mix and match unencrypted, SecurePrint encrypted and digital fragments to implement a stricter security model. An attacker would need a quorum of fragments to even attempt anything.

[pf]

Brute forcing a SecurePrint key is pretty expensive.

The key is elongated through a scrypt precursor (ROMix): high RAM cost so it's expensive to parallelize a brute force attack. Just decrypting the encrypted root key with a candidate passphrase isn't enough to verify it, you still need at least 2 ECDSA public key exponentiation to get the first public key with potential balance.

Let's ignore the other operations, let's just look at the KDF. The key derivation function defaults to 16MB RAM. Assuming a recent high end computer can compute 2000 candidates per second, with 10000 machines attacking your SecurePrint passphrase simultaneously, you are looking at 2^24 attempt/s on a 7 bytes passphrase so you are left with 2^32 seconds worth of work to crack the passphrase, or about 130 years (unless I messed up somewhere).

Obviously this isn't as strong as the 128bits of actual security a 256bits EC offers, but I find it acceptable considering the economics of such attack.

If you are unsatisfied with this level of security, you can always use fragmented backups. In this case you can choose to mix and match unencrypted, SecurePrint encrypted and digital fragments to implement a stricter security model. An attacker would need a quorum of fragments to even attempt anything.

Okay, I see. But is there any way that you guys (Armory developers) could one day make it like 20 (or even 40) characters instead of just 11? This would boost my confidence.

You see, as I explained, I have to assume that my SecurePrint wallet (without password) is publicly available. Someone could have started work on brute-forcing it already and may plan on doing so for the next decade or two. Especially if he knows I'm a millionaire (could be the case if a coworker compromised the printer at work). Another case is where a few bank employees know I'm a billionaire and break into my safe deposit box (which is exactly why I ain't putting the SecurePrint password in that same location).

Because of this, I'm not going to feel very confident putting a lot of money into my SecurePrint wallet. And I don't really want to be recreating my wallets every 2 years. I want to use the same wallet for the next 20 years. That's why I ask for that extra entropy.

What do you think? Maybe I'm missing something.

[goatpig]

I didn't implement SecurePrint, this code predates Armory having any employees. You would have to rest your case directly with etotheipi to have this feature customized. As you can see all the parameters for SecurePrint passphrase derivation are hardcoded, I'm guessing to make things simple while maintaining an acceptable level of security.

I believe your request is receivable but I cannot modify this feature without getting approval, and I don't expect I will get it simply because we have a large list of high priority items to go through currently. The best I can do for you atm is to point etotheipi to this thread, leaving you to defend your position.

This would be a good candidate for a plugin though, and if you are willing to develop one we will most likely sign it. Otherwise I would suggest you modify the hardcoded values for passphrase derivation (it's pretty simple) and write down your custom parameters on your paper backups, maybe with some instructions on how to reproduce them.

This way you can use any parameters you want now while waiting for a plugin to be developed.