Why you cannot enter an arbitrary seed in Electrum

[flatfly]

What are your thoughts on this: http://www.sendspace.com/file/68tgbd
You have to roll your own seed. 5 dice for each word = 60 rolls, if a roll is invalid (i.e. under certain circumstances not applicable), roll again. IMO this should lead to a truly random seed, which can't be compromised by faulty or limited random number generators implementations. It's a bit cumbersome, but for long-term storage a decent decision.

Any downsides or potential risks I don't see?

This method is well known as Diceware - http://world.std.com/~reinhold/diceware.html

Good question! How Diceware (5 words with dice, dictionary size of 7776) compares to Electrum (12 words, from a dictionary of 1600) for practical purposes; to use as your master password?

Diceware 5 words bit strength:

>>> log(7776**5,2)
64.624

Electrum 12 words bit strength:

>>> log(1626**12,2)
128.005


What this means: Diceware 5 words is no longer secure. With dictionary size 7776, use at least 7 or 8 words for critical/financial stuff.

[1713861159]

1713861159

[Abdussamad]

As you may have noticed, it is possible to bypass this protection; if you restore your wallet from a hexadecimal string, any string length will be accepted. However, this will only work with hexadecimal inputs. Thus, if you absolutely insist on using an arbitrary phrase as seed, you will need to hex-encode it yourself. Consider this as a protection.

I am not a cryptographer (what are some good sources to learn some very basic concepts? Maybe one good article for noobs), so this is a basic question: let's say I used my own passphrase and I am happy with it, my passphrase is (obviously)

the quick brown fox jumps over the lazy dog

then how do I hex-encode it to become an Electrum seed?

Here you go:

https://www.google.com.pk/search?q=letters+to+hex

and just for fun, can I also convert it for Electrum style 12 words?

Easiest way for you is to create a new wallet and use the restore function. Paste in the hex and then view the seed to get the electrum words.

edit: python is not my strong suit so I am sure this can be done in the electrum console as well. But to do it in the Linux shell you just run python, then do "import electrum", and then "electrum.mnemonic.mn_encode( '34343' )" ofcourse replacing the numbers wiht your hex.

Edit2: Yeah you can do it in the electrum console too. Just type import electrum first and then the rest.

[manicminer]

Diceware 5 words bit strength:

>>> log(7776**5,2)
64.624

Electrum 12 words bit strength:

>>> log(1626**12,2)
128.005

If you or someone could show this quotation with 'normal' mathematical signs (a picture or external link with different numbers are OK), that would be helpful.

I have found this as well: https://security.stackexchange.com/questions/36246/what-is-the-entropy-of-just-1-diceware-passphrase-like-my-passphrase

Still not clear.

What this means: Diceware 5 words is no longer secure. With dictionary size 7776, use at least 7 or 8 words for critical/financial stuff.

If we assume that a flawed(?) electronic random number generator is as random than an actual dice.

[manicminer]

Diceware 5 words bit strength:

>>> log(7776**5,2)
64.624

Electrum 12 words bit strength:

>>> log(1626**12,2)
128.005

https://www.google.com/search?q=log(1626**12%2C2)

https://www.google.com/search?q=log(7776**5%2C2)

Entering these into Google calculator give different results - doesn't help, either.

[kellrobinson]

I understand that the seed in number form is 128bits of entropy. But is the mnemonic 128 bits too? 12 words out of 1600 are 128bits of entropy? Just curious.

The randomness ("entropy") of one word, chosen at random from a list of 1600, is simply 1600, and the number of bits in 1600 is 10.644 because 2^10.644=1600.  So in a string of words chosen at random from a list of 1600, each word contributes 10.644 bits of randomness (entropy).  To get 128 bits of entropy you need 128/10.644=12 words.  1600 is a pretty short list, which is why electrum makes such long seeds.
Diceware uses a longer list of 7776 words.  Log2 (7776)=12.925;  128/12.925=9.9.  10 words in diceware would give 129 bits of entropy.
I generated a spreadsheet with about 55,000 words by collecting scrabble lists and pasting them into excel.  More entropy there.  By using random numbers to select words, I can generate a strong passphrase which is short enough that I have some chance of remembering it.  The scrabble list also has some real oddball words.  Makes for a memorable passphrase.  The extremely commonplace vocabulary words in the electrum and diceware lists generate very bland phrases that are not memorable at all, besides just being very long.
Electrum should have gone with a much bigger word list.

[btcven]

I understand that the seed in number form is 128bits of entropy. But is the mnemonic 128 bits too? 12 words out of 1600 are 128bits of entropy? Just curious.

The randomness ("entropy") of one word, chosen at random from a list of 1600, is simply 1600, and the number of bits in 1600 is 10.644 because 2^10.644=1600.  So in a string of words chosen at random from a list of 1600, each word contributes 10.644 bits of randomness (entropy).  To get 128 bits of entropy you need 128/10.644=12 words.  1600 is a pretty short list, which is why electrum makes such long seeds.
Diceware uses a longer list of 7776 words.  Log2 (7776)=12.925;  128/12.925=9.9.  10 words in diceware would give 129 bits of entropy.
I generated a spreadsheet with about 55,000 words by collecting scrabble lists and pasting them into excel.  More entropy there.  By using random numbers to select words, I can generate a strong passphrase which is short enough that I have some chance of remembering it.  The scrabble list also has some real oddball words.  Makes for a memorable passphrase.  The extremely commonplace vocabulary words in the electrum and diceware lists generate very bland phrases that are not memorable at all, besides just being very long.
Electrum should have gone with a much bigger word list.

Have you read this?

The main reason is that the encoding method used in RFC1751 collides with patent US5892470 A.
My personal opinion is of course that this patent is ridiculous and should never have been granted.
However, I did not want to take any risk, because if the site hosting the source code (github, gitorious)
receives a cease and desist letter, they will remove the project rather than hire a lawyer to defend the
case. And if someone decided to target Bitcoin software in general, this patent gives them a reason to
attack Electrum.
 
In order to circumvent that patent, I used a different encoding algorithm and a different dictionary.
Of course I could have changed only the encoding algorithm and kept the same dictionary, but that
would have been a terrible idea, because it means Electrum would have generated RFC 1751 valid
passphrases, but decodes these phrases differently. This would definitely have been considered as a bug.
 
Another reason not to use the same dictionary as in the RFC is that it contains mostly short words,
which are not good for long-term memorization. People often believe that short words are easier to
remember, because they confuse short-term and long-term memory. STM and LTM are separate functions,
that are performed in anatomically distinct parts of the brain (hippocampus and cortex, respectively).
It is true that sequences of short words are easier to store and recall in short term memory (Baddeley
et al 1975), but that does not make them good candidates for long term memory storage. In order
to store a list of words in long term memory, these words must be both familiar and salient (not too
common and with some semantic or emotional load). Another good thing that boosts memory is to
have words from different categories (eg verbs and nouns), as explained in this paper:
http://csjarchive.cogsci.rpi.edu/proceedings/2008/pdfs/p2183.pdf
 
This is why I used words from a poetry list found on Wikimedia; this list contained words that were both
familiar and salient. Starting from this list, I first removed words that I found too short or too common,
and verbs that were conjugated with different tenses. (I also removed nsfw words such as "fuck" and "shit",
although I realize I forgot a few of them). After that, I still had more words than needed, so I ran an
optimization algorithm, in order to select the subset with maximal average Hamming distance between words.
 
cheers
 
Thomas

[jonald_fyookball]

Electrum does not let you use an arbitrary sequence of words as seed. This is because humans are not good at generating really random phrases.

The seed generated by Electrum is a 128-bit random number. It is encoded as a sequence of 12 words, for the purpose of memorization. However, it is important to understand that it has 128-bits of entropy. A phrase generated by a human, or picked from a random book opened at a random page, will in general be much less random, and much more vulnerable to attacks. (and "much more" here means astronomically more).

In this type of attack, time is on the side of the attacker. It is perfectly possible for an attacker to try all the phrases existing in a large database of books, and some variants of those, until they find a wallet. In contrast, it is not possible to do the same with 2^128 random phrases.

As you may have noticed, it is possible to bypass this protection; if you restore your wallet from a hexadecimal string, any string length will be accepted. However, this will only work with hexadecimal inputs. Thus, if you absolutely insist on using an arbitrary phrase as seed, you will need to hex-encode it yourself. Consider this as a protection.

So, I've been trying this... I'm a bit confused...I chose some arbitary words , hex-encoded them , entered that hex code as the seed... and then viewed the seed, and the seed become like 45 words or 100 words even sometimes when viewed in electrum.  is this normal?  

(Even when I chose only words from the electrum passphrase dictionary, it still redid them... i chose 16 words and they become like 60 words)

[btcven]

So, I've been trying this... I'm a bit confused...I chose some arbitary words , hex-encoded them , entered that hex code as the seed... and then viewed the seed, and the seed become like 45 words or 100 words even sometimes when viewed in electrum.  is this normal?  

(Even when I chose only words from the electrum passphrase dictionary, it still redid them... i chose 16 words and they become like 60 words)

In the current version, seeds are treated in groups of 3 words. ThomasV might explain how this affect what you are trying to do. The new version of the seeds will let you use larger seeds as it will be hashed.

[jonald_fyookball]

My concern is that the 12 words might not be secure enough...

I guess as long as I can import a hex value and it gives me a seed of
words, it will work, right?

[Abdussamad]

My concern is that the 12 words might not be secure enough...

I guess as long as I can import a hex value and it gives me a seed of
words, it will work, right?

A seed generated by electrum is more secure than any hex you manually input however long the latter might be.

If you absolutely want more than 12 words then do it right. Use openssl to generate a random seed for you:

Code:

openssl rand -hex 32

Then use the restore wallet option to create a new wallet and enter the output of the above as seed.

[jonald_fyookball]

well  1600^12  < 2^128....

but i guess not by much.

[Abdussamad]

well  1600^12  < 2^128....

but i guess not by much.

1626^12

https://github.com/spesmilo/electrum/blob/master/lib/mnemonic.py

[eggdescrambler]

Hi Guys

I’m assuming the 128-bit seed could be increased to 256-bit instead. I would prefer this as it would be more secure.
What changes (code) would be required to have the Electrum wallet go from 128bit seed to 256-bit seed?


https://electrum.org/faq.html
Electrum uses a 128-bits random seed to generate your private keys. The seed can be represented as a 12-words mnemonic code. You do not need to perform regular backups, because your wallet can be recovered from the seed that you can memorize or write on paper.

Example:
hexadecimal: 431a62f1c86555d3c45e5c4d9e10c8c7
mnemonic: "constant forest adore false green weave stop guy fur freeze giggle clock"
There are 2128 possible seeds for a deterministic wallet in Electrum. For comparison, the total number of Bitcoin addresses is 2160.

Thanks

[jonald_fyookball]

Hi Guys

I’m assuming the 128-bit seed could be increased to 256-bit instead. I would prefer this as it would be more secure.
What changes (code) would be required to have the Electrum wallet go from 128bit seed to 256-bit seed?


https://electrum.org/faq.html
Electrum uses a 128-bits random seed to generate your private keys. The seed can be represented as a 12-words mnemonic code. You do not need to perform regular backups, because your wallet can be recovered from the seed that you can memorize or write on paper.

Example:
hexadecimal: 431a62f1c86555d3c45e5c4d9e10c8c7
mnemonic: "constant forest adore false green weave stop guy fur freeze giggle clock"
There are 2128 possible seeds for a deterministic wallet in Electrum. For comparison, the total number of Bitcoin addresses is 2160.

Thanks

Hi Egg,

Welcome to the forum.

I had the exact same thoughts as you're having now.

Turns out:

1. Private keys "only" have maximum 160 bits of security anyway
and sometimes 128.

2. Electrum does a 100,000 round key-stretching hash,
effectively adding another 16 bits of security.  So,
you really have 144 bits, which is plenty.

So, plenty of security and nothin to worry about.

 

JF

[eggdescrambler]

Hi JF
Thanks for the reply

Yes, but the seed should at least be a minimum of 160bit as are the Bitcoin address.
But ideally even more as you have multiple Bitcoin addresses derived from this single key.

Wouldn't it become enough profitable then for someone to keep generating seeds and looking it up against the blockchain until they find the seed of somebody else?
With bitcoin addresses, the task is quite harder since it's actually a hash of a public address (which is even larger than the 160 bit bitcoin address). Hence, the attacker has to work on all the possibilities of the private address - which is 256 bits, so even larger.
But with this seed, it's just 128 bit possibilities (2^128) (and even, divided by the number of wallets used to find one of them)

[jonald_fyookball]

Hi JF
Thanks for the reply

Yes, but the seed should at least be a minimum of 160bit as are the Bitcoin address.
But ideally even more as you have multiple Bitcoin addresses derived from this single key.

Wouldn't it become enough profitable then for someone to keep generating seeds and looking it up against the blockchain until they find the seed of somebody else?
With bitcoin addresses, the task is quite harder since it's actually a hash of a public address (which is even larger than the 160 bit bitcoin address). Hence, the attacker has to work on all the possibilities of the private address - which is 256 bits, so even larger.
But with this seed, it's just 128 bit possibilities (2^128) (and even, divided by the number of wallets used to find one of them)

No, the seed is for your wallet, which contains many addresses.  
So that's a 1-to-many relationship.  Hence, you will have
less seeds than addresses.

There are many threads here on the forum discussing the
feasibility of cracking a private key.  Bottom line,
it can't really be done.  2^128 is simply too big a number.

Although there are 2^256 possible private keys,
if you know the public key (which is possible
only if a transaction was already sent from
the corresponding address), you can use
the elliptic curve math to find the private key
in 2^128 operations.  

Otherwise, if you don't know the public key
of an address, you're struck with a brute-force
approach, hoping for a hash collision
with probability on the order of 2^160.
(Something to do with RIPEMD-160,
although i'm not yet up to speed on
exactly how that last point works.)

With electrum, the 12 word seed is
run through an iterative loop... hashing
it 100,000 times through SHA-256,
so if you want to try to brute-force
the 2^128 combinations, each try
will take 100,000 times as long.

 

[eggdescrambler]

With electrum, the 12 word seed is
run through an iterative loop... hashing
it 100,000 times through SHA-256,
so if you want to try to brute-force
the 2^128 combinations, each try
will take 100,000 times as long.

I might not have explained myself correctly.
Yes, I know the seed is for the wallet and contains multiple addresses, which was my original point.
I was talking about a brute force attack on the seed until one generates a set of addresses that the block chain shows as owning Bitcoin.

But I didn't get this earlier, a 100,000 times SHA256 of the original seed is done before addresses are taken. I see your point.
That's good.

However, if SHA256 on the original seed is done, this means the original seed could easily well be 256 bit instead of 128.
With 256 bit feed, it would be even more difficult brute force, in addition to the 100,000 times.

Thanks for the input.

[DeathAndTaxes]

However, if SHA256 on the original seed is done, this means the original seed could easily well be 256 bit instead of 128.
With 256 bit feed, it would be even more difficult brute force, in addition to the 100,000 times.

Well a hash can have any size input.  Why stop at 256 bit, why not 512 bit, or 1,024 bit, or 94832049823409238490238490324872 bits just to be super duper uper secure?

128 RANDOM bits is beyond brute force.  Electrum then engages in key stretching giving you 144 bit security.  Still I expect the author will allow infinitely sized seeds so people can engage in feel good security.

If you could perform 2^128 operations you could steal nearly half a million bitcoins right now from a handful of the top addresses right now.  Just checked and they are still there so I imagine your seed is safe.

[jonald_fyookball]

I may be wrong, but it would seem like you can just choose the option "restore a wallet from its private seed" and then add more words to your 12 word seed.
Just make sure you know what you're doing though (read this thread in full and understand entropy) 

EDIT:
Maybe not.  I tried this and can't seem to get any receiving addresses, nor can I see
the master public key.  But I think there's a way to do it (review the thread).

But its pointless.

2^128 can't be brute-forced.   Even if you could do could try
a trillion trillion key combinations a second (and you cant),
it would take 8.9 million years to try all the combinations.

 

[Abdussamad]

If eggdescrambler wants a larger seed he should have one:

- Create a 256 bit random seed and output as hex:

Code:

openssl rand -hex 32

- Create a new electrum wallet, choose the restore function and paste in the hex seed.

The only caveat is that you can't do a restore from seed for this >128bit seed wallet under electrum 2.0+. You will be able to use the wallet file softcopy. But not restore from seed. The reason being that the seed format is changing and electrum won't know which seed version you are using just from the bare seed. The wallet file, OTOH,  contains the seed version.

That's all there is to it.