Why would anyone trust something that can spawn all of your private keys ever out of nowhere? Im still using the old wallet.dat format because im paranoid of the HD format of the new wallet.dat, imagine if I had to trust any of these brainwallets. Why expect your seed isn't going to eventually get bruteforced?

I personally feel safer by holding private keys locally which could never be accessed unless you actually had access to the files and you could always host your file somewhere in an encrypted SHA512 file with a strong password or something, if you really needed to for example move somewhere without carrying your private keys physically.

I just don't like the idea of "you need a couple of data here and there to derive all of you private keys", doesn't sound like a strong model to trust.

curiosity81, it seems (at a glance) that you are deploying a word generator generated from a decent (i.e. non-human) source of randomness. Not a syntactically valid phrase, not something the user comes up with, not something from a book you cross your fingers and hope to be really obscure. Not what most people call a “brainwallet”.

True. That's why I mentioned above that "brainwallet" might be the wrong term.

I have to stress again, that I wanted simple code for generating key pairs from strings, either from a concatenated complex list of words (kind of brainwallet) or a complex set of characters (kind of passphrase). And I want to understand the code. A kind of finger exercise. And maybe some of the code is simple enough to be useful for others.

For instance, to derive the public key of a private key is the only piece of code, which is not a bash script. I found this code somewhere at stackoverflow (the link is given in the source). It is c, but relatively easy to compile. If I remember correctly only libssl-dev is necessary for compilation. This is the only simple (!) piece of code I found! Another example is the bash script for computing base58. The code you can find online uses a lot of bash magic, so that it is virtually impossible for a normal guy to understand. At least I learned what bc is. So it was easier to write the code by myself with the benefit, that I now know how it works.

Quote

That raises an obvious question, which I must ask out of—curiosity: Why don’t you simply use BIP 39? It was developed by the same experts whose security acumen you trust when you use Bitcoin anyway. Its wordlists were developed with human use in mind, e.g., all words on the English wordlist are unique within the first four characters. And it will perfectly encode 128–256 bits of randomness in 12–24 words, without any of the pitfalls of trying to develop your own word randomization scheme.

With your wordlist, I presume not tuned to a power of 2, did you avoid the common mistake of introducing modulo bias? (I did not review your code.) Does your wordlist exclude similar, confusable words? (I am guessing not.) Etc.

Honestly, I did not take care of the random generator's entropy yet. But I can assure you, that I am paranoid enough to invest (and already invested) a lot of energy to get the maximum entropy into my systems. In the current version, one bash script simply shuffles (shuf) a complete aspell dictionary and takes the head (the n first words) of the output. That's it. Clearly I have to figure out in detail how shuf works and where it gets its entropy. Entropy pool could be filled with additional entropy via randomsound or similar. But how to connect shuf to /dev/random or /dev/urandom is a question for the future. And should be as simple as possible.

I did not wrote my own BIP39 generator, even though I am aware of the proposal. Maybe I even stole some ideas (checksum). Maybe I used them wrongly.

You'll likely have to use a combination of different hashes in varying rounds (eg., 10x Sha256 => 2x Scrypt => Bcrypt => etc) requiring an attacker to reproduce your exact hashing steps. Let's not forget that anyone who is scanning for brainwallets has a lot of time to do so and thus can account for multiple hashing rounds as well.

Question being, whether a simple obfuscation algorithm that can be done in your head or with a piece of paper is sufficient, as opposed to a computer-supported one. Unless you can mentally sha256

Given the amount of possible simple obfuscation algorithms I guess one can achieve sufficient security without computer support, assuming you don't rely on any well known methods (rot13 anyone?). In other words, this could be a use case where rolling your own "crypto" and security by obscurity might be a good thing.

Using the word “algorithm” loosely, if you can’t design an algorithm which remains secure when your adversary knows it, then you will certainly be unable to design an algorithm which is secure when “unknown”.

Note the subtle difference from what you usually hear.

Maybe I misunderstand you, but the obfuscation algorithm itself doesn't need to be secure. After all the attacker doesn't want to derive the original message from your obfuscated passphrase. That's were "security by obscurity" would fail.

Instead, my rationale is based on the potential attacker having two choices:

b) Brute force your original passphrase AND the correct steps with which you obfuscated it -- the latter of which there are effectively infinite possibilities, even when limiting yourself to pen-and-paper algorithms (eg. uppercase every nth letter, insert a special character according to the fibonacci sequence, apply multiple rounds of rot26... etc etc).

Combine a strong passphrase with some layered weird-ass obfuscation steps and you should get yourself enough entropy for decades to come.

On the other hand I just stumbled upon a fairly recent Def Con talk about cracking brainwallets, maybe it makes me rethink my assumptions.