Seeing output of 40 BTC when i'm trying to send 1 coin

[jonald_fyookball]

It isn't standard PBKDF2 but it is injecting entropy back into the process.  Generally I think it is a good idea to stick with standards but I dont' see anything wrong with the way it was implemented.  

But each of those 2^128 (or 2^160) "operations" would actually be 100,000 rounds of hashing if I understand correctly.

Yup that is the whole point.  Imagine you have a GPU rig (8 GPUs) which can has 1 billion passwords per second. Using a key derivation function with 100,000 iterations chops that throughput to 100K passwords per second.  Another way to look at is say for a given hardware using a single hash per password you could brute force it is 1 minute.  It would not take 100,000 minutes (or ~70 days).
 

I get it... However, bitcoin already has key stretching.  Why stretch again in electrum (unless we are simply trying increase the 12 word seed entropy from 128 bits up to 160)?

edit: actually i dont think it would increase the entropy, just add more stretching, since the seed has less entropy than a 160 bit "normal" priv key

hmmm......  lol

[Abdussamad]

It isn't standard PBKDF2..

I'd just like to add that from 2.0 they'll be using PBKDF2. It's a standard that lots of wallets will support:

https://github.com/spesmilo/electrum/blob/41f9da1559f838fd191eb936359b911635010d2a/lib/bitcoin.py#L67

https://github.com/trezor/python-mnemonic/blob/master/mnemonic/mnemonic.py#L103

[jonald_fyookball]

It isn't standard PBKDF2..

I'd just like to add that from 2.0 they'll be using PBKDF2. It's a standard that lots of wallets will support:

https://github.com/spesmilo/electrum/blob/41f9da1559f838fd191eb936359b911635010d2a/lib/bitcoin.py#L67

https://github.com/trezor/python-mnemonic/blob/master/mnemonic/mnemonic.py#L103

Really? 

How the heck is that supposed to work if I'm trying to import my seed into a new version and its hashed differently?

[Abdussamad]

Really? 

How the heck is that supposed to work if I'm trying to import my seed into a new version and its hashed differently?

It supports old seeds. See the oldwallet class.

I get it... However, bitcoin already has key stretching.  Why stretch again in electrum (unless we are simply trying increase the 12 word seed entropy from 128 bits up to 160)?

Electrum does key stretching because it allows you to enter your own seed which may be a human generated one. Because it has no way of knowing whether a seed is human generated or computer generated is stretches them all.

I am not sure what you mean by bitcoin does key stretching. If you are referring to bitcoin core software then it does key stretching for the wallet passphrase. That's all. It has nothing to do with the public blockchain or other wallets like electrum.

[jonald_fyookball]

  The Bitcoin-Core wallet does something similar to provide brute force resistance for wallet passphrase.

I was told this,...gotcha....thx for clarifying.

Ok, thanks all for information.  I'm more than satisfied that I
understand how electrum handles the keys and that it's
secure.

[DeathAndTaxes]

I get it... However, bitcoin already has key stretching. 

Bitcoin the protocol does not use key stretching.

Bitcoin-core "the client" uses key stretching to harden to the WALLET DECRYPTION PASSPHRASE against brute force attack.  Nothing more.   Electrum doesn't copy that code from bitcoin-core wallet so it isn't key stretching "again".

edit: actually i dont think it would increase the entropy, just add more stretching, since the seed has less entropy than a 160 bit "normal" priv key

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

[jonald_fyookball]

I get it... However, bitcoin already has key stretching. 

Bitcoin the protocol does not use key stretching.

Bitcoin-core "the client" uses key stretching to harden to the WALLET DECRYPTION PASSPHRASE against brute force attack.  Nothing more.   Electrum doesn't copy that code from bitcoin-core wallet so it isn't key stretching "again".

edit: actually i dont think it would increase the entropy, just add more stretching, since the seed has less entropy than a 160 bit "normal" priv key

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

I see.  So then, it would be even harder to brute force an private key from the electrum seed dictionary because of the key stretching versus trying to do it "directly".

Correct?

[DeathAndTaxes]

I get it... However, bitcoin already has key stretching. 

Bitcoin the protocol does not use key stretching.

Bitcoin-core "the client" uses key stretching to harden to the WALLET DECRYPTION PASSPHRASE against brute force attack.  Nothing more.   Electrum doesn't copy that code from bitcoin-core wallet so it isn't key stretching "again".

edit: actually i dont think it would increase the entropy, just add more stretching, since the seed has less entropy than a 160 bit "normal" priv key

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

I see.  So then, it would be even harder to brute force an private key from the electrum seed dictionary because of the key stretching versus trying to do it "directly".

Correct?

If the seed is random then it would be more difficult to brute force the seed.  If the seed is not random then it would depend on what entropy the seed has.   100K iterations is ~2^16 so the stretching adds 16 bits of key strength.  Then again if the seed is "password123" then stretching or not the resulting entropy is too low to be considered secure.

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.

Key stretching is used to provide brute force resistance to keys that otherwise would have less than 128 bit key strength.  As an example consider a passphrase which has 74 bits of entropy.  It may be possible to brute force that.  Through key hardening you can add 16 bits of key strength making it the equivalent of a 90 bit random symmetric key which today is beyond brute force for all but maybe the largest nation states.   It turns a moderately weak key int one that is nearly unbreakable.   On the other hand "password123" has 0 bits of entropy (it is on lists of know passwords) and thus even with key hardening would be quickly compromised.

[jonald_fyookball]

Very good.

Yes, I was referring to the 1626 word dictionary  , 1626^12 is slightly
more than 128 bits of entropy.

Mostly academic, as you say.

It might be conceivable that out of dumb luck, you get the first
2 words alphabetically on the list (a 1 in 2.6 million chance), and if a brute-force
attack was done starting in alphabetical order,
you would then only have a 1626^10 key strength, which is about
107 bits of entry.

We all know how people here like to argue about how fast computers
could be in the future, etc... 107 bits starts to creep down a bit (no pun intended),
so its nice to know that the key stretching puts it right back squarely into
unfeasible to brute-force territory.

And there's no need to regenerate your electrum seed simply because the
first word starts with an "A".

I think it is good to understand these things to give people confidence in Electrum.
Helps me sleep at night anyway