Does more seed words equal better security?

[20kevin20]

Would Bitcoin be more secure against extremely powerful computing tech with more words in the dictionary list, a larger number of seed words and perhaps a longer BTC address/privkey? Say a seed had 50 words instead of 12 or 24 and Bitcoin addresses or seeds had at least one more character. Would it be more secure against bruteforcing or high computing power?

[1714125353]

1714125353

[BlackHatCoiner]

Would Bitcoin be more secure against extremely powerful computing tech with more words in the dictionary list, a larger number of seed words and perhaps a longer BTC address/privkey?

If you extended your seed phrase from 24 to 50 words, it wouldn't make it more secure in a case of a brute force. The attacker would have to either search among 2048²⁴ or 2048⁵⁰ different combinations. But, an attacker wouldn't need to brute force any of the seed phrases above to steal your money; he'd find it less demanding if he went straight by brute forcing 2¹⁶⁰ RIPEMD-160 hashes.

Quoting one of my posts:

I'm just adding the numbers decimally:

Code:

2^128 = 340282366920938463463374607431768211456 (12 words)
2^160 = 1461501637330902918203684832716283019655932542976 (RIPEMD-160 hash different combinations)
2^256 = 115792089237316195423570985008687907853269984665640564039457584007913129639936 (24 words)

I believe that the seed system works fine. You shouldn't think about a dictionary list with more words, but rather with bits. A twelve words seed phrase is a 132 bits representation in BIP39. A twenty four words seed phrase is 264 bits representation. I highly doubt if these numbers can be characterized as “weak”. Same for RIPEMD-160 hashes.

[NotATether]

Technically yes but then seed phrases would be impossible to remember, a hassle to type, and also impossible to recover if even (say) 2 or 3 words are missing. For seed phrases, there must be a balance between security and ease of use. Also, a seed phrase can't really have 50 words - it must be a multiple of 3.

A longer bitcoin address does nothing to improve security. Private keys are already long enough (2^256) that they are astronomically impossible to break using the futuristic hardware you're talking about.

If you want to make your seed phrase more secure, consider practicing backup hygiene - write multiple copies of it down and hide it somewhere, storing it away from locations where theft is likely.

[o_e_l_e_o]

Also, a seed phrase can't really have 50 words - it must be a multiple of 3.

A seed phrase can have as many or as few words as you like and still generate an HD wallet without any issue. Only if you want it to follow the BIP39 specification, then it must be 12/15/18/21/24 words.

Further, bitcoin private keys have 128 bits of security. Given that, in terms of brute forcing it doesn't matter if your seed phrase has 256 bits of security or 4096 bits of security - it is not the weakest link in the chain.

[LoyceV]

Technically yes but then seed phrases would be impossible to remember, a hassle to type, and also impossible to recover if even (say) 2 or 3 words are missing.

This is the real problem indeed. I always check my seed words before funding any address (by entering them again and checking if it produces the same address), and I have made a mistake writing them down once. So checking pays off

The same goes for writing down private keys: you wouldn't be the first to lose coins because of your own handwriting. And the longer the keys, the more likely you are to make a mistake.

[Bitcoin_Arena]

Technically yes but then seed phrases would be impossible to remember, a hassle to type, and also impossible to recover if even (say) 2 or 3 words are missing. For seed phrases, there must be a balance between security and ease of use.

Not forgetting that if a seed phrase is longer, it will encourage bad wallet backup practices among the users especially newbies such as;
- Copying and pasting the seed words instead of writing them down manually
- Not cross checking the seeds well due to so many words
- Using mobile devices to just screenshoot the seeds writing them down as encourages

So in the end it makes no sense having a super long "secure" seed if the user is still going to lose their Bitcoins due to poor wallet backup practices.

[ranochigo]

The benefits of having longer seed words diminishes as you increase the number of seed words and would just make storing it a hassle; given that the security of your individual addresses are only 128bits.

People often associate the security of their seeds only with the number of seed words that they have, that is untrue. The way you're generating it will affect it significantly. Generating it in an environment infested with malware will provide zero security. Generating it with a weak RNG resulting in a lesser than desired entropy will also result in a very weak seed.

[pooya87]

If you want to maintain anonymity on the Bitcoin network, it is suggested that you use a address each time.

You don't achieve anonymity by not-reusing bitcoin addresses, you can only improve your privacy to some extent by doing so. The anonymity while using bitcoin can mainly be achieved if you have never created any kind of connection between your transactions and your real identity such as signing up on a centralized exchange and filling out their KYC.

[LoyceV]

The benefits of having longer seed words diminishes as you increase the number of seed words and would just make storing it a hassle; given that the security of your individual addresses are only 128bits.

The benefit of long seeds it that you can create "2 out of 3" Split mnemonic cards:

Code:

Card 1: basket wrong sketch bar XXXX sad XXXX visa shrimp rally XXXX XXXX XXXX wild scene forum XXXX stage XXXX amused able XXXX thing add
Card 2: basket XXXX XXXX XXXX super XXXX mandate XXXX shrimp rally betray october whisper wild scene XXXX beef XXXX runway amused XXXX armed thing add
Card 3: XXXX wrong sketch bar super sad mandate visa XXXX XXXX betray october whisper XXXX XXXX forum beef stage runway XXXX able armed XXXX XXXX

With 12 words, there are 4 unknowns on each card, which can be brute-forced. With 24 words and 8 unknowns, having one card is pretty much useless.

[ranochigo]

The benefit of long seeds it that you can create "2 out of 3" Split mnemonic cards:

Code:

Card 1: basket wrong sketch bar XXXX sad XXXX visa shrimp rally XXXX XXXX XXXX wild scene forum XXXX stage XXXX amused able XXXX thing add
Card 2: basket XXXX XXXX XXXX super XXXX mandate XXXX shrimp rally betray october whisper wild scene XXXX beef XXXX runway amused XXXX armed thing add
Card 3: XXXX wrong sketch bar super sad mandate visa XXXX XXXX betray october whisper XXXX XXXX forum beef stage runway XXXX able armed XXXX XXXX

With 12 words, there are 4 unknowns on each card, which can be brute-forced. With 24 words and 8 unknowns, having one card is pretty much useless.

What about Shamir's secret sharing? I've seen quite a few implementation of it but have yet to check the threshold for the number of compromised shares before it comes trivial to get the entire secret.

For the record, I'm not aware of any standardized implementation and some of it has been plagued with certain vulnerabilities. Probably not as convenient as the system that you've mentioned.

[LoyceV]

What about Shamir's secret sharing? I've seen quite a few implementation of it but have yet to check the threshold for the number of compromised shares before it comes trivial to get the entire secret.

I've read about it several times, and each time realized I can't use it. Just look at Shamir's Secret Sharing on Wikipedia: it's complicated. Which means even if I'd be able to use it, I wouldn't fully understand it, which means I have to trust whoever created whatever software I'm going to use.

For the record, I'm not aware of any standardized implementation and some of it has been plagued with certain vulnerabilities. Probably not as convenient as the system that you've mentioned.

It's been around for years (Shamir is mentioned 600 times on Bitcointalk since 2010) but hasn't really been implemented anywhere. It's probably going to be mentiond for the coming 10 years too, and my guess it nothing will change.
That's why I like Ian Coleman's simple 3 cards: it's very easy to understand. On a mathematical level it's probably inferior, as far as I understand Shamir's system doesn't give you any information if you have just one share, but it's much more practical.

[ranochigo]

I've read about it several times, and each time realized I can't use it. Just look at Shamir's Secret Sharing on Wikipedia: it's complicated. Which means even if I'd be able to use it, I wouldn't fully understand it, which means I have to trust whoever created whatever software I'm going to use.

It is. The implementation also requires certain degree of technical expertise. That I agree.

It's been around for years (Shamir is mentioned 600 times on Bitcointalk since 2010) but hasn't really been implemented anywhere. It's probably going to be mentiond for the coming 10 years too, and my guess it nothing will change.
That's why I like Ian Coleman's simple 3 cards: it's very easy to understand. On a mathematical level it's probably inferior, as far as I understand Shamir's system doesn't give you any information if you have just one share, but it's much more practical.

Yup correct. Actually Trezor and Armory both implements it as well. Of course, it isn't most suited for Bitcoin due to the aforementioned limitations by you and I. But it should offer a better theoretical security advantage even with using only 12 seeds, that is if it is done properly.

[o_e_l_e_o]

I've seen quite a few implementation of it but have yet to check the threshold for the number of compromised shares before it comes trivial to get the entire secret.

The threshold can be whatever you want it to be. You could do 2-of-15, or you could 15-of-15. As long as the attacker has anything up to and including n-1 shares, then they learn nothing about your seed phrase and brute forcing is no easier than starting from scratch.

It's been around for years (Shamir is mentioned 600 times on Bitcointalk since 2010) but hasn't really been implemented anywhere.

Ian Coleman has both a Shamir's tool and a SLIP39 tool. My problem is not that it hasn't been implemented - it is that it hasn't been implemented in a standardized way. You could use either of the tools I've just mentioned, but then you are completely dependent on those tools for recovery, meaning you probably need to back up their source code along with every one of your split secrets, which is impractical and still does not guarantee safety.

[BrewMaster]

worth quoting here considering SSS:

There are many programs out there for shamir secret sharing, such as http://point-at-infinity.org/ssss/  most implementations I've seen leave a lot to be desired, including insecure random number generation which doesn't grant full information theoretic security, to incorrect share splitting such that sub threshold collections are sufficient to recover most of a key, to just gross timing sidechannels which any secret key handling software should avoid.

It is my view that In general, secret sharing is largely snake oil in practice because you must have a computer to split and join keys and if that computer is compromised your security is gone.  If you really had a compromise immune computer, just leave your key there and avoid the pointless ritual.

Bitcoin has multisignature which allows split keys without any single point of failure. Anyone considering secret sharing should first have a darn good reason they aren't using multisig.

[o_e_l_e_o]

-snip-

I don't use SSS because of the issues I mentioned above, and I rarely use multi-sig because of the decrease in privacy (as my transactions are easily identified as multi-sig) and because of the increased size and increased fee required, which can be significant at times of high mempool load. However, with Taproot, both of those reasons no longer apply. I'm already planning on moving several of my wallets to multi-sig once Taproot goes live. My desktop hot wallet I might turn in to a 2-of-3 multi-sig along with my phone and a hidden offline back up; my phone is always with me, so it only adds 30 seconds on inconvenience to scan a QR code, sign, and scan back again. I'm also planning on creating a couple of multi-sig paper wallets for long-term cold storage.

[PrimeNumber7]

Further, bitcoin private keys have 128 bits of security. Given that, in terms of brute forcing it doesn't matter if your seed phrase has 256 bits of security or 4096 bits of security - it is not the weakest link in the chain.

The benefits of having longer seed words diminishes as you increase the number of seed words and would just make storing it a hassle; given that the security of your individual addresses are only 128bits.

I would have to disagree with you on this point. Getting a private key of an individual address means you can access unspent outputs spendable by that private key. Discovering a seed will allow you to have access to all private keys associated with that seed. Some entities, such as an exchange potentially has thousands or millions of addresses associated with a single seed.

Also, if you generate a seed in a flawed way, such as using weak RNG, the number of bits of entropy will decrease, and how much it decreases will depend on how flawed your process is. Obviously, things such as flawed RNG will quickly make your entropy approach zero with even minimal flaws, so you should try to use a process to generate your seed without flaws.

[The Cryptovator]

I am not much experienced, but I can't see many benefits to extend the seed phrase. Because a powerful computing system will reverse the hash calculation and at the end, the same thing will happen, it could calculate long seed as well. If a powerful computing system could reverse current seed & hash calculations then it would do even you extend the seed. The main fact is hash calculations, if it could calculate then most likely extended seed wouldn't save our funds.

[ranochigo]

I would have to disagree with you on this point. Getting a private key of an individual address means you can access unspent outputs spendable by that private key. Discovering a seed will allow you to have access to all private keys associated with that seed. Some entities, such as an exchange potentially has thousands or millions of addresses associated with a single seed.

Trying to bruteforce HD seeds would require far more effort than trying to bruteforce addresses. Reason being that there are far more possible child keys derivations (which is stretched with HMAC-SHA512), due to the seed size and the possible derivation paths. All of these adds up to significantly more effort than trying to bruteforce addresses, given that most people will ensure that their seeds are generated with sufficient entropy. You're far more likely to gain from finding addresses instead of HD seeds.

Attacking through the entropy (128bits) will require going through HMAC-SHA512 to get the master keys.

[PrimeNumber7]

I would have to disagree with you on this point. Getting a private key of an individual address means you can access unspent outputs spendable by that private key. Discovering a seed will allow you to have access to all private keys associated with that seed. Some entities, such as an exchange potentially has thousands or millions of addresses associated with a single seed.

Trying to bruteforce HD seeds would require far more effort than trying to bruteforce addresses. Reason being that there are far more possible child keys derivations (which is stretched with HMAC-SHA512), due to the seed size and the possible derivation paths. All of these adds up to significantly more effort than trying to bruteforce addresses, given that most people will ensure that their seeds are generated with sufficient entropy. You're far more likely to gain from finding addresses instead of HD seeds.

I think it is a fair assumption that an attacker trying to learn a seed would know the seed size, and most people use the same derivation path for the same coin, even if it is technically possible to use an arbitrary path.

For all intents and purposes, you are not going to successfully brute force anything with 128 bits of entropy. The same is probably true for anything with somewhere in the range of mid 70's bits of entropy, and I would argue it would be impossible to brute force anything with somewhere between the mid 80's to mid 90's bits of entropy, assuming the laws of physics as we know them hold true.

If you assume a "secret" is generated in a way without flaws (such as flawed RNG), you will receive no additional security (regarding brute force attacks) by having your secret having 129 bits of entropy versus it having 128 bits of entropy because in both cases, it is impossible to brute force the secret. The only reason you would want to generate a secret that would have more than 128 bits of entropy if you assume no flaws in the generation process is if you are making the assumption there may flaws in the process.

[pooya87]

I think it is a fair assumption that an attacker trying to learn a seed would know the seed size, and most people use the same derivation path for the same coin, even if it is technically possible to use an arbitrary path.

Actually there are a couple of popular derivation paths that wallets use, they don't stick to the same universal thing. And depending on the address type the derivation path can differ which brings the number to about 7. There are also some custom weird derivation paths like m/84'/0'/2147483644' that some wallets like Samourai use and some unknown derivation paths that unpopular and closed source wallets use.

The assumption here is the attacker is brute forcing without any prior knowledge of anything. But you are right, if the attacker can learn some stuff about the seed, it is safe to assume they know a lot more such as the derivation path, address type,...