Topic: Does more seed words equal better security? (Read 1150 times)

maybe your not seeing the big picture because the numbers are so huge..
(i hate writing long numbers so ill simplify demo(dumb down) the numbers)

call 128bit.. 13bit  (8192 combination possibilities)
call 160bit.. 16bit (65536 combination possibilities)
call sha256 .. 26bit (67108864 combination possibilities)


(now that you have corrected the/your preference)
if you are going to go through all
brute(0 to26bit)->ecdsa26->ripemd16(26bit)=p2pkh(16bit)
0 to 67108864 ->  ecsda  ->ripemd(67108864) =  67108864results  of 65536(16bit combinations) (1024 collisions)

you will find your 67108864 results are actually ~65536(16bit) results listed repeatedly 1024 times
(in simple example collisions)

and then out of your list of lots of repeated collisions 67108864

you then have to compare the UTXO p2pkh to your big list to then look at the privkey to then spend it
you may think. great you have 1024 possible privkeys that can sign that same utxo
but reality is you wasted like 1000x time by bruting such a big number
..
however if everyone uses seeds of 13bit randomiser to make privkey
                                                   128bit   (12seedwords of 2048 librarywords)
you follow the complete process which everyone else follows.. meaning less brute attempts needed

because: everyones seed based private key is somewhere between0-8192(13bit) because they all using  13bit

do you get it yet? everyones seed in this demo is between 0 and 8192. and there are only 8192 resulting p2pkh that match the privkey/seed out of 65536 possible keys

and before you ask.. no.
just bruting0-8192-ecdsa-ripemd will give you 8192(skipping sha).
but you missed the sha 'scatter'.. meaning your results 8192 p2pk might have only 1 p2pkh that goes back to a range within the 13bit seed

however doing it the full way
 only need to do brute(0 to 8192)-sha->ecdsa->ripemd= 8192

and then you will have all the keys that people use seeds would ever end up using
no long lists of unused keys that are out of bounds of the rule.
no extra cycles. no end results that dont lead back to a 13bit possible seed

emphasis:
less brute cycles. less end results. but all results in range of all users range of their own key gens
thus less to sort through to compare to the utxoset too
(outside the demo in real bit number terms)
its still a huge number. meaning still a project you have to hand down to your offspring and descendants to be bruting on their colony planet in millions of years
but can be completed a few millenia sooner

No, before my quoted part, you've written what obsesses people and after that you conclude why trying all the RIPEMD-160 combinations is worthless. And I say, what does it matter if you don't generate the same public key since you'll be able to sign a valid transaction? The nodes will validate it for the given RIPEMD-160 hash.

When I quote a part of your text, it doesn't matter that I haven't read it all.

I meant he'd find it easier to do the ECDSA —> HASH160. Not just calculate the 160 bit numbers...

oh it is correct

some of the 128bit nonce (private keys) dont fill every slot of the ripemd160 result
some of the 128bit nonce (private keys) do overlap and result in colliding with another ripemd160 result
collision rate is super low, but its there

its simple math

EG nonce length 128bit in-> SHA-> results in only
                                                    340282366920938000000000000000000000000 results of
115792089237316000000000000000000000000000000000000000000000000000000000000000
possible results sha could give

128bit wont give out
115792089237316000000000000000000000000000000000000000000000000000000000000000 results

it ends up with 1 result being 0.00000000000000000000000000000000000000X% of possible results of a sha
repeated sha still result in only 340282366920938000000000000000000000000 answers.
all your doing then is just moving the results positions and gaps position in the
115792089237316000000000000000000000000000000000000000000000000000000000000000 that they appear in
but not causing more then 340282366920938000000000000000000000000 results
same with ripemd160
them 340282366920938000000000000000000000000 randomly placed results somewhere through out
115792089237316000000000000000000000000000000000000000000000000000000000000000
then become
340282366920938000000000000000000000000 answers randomly spaced out somewhere within
1461501637330900000000000000000000000000000000000 possible answers

...
running all 128bit through the sha, edcsa, ripend160 processes finds
340282366920938000000000000000000000000  p2pkh of all keys that everyone uses if they are all seed users of 128bit nonce private keys


however foolishly if you are ignoring 128bit sha ecdsa ripemd160.. and just trying to run
all 256bit nonce(p2pk) -> ripemd160 (p2pkh)
=1461501637330900000000000000000000000000000000000 results
takes longer.. and your finding lots of collisions

or just 128bit nonce -> ripemd160
=340282366920938000000000000000000000000 results (scattered)
not all ripemd160 will be found

or just 128bit nonce -> sha-> ripemd160
=340282366920938000000000000000000000000 results (scattered)
not all ripemd160 will be found


and because your only foolishly doing basically p2pk -> p2pkh (because your skipping ecdsa) you still cant spend a utxo of the same p2pkh you found because you ignored the ecdsa part

so not worth just doing nonce-> ripemd160

also answering:

having a list of
1461501637330900000000000000000000000000000000000 combinations by just doing 2¹⁶⁰
is a meaningless database.. as its associated with no edcda

heck there is no need to just list all ripemd160
block data already show the ripemd160. so you just have to convert to binary

well if you read the whole post..the rest of the message clearly talks about the public key.. (p2pk) before it gets ripemd160.. then you will see the context on the whole talks about public key yo ripemd160 which other people in this topic have been suggesting to concentrate on.. doing publickey to ripemd160 only

so dont take a part quote and try to infer it is talking about priivatekey (all processes) bitcoin addres

i cannot control which snippets you choose to snip to make it then out of context. so no i cant take care of your snipped quotes of my messages

If you've successfully found a private key, whose public key once hashed with hash160 gives you a RIPEMD-160 collision, then the signature is enough to spend the UTXO except if I misunderstood your text. You don't take care of your writings, do you?

seems some people are obsessed with the
'try every P2pk to find all 160bit p2pkh'
'no need to try all private keys. just try all randoms of hash ripemd160's'

what they are not realising is.. that having the combination that results in the ripemd160 answer thats a funded utxo.. is still not enough info to actually write a signature to spend the utxo

THUS WORTHLESS trying just ripemd160 combinations

if it were then satoshis 2009 stash would have been raided because he reveals is 'pre-ripemd160' public keys
(he used p2PK not p2PKH in 2009)

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.

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.

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.

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

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

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?

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.

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.

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:

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.

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

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

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

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

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.

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.

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

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.

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.

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