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?

[1714527739]

1714527739

[1714527739]

1714527739

[1714527739]

1714527739

[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,...

[ranochigo]

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.

[NotATether]

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.

[ranochigo]

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.

[LoyceV]

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.

[o_e_l_e_o]

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.

[NotATether]

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.

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.

Interesting, never knew that iancoleman could split seeds differently. Does there happen to be a BIP that documents this feature (it does not seem to be BIP39), since I don't get the way it's splitting the seeds, or is it just something implemented by Ian Coleman just for the tool and the source code's the only reference?

Then the real SSS tool must be this one, which you can't find on the BIP39 page: https://iancoleman.io/shamir39/, and it makes shares that look like this:

Code:

shamir39-p1 army abandon gentle account north license cherry happy pave gadget control viable survey come laptop

shamir39-p1 around abandon habit topple subway employ tomorrow mom dumb debris inspire rotate vintage nut organ

shamir39-p1 arrange abandon ankle stadium neglect home shoulder often fetch quantum addict village hunt brain trophy

shamir39-p1 arrest abandon just hospital response title firm time delay finish able trim catch immense spike

shamir39-p1 arrive abandon blur forest wine shove intact vivid consider scan iron party satisfy wolf pipe

[o_e_l_e_o]

Does there happen to be a BIP that documents this feature (it does not seem to be BIP39), since I don't get the way it's splitting the seeds, or is it just something implemented by Ian Coleman just for the tool and the source code's the only reference?

There is not a BIP for SSS. There is an associated Satoshi Labs Improvement Proposal, aptly SLIP39, which deals with SSS and explains how Trezor devices implement it. The reference implementation of this is available here: https://github.com/trezor/python-shamir-mnemonic/

Ian Coleman, on the other hand, uses the mechanisms he has outlined here: https://github.com/iancoleman/shamir39/blob/master/specification.md

Although both are implementations of SSS, they are not compatible with each other, which is one the issues I have with SSS. There are several such implementations, but whichever one you use then you are completely dependent on that one for recovery.

[PrimeNumber7]

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,...

There is an arbitrary number of derivation paths someone can use, but in practice, there are only a small number of paths that are used by the majority of users. If you are checking 8 paths for each seed you check, the entropy will increase by 3 bits, so 256 bits increases to 259 bits.

Like I mentioned before, you cannot brute force a secret that has 128 bits of entropy, and trying to do so is a waste of resources. In order to have any realistic chance of brute forcing either a seed or a bitcoin address, you need to do something to reduce the entropy. I vaguely remember reading about a wallet that was intentionally using weak RNG to generate addresses in 2011 or 2012 (I can't find the article now). In 2013, there was a flaw in android's RNG.

Other than reducing the entropy of the seed below 128 bits, I don't think it is possible to reduce the entropy of a bitcoin address below 128 bits when the address is generated from a seed.

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.

Maybe, maybe not, especially if you change the parameter to finding a seed with tens of thousands of addresses that have ever been used. According to the source you provided, there are about 40 million addresses with unspent outputs, about 0.01% of which have more than a thousand bitcoin. It is not known how many seeds are in existence that have been used, but it is far less than the number of addresses. There are probably several dozen companies that have over 10k addresses. I would think that even smaller exchanges would probably have 10k addresses, same with moderate-sized casinos and mixers.

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.

There are many advantages to using bitcoin addresses generated via a seed versus a bitcoin address generated individually. An address generated with a seed is not going to have flaws in the generation process. That, along with the fact that you only need to backup your seed once, and that using a seed somewhat discourages address reuse, means that users should really not generate bitcoin addresses individually. Most (all?) major wallet software today does not support generating addresses individually. I would say the overwhelming majority of addresses used today were generated via a seed.

Using "correct horse battery staple" as a brain wallet would have zero entropy because that private key is already well known.

[pooya87]

I vaguely remember reading about a wallet that was intentionally using weak RNG to generate addresses in 2011 or 2012 (I can't find the article now). In 2013, there was a flaw in android's RNG.

Blockchain.info (now .com) has always been involved in this type of vulnerabilities, not just in 2013 like the article but multiple times. They had the flaw with their RNG as far as I can remember it was in address generation (using random.org as "secure" random!!!), using bad k values for signing leading to private keys being revealed, etc.

[PrimeNumber7]

I vaguely remember reading about a wallet that was intentionally using weak RNG to generate addresses in 2011 or 2012 (I can't find the article now). In 2013, there was a flaw in android's RNG.

Blockchain.info (now .com) has always been involved in this type of vulnerabilities, not just in 2013 like the article but multiple times. They had the flaw with their RNG as far as I can remember it was in address generation (using random.org as "secure" random!!!), using bad k values for signing leading to private keys being revealed, etc.

Blockchain.info has a long history of having problems with their wallet. I don't recall them having an issue with their RNG (the article I cited was an issue with android's RNG, and was google's fault). I remember blockchain.info having issues with a user generating a bitcoin address on the client side, there being an issue with the connection between the user and blockchain.info, and the encrypted private key never making it to blockchain.info servers, so it would not be part of the users wallet; this was resolved with blockchain.info only generating addresses via a seed. The k values blockchain.info wallets were using were not "bad" they were being reused, which allowed someone to easily calculate the private keys when addresses were reused.

The wallet software I was referring to had intentionally used weak RNG, and had done so in a way that was only known to the dev of the wallet software. I don't believe the general public could easily brute force addresses, but the dev could because he knew the reduced space in which private keys were being generated in.

[pooya87]

I don't recall them having an issue with their RNG (the article I cited was an issue with android's RNG, and was google's fault).

I believe blockchain.info wallet has had any flaws that you can think of which involves using RNGs at some point in the past and who knows what more flaws it still has.
Here is their fault in creating weak ephemeral keys (k) which meant you could calculate users' private key from their signature: https://security.stackexchange.com/questions/74711/blockchain-info-exploit-random-number-flaw
Here is their dumb wallet using random.org to generate new keys/addresses for users over HTTP (not-encrypted!!!) then since random.org stopped responding to HTTP requests and moved to HTTPS and since their dumb wallet had no fail safe, the users started generating the same exact key: http://dillingers.com/blog/2015/06/09/ce-random-numbers-and-response-parsing/

[LoyceV]

You can also generate individual private keys in a flawed way, such as by taking the SHA256 hash of "correct horse battery staple".

That private key has received thousands of transactions totalling 38 Bitcoin. People are dumb

Does there happen to be a BIP that documents this feature (it does not seem to be BIP39), since I don't get the way it's splitting the seeds, or is it just something implemented by Ian Coleman just for the tool and the source code's the only reference?

I'm confused, are you still talking about this code? It's as human readable as it gets: if you have 2 cards, all you have to do is replace the XXXX on one card with the corresponding word other card. Each word is always on 2 out of 3 cards.

Then the real SSS tool must be this one, which you can't find on the BIP39 page: https://iancoleman.io/shamir39/

I never knew
Good to know https://iancoleman.io/ has many more tools, I always go straight to https://iancoleman.io/bip39/ from my bookmarks, and never looked further.

it makes shares that look like this:

Code:

shamir39-p1 army abandon gentle account north license cherry happy pave gadget control viable survey come laptop
shamir39-p1 around abandon habit topple subway employ tomorrow mom dumb debris inspire rotate vintage nut organ
shamir39-p1 arrange abandon ankle stadium neglect home shoulder often fetch quantum addict village hunt brain trophy
shamir39-p1 arrest abandon just hospital response title firm time delay finish able trim catch immense spike
shamir39-p1 arrive abandon blur forest wine shove intact vivid consider scan iron party satisfy wolf pipe

This is cool! But, unless I read and understand the source code, I have to completely trust the software again.

It's also available for random text: https://iancoleman.io/shamir/

[NotATether]

Does there happen to be a BIP that documents this feature (it does not seem to be BIP39), since I don't get the way it's splitting the seeds, or is it just something implemented by Ian Coleman just for the tool and the source code's the only reference?

I'm confused, are you still talking about this code? It's as human readable as it gets: if you have 2 cards, all you have to do is replace the XXXX on one card with the corresponding word other card. Each word is always on 2 out of 3 cards.

Yes I am, and I suppose there's no black magic involved in making the words on each card. Just make one phrase, and write it on three sheets of parts, omitting some words on each paper.

This is cool! But, unless I read and understand the source code, I have to completely trust the software again.

It's also available for random text: https://iancoleman.io/shamir/

To be fair, you can't trust any program's source that hasn't been built using a deterministic process, such as Bitcoin Core's.

[LoyceV]

To be fair, you can't trust any program's source that hasn't been built using a deterministic process, such as Bitcoin Core's.

True. But I can use different programs to verify the same seed phrase. So when I setup a new hardware wallet, it gives me piece of mind to verify the same words produce the same addresses using some (offline) software.

[franky1]

a basic laymans view:
a 12 word seed using a 2048 word-library results in each seed-word being expressed as 11 bits from
00000000000 abandon
to
11111111111 zoo
obviously 12 seed-words = 12*11=132bits of entropy

which is far lower than a private keys 256bit length
after all all private keys derived from a 12seed are all within the first 132 bits of a 256privkey
where as:
14 words=154
16 words=176
18 words=198
20 words=220
22 words=242
23 words=253

so having more seed-words than 12, upto 23 can add more entropy

obviously these extra unused bits can be used for nonces/indexes to then be able to make a crap tonne of keypairs using the same 12 words
where a 23word seed only has 3 bits spare so can only make 8 keypairs using the 23word seed
            22word seed has 14 spare bits so can make 16384 keypairs using 22 word seed

22 words with enough indexes to make 16k of keypairs. is enough for all purposes and has enough security 242 entropy
...

because all seed-words have the possibility of everything from 00000000000 to 11111111111 having means anything above 22 seed-words becomes meaningless

but even just 12 seed-words is more entropy than needed. where even if a bruteforcer was to start at
abandon abandon abandon abandon abandon abandon
abandon abandon abandon abandon abandon abandon
and tried every option

they still would need to pass their project down to their great great great great  * xxx grandkid to keep the project going

..
the only real leakage of entropy. is if people decide to use words personal to them. common words. rather than letting a randomiser pick randomly from the 2048 library

eg more likely to say 'work' 'update' but not likely to say 'voyage' 'vicious'

having a 12 word-seed of a word-library of 15bits(32k library) using a random picker
is far better than
having 16 words of human chosen personal words from the 2048 library
even if mathematically the entropy of both are nearly the same

[Welsh]

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.

Exactly. This is the issue with many security implementations. Well, really its usually the user is the weak point. If you go into computing or anything to do with security you will always hear the phrase "The user is the weak point", and while it might be cliche its absolutely true. The reason we don't have more secure implementations in every day things is because the person behind that implementations wants it to be as simple as possible.

Password managers are extremely popular around here, and their passwords are usually pretty damn strong. However, its quite common for people to use a easy to remember password to access that password manager effectively reducing their overall security, because that easy to remember password is usually rather poor from a security point of view. Once they get access to the password manager, they have access to the more complicated, randomly generated passwords.

So, absolutely increasing the seed length increases the security. Well, I should say it increases the strength, however not necessarily the security. Since, if its easy to forget or hard to store in a safe place, it is no longer secure. The problem with security of today is finding the right balance of strength, and usability.

[LoyceV]

Password managers are extremely popular around here, and their passwords are usually pretty damn strong. However, its quite common for people to use a easy to remember password to access that password manager effectively reducing their overall security, because that easy to remember password is usually rather poor from a security point of view. Once they get access to the password manager, they have access to the more complicated, randomly generated passwords.

Even a weak password becomes harder to crack if the password manager uses millions of rounds of encryption. Without that feature, an attacker could easily use cloud computing to try billions of passwords per second. But with it, it takes the same amount of computing just to try a couple (hundred) passwords per second.
Of course, a strong password helps a lot to further multiply the time required to brute-force the password.

[pooya87]

obviously 12 seed-words = 12*11=132bits of entropy
which is far lower than a private keys 256bit length

To be clear a 12-word mnemonic using BIP39 algorithm has 128 bits of entropy, the rest is the checksum.
Also a n-bit long entropy provides n bits of security while a n-bit long elliptic curve key provides n/2 bits of security that is why the BIP39 entropy size starts at 128 which is the same security level as the bitcoin 256-bit private keys.

[o_e_l_e_o]

obviously 12 seed-words = 12*11=132bits of entropy

128 bits of entropy for BIP39 seeds phrases. 132 bits of entropy only for Electrum seed phrases.

which is far lower than a private keys 256bit length

Bitcoin private keys have a strength of 128 bits.

where as:
14 words=154
16 words=176
18 words=198
20 words=220
22 words=242
23 words=253

The actual table for BIP39 seed phrases is as follows:

12 words = 128 bits of entropy
15 words = 160 bits of entropy
18 words = 192 bits of entropy
21 words = 224 bits of entropy
24 words = 256 bits of entropy

obviously these extra unused bits can be used for nonces/indexes to then be able to make a crap tonne of keypairs using the same 12 words
where a 23word seed only has 3 bits spare so can only make 8 keypairs using the 23word seed
            22word seed has 14 spare bits so can make 16384 keypairs using 22 word seed

A seed phrase of any length can make as many key pairs as you like by following the BIP32 standard for deriving child keys from parent keys. Since BIP32 specifies no maximum number of derived levels, you can theoretically generate all the possible valid key pairs in existence from any seed phrase.

[franky1]

obviously 12 seed-words = 12*11=132bits of entropy
which is far lower than a private keys 256bit length

To be clear a 12-word mnemonic using BIP39 algorithm has 128 bits of entropy, the rest is the checksum.
Also a n-bit long entropy provides n bits of security while a n-bit long elliptic curve key provides n/2 bits of security that is why the BIP39 entropy size starts at 128 which is the same security level as the bitcoin 256-bit private keys.

not to want to knit pick your knitpick or o_e_l_e_o..but.. i will

a library of 2048 words
is binary of eleven bits

one bit:        1=2
two bits:      11=4
three bits:   111=8
four bits:     1111=16
five bits:      11111=32
six bits:       111111=64
seven bits:   1111111=128
eight bits:    11111111=256
nine bits:     111111111=512
ten bits:       1111111111=1024
eleven bits    11111111111=2048

this topic made no specification to be anal towards CORES bip.. nor any other.
so i just stuck to the layman of MATH and logic.
seems a shame many people want to be anal and only want to discuss one softwares version.
even when thte topic creator is asking about different key lengths (options outside the bip)

anyway lets get back to the point
so knowing each seed-word is 11 bits.
knowing there are 12 seed-words

simple math of 11*12=132
12 seed words of eleven bits is 132

yes i know that anything beyond 128bit is cut short in the curve/hash process

but this topics question was not about priv-public keypair entropy after the curve-has process. it was about the initial seed words.

i could go into the nuances of how there is more then one private key per public key.. (the point your moving into) but thats not the topic

my point was more about the human flaws of entropy of the seed words at the beginning.
the security level of seed words.. not the latter keypair

EG is it better to have a 12 seed with a library of 32k words
or a 20 seed using a library of 2048

[o_e_l_e_o]

a library of 2048 words
is binary of eleven bits

No one is disputing that. Yes, each word encodes 11 bits of data, but not necessarily 11 bits of entropy. BIP39 seed phrases include a checksum, which is why 12 words give 128 bits of entropy and not 132. The 132 bits of data include the 128 bits of entropy and 4 bits of checksum.

this topic made no specification to be anal towards CORES bip.. nor any other.

Core does not use seed phrases at all.

seems a shame many people want to be anal and only want to discuss one softwares version.

The only standards for seed phrases are BIP39 or Electrum, both of which are being discussed above. And regardless of which one of you use, the same premise still holds true - you will never end up with private keys with more than 128 bits of security.

yes i know that anything beyond 128bit is cut short in the curve/hash process

It isn't. Your entire seed phrase, regardless of length, will be used in the HMAC-SHA512 function to generate your 512 bit seed number. Nothing is cut short, it just doesn't result in any increase in the security of your private keys.

EG is it better to have a 12 seed with a library of 32k words
or a 20 seed using a library of 2048

It is better to do neither of these non-standard things, since chances are you will run in to problems trying to recover from your seed phrase in the future. If you feel 12 words are not enough, then simply generate a 24 word seed phrase using the BIP39 standard. If you still feel this is not enough, then use one or more additional passphrases.

[PrimeNumber7]

I don't recall them having an issue with their RNG (the article I cited was an issue with android's RNG, and was google's fault).

I believe blockchain.info wallet has had any flaws that you can think of which involves using RNGs at some point in the past and who knows what more flaws it still has.
Here is their fault in creating weak ephemeral keys (k) which meant you could calculate users' private key from their signature: https://security.stackexchange.com/questions/74711/blockchain-info-exploit-random-number-flaw
Here is their dumb wallet using random.org to generate new keys/addresses for users over HTTP (not-encrypted!!!) then since random.org stopped responding to HTTP requests and moved to HTTPS and since their dumb wallet had no fail safe, the users started generating the same exact key: http://dillingers.com/blog/2015/06/09/ce-random-numbers-and-response-parsing/

I was referring to the generation of private keys, but the point you make is fair enough. Although to be fair to blockchain.info, users should not reuse addresses, and reusing addresses was an additional step that caused reused k values to lead to the potential for the loss of coin.

I don’t recall hearing about security issues about blockchain.info wallets for quite some time now and their wallet is open source. They may have eventually been able to hire experienced security engineers to address security issues. Today, there are many engineers willing and interested in working on blockchain/bitcoin related projects/companies, but this was not always the case, especially to the extent that there is interest today.

[BlackHatCoiner]

132 bits of entropy only for Electrum seed phrases.

Aren't they 128 too, but with 8 bits of entropy?

EG is it better to have a 12 seed with a library of 32k words
or a 20 seed using a library of 2048

Let's leave the fact that each private key has 128 bits of security; if someone tried to brute force your address, he'd find it easier to go straight by calculating 2¹⁶⁰ hashes rather than 32000¹² or 2048²⁰. They're far larger numbers than the RIPEMD-160's possible outputs.

The twelve words with 2048 words in total is a great choice, but if you feel insecure, your best option would be 15 words that provide 165 bits. Anything longer than that would be an “overdose”.

[o_e_l_e_o]

Aren't they 128 too, but with 8 bits of entropy?

I assume you mean 8 bits of checksum, but no. Electrum seed phrases have 132 bits of entropy. It generates 132 bits of entropy, hashes it, checks if the resulting hash starts with the correct version number, and if not, then it increases the entropy by one and hashes it again. It repeats this until it finds a hash starting with the desired version number. One it has, it turns the full 132 bits of entropy in to a seed phrase. This is obviously different from BIP39, which generates 128 bits of entropy, hashes for the checksum, appends it to make 132 bits, and then turns those 132 bits in to the seed phrase.

You can read more about this process here: https://electrum.readthedocs.io/en/latest/seedphrase.html

The twelve words with 2048 words in total is a great choice, but if you feel insecure, your best option would be 15 words that provide 165 bits. Anything longer than that would be an “overdose”.

15 BIP39 words provides 160 bits of entropy, with 5 bits of checksum.

[pooya87]

~
which is far lower than a private keys 256bit length

~

not to want to knit pick your knitpick or o_e_l_e_o..but.. i will
~

First of all you are thinking in reverse, we aren't selecting words out of a word list. We are encoding a stream of random bits to human readable words. Secondly what we generate as an "entropy" in programming is actually not a stream of bits but a stream of octets or bytes. So we can't have 132 bits, but 128 or 136 bits. Even Electrum mnemonics are actually generating 136 bits then reducing it to 132 bits. And finally that wasn't even the part I was "nitpicking" it was the wording in the part I quoted which could be interpreted as a 128 (or 132) bit entropy is "far less secure" than a private key which would be a false interpretation because it provides the same security as I explained above.

EG is it better to have a 12 seed with a library of 32k words
or a 20 seed using a library of 2048

Again you are thinking in reverse. We are not selecting words, we are just encoding an entropy and the equal length entropies are the same thing no matter the encoding (Base16, Base64, PGP words, BIP39 words, ...).

[j2002ba2]

Aren't they 128 too, but with 8 bits of entropy?

I assume you mean 8 bits of checksum, but no. Electrum seed phrases have 132 bits of entropy. It generates 132 bits of entropy, hashes it, checks if the resulting hash starts with the correct version number, and if not, then it increases the entropy by one and hashes it again. It repeats this until it finds a hash starting with the desired version number. One it has, it turns the full 132 bits of entropy in to a seed phrase. This is obviously different from BIP39, which generates 128 bits of entropy, hashes for the checksum, appends it to make 132 bits, and then turns those 132 bits in to the seed phrase.

You can read more about this process here: https://electrum.readthedocs.io/en/latest/seedphrase.html

I read it, and looked at the source. It starts with 132 bits of entropy, but then discards the ones with no matching version, thus reducing the entropy. For "standard" (p2pkh, version starting with "01") the resulting entropy is at most 132-8=124 bits. For "segwit" (version starting with "100") it is even worse 132-12=120 bits. Additionally the BIP39 checksum must fail. For 12-word seed this reduces the entropy slightly as well, by ~0.093 bits. So a newly generated wallet would have entropy about 119.9 bits.

To make it clear: for any 132 bit number the chance of it being a correct "segwit" seed is 1/4096 * 15/16, thus getting only 2^119.9 possibilities.
"standard" has a chance 1/256 * 15/16, giving 2^123.9 possibilities.

[pooya87]

I read it, and looked at the source. It starts with 132 bits of entropy, but then discards the ones with no matching version, thus reducing the entropy.

It doesn't discard the entropy it increments it[1] and you don't lose entropy by incrementing it. It is basically the same concept as vanity address generators, they too start from a random entropy then increment it until they reach the desired address.

[1] https://github.com/spesmilo/electrum/blob/3bc8ef6651ed9d9aff0531b3597f80eca4886301/electrum/mnemonic.py#L208

[j2002ba2]

I read it, and looked at the source. It starts with 132 bits of entropy, but then discards the ones with no matching version, thus reducing the entropy.

It doesn't discard the entropy it increments it[1] and you don't lose entropy by incrementing it. It is basically the same concept as vanity address generators, they too start from a random entropy then increment it until they reach the desired address.

[1] https://github.com/spesmilo/electrum/blob/3bc8ef6651ed9d9aff0531b3597f80eca4886301/electrum/mnemonic.py#L208

The act of randomly choosing one of 2^119.9 possibilities cannot magically have more than 119.9 bits entropy, this is the upper limit.

You loose entropy by rejecting a significant portion of the possible input. Yes, incrementing is rejecting. It's like throwing a dice, then rejecting all but numbers 1 and 6, this gives you 1 bit entropy, not 2.58. Or most extreme: tossing a coin, where only heads are valid, getting 0 bits entropy.

Let's for example start with 11 bits entropy, a single word seed. With version "01" we get only 7 possible words: "best" "frequent" "lounge" "spin" "stay" "tone" "true", with input range for each 0-170, 171-741, 742-1058, 1059-1679, 1680-1703, 1704-1826, 1827-1866; 1867-2047 raises exception due to overflow. After applying the entropy formula we get 2.18 bits entropy. Version "100" is way more drastic - no possible words, zero bits entropy.

[o_e_l_e_o]

The act of randomly choosing one of 2^119.9 possibilities cannot magically have more than 119.9 bits entropy, this is the upper limit.

But an attacker does not know the set of 2^119.9 you are choosing from.

An attacker does not know in advance which seeds from the 2¹³² possibilities result in a hash with the necessary prefix. The only way to obtain this data is to brute every one of the 2¹³² possible seeds. Sure, if they find an invalid seed then they do not need to go through the rest of the steps of PBKDF2 and generating private keys and addresses to check for funds, but this does not mean the initial seed has less than 2¹³² bits of entropy.

Consider the following example: Let's say I impose a prefix requirement that is 130 bits long. By your logic, my entropy has now been reduced to 2, and so my seed would be trivial to brute force. Obviously this is not the case.

[j2002ba2]

The act of randomly choosing one of 2^119.9 possibilities cannot magically have more than 119.9 bits entropy, this is the upper limit.

But an attacker does not know the set of 2^119.9 you are choosing from.

You are right. Looks like I'm nitpicking.

Entropy is 2^119.9, while the attack surface remains 2¹³².

Thinking about it, one needs to make on average 4096 HMAC-SHA512 to get a correct version, which is twice the HMACs needed by PBKDF2. This looks like speeding up the attack 1365 times ((4096 * 2048) / (4096 + 2048)), compared to doing PBKDF2 on every possible input.

With BIP39 the attack is 2¹²⁸ PBKDF2, while Electrum is 2^121.6 equivalent PBKDF2. After that we have 2¹²⁸ address derivations for BIP39, and 2^119.9 for Electrum.

Is this correct?

EDIT:

The cost of computing a single valid seed for BIP39 is 1xPBKDF2 + 1xAD (address derivation), while for Electrum it is 3xPBKDF2 + 1xAD. So Electrum seeds are harder to attack, it all depends on the cost of AD versus PBKDF2. If AD is the main cost, then it's about the same. When PBKDF2 is the main cost, Electrum seeds are 3 times harder to attack.

So if BIP39 has 128 bit security, Electrum has 128-129.5 bit equivalent security.

[o_e_l_e_o]

Is this correct?

I believe so.

The probability of a seed having the correct version prefix for a 3 character prefix is 2^-12, which is in 1 in 4096. For those seeds with a correct version prefix, then an attacker must perform a total of 2049 hashes. For the other 4095 possibilities, one hash is sufficient to exclude that seed. This means an average of 1.5 hashes per seed is required, as opposed to 2048 with BIP39, which is indeed a 1365.33... speed up.

With BIP39 being 2¹²⁸ * 2048 hashes, that would be 2¹³⁹
With Electrum being 2¹³² * 1.5 hashes, that would be 2^132.58, which is the same as your 2^121.6 * 2048.

The cost of computing a single valid seed for BIP39 is 1xPBKDF2 + 1xAD (address derivation), while for Electrum it is 3xPBKDF2 + 1xAD.

I don't follow you here. Why is it 3x PBKDF2 for Electrum?

[j2002ba2]

The probability of a seed having the correct version prefix for a 3 byte prefix is 2^-12, which is in 1 in 4096.

You mean 3 hex digits (or 3 nibbles).

The cost of computing a single valid seed for BIP39 is 1xPBKDF2 + 1xAD (address derivation), while for Electrum it is 3xPBKDF2 + 1xAD.

I don't follow you here. Why is it 3x PBKDF2 for Electrum?

Normalizing hashes to PBKDF2. In other words BIP39 is 2048xHMAC + 1xAD, Electrum 6144xHMAC + 1xAD.

[PrimeNumber7]

Is this correct?

I believe so.

The probability of a seed having the correct version prefix for a 3 byte prefix is 2^-12, which is in 1 in 4096. For those seeds with a correct version prefix, then an attacker must perform a total of 2049 hashes. For the other 4095 possibilities, one hash is sufficient to exclude that seed. This means an average of 1.5 hashes per seed is required, as opposed to 2048 with BIP39, which is indeed a 1365.33... speed up.

The reason why this does not result in a loss of entropy is that you cannot know in advance if a seed is valid or not prior to checking the seed. You will need to perform a calculation on every seed candidate before ruling it out as not being your seed. According to the electrum devs, the cost to rule out a seed candidate as being outright invalid is less than calculating the actual seed. While technically not reducing the number of bits of entropy, it would somewhat reduce the cost of a bruteforce attack with a given n bits of entropy, when compared with a setup in which every seed candidate is valid.

I would compare the above to j2002ba2's above comparison to only accept dice rolls that are a 1 or a 6 on a 6-side dice. In his example, no calculation is needed in advance, the dice is reduced to a coin, with one side being valued as True and the other being valued as False, and the seed is calculated accordingly. An individual attacker may not specifically know you are using the "1" and "6" constraints but may bruteforce with two random numbers in order to have a lower space of possible values, and with many attackers, one will eventually try 1 and 6. 

[o_e_l_e_o]

You mean 3 hex digits (or 3 nibbles).

Fixed, thanks.

Normalizing hashes to PBKDF2. In other words BIP39 is 2048xHMAC + 1xAD, Electrum 6144xHMAC + 1xAD.

Ahh right, I'm with you now. So yes, it is harder to attack a single valid Electrum seed compared to a single valid BIP39 seed, but for a 3 character prefix there are only 2¹²⁰ valid Electrum seeds compared to 2¹²⁸ valid seeds for BIP39. Does this not making attacking an Electrum seed theoretically easier? (2^132.58 versus 2¹³⁹ as I stated above?)

The reason why this does not result in a loss of entropy is that you cannot know in advance if a seed is valid or not prior to checking the seed. You will need to perform a calculation on every seed candidate before ruling it out as not being your seed.

This is exactly what I said above:

An attacker does not know in advance which seeds from the 2¹³² possibilities result in a hash with the necessary prefix. The only way to obtain this data is to brute every one of the 2¹³² possible seeds.

[franky1]

132 bits of entropy only for Electrum seed phrases.

Aren't they 128 too, but with 8 bits of entropy?

EG is it better to have a 12 seed with a library of 32k words
or a 20 seed using a library of 2048

Let's leave the fact that each private key has 128 bits of security; if someone tried to brute force your address, he'd find it easier to go straight by calculating 2¹⁶⁰ hashes rather than 32000¹² or 2048²⁰. They're far larger numbers than the RIPEMD-160's possible outputs.

The twelve words with 2048 words in total is a great choice, but if you feel insecure, your best option would be 15 words that provide 165 bits. Anything longer than that would be an “overdose”.

yet again..
my whole point was..
the HUMAN ELEMENT

someone handpicking 12 words. means their entropy of library might just be 500 words they commonly use and are personal to them..
EG many IT/Network nerds might choose words affiliated with IT/networking. and not even think to uuse words like 'voyage' / vicious

so 12 words of a library of 500 handpicked words is very bad.
(its why a few passphrase wallets got emptied)

next up is the HUMAN element of when using a randomiser
is it better to have 12 words or 24 words of a 2048 library
or a 20 word of a 32k library

and the answer is. most people write down their seeds so human memory is of no issue and so a 20 word of 32k library allows for the most randomness

..
i honestly thought this topic was about seed word security of DO MORE SEED WORDS EQUAL BETTER SECURITY
seems many want to think its about the edcsa sha ripemd160 process, and the pre to post bit differences either side of that process..

but anyways moving on, ive said my peace

answering to below..
(sticking with speaking laymans<-emphasis)
(using basic math of entropy and not the technical anals of acertain wallets prefered method of conversion)
i know you want to obsess about the 2¹⁶⁰ to go through all keys..

but for a HUMAN wanting to know his security risk of HIS seed key..
ill lay out the math
how many combinations:
a. 2¹⁶⁰ =      1461501600000000000000000000000000000000000000000
b. 2048¹² =                   5444517900000000000000000000000000000000
c. 500¹² =                                       488281250000000000000000000000

a=ripemd160 combinations
b=12 seed with 2048 library+good randomiser
c=manually choosing personalised words from common vocab

his 12 word seed with 2048 library. can be found easier then ripemd160
his personally chosen words from his common vocab can be found even easier

so if a brute forcer was looking for a particular persons seed and knew his vocab preference by scanning all his posts and finding the words he uses.
a bruteforcer could find his seed in 19 less significant figures then bruteforcing all ripemd combinations

it doesnt matter about how many combinations there are in the hash process
because his seed keys have less combinations at the beginning

its never a debate about total combinations a process allowes
its that his key is somewhere in the middle of
5444517900000000000000000000000000000000
or
488281250000000000000000000000
before it even goes though any particular wallets prefered conversion method

[BlackHatCoiner]

someone handpicking 12 words. means their entropy of library might just be 500 words they commonly use and are personal to them..

Why would someone handpicked twelve words since he can generate them and ensure that he's made a completely unpredictable choice? As you said, there may be people who won't use specific words, but that doesn't matter that much; it matters the fact that they won't make an unpredictable guess while the whole point of cryptography is to always generate the private key with no human intervention. (Knowing what he's doing)

i honestly thought this topic was about seed word security of DO MORE SEED WORDS EQUAL BETTER SECURITY
seems many want to think its about the edcsa sha ripemd160 process, and the pre to post bit differences either side of that process...

The point of this thread is to give an answer if the more words means the better security and we've explained that an attacker won't have to brute force an extremely long seed phrase; he'll find it easier to successfully find a RIPEMD-160 collision instead.

[o_e_l_e_o]

someone handpicking 12 words. means their entropy of library might just be 500 words they commonly use and are personal to them..

Someone hand picking words is almost certainly going to be less secure than a randomly generated 12 word seed phrase, regardless if they are picking from a list of 500 words or 32k words or 100k words.

next up is the HUMAN element of when using a randomiser

There should not be a human element at all. You should allow your software to randomly generate entropy for you. As soon as you introduce a human element, then you are far less secure than if you just let the software generate a 12 word seed phrase for you.

so a 20 word of 32k library allows for the most randomness

No, it doesn't. The number of words or the size of the library have no direct correlation with "randomness". I could pick the same word 12, or 20, or 100 times and be far less secure than a standard 12 word BIP39 seed phrase.

[j2002ba2]

Does this not making attacking an Electrum seed theoretically easier? (2^132.58 versus 2¹³⁹ as I stated above?)

Only when doing exhaustive search. But then "ease" of attack depends on other things as well. What is the proportion of BIP39 seeds versus Electrum ones? If there are 100 times more BIP39 seeds than Electrum, then the chance of stumbling upon BIP39 is higher.

I looked up PBKDF2 vs Address Derivation timings, and for the usual non-hardened addresses (m/84'/0'/0'/0/0) AD is about 10 times faster than PBKDF2. Hardened only derivation is 30 times faster. Specialized hardware might change the ratio.

The reason why this does not result in a loss of entropy is that you cannot know in advance if a seed is valid or not prior to checking the seed. You will need to perform a calculation on every seed candidate before ruling it out as not being your seed.

Entropy is a word with many meanings. The Shannon Entropy, measured in bits, does decrease. It has nothing to do with how many calculations are done.

[o_e_l_e_o]

What is the proportion of BIP39 seeds versus Electrum ones? If there are 100 times more BIP39 seeds than Electrum, then the chance of stumbling upon BIP39 is higher.

Good point. So attacking a specific seed is easier for Electrum seeds, but if attacking any used seed then that may not be the case. Interestingly, if you assume 100 times more BIP39 than Electrum seeds as you have, then you end up with very similar numbers between the two.

I looked up PBKDF2 vs Address Derivation timings, and for the usual non-hardened addresses (m/84'/0'/0'/0/0) AD is about 10 times faster than PBKDF2. Hardened only derivation is 30 times faster. Specialized hardware might change the ratio.

Remember as well that Electrum uses simpler derivation paths which would be easier to derive than the BIP39 ones. It uses m/0/0 for the first legacy address, and m/0'/0/0 for the first segwit address.

[j2002ba2]

So attacking a specific seed is easier for Electrum seeds, but if attacking any used seed then that may not be the case.

The opposite. Attacking specific Electrum seed is 3 times harder compared to BIP39, if we look at single derivation path. Attacking sufficient number of derivation paths (100?) makes the difficulty same.

I looked up PBKDF2 vs Address Derivation timings, and for the usual non-hardened addresses (m/84'/0'/0'/0/0) AD is about 10 times faster than PBKDF2. Hardened only derivation is 30 times faster. Specialized hardware might change the ratio.

Remember as well that Electrum uses simpler derivation paths which would be easier to derive than the BIP39 ones. It uses m/0/0 for the first legacy address, and m/0'/0/0 for the first segwit address.

The difficulty in derivation is mainly the number of elliptic curve multiplications (by scalar), m/0/0 uses 3 multiplications and 2 additions. m/0'/0/0 does exactly the same, so does m/84'/0'/0'/0/0. m/0'/0' is single multiplication. Non-hardened child means we need the parent public key, and have to add it to another public key.

[o_e_l_e_o]

Attacking specific Electrum seed is 3 times harder compared to BIP39, if we look at single derivation path.

Allow me to rephrase. Yes, finding a valid Electrum seed requires 3 times the hashes of a valid BIP39 seed (assuming it takes a full 4096 attempts to find a valid prefix), but if searching the entire space for a specific seed, then it would be easier with Electrum seeds than with BIP39 seeds, no? There are fewer valid Electrum seeds as you point out here:

With BIP39 the attack is 2¹²⁸ PBKDF2, while Electrum is 2^121.6 equivalent PBKDF2. After that we have 2¹²⁸ address derivations for BIP39, and 2^119.9 for Electrum.

The difficulty in derivation is mainly the number of elliptic curve multiplications

Sure, but an additional three HMAC-SHA512s and additions per derivation path is not trivial when considering 2¹²⁸ seeds.

[franky1]

its been many posts and many hours. and i still see people beating their chest showing off how much they know about the math of the hashing cycle of sha, ecdsa and ripemd160..

but the question of SEEDS.. is the part pre hashing cycle
and thats about the human security of what randomiser/human personal selection entropy
which can make the difference between 500¹² or 2048¹²

yet again. if they want to talk about the 2¹⁶⁰ post hash cycle(a)
they are ignoring the less secure(b,c)

a. 2¹⁶⁰ =      1461501600000000000000000000000000000000000000000
b. 2048¹² =                   5444517900000000000000000000000000000000
c. 500¹² =                                       488281250000000000000000000000

by the way.
having 10 seed words of 32000 library(d) is more secure than 12seed with with randomiser(b) or personally chosen(c)
d. 3200¹⁰ =        1125899900000000000000000000000000000000000000

and thats without having to do any gorilla chest beating of whos the smartest and explaining the hashing functions

yep you will have much better luck brute forcing seeds in (b,c,d) than you would by trying all (a) combinations
so. try to keep to the topic of the SEEDs and not the post ripemd160 entropy

remember the question is
"does more seed words"
not
"whats the most combinations post keyhash cycle"

[j2002ba2]

Allow me to rephrase. Yes, finding a valid Electrum seed requires 3 times the hashes of a valid BIP39 seed (assuming it takes a full 4096 attempts to find a valid prefix), but if searching the entire space for a specific seed, then it would be easier with Electrum seeds than with BIP39 seeds, no?

Seems that I got confused. Yes, it would be easier.

On the other hand, while attacking specific seed, it's way more probable to stumble upon another seed before finding it.

The difficulty in derivation is mainly the number of elliptic curve multiplications

Sure, but an additional three HMAC-SHA512s and additions per derivation path is not trivial when considering 2¹²⁸ seeds.

If my numbers are correct generating one public key from private is ~68 times slower than a single HMAC-SHA512. That's why I assume elliptic curve operations are the slow thing here.

[BlackHatCoiner]

remember the question is
"does more seed words"

Don't miss the forest for a tree; the title may say that, but in the original post, 20kevin20 asks if Bitcoin would be more secure if we extended the phrase with additional words. Therefore, we answer that an attacker will prefer computing 2¹⁶⁰ hashes rather than a range of mnemonics which exceeds it. Besides that, calculating a RIPEMD-160 hash takes less time than generating a BIP39 seed.

having 10 seed words of 32000 library(d) is more secure than 12seed with with randomiser(b) or personally chosen(c)

Again, if it exceeds the time 2¹⁶⁰ hashes would take, then the point is lost.

[o_e_l_e_o]

and i still see people beating their chest showing off how much they know about the math of the hashing cycle of sha, ecdsa and ripemd160..

We are having a discussion about the security of different seed phrases. No one is beating their chest about anything.

and thats about the human security of what randomiser/human personal selection entropy

Here you go with the "personal selection" again. Humans are not random. Despite how random you think you are being, you aren't. I'll take 128 bits of properly generated entropy over any of your "human chosen words from a list of 32,000 words" any of the day week. Not to mention that choosing words is the completely wrong way to think about the whole thing. You generate entropy, not words. The words are simply an encoding of the entropy.

remember the question is
"does more seed words"

Are 256 bits of entropy encoded by 24 words more secure than 128 bits of entropy encoded by 12 words? Sure.
Does that result in private keys which are more secure? No.
Is any harebrained scheme where someone picks their own words going to be more secure than either of those? No.

[franky1]

remember the question is
"does more seed words"

Are 256 bits of entropy encoded by 24 words more secure than 128 bits of entropy encoded by 12 words? Sure.
Does that result in private keys which are more secure? No.
Is any harebrained scheme where someone picks their own words going to be more secure than either of those? No.

if you stop beating your chest for a slight moment.
have a cup of coffee, take a breath and read the details.

none of my posts say human hand picked keys are more secure
NOTE: yes i mentioned human chosen words are LOW entropy as people usually only hand pick from a vocab of about 500 common words
that was an example of low entropy. no conclusion or suggestion was made that hand picked brain chosen words were better(though your chest beating assumed so due to weirdly looking for something to oppose)

ill explain the separate part now
your 1 round 128bit random...
then add on 4 bit checksum
then divide by 12 (call it the backward flow method of seed)

is not as much entropy as
12 rounds of 11bit random. then joined together
(call this the forward flow method)

both equal 132bit. but forward flow random 12 words, gives more combinations than your backward flow single random 128bit
(the extra 4bit checksum adds no extra combinations because the checksum is linked to the 128bit)


so we both agree(if you stop thumping your chest) that hand picked low vocab human chosen is bad
that has never been a debate.

let me take it one step further as it seems you missed the entire point
i understand your backward flow method

BEFORE going into a ECDSA cycle. that 128bit+checksum of yours needs to be padded out into 256bits
meaning your limiting how many possible private keys you can have by only seeking within the first 128bit
meaning your scheme has less entropy than whats possible
yes your 128bit may calculate to having more then private key for a public key. meaning you are not going to be calculating all possible 160bit public keys.

for emphasis:
i know you will be beating chest ready to growl how there are only 160bit of public key so no need to worry about 256bit. but only having 128bit means your not finding all 160bit publics

but hey lets limit it to your chest beat of 160bit public key as the max entropy for the private(still not enough, but lets play it your way)

so
12 rounds of random 11bit is more possible combinations (132bit)
13 rounds of random 11bit is more possible combinations (143bit)
14 rounds of random 11bit is more possible combinations (154bit)
15 rounds of random 11bit is more possible combinations (165bit)
    ^15 rounds is a bit of an over flow but would atleast cover all 160bit public keys

and one step further
10 rounds of random 15bit(32k library) is more possible combinations (150bit)
11 rounds of random 15bit is more possible combinations(165bit)
    ^11 rounds is a bit of an over flow but would atleast cover all 160bit public keys

so the point of my answer is
to the topic creator
using the standard 2048word library(11bit)
doing 13-14-15 random rounds is more secure than o_e_l_e_o's single round of 128bit
so more seed-words of 2048library-words (rounds of 11bit random) is more secure
but, so is
10 random seed-words of 32k library-words(rounds of 15bit random) is more secure
11 random seed-words of 32k library-words(rounds of 15bit random) is more secure

i wont do the math of all the privates needed to get EVERY public including all double privates..
because o-e-l-e-o wants to keep his debate to 160bit. so just on the limited scope

forward flow method of 13-14-15 is more secure

have a nice day,
hopefully a more calm and relaxed day

[o_e_l_e_o]

You might find people are more willing to discuss things with you if you stopped using personal insults in every other sentence.

BEFORE going into a ECDSA cycle. that 128bit+checksum of yours needs to be padded out into 256bits
meaning your limiting how many possible private keys you can have by only seeking within the first 128bit

The seed phrase does not enter an elliptic curve multiplication function (which is not the same as ECDSA). It enters 2048 rounds of HMAC-SHA512 to produce a 512 bit seed number, the first 256 bits of which become the master private key of your wallet, and the second 256 bits becoming the master chain code.

yes your 128bit may calculate to having more then private key for a public key. meaning you are not going to be calculating all possible 160bit public keys.

There are (slightly fewer than) 2²⁵⁶ public keys, not 2¹⁶⁰. And thanks to how hierarchical deterministic wallets work with unlimited levels, you can theoretically generate every public private key pair from a single seed phrase.

I'm not saying that 15 words from a wordlist of 32,768 does not have more entropy than 12 from a wordlist of 2,048, provided both are encodings of a randomly generated number. But given how bitcoin generates private keys and addresses, you are not decreasing the security of your private keys nor limiting yourself to a subset of private keys by using the latter.

[BlackHatCoiner]

If only I had a 'toshi for each chest beat of this page.

if you stop beating your chest for a slight moment.
have a cup of coffee, take a breath and read the details.

Do you read what you write? Do you actually read your sentences before you submit? It's not bad if english isn't your mother language, but I'd recommend you to translate one of your posts and try making any sense. I'll need more than just a breath and a cup of coffee for this. Also, stop insulting, we're having a discussion.

so more seed-words of 2048library-words (rounds of 11bit random) is more secure

Yes, they are. As you said, having a fifteen-words seed is the maximum security you can get acknowledging that it exceeds the 160 bits. Although, that's correct if the public key of the related address has never been exposed. The security of secp256k1 is 128 bits.

[o_e_l_e_o]

Yes, they are. As you said, having a fifteen-words seed is the maximum security you can get acknowledging that it exceeds the 160 bits.

They aren't. franky1's number of 160 bits is incorrect.

Either we are considering the security of your private keys, of your coins, of bitcoin itself, in which case 128 bits is the maximum security unless we change the protocol. Or we consider the security of only your seed phrase as an isolated concept, in which case we might as well generate a seed phrase a million words long. Obviously the latter makes no sense since it does not make your private keys or your coins any more secure if your seed phrase is 12 words or a million words (all else being equal).

[BlackHatCoiner]

They aren't. franky1's number of 160 bits is incorrect.

I guess he talks about the private keys and specifically, the RIPEMD-160 function that returns 160 bits. Why is he incorrect?

[ranochigo]

They aren't. franky1's number of 160 bits is incorrect.

Either we are considering the security of your private keys, of your coins, of bitcoin itself, in which case 128 bits is the maximum security unless we change the protocol. Or we consider the security of only your seed phrase as an isolated concept, in which case we might as well generate a seed phrase a million words long. Obviously the latter makes no sense since it does not make your private keys or your coins any more secure if your seed phrase is 12 words or a million words (all else being equal).

I'm not sure if I'm following the discussion correctly since it's getting a bit lengthy but I share the same sentiments as BlackHatCoiner.

The 128bits value is for breaking ECDSA to obtain the private key for secp256k1 curve, as defined here[1] to be 128bits. Unless we're able to get the public keys in the first place, we won't be able to have the 2^128 operations to get to the private keys. If we have no knowledge of the public keys, then we're going to the old school bruteforce for the preimage attack which 160bits of security applies since, 160 due to size of RIPEMD-160.


[1] https://www.secg.org/sec2-v2.pdf

[o_e_l_e_o]

Sure, if we are talking about brute forcing a public key from an address, then you are looking at 160 bits. Maybe I've misunderstood franky1, in which case I apologise, but I've re-read what he wrote I don't see him mention that anywhere. However, when he says this:

yes your 128bit may calculate to having more then private key for a public key. meaning you are not going to be calculating all possible 160bit public keys.

To me, that reads that he is suggesting you can generate multiple private keys per public key, and your seed phrase will not be able to generate all possible public keys, of which there are 2¹⁶⁰, none of which is correct.

[PrimeNumber7]

yet again..
my whole point was..
the HUMAN ELEMENT

someone handpicking 12 words. means their entropy of library might just be 500 words they commonly use and are personal to them..
EG many IT/Network nerds might choose words affiliated with IT/networking. and not even think to uuse words like 'voyage' / vicious

so 12 words of a library of 500 handpicked words is very bad.
(its why a few passphrase wallets got emptied)

You are describing a problem with a typical brain wallet that is created using a means that is not random. In order for a seed to have its advertised bits of entropy, the seed words need to be chosen at random from the word list.

A person creating a typical brain wallet will have a very large word list (their vocabulary), however they will often pick a phrase in a predictable way. An attacker trying to crack a typical brain wallet will not use random, but will rather use a library of common phrases or words that have the highest chances of being used.

A person trying to crack a seed on the other hand will need to use randomness in order to attempt to guess the correct seed.

[o_e_l_e_o]

In order for a seed to have its advertised bits of entropy, the seed words need to be chosen at random from the word list.

I get what you mean, but for the sake of accuracy/clarity, the words shouldn't be "chosen at random" at all. Rather, a (usually) 128 bit or 256 bit number should be randomly generated, and then 11 bit sections of this number should be encoded by the very specific word on the wordlist which represents those 11 bits.

I think part of the reason we still see brainwallets being used and people trying to come up with their own seed phrases is because they think a seed phrase is also just a computer "choosing words",  think "I can do that just as well as it can", and don't appreciate that they have the entire process back to front.

[PrimeNumber7]

In order for a seed to have its advertised bits of entropy, the seed words need to be chosen at random from the word list.

I get what you mean, but for the sake of accuracy/clarity, the words shouldn't be "chosen at random" at all. Rather, a (usually) 128 bit or 256 bit number should be randomly generated, and then 11 bit sections of this number should be encoded by the very specific word on the wordlist which represents those 11 bits.

I think part of the reason we still see brainwallets being used and people trying to come up with their own seed phrases is because they think a seed phrase is also just a computer "choosing words",  think "I can do that just as well as it can", and don't appreciate that they have the entire process back to front.

By my calculations, picking a number between 1 and 2048, 12 times (2048^12) equals ~5.4445e+39, and log2 of this number is 132. The reason for the difference in the number of bits is due to seeds have a checksum that remove some of the actual entropy.

My understanding is that brain wallets are not typically standardized, and as such, it is possible to create a branwallet that does not have a checksum that would remove bits of entropy. So if you were to one hot encode each word in a passphrase that is L words long, out of a vocabulary of V words, it would result in an array that has a dimension of [V, L], and is one of V^L possiblities.

Unless I am missing something?

[o_e_l_e_o]

This is looping back round to the points I've made above. Sure, if you pick 12 words from a BIP39 wordlist, then (ignoring the checksum) you will end up encoding a 128 bit number. However, you will not end up with 128 bits of entropy. If you pick 10 words from the entire English dictionary of ~150,000 words, then you can encode a ~172 bit number, but you do not have 172 bits of entropy.

Humans are not random and are not a source of entropy. As soon as you introduce a human element, i.e. manually picking or choosing anything, then you have lost a significant amount of entropy. A 8 character password, for example, could encode ~53 bits of entropy, but it almost never does, because literally millions of people use passwords such as "password", "iloveyou", and "princess".

[dortheamangum]

It does not make it more secure but of course it would make it difficult for the hacker.

[BlackHatCoiner]

Humans are not random and are not a source of entropy. As soon as you introduce a human element, i.e. manually picking or choosing anything, then you have lost a significant amount of entropy. A 8 character password, for example, could encode ~53 bits of entropy, but it almost never does, because literally millions of people use passwords such as "password", "iloveyou", and "princess".

Instead of saying that you lose a significant amount of entropy, shouldn't it be a significant amount of randomness? The entropy length remains the same whether you generate it randomly or pick fifty three zeros. “Losing entropy” sounds like the size of it rather than its unpredictability.

My understanding is that brain wallets are not typically standardized, and as such, it is possible to create a branwallet that does not have a checksum that would remove bits of entropy.

But, the checksum doesn't remove you bits of entropy. If you extend a 128-bits seed with 4 extra bits, you aren't reducing your security.

[BASE16]

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?

You have to specify more secure in terms of YOUR specific mnemonic/address or more secure in terms of ANY address because those are two different things.

Mnemonics exist to make your life easier by using words in stead of digits, and not to make it more secure.