a

[smesv]

a

[1714904985]

1714904985

[1714904985]

1714904985

[1714904985]

1714904985

[tspacepilot]

If someone stole your recovery seed but they are protected with additional passphrase, how many guesses can they make per second and how strong must password be to protect until you notice your seeds were stolen (few day max)? I am talking about passphrase that Trezor and other hardware wallets give you.

I can't answer all of this question, I don't know what kind of symmetric encryption algorithms trezor is providing.  I can tell you that the number of guesses per second depends on the implementation of the cracking script and the hardware it's running on.

Now, assuming your additional passphrase is sufficiently random (not something that could be found in a rainbow table), and assuming some modern encryption procedure, like, say AES 256 (https://en.wikipedia.org/wiki/Advanced_Encryption_Standard) then unless these hypothetical ppl are throwing tons of resources at cracking your wallet, it should be pretty difficult.  On the other hand, if they have huge, dedicated compute clusters then maybe they'll find your password really soon.  It's all about resources.

[HCP]

You can see the "technical specs" of the passphrase in BIP39: https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki

Specifcally:

To create a binary seed from the mnemonic, we use the PBKDF2 function with a mnemonic sentence (in UTF-8 NFKD) used as the password and the string "mnemonic" + passphrase (again in UTF-8 NFKD) used as the salt. The iteration count is set to 2048 and HMAC-SHA512 is used as the pseudo-random function. The length of the derived key is 512 bits (= 64 bytes).

So any passphrase you choose, gets concatenated with "mnemonic" and is used as a salt. ie. if your passphrase was "Th1sI5mYp@ssphr@se"... it would be "mnemonicTh1sI5mYp@ssphr@se" being used as the salt and an iteration count of 2048.

Also, as mentioned in the BIP, ANY passphrase provided will generate a valid seed... so an attacker would then need to check addresses for every generated/tested passphrase for coins further slowing down any attack.

As long as your passphrase isn't "abc123" and/or the attackers aren't using huge computing clusters then even if your mnemonic gets compromised, you should have plenty of time to move your coins.

[tspacepilot]

You can see the "technical specs" of the passphrase in BIP39: https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki

Specifcally:

To create a binary seed from the mnemonic, we use the PBKDF2 function with a mnemonic sentence (in UTF-8 NFKD) used as the password and the string "mnemonic" + passphrase (again in UTF-8 NFKD) used as the salt. The iteration count is set to 2048 and HMAC-SHA512 is used as the pseudo-random function. The length of the derived key is 512 bits (= 64 bytes).

So any passphrase you choose, gets concatenated with "mnemonic" and is used as a salt. ie. if your passphrase was "Th1sI5mYp@ssphr@se"... it would be "mnemonicTh1sI5mYp@ssphr@se" being used as the salt and an iteration count of 2048.

Also, as mentioned in the BIP, ANY passphrase provided will generate a valid seed... so an attacker would then need to check addresses for every generated/tested passphrase for coins further slowing down any attack.

As long as your passphrase isn't "abc123" and/or the attackers aren't using huge computing clusters then even if your mnemonic gets compromised, you should have plenty of time to move your coins.

I thought OP was talking about the time to break symmetric encryption on a file containing the mnemonic.   I just learned something.

[HCP]

Thanks, thats reassureing.

Are there any calculations how much does checking if passphrase generate adress with coins slow down brute force? That would solve my paranoia.

I'm sure there are... but to be honest, I don't know exactly what they are... The attacker would need a fully indexed copy of the blockchain... and would need to generate at least 20-50 addresses AND change addresses PER generated seed and scan the blockchain for each of those addresses... or have generated a DB with appropriate indexes referencing every address seen on the blockchain.

Given that this involves a lot of SHA256() stuff (to get from private key to public key to address), the time taken doing hundreds and thousands of these calculations isn't exactly trivial... but then you have ASICs and GPUs that are measuring in GH/s etc when doing essentially the same thing when mining...

Personally, I suspect the address balance lookup is probably the real time limiting factor in all this... as it isn't just pure number crunching like the address generation... but honestly, I have no hard data to back this up.

[HCP]

Pretty sure that if you asked 10 different people what the "recommended" way to achieve this is, you'd probably get 10 different answers... it will come down to a trade off between convenience and perceived level of safety...

You can have a small (short), easy to remember passphrase that makes it fast and convenient, but your level of safety may be less than desired.
You can have a long complex passphrase that makes you feel adequetly secure, but then is way less convenient for you to remember and/or enter when required.

Only you can decide the level of risk you wish to carry...

[HCP]

I guess the real benefit is the whole "plausible deniability" as mentioned here: https://blog.trezor.io/hide-your-trezor-wallets-with-multiple-passphrases-f2e0834026eb

By putting a small amount of coin in the "default" wallet... ie. the one without any passphrase, a "simple" thief would plug your mnemonic in, see that you have only 0.1 BTC (or whatever you consider to be a small amount of coin) and then probably assume that you only held a small amount of coins and move on to the next target...

Adding on a passphrase (or even two) gives you the option to "hide" extra wallet(s) with your "real" stash of coins... As there is no evidence that you even have a passphrase (it's stored in your head right? and the mnemonic WILL generate a valid decoy wallet that shows some coins/history)... so even a relatively "short" but complex passphrase (10-12 chars with alphanumerics and symbols) should easily give you time to move your coins should you learn that your mnemonic has been compromised... assuming that the thief believes you even have a passphrase setup and are hiding coins.

I guess your best bet is to see if you can find data relating to the "strength" of the "PBKDF2 function" that BIP39 uses... working with the numbers described in the BIP (ie. mnemonic sentence (in UTF-8 NFKD) used as the password, the string 'mnemonic' + passphrase (again in UTF-8 NFKD) used as the salt. The iteration count is set to 2048 and HMAC-SHA512 is used as the pseudo-random function.)

[HCP]

Again... I refer to what I said earlier:

Adding on a passphrase (or even two) gives you the option to "hide" extra wallet(s) with your "real" stash of coins... As there is no evidence that you even have a passphrase (it's stored in your head right? and the mnemonic WILL generate a valid decoy wallet that shows some coins/history)... so even a relatively "short" but complex passphrase (10-12 chars with alphanumerics and symbols) should easily give you time to move your coins should you learn that your mnemonic has been compromised... assuming that the thief believes you even have a passphrase setup and are hiding coins.

How would these theoretical hackers even know you have a passphrase? Why would they continue looking after discovering the decoy 0.1 BTC in the "default" wallet (ie. mnemonic only, no passphrase)?

Given that people use 10-12 character passphrases to encrypt wallet files... I don't see why using a 10-12 character passphrase to secure a mnemonic would be any less secure... especially given that any attacker cannot simply test that their generated passphrase "works"... it isn't a simple "boolean" check like testing username/password combinations... ANY passphrase entered in combination with a valid mnemonic will generate a valid master private key and valid keys/addresses... so they have to generate a master private key... generate a number of receive addresses AND change addresses... and check for balances.

Maybe try playing with these:
https://www.grc.com/haystack.htm
https://apps.cygnius.net/passtest/

[chouxnative]

Sorry about your loss