Calculate Password with Private Key and BIP38 Key?

[zappylappy]

Alice has encrypted two Private Keys (PrivKey1, PrivateKey2) with the same Password (Password1) and gets as a result two BIP38 Keys (BIP38Key1, BIP38Key2).

Bob eavesdrop with a keylogger, but can only read one Private Key (PrivKey1) and one BIP38 Key (BIP38Key1).

Can Bob calculate or reduce the necessary brute force possibilities to get access to the Password (Password1) and the other BIP38 Key (BIP38Key2)?

[1714808616]

1714808616

[1714808616]

1714808616

[1714808616]

1714808616

[1714808616]

1714808616

[1714808616]

1714808616

[Charles-Tim]

Bob eavesdrop with a keylogger, but can only read one Private Key (PrivKey1) and one BIP38 Key (BIP38Key1).

From your second question, it is clear that Bob (the invader/hacker) do not know the same BIP38 password used to to encrypt both paper wallet.

The only way for Bob to know the unencrypted private key is if it is backup along with encrypted private key. But, why would Alice do that? Alice encrypted the private key on purpose, which is to provide another layer of protection.

If the unencrypted private key is known, it can be used to compromise the paper wallet.
If only the encrypted private key is known, it will be difficult for Bob to compromise/decrypt it if strong password is used.

Can Bob calculate or reduce the necessary brute force possibilities to get access to the Password (Password1) and the other BIP38 Key (BIP38Key2)?

If strong password is used, it will be difficult to brute-force the private key password

But, for additional security, using different BIP38 passphrase will be better.

[BrewMaster]

it won't matter if we have both the private key and the BIP38 encrypted key we still can't reverse AES256 to get the password and there is no other relationship between the private key (or the derived key used in AES for encryption) and the encrypted result for us to use to figure out the password.

[ranochigo]

What you've described is called a known plaintext attack.

By looking at BIP38's specifications[1], BIP38 uses Scrypt as a PBKDF and that by itself can't be reversed as of now. AES256 has quite a large keyspace so trying to get the correct Scrypt key would be close to impossible and even if you get it, you'll have to either find a vulnerability within Scrypt or to bruteforce it. Given the circumstances, I don't think either is currently practical.

[1] https://github.com/bitcoin/bips/blob/master/bip-0038.mediawiki#Encryption_when_EC_multiply_flag_is_not_used

[NotATether]

Can Bob calculate or reduce the necessary brute force possibilities to get access to the Password (Password1) and the other BIP38 Key (BIP38Key2)?

The answer is yes for calculating, no for reducing the space (unless Bob also knows what kinds of passwords Alice uses).

With the private key and the BIP38 encrypted key you can loop through the algorithm trying each possible passwords, but the number of loops per second will be insanely slow. For comparison, a bitcoin wallet.dat hash uses two AES encryptions if I remember correctly, and high-end GPUs can only brute force a few KHashes/s of those. I estimate they could run a BIP38 brute forcer at a few dozen hashes/second.

At that rate you'll have trouble even exhausting all combinations of 4 or 5 ASCII characters!