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

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.

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

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

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

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

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

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.

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.

Core does not use seed phrases at all.

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.

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.

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.

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

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

Bitcoin private keys have a strength of 128 bits.

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

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.

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.

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.

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.

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

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.

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.


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.

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

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.

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.

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/

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/

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.

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.

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.

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.

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.

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.

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: