Topic: Randomly Generated Private Key Outside of a Computer Environment (Read 527 times)

All in "Security" must be reasonable.

Offcourse, you can do almost all "by hand".
1. Do all calculation,
2. learn bitcoin protocol,
3. gather nodes/pools addresses,
4. open socket and manually send packet.
and spend week on each transaction (in best case)

But all your activity is useless... if you careless in other parts i.e. use insecure WiFi or got keyloggers, viruses, trojans or know nothing about MitM and so on.

Thanks bitmover! As for "Mastering Bitcoin", it's a great book. I'm sure you will enjoy reading it.

Amazing post!

I just bought this book, I didn't read it yet!!

Congratulations for the first place in Joe's Contest!

Binary hash, integer, and script representations, no text at all.


You are correct. Creating the transaction itself is trivially easy. It is the signature that will require extensive amounts of time and effort performing tedious maths.

Very interesting, thanks for sharing. The broadcasting part does not really pose any security problem. So it looks that for someone obsessed with security, who also doesn't mind the ultra hard work, there's is not only a complete off-line solution, but a complete solution outside of a computer environment as well. 

It's definitely possible to do it all by hand (except for maybe broadcasting it to the network).

According to this blog post it would take about 36 hours to do a SHA256 hash on paper. To work out your address from your public key, you need to do three SHA256 hashes and one RIPEMD160 hash, so you'd need a lot of free time on your hands .

Sure, that's clear. I never really intended to go beyond generating a private key by hand. But, it turned out to be an interesting discussion in that direction. Even the fact that it is possible to generate a public key outside of a computer is astonishing.

Now, as you said, if someone wanted to write the transaction by hand, it should also be possible, right? After all the transaction is just a plain txt file, isn't it. The hard work should, again, be signing the transaction. This, I guess, should also be possible!?

Even if you could generate and validate the private and the public key, remember that when you need to spend the received money, you will need to write the transaction with the inputs and outputs (and a lot of other things) by hand, and after this work, you will need to sign the transaction with your generated private key .

Fair enough.

I was thinking of it from a security standpoint, since IMO that would be the biggest reason for doing this. If you're just trying to see if you can do it or trying to learn from it then of course can do it by hand.


My 8-digit dollar store calculator can't do it but you could download a website or write a script to do it for you.

It's 4157513175418406505095030749428713867857651007422147613981302932987032615483476 89492221125050088040198962834063073502886491626063421408756279404566647840 according to http://www.javascripter.net/math/calculators/100digitbigintcalculator.htm and the calculator on my Linux machine says it's 4.157513175×10¹⁵², so I'm assuming it's accurate. If the system you're calculating it on is air-gapped then strictly from a security standpoint, doing it by hand isn't needed.

I understand wanting to do it by hand though. Who can say they generated their bitcoin address by hand? That's bragging rights right there.

The reason for not using a computer isn't important here.  If someone doesn't want to use a computer, then they don't want to use a computer.

Once it is established that we are not going to use a computer, then we need to answer the questions:
"Can it be done without a computer?"
and
"What are the risks if I don't use a computer?"

I don't own a calculator that will perform the following accurately, do you?
55066263022277343669578718895168534326250603453777594175500187360389116729240 X 7550018736038911672924053432625060345377759415506626302227734366957871889516

Additionally, if I do use a calculator (or even a computer), I still run the risk of making an error keying in the numbers.

Now you have introduced Base6 type numbers. I have to admit, I didn't even know they existed. But now, they seem ideal to be used together with a dice!

Sure one would be crazy to use that private key. It is strange, though, how the rear portion of the resulting Hexadecimal private key is all 3's, while the front part does seem random? 

That was my thought. I know I've generated random addresses with dice in the past, but I just converted the 99 b6 digits on Bitaddress.org (offline of course). I rolled 5 dice 20x then removed the last number that I rolled. I'm wondering if I created any sort of bias when I rolled them, because I would just roll the 5 dice and record them from left to right each time. Maybe it would be better to have different coloured dice to avoid a bias.

In terms of converting b6 to a public key to an address, idk. That's just like using a calculator to calculate 24950338395935935803258 x 45984839059838383339923. I could do it on paper, but why would I? It's not any less secure if you're using a program on an air-gapped system to do the conversion for you (or in that case, just a calculator of course).

---

Just for fun, I converted 1111111111111111111111111111111111111111111111111111111111111111111111111111111 11111111111111111111 to a bitcoin address. I'd try to use something a little more complicated if I were you

It will take me some time to digest it, but it looks like a great article that I can actually understand without getting into too much math! Thanks for sharing.

The maths is pretty straight forward.  You are just performing point multiplication with an elliptic curve.  There are shortcuts that can reduce the effort as well.  However, you are working with rather big numbers, so performing steps such as addition, subtraction, multiplication, or division with pencil and paper will quickly become very tedious.

For an introduction to the concepts, I'd start here:
https://arstechnica.com/information-technology/2013/10/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/

(page 2 has the important parts)

Yes, it makes sense. If one is going to do this with 4 coins, which saves time, the coins should be uniquely identifiable.


I see now, but then again, if this is only a personal bias, will this pose a danger? I mean, every person will have their own entropy sub-space, so a possible attacker wouldn't be able to guess it in advance.


I never really thought of calculating your private keys (without a computer) as a possibility, but now I'm curious. Do you know if there is an analytic function one should solve, or everything is done numerically?

You'll need to make sure that you aren't introducing a bias when you select which order to record the 4 coins.  It would be best to use 4 uniquely identifiable coins (for example: quarter, dime, nickel, and penny) and always record the exact same coin first, second, third, and fourth.


There are 2 concerns that come to mind right away.

1. Muscle memory and habit result in you flipping the coins in nearly the same way every time. As a result, the coin flips are biased to land on one side more frequently than the other.

2. The physical environment itself is biased. For example, perhaps a coin geometry or mass distribution is such that the coin is slightly more likely to land on one face vs. the other.


Technically, I think it might be possible to calculate a public key from a private key without a computer.  However, it would be VERY time consuming, VERY tedious, AND if you made just a single tiny mistake in a step, then you would end up with entirely the wrong public key.  In that case, any bitcoins sent to that address would likely be permanently lost.

With some additional time consuming and tedious maths, you might be able to verify that the public key was calculated correctly.  You'd still risk errors though when calculating your address from your public key.

It seems to be much easier to do this with 4 coins, that's for sure. I don't know about the entropy concern, though.


It could be that tossing 4 coins further decreases the entropy with respect to tossing just 1 coin, I don't know. Anyhow, why would flipping a coin give poor entropy vs a computer?? Is it that people somehow do that in a predictable way, for example, the coin always rotates several times at the most?



Thanks for the links, very helpful.

I think when you flip the coin, the entropy generated by this action is so poor if you compare with the entropy generated by computer...
But if you really dont trust in machines, you can use this github.com/taelfrinn/Bip39-diceware and generate a 12 words seed with a dice and a coin  that can be used to generate addresses derived direct from there.

Use 4 coins and flip it 64 times and write down hex values. Much easier and it will still be random.   .... but converting that private key to a public key needs a computer, which means entering your private key into a program.

Here is a python utility for the converting from hex to WIF and extracting addresses : https://github.com/neocogent/misc/tree/master/bkkcoins/keyfmt

Demo : https://steemit.com/bitcoin/@blocklab/flip-a-coin-256-times-to-create-a-bitcoin-private-key

Hope this helped you. ^hmmmm^

I was thinking about NOT using any form of machine generated private key for my wallet.

Not that I doubt the randomness of computer generated keys. There is plenty of debate already on this forum that I have been able to find.

Simply, let's say that I wanted to do this outside of any computer environment, the old fashioned way.

This was something I picked up in Andreas Antonopoulos's book "Mastering Bitcoin". Without too much detail, he mentions the possibility of creating a private key by flipping a coin. One simply has to flip a coin 256 times and record the private key in its binary form. Now, obviously one would have to convert it into a hexadecimal number, and that should be it (if I understand the process in the first place).

Here's how I understand it (please feel free to correct me if something is wrong):

1. You flip a coin. If the outcome of the flip is heads, number 1 is recorded. If the outcome is tails, 0 is recorded. (or the other way around, but once you choose, stick to it till the end)

2. Repeat this 256 times, each time writing down the number (either 0 or 1).

3. After 256 flips, you get a long number of random zeros and ones, like this: 100111011101100011100001... (256 in total)

4. Next, you gather the ones and zeros in groups of four numbers, like this: 1001 1101 1101 1000 1110 0001...

5. Now, you just use a binary to hexadecimal converter (there are online converters, like this https://www.binaryhexconverter.com/binary-to-hex-converter), or I just use the following table:

0000 -->0
0001 -->1
0010 -->2
0011 -->3
0100 -->4
0101 -->5
0110 -->6
0111 -->7
1000 -->8
1001 -->9
1010 -->A
1011 -->B
1100 -->C
1101 -->D
1110 -->E
1111 -->F

6. The random number 1001 1101 1101 1000 1110 0001... is now four times shorter: 9DD8E1... (64 in hex format)

All in all, you have generated a random private key without the help of a computer program.

7. You now carefully import this private key in a wallet!

What are your thoughts on this?