Topic: Why is electrum seed have small entropy? (Read 1243 times)

Ok I have asked around a few experts and you can see the whole conversation here:

https://bitcointalksearch.org/topic/bitcoin-entropy-questions-1523431

But to sum up, here is the info:

Unspent bitcoin address -> private key =160 bit entropy + other intensive crypto operations to calculate

Spent bitcoin address (revealed pubkey)  -> private key = 128 bit entropy (naked)

Solve the ECDLP to guess priv key -> 128 bit + intensive database operations, memory, etc

---

Now this is all good and fine and seems the lowest common denominator is 128 bit. I would still like to know how this applies to electrum.

Specifically how is the electrum seed linked to this, and how much entropy is lost in the wallet generation.

Especially an answer to my Point 1) would satisfy me:

I'm not a cryptologist so I'm starting to regret posting in this thread I quoted this bit below because I thought it would answer your question about a larger size seed:


I've highlighted the relevant bit. DeathandTaxes is someone who knows what he's talking about.

So let me get it straight.

Unspent bitcoin address =160 bit entropy + lots of crypto operations  for brute forcing

Spent bitcoin address = 128 bit entropy + lots of crypto operations  for brute forcing

Maximum private key entropy = 128 bit + lots of crypto operations for brute forcing

Electrum seed (english-default 13 word) = 143 bit - entropy loss from searching +16 bit (from key stretch) = 128     (it can be customized with the electrum help make_seed command)

---

1) Ok so I read the documentation it shows that the electrum seed has only 128 bit entropy , how?
http://docs.electrum.org/en/latest/faq.html#how-secure-is-the-seed

It also says:

So does this mean that the searching for seeds actually loses 16 bit entropy which is then compensated by the 16 bit added in the key stretch? So actually the default seed has only 128 bit?  How much entropy is lost exactly in the seed generation/searching process, 16 bit?

2)

It seems to me that the bitcoin private key is the weakest link. Brute forcing a bitcoin address is one thing because it involves many operations, but what if somebody tries to calculate all private keys?

Or the fact that he still needs to calculate the address from the private key, and check the balance on the blockchain, and put all items in a spreadsheed to compare, adds too many operations, makes a private key actually as secure as an address (if not more)?

So the 128 bit private key + many operations (calculate address, comparation, spreadsheet in memory, getting balance of address)

3)

Isn't it logical to generate a 256 or 512 bit seed. For example

-In a non-deterministic wallet you have 10 addresses with 1 bitcoin each on them.Protected by 160 bit unspend address. If 1 gets compromized that is 160 bit security+ (additional operations)  broken. Results in 10% risk.

So the total wallet security is 1600 bits + crypto operations, and the minimum risk is 10%.

-In a deterministic wallet (electrum) you have 10 addresses with 1 bitcoin each on them. All protected by 128 bit seed

So total wallet security is still 128 bit , and the minimum risk is 100%, if the seed is broken all money is lost.

So it would make sense to make higher security seeds?

What 15 extra bits? NVM

There is a discussion here on this subject. Some of it refers to the old 1.9 branch. One thing that stands out:


and this too:

So you have 128 bits (+15 bits extra thats irrelevant) + key stretching  ?

Am I correct?

Dabura667 is right on the money as usual.

However if you want to make a larger seed (like 256 bits) you *can* do that. The make_seed command line option will generate larger seeds:

No.

Comparing prime factorization (actually, just guessing primes and multiplying normally lol) to Elliptic Curve multiplication (which is actually like 20 multiplications, 15 divisions, and a bajillion mods for each operation) is like comparing apples and oranges.

128 bits of security for ecc is fine. It would take me millions of lifetime-of-the-universe-thus-fars to guess 128 bits with my computer.

In comparison, 128 bit RSA encryption would be a joke if anyone used it today.

The time needed to:

1) Craft a new seed
2) Generate the master private key corresponding to that seed
3) Derive 50 private keys from the master private key
4) Derive the corresponding 50 addresses from those private keys
5) Check those 50 address for balance

is WAY higher than the time needed to "just" check whether a certain plaintext matches a hash.

In order to randomly iterate through the 128 bits space of all seeds, you need to do steps 3, 4 and 5 which are HUUUUGELY expensive, computationally wise.

Also:
https://bitcoinspakistan.com/blog/electrum-seed-explained/

PGP uses RSA where more bits are required than ECDSA to get the same security.

Isnt that worrysome? Most crypto systems already uppgrade to 2048/4096 bits and we are still stuck at 128 bit?

At least does electrum have key stretching to make brute force slower?

There is a cap to the maximum security possible on secp256k1 at n/2 of key size.

256 bit keys therefore only provide 128 bits of security.

Anything more than 128 bit for bitcoin is just "feel good" territory.

Why is electrum seed have only 143 bit entropy when most passwords are already uppgrading to 512 bit entropy?

It seems very careless to have only 143 bits when BIP_32 recommends 512 bits to private keys. Even PGP keys use like 4096 bits, so why so small when we are talking about money here?

Am I missing something?