Why is electrum seed have small entropy?

[RealBitcoin]

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?

[dabura667]

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.

[RealBitcoin]

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.

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?

[belcher]

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

[racezefi]

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/

[dabura667]

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.

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?

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.

[Abdussamad]

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:

Code:

electrum help make_seed

[RealBitcoin]

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:

Code:

electrum help make_seed

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

Am I correct?

[Abdussamad]

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:

Code:

electrum help make_seed

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

Am I correct?

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:

Private keys only have 128 bit key strength.  Not 160 bit and not 256 bit.

and this too:

In either case brute forcing the seed would allow you to gain access to all the private keys, where as brute forcing a single private key only gives you access to that key.  It is generally speaking academic if the seed has sufficient entropy because keys with 128 bit key strength are considered beyond brute force anyways.

[RealBitcoin]

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:

Private keys only have 128 bit key strength.  Not 160 bit and not 256 bit.

and this too:

In either case brute forcing the seed would allow you to gain access to all the private keys, where as brute forcing a single private key only gives you access to that key.  It is generally speaking academic if the seed has sufficient entropy because keys with 128 bit key strength are considered beyond brute force anyways.

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:

The seed generation requires to find a seed that has a legal version prefix. That constraint results in a loss of entropy. This loss is compensated by adding extra bits of entropy during the seed generation.

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?

[Abdussamad]

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:

In either case brute forcing the seed would allow you to gain access to all the private keys, where as brute forcing a single private key only gives you access to that key.  It is generally speaking academic if the seed has sufficient entropy because keys with 128 bit key strength are considered beyond brute force anyways.

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

[RealBitcoin]

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:

In either case brute forcing the seed would allow you to gain access to all the private keys, where as brute forcing a single private key only gives you access to that key.  It is generally speaking academic if the seed has sufficient entropy because keys with 128 bit key strength are considered beyond brute force anyways.

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

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

https://bitcointalk.org/index.php?topic=1523431.0

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:

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:

The seed generation requires to find a seed that has a legal version prefix. That constraint results in a loss of entropy. This loss is compensated by adding extra bits of entropy during the seed generation.

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?