Does more seed words equal better security?

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

[1714160512]

1714160512

[1714160512]

1714160512

[1714160512]

1714160512

[1714160512]

1714160512

[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