Pages:
Author

Topic: Does more seed words equal better security? - page 4. (Read 1079 times)

legendary
Activity: 2268
Merit: 18587
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, if one part of the process is implemented in a flawed manner, then that part of process will likely become the weakest link. But that's not really a fair comparison. You can also generate individual private keys in a flawed way, such as by taking the SHA256 hash of "correct horse battery staple". Provided everything is done properly, it doesn't matter if your seed phrase has 24 words or 384 words, you will still have private keys with 128 bits of security.

For all intents and purposes, you are not going to successfully brute force anything with 128 bits of entropy.
Which is exactly the point I am making. Your private keys, with 128 bits of security, are perfectly secure. Having a seed phrase with more than 128 bits of entropy is, at least for the foreseeable future, unnecessary.
legendary
Activity: 3290
Merit: 16489
Thick-Skinned Gang Leader and Golden Feather 2021
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.
My turn to disagree: finding a seed connected to millions of addresses is just as (un)likely as finding the private key to an address holding thousands of Bitcoins. The "ROI" will be quite similar on average.

LoyceV's split phrases are SSS seeds, because the seeds are split into multiple shares in the same way and also have a smaller number-of-shares requirement for unscrambling the seed.
That's incorrect: with SSS, one share doesn't give you any information. With split seeds, one share gives you 16 out of 24 words already.
legendary
Activity: 2954
Merit: 4158
LoyceV's split phrases are SSS seeds, because the seeds are split into multiple shares in the same way and also have a smaller number-of-shares requirement for unscrambling the seed.
They aren't. Shamir Secret Sharing has entirely different properties from the split mnemonic by iancoleman, with far more complicated logic.

The system implemented basically just splits the seeds up into different cards, which still allows the person to bruteforce (albeit less effectively) given a few of the shares.
legendary
Activity: 1568
Merit: 6660
bitcoincleanup.com / bitmixlist.org
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's split phrases are SSS seeds, because the seeds are split into multiple shares in the same way and also have a smaller number-of-shares requirement for unscrambling the seed.

Most SSS implementations, and particularly the web-based ones, are vulnerable to timing attacks partially because JS does not support a sleep() function to break up the compute time into smaller groups.
legendary
Activity: 2954
Merit: 4158
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.
That would only lower the complexity by a little. It is still more timeconsuming to bruteforce seeds via its entropy as compared to the addresses itself. While if you succeed in bruteforcing the seeds, you'll access more than a singular address, you're far more likely to succeed in bruteforcing addresses as most of the addresses out there are generated before HD wallet became a thing and that you need additional steps to go from a seed to an address. Hence, it wouldn't make a difference to how many addresses you can access with a successful attempt.

It is quite futile to target specific groups of people, unless you know for a fact that their generation if is flawed or if majority of the users are using the same parameters for their seeds.

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.
Yes. Same holds true for addresses and infact, people should be more likely to succeed at bruteforcing an address as compared to seeds.
legendary
Activity: 3472
Merit: 10611
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,...
copper member
Activity: 1624
Merit: 1899
Amazon Prime Member #7
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.
legendary
Activity: 2954
Merit: 4158
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.
legendary
Activity: 2268
Merit: 2191
Signature Space For Rent
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.
copper member
Activity: 1624
Merit: 1899
Amazon Prime Member #7
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.
legendary
Activity: 2268
Merit: 18587
-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.
legendary
Activity: 2114
Merit: 1292
There is trouble abrewing
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.
legendary
Activity: 2268
Merit: 18587
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.
legendary
Activity: 2954
Merit: 4158
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.
legendary
Activity: 3290
Merit: 16489
Thick-Skinned Gang Leader and Golden Feather 2021
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.

Quote
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.
legendary
Activity: 2954
Merit: 4158
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.
legendary
Activity: 3290
Merit: 16489
Thick-Skinned Gang Leader and Golden Feather 2021
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.
legendary
Activity: 3472
Merit: 10611
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.
legendary
Activity: 2954
Merit: 4158
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.
copper member
Activity: 2030
Merit: 1788
฿itcoin for all, All for ฿itcoin.
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.
Pages:
Jump to: