Bitcoin Forum

I've implemented the algorithm for brainwallets from https://www.bitaddress.org in Rust as a command line program, for learning how it works and to get more practice with Rust:

https://github.com/FrankBuss/brainwallet

I guess it could be simplified with the bitcoin crate, but I wanted to use just the basic algorithms which are common to many blockchains, like SECP256K1 and SHA256, to see how the Bitcoin addresses and keys are generated.

Should be easy to extend it to other blockchains, or could be used as a starting point for your own blockchain (which I plan to do someday).

It goes without saying that brainwallets, specially those that perform a single SHA256 hash on a user given password, are not safe at all. Collection of 18.509 found and used Brainwallets (https://bitcointalk.org/index.php?topic=4768828.0).

I don't know how Rust works but if it "throws exceptions" you should get in the habit of handling them without letting your program crash. For example the following line may throw an exception if seed_bytes value is not in range defined by secp256k1 curve. Even though this particular case is very unlikely but it is a good habit to have "error handling" in your code.

You are right, I should probably print a nice error message in case of this error. But it wouldn't crash, at least not in the way C++ crashes with segfaults or undefined behavior. unwrap creates a controlled panic, and unrolls the stack, same like an exception, and then prints the panic on the console (with call stack in debug mode, and if you set an environment variable for it).

Do you have a test case which creates this error? The BitAddress website uses the same function, but looks like it doesn't handle such errors either.

No because as I said this is highly unlikely. You are basically looking for an input (seed variable) that could produce a SHA256 hash that is between N and 2²⁵⁶ and that range is very small in comparison to 1 to N range. We don't know any message that produces such a hash.

What you could do for this test is to split the "create_key_pair" method into two parts, one computes the hash and the other creates the key pair. Now you can feed any hash result you want to the second method like 2²⁵⁶ and see how it fails.

I fixed it  ;D
https://github.com/FrankBuss/brainwallet/blob/325baaa769902ce19b52891db38f8c4736356f43/src/main.rs#L23-L38

Well I don't know if I could agree with that.It all depends on the passphrase. If the passhprase has enough entropy then it is just as secure as a bitcoin address you would generate by throwing dice.

 But just for the sake of argument, to your way of thinking, how many hashes would make it become "safe"?

Only a 128 bit entropy entered into a cryptography function can provide the same security as a randomly generated private key. Human beings are terrible at memorizing things in general and they are even worse when the length of what they have to memorize is too long.
In other words the whole idea for a brainwallet is moot if you are using such a big entropy.

There is no easy answer to this. But for your information we are currently computing 165 exa double_SHA256 hashes in bitcoin mining. That is:

yeah  warpwallet is a pretty serious attempt to make a real strong brainwallet. uses 2^18 iterations. takes a ton of time on my little computer.

as for the OP's implementation as he mentioned he just uses a single sha256 of the passphrase. unless someone has a seriously hard to guess password you can't really expect it to not be hacked. i guess you could always salt the passphrase with your email address manually so they would have to "target you individually" then if they didn't know you yourself were using a brainwallet well, they wouldn't be able to do anything!

---

Assuming that is per second that's still a piss in the ocean. So I dont think brainwallets are under any serious threat.

[moderator's note: consecutive posts merged]

In what world 165 quintillion hashes per second is considered "piss in the ocean"?

Tell that to the million+ dollar worth of bitcoin that was stolen in total from brainwallets.

Well, it is only 0.00000000000000000000000000000000000000000000000000000014% of all possible SHA26 hashes (assuming a bijective mapping, so probably a bit higher, if there are collisions).

True, but in the context of a brainwallet we aren't talking about a 256-bit entropy. We are talking about user provided passwords and in this context even a big 8 character passphrase consisting of random alphanumerical characters (eg. _Cf}u$b0) needs computing 6 quadrillion hashes (0.006 quintillion) in total, the "165 quintillion hashes per second" rate is huge.

I do see what you're saying and it caused me to reconsider exactly what is a brainwallet. At first I didn't think it would be something someone has to "remember". But you are taking that to be a requirement.

What if I or someone else came up with some super-secretive procedure for taking a phrase and turned it into a 256-bit private key. Since the method is not published and only exists in their head, although they would have certainly tested it on a computer at some point, as long as they remember the procedure and the passphrase, I don't see how someone woudl be able to crack that. And the phrases could be very simple and yet since no one has the secret method, they don't even know where to start even if they know the phrase itself. yes the sample space has lower entropy but the problem is that you can't just check all 8 character passphrases because you don't even know the algorithm for converting them into a private key.

All I can say to that is people who are not a cryptography expert should never try to invent their own cryptography algorithms. Not to mention that you still can't solve the other more important issue with brainwallets which is the issue with forgetting things over the long term.

So maybe a particular method of generating a private key has 30 (for example) bits of entropy, but the fact that an adversary does not know the first step in creating the private key, it would appear the private key actually has 120 bits of entropy.

For example, someone might call numpy.random.choice([0, 1], size=90), but only after calling numpy.random.seed(420), and prior to doing something that creates 30 bits of actual entropy. The private key would probably remain "private" for a long time, but once an adversary figures out the procedure, any private key created via the above procedure would be quickly learned by adversaries.

Maybe no one thinks to try the above procedure for a long time, but one day, someone learns that the above person has a lot of coin, their favorite number is 420, and they like to generate their private keys via non-standard methods. This might lead someone to try to generate private keys via psudo-random methods in various ways using '420' as the seed up to a certain level of entropy that can be easily cracked.

Well I'm not sure what qualifies someone as a "cryptography expert" but I think we all use things that may have flaws. For example, BIP-32. Could 2 different starting seeds have some overlap in derived keys? If so, is that something the designer felt an acceptable occurrence? Or did they even think about that issue at all?

But you're right that the limitation of brainwallets is the human memory, but even so...



What I'm thinking is if I designed some super secret but easy for me to remember branwallet algorithm, it wouldn't even help you to know my starting brainwallet passphrase simply because the main source of entropy is the algorithm itself. And you could spend an eternity going through those before you hit on the correct one.

some people might argue that it's impossible to degisn such an algorithm thats easy to remember. for me, it's the opposite way. i could remember an algorithm but i would have more trouble memorizing a 30 character phrase that had 120 bits of entropy. because a human doesn't have the capability to truly generate such a thing i dont think. unless they roll dice but then that would make it impossible to memorize...


Maybe but trying to memorize a 30 character phrase may not be easy either. for me, algorithms are easier to remember than long strings. ;D

Right, and in cryptography, it is always assumed that the algorithm is known. For example some malware could find the source code, if it is not developed on an offline computer with no storage, which is not how software these days is developed.

But the standard SH256 brainwallets are very safe, if the password is safe. And I don't see a problem with forgetting it. Just write it down on paper and deposit it at a safe place. There are many ways to disguise it as well, like use the first sentence in a diary. If it is personal and not found somewhere else, it would be very safe. Like "This is the diary of the very knowledgeable programmer Frank, born on x, in the city y.". No way this could be discovered with a brute-force program. It would be much more safe than a random 30 character password.

But, the problem is that you can't know how safe it is and most of the times, it isn't same like a seed phrase. When you pick a password, your money are vulnerable to the entropy that you, as a human, think it's unpredictable enough.

So why not just let your computer pick a random number, instead of you, which is a proven fact you can't, represented in twelve words? I mean, you can't really find much passwords which are both so strong and short as a twelve-words phrase.

In my example, most of the entropy is from the pseudo-randomness, and very little from the "brain wallet" portion of generating the key.

Does calling a pseudo-random function while using a particular seed really create 90 bits of entropy? It does create a set of numbers that would take 2^90 guesses in order to be guaranteed to guess that particular set of numbers. If you know that the random function of numpy is being used, the amount of entropy is reduced to ~8.75 bits.

The problem with "inventing" an algorithm with the purpose of generating a private key is that it is difficult to measure how much entropy (security) your private key really has. If you can think of an algorithm, there is no reason why someone else couldn't think of a similar algorithm.

Although my recommendation is to create a seed that has 256 bits of entropy, if you insist on creating a brain wallet with low amounts of entropy, I would suggest using an algorithm that is computationally inefficient. If it is difficult to calculate the private key from the 'brain wallet' phrase, then each bit of entropy is "worth" more. Obviously, this assumes that new technology will not be invented that can go from 'brain wallet' phrase to private key more efficiently in the future.

My understanding is that most scripts/programs that try to find/steal brain wallets are not doing what most would describe as "brute forcing". I believe they will look at literature to find phrases, and use those phrases against bitcoin addresses that are known to have ever received any transactions. They likely also append things such as birthdays, popular vacation locations, and various punctuation to these phrases. This is somewhat similar to trying 'password1' when someone's known password is 'password!'

There are around 171k words in the English dictionary, and randomly using 7 words as a brain wallet would generate about 121 bits of entropy. The risk of using your method is that if anyone has ever said the phrase you use in a book, movie or TV show, (or something similar), or has ever appeared in a news article, blog post or forum post, there is a high probability that someone will try your phrase against bitcoin addresses that have ever received coin. If your brain wallet is not generated randomly, it will not have anywhere near the amount of entropy you think it has.

Not always. Not with my brainwallet idea. The algorithm needs to be something I keep in my head only. And that's easily doable.


maybe it's just me but i wouldn't feel secure using a setup like that. people know how to go about hacking it. it's trully just a matter of time before they get around to trying that particular phrase you mentioned. and then your mone is gone by bye. ;D as well to be anal, brainwallets should only be stored in the brain not on any paper anywhere. bank employees have keys to deposit boxes robbers dont need them.

That's not a flaw. Such a collision in cryptography exists in all algorithms and it is only considered a flaw if one could spend reasonable amount of computing power and find such collision in reasonable time. Otherwise when it would take something like millions of years we consider it safe.

ok then I'll rename it as an "imperfection" if that satisfies you. an imperfection is anything less than perfection. having collissions means it is not perfect.

now having gotten that out of the way, i don't think just saying something will take millions of years is fully satisfying in the sense that did the people that developed this standard even stop to consider what the actual probabilities for such a thing were and where is their analysis. i doubt it exists. ;D i'd love to see it though.

---

Well, i think the chances of someone writing down a random private key that matched my private key would be higher than them being able to design an algorithm that generated my private key given some input. Much higher.


Not necessarily. There's no reason to think that is the case in general.


That certainly is one possible feature such an algorithm could have.


yeah that's not an issue when the algorithm being used to "go from 'brain wallet' phrase to private key" is not known.
they will have to find some other way to crack the bitcoin address. and that's something that all bitcoin addresses would be susceptible to no matter how they were created.

[moderator's note: consecutive posts merged]

All hash functions have collisions. If there would be no collisions, then it would be called "compression".

In that case you will never reach "fully satisfying" things. Even Bitcoin mining works because finding low hashes is difficult and the fastest known way is checking every single combination. Bitcoin works because overwriting the chain would take a lot of computing power. Also it works because finding any collision will take millions of years if you use existing algorithms to do that.

It is not. In base 10, the number 2^256 is 77 digits long. It is well documented that the average person can memorize 7 pieces of information at once. You are not going to be able to reasonably memorize a function that is one out of 2^256 possibilities.

People tend to have a bias towards their own experiences. If a function is something you thought of on your own, it is probably not random. If the function is partially the output of a random generator (for example if at one point you multiply your starting number by 5, and "5" is the output of a random generator), your function will be more difficult to memorize.

I was referring to the algorithm that you may invent that would be computationally expensive.

IMO, the only excuse for having a low entropy input to generate a private key is that it is expensive to go from input to private key.

I do agree that computational expense is an extra thing to throw in but it's not everything. I don't even find it necessary, as what is expensive today might not be expensive tomorrow so we can't just pin all our hopes on that one thing. With that said, I would be more than confident that no one could ever come up with the algorithm I have in mind. Their chances of brute forcing the bitcoin address would be just as good if not higher. And easier. As I have already pointed out. You have a bitcoin address. You might have a probable brainwallet passphrase. You don't know anything about the brainwallet algorithm. You are stuck.
 ;D

Maybe sometime I'll actually deposit some funds onto a brainwallet address. Just to prove my point. And let you know the passphrase. Not that anyone would actually want to waste their time trying to get the money because it would be just like brute forcing a bitcoin private key no simpler than that.

My end of the bargain will be that I have to have the entire brainwallet algorithm memorized in my head and there can be no program that I use to ever redeem the money. When I wish to redeem the money since no one is ever going to crack it, I have to do a cleanroom implementation of the algorithm from scratch all over again. All from my head. How's that sound?

You are denying how cryptography has always worked, from its inception thousands of years ago until today. Every cryptography algorithm that has ever been invented has had some sort of expiration date before which it couldn't be broken (the cost were too high) and after that date it was broken.
For example substitution ciphers were a popular encryption algorithm in first century, today they are a joke. The first book on "breaking" cryptography is from the year 800 by an Arabic linguist of Persian descent.

tell me something i don't already know. i'm not talking about published algorithms. mine would never see the light of day and you would never imagine what it is.  ;D as i already said, even if i told you the brainwallet passphrase and the related bitcoin address, it would do you no good at all. you don't seem to get that but it's ok...

I think you are referring to something different than what larry_vw_1955 and I were discussing.

It is very easy to get from a string (or a file) to the SHA256 hash of said string (or file). Very little computational effort is required. I was referring to an algorithm that takes a relatively long time to get from the string to the ALGORITHM hash of that string.

It is currently not possible to calculate a string based on the SHA256 hash -- the only way to know that the SHA256 hash
C67F9F258F01BEC38DB1E0ACC35CBD33675774153B1460BDB414A2252E50E9EE
is the hash of the following string:
is by going from the above string to SHA256 hash, you cannot go the other direction. I believe this is what you were referring to.

In the future, it is possible that someone will "break" SHA256 hashing algorithm, and whatever algorithm larry_vw_1955 is thinking of. Then again, secp256k1 curve cryptography could also be broken in the future.

Short of "breaking bitcoin itself" as you describe above, that's really the only feasible way someone would have a chance since the chances of them coming up with my secret algorithm they wouldn't even know where to start and a computer wouldn't either. It's not that I'm some super genius that has some talent for designing secret algorithms either. But it is fun  ;D

I came up with one quick one the other day passphrase is satoshi. Address is here: https://live.blockcypher.com/btc/address/1BGuYNzNsxDxAEn9roDrVa1Z9aqr3ENZU2/

Thing is I kind of almost forgot the steps but i did record them but I'm trying to see if I can remember them without having to remind myself. i wasn't doing it seriously though. it was just a quick test to see what a possible secret algorithm could look like

I simplified the code, see the github repository. No extra functions and no macro needed anymore for the Sha256 and Ripemd160 hash, 20 lines shorter and easier to read now.

I think Rust is a good choice for writing blockchain related code. Typesafe and fast like C++, but the Rust compiler is much better. Together with the borrowing memory concept it is really hard to write code which crashes, or has memory leaks or undefined behavior at runtime, which is no problem at all with C++. And there are over 70,000 Rust crates (what other languages call modules or libraries) available for nearly everything you can imagine, usable with one line in the cargo.toml file with the nice "cargo" build system.

What do you think about how it compares with Python for blockchain related things? I find python to be a real confusing thing when it comes to bitcoin simply because you have old packages and then newer packages that presumably do the same things in some cases. Then you have vitalik's circa 2013 that has over 800 forks how do you know which fork to use or trust? Its a real crapshow. The even worse thing is that his package and its derivatives are not really fully featured. They only do a limited set of things and I'm not even sure they do it really well. the code seems kind of hacked together and not very well commented at all but anyhow...

It would be nice to have some type of quality control process to the package management system where the only packages that could make it into the repository were verified and vetted for not only functionality but full functionality and correctness and professionally written not cobbled together. And don't include 2 packages whose functions overlap.

Python is nice, and the programs are shorter and easier to read than the same in Rust. But right, package management is not as nice as with the Rust cargo build system.

Package quality is always a problem. For Rust I use the crates.io site and sort for number of downloads. Usually the more popular a library is, the better the quality and maintained it is. For example for the secp256k1 algorithm this is the search result:
https://crates.io/search?q=secp256k1&sort=downloads
The first library is just a wrapper around a C library, which I want to avoid, to avoid build problems on Windows. Second crate is really big, with lots of different signatures, but i wanted just secp256k1. So 3rd result looked good and I checked the documentation, github, test cases etc., and then I used it for my project (btw, all the 0.x.y packages don't mean beta quality in Rust, it is just a convention that the interface might change until the first 1.0.0 version).

But for larger applications, the lack of static typing in Python can be problem (which is the reason why they introduced type annotations in Python 3.9), and it is much slower and needs more memory, so you don't really want to process gigabytes of blockchain data with it, or use it for a high traffic network node. But I think for such tools like the brainwallet, Python is better than Rust, and I use it often for such tasks. A Python REPL (Python in interactive mode) is also one of the best hand calculator replacements ;D and very useful with Jupyter for interactive data manipulation and visualization.

That is not a python specific problem.

This can't happen because it would limit development and discourage any new developers from creating any new packages. It's true that there are sometimes more than one package doing the same thing but most of the times they are different in some ways, for example one could perform better, have some additional functionality, or better API, etc.
In the end, the choice is up to the developer using those packages. They have to do some research into the respective repository and see how mature the project is before using the package.

yes it is. python is a very good example of how that whole thing can really get out of hand. i doubt other software programming languages have this issue to that degree whatsoever other than Rust of course since the OP mentioned it kind of has that issue  :o
 
clearly there is a need for centralization to some degree. i mean if bitcoin core just let anyone put their code into it without serious peer review and evaluation of whether it was really necessary do you think there would be a bitcoin?

no it's not that at all. vitalik's bitcoin package was forked over 800 times. do we know what the difference is between them all? and do we even know which one we're running when we install bitcoin on python?  ???


well, and that's the part of the problem. using one metric to get a handle on another metric. maturity doesn't equal no bugs necessarily. they need some better way to guarantee people the packages run correctly such as certification process that they give to particular packages. one for each type. one for bitcoin for example. then if someone wanted to change that package, it would have to go through a peer review process like linux kernel.

Your post remind me of this discussion, [meta] Rust in Bitcoin reference implementation (https://bitcointalk.org/index.php?topic=5192509.0).


You should try installing software which use NodeJS/npm ::)

no thanks.

i remember doing that once with a particular company's tool that let you get your private keys to your wallet. Just to install a piece of software that did that simple task took a huge amount of time and storage space because it created a huge number of directories I think thousands. I don't understand that at all but it can't be a good thing. I don't know why a company would ever want to use that method of software packaging because I certainly won't be using their products now or in the future.

Maybe NodeJS programs have so many files, because JavaScript programmers like to use a lot of packages, even for one-liners:
https://dev.to/jyotishman/10-useless-npm-package-with-millions-of-downloads-de9
To be fair, the upper-case package can do a lot more, like converting to and from camelCase etc. But is-odd and is-even really doesn't make sense. I mean just import is-odd, and do a negation on the result to get is-even for free, as the source code of the is-even package demonstrates ;D

C#: https://www.nuget.org/packages?q=bitcoin
2nd result is an RPC wrapper, it is not even a bitcoin library despite the name. It is also abandoned and hasn't been updated for 3 years.
3rd result is an ancient low quality library last updated 7 years ago.
...
There are a lot of other results that aren't even bitcoin libraries, they are for altcoins but since the dev added the bitcoin tag (for some unknown reason!) the search brings it up.

There are 515 packages out of which only about 10 is worth looking into.

There is a huge difference between inserting code into someone else's existing project and letting people create new projects and publish them! My previous comment was about the later.

The package is not forked, the code on github is. And those forks don't release a package unless they have actually changed something or updated this abandoned project.

If you are looking for no-bugs, you are out of luck because you will never find any code that has no bugs ever. The bigger they are the more bugs they have and no amount of license can solve it.

ok maybe you proved your point although with python 1019 packages come up. so that's almost twice as bad.


but still i think the argument could be made that "bitcoin" belongs in the standard library of python in the core


if you go to https://github.com/vbuterin/pybitcointools you can see that master branch contains nothing. so i'm not sure where python is getting this "bitcoin 1.1.42" package from and how they are coming up with that particular version number. and even if you say they are getting it from such and such a place, you don't really have a way of verifying it short of comparing the files line by line visually. to see if they really are the same or not. that seems kind of inefficient but whatever. ;D


we can't be having software that generates the wrong bitcoin address. that could cost someone their lifetime savings.

I don't use (try not to rely on) software that has that problem. In general. If it needs to be that complicated then to me that means whoever programmed it doesn't know what they are doing. How could they if they are letting something else do all the work for them and they are just slapping something together?...

Yeah, I've played around with javascript bitcoin tools here and there but I'm not a big fan of them. To me, running programs in a web browser for doing things like creating bitcoin addresses I don't trust web browsers. They connect to the internet. Which is a bad thing when it comes to keeping things secret. :D



it might mean that. it all depends on the quality of the ruby and C# packages. if there are some good ones then it could mean that.