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?

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

Diceware 5 words bit strength:

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

Electrum 12 words bit strength:

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

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.

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

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)

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?

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

but i guess not by much.

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

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.