openssl passwd -1 -salt "long phrase" | sha256sum

Why use salt in this case? Just include the salt in the phrase.

Do you think we need a measure against brute force attacks? If not, sha256 should be fine, IMO.

Yes, a standard deterministic wallet generation scheme would be very useful. Are there any shortcomings of Electrum's?

Yes, I agree to "do 10000 hashes of the phrase", but only if the number is given by the standard. Make it changeagle in "expert mode", if you like. But its trivial for a computer to generate 100000 times the hash of a phrase, and stop when one of the hashes matches a known address. It would not add security, but be another thing the user has to remember.

Ente

You could've put those digits in the passphrase itself, which would increase the required iterations much more.

Good point - so perhaps the idea could just be to use something like name + bithdate + "x randomly chosen words" for the pass phrase.

exactly. And then you are at the beginning, again, where the user is responsible to create a secure passphrase, by which means he chooses. If everyone uses the same (given) scheme to generate the passphrase, it gets substantially more insecure..

Ente

Well, apparently Electrum accepts a longer seed, so it's possible to sha256sum some pass phrase and create a deterministic wallet using that (edit: I used the "restore wallet from seed" function). Is Electrum's deterministic wallet generation algorithm documented somewhere? I'm sorry if this question is redundant.

All wrong? So you say it is not possible to calculate the "strength" of a passsphrase in bits? Easy way: calculate the bits for a brute-force case, from length and keyspace. More clever way: Let the user enter a few additional infos, like "there are three real-world words in that phrase". I am not saying this is a must or necessarily worth the effort, but I don't agree "they are all wrong" at all.


Of course "I can choose my passphrase" is not enough by itself for me to trust it. But in such a case I could (and might) skim through the sourcecode. If there is nothing hinting it transfers data through the internet as well as it seems reasonable it does what it states (i.e. use the installed openssl libraries to make hashes), I am reasonably sure. If then I dont find any warnings online, find some recommendations, and use it on a live-cd, I feel safe enough to trust it with some value.

If said program creates the passphrase (or a list of words), it doesn't have to transfer any data online. If there is a backdoor which makes the combination of the words non-random, it is close to impossible to find in the sourcecode as well as close to impossible to detect in the created passphrase. I would (and did) read through sourcecode. But I will definitely not make a statistical analysis of so-called random passphrases a program generates for me.

I will not trust any program/service/page/algo if I can not reproduce the output with a different method. Easy with pywallet and the like, I verify its working as intended with online sha256- and Hex/Base56 generators. If both ways lead to the same privatekey, I use the program in a secure (offline) way to create the privatekey I finally use for funds.


Does that mean the user chooses a password and the seed is generated from this as well, or
the user chooses a password and gets an additional passphrase from the program?

Ente

indeed, Electrum accepts any seed if you chose to use the "restore from seed" function;
this method lets you bypass its 128 bits generated seed.

sorry but there's no documentation. the code is simple to read, though