Use raspberry to create a paper wallet?

[deus_vult]

Anyone here has any experience using raspberry and sites like bittaddress.org for creating a paper wallet?
I mean, Instead of using a PC, we use a raspberry to access the website, load the page, disconnect, create the wallet, print the wallet, then format the whole raspberry SD card.
Is it safe to do that?

[achow101]

Instead of loading the website, you should download the website's source code from github and load that locally offline. It will still work without any webserver.

[jackg]

Anyone here has any experience using raspberry and sites like bittaddress.org for creating a paper wallet?
I mean, Instead of using a PC, we use a raspberry to access the website, load the page, disconnect, create the wallet, print the wallet, then format the whole raspberry SD card.
Is it safe to do that?

As far as I know that should be safe to do. You may want to run a test on it first with a small amount just to check it works.

Instead of loading the website, you should download the website's source code from github and load that locally offline. It will still work without any webserver.

The site should work offline just by hitting ctrl+s and saving it in any device where it can then be imported to the Pi. No need to use github to pull the code.

[HI-TEC99]

Anyone here has any experience using raspberry and sites like bittaddress.org for creating a paper wallet?
I mean, Instead of using a PC, we use a raspberry to access the website, load the page, disconnect, create the wallet, print the wallet, then format the whole raspberry SD card.
Is it safe to do that?

As far as I know that should be safe to do. You may want to run a test on it first with a small amount just to check it works.

The only concern I have about it is how effective a raspberry is at generating random data. Normal PCs employ random events such as interrupts and hard drive reads. A raspberry has no hard drive, it lacks one of the biggest sources of random data available to PCs. I'm not sure if it matters, but I'd consider the risk of a raspberry generating weak private keys.


https://seifried.org/lasg/encryption/

In order for encryption to be effective, especially on a large scale such as IPSec across many hosts, good sources of random, cryptographically secure data are needed. In Linux we have /dev/random and /dev/urandom which are good but not always great. Part of the equation is measuring 'random' events, manipulating that data and then making it available (via (u)random). These random events include: keyboard and mouse input, interrupts, drive reads, etc.

However, as many servers have no keyboard/mouse, and onsider the risk of it cnew "blackbox" products often contain no harddrive, sources of random data become harder to find. Some sources, like network activity, are not entirely appropriate because the attacks may be able to measure it as well (granted this would be a very exotic attack, but enough to worry people nonetheless).

[deus_vult]

About the randomizing part:

Would that be risky even if everything was done offline, using a mouse, and formatting the sd card later?

[jackg]

Anyone here has any experience using raspberry and sites like bittaddress.org for creating a paper wallet?
I mean, Instead of using a PC, we use a raspberry to access the website, load the page, disconnect, create the wallet, print the wallet, then format the whole raspberry SD card.
Is it safe to do that?

As far as I know that should be safe to do. You may want to run a test on it first with a small amount just to check it works.

The only concern I have about it is how effective a raspberry is at generating random data. Normal PCs employ random events such as interrupts and hard drive reads. A raspberry has no hard drive, it lacks one of the biggest sources of random data available to PCs. I'm not sure if it matters, but I'd consider the risk of a raspberry generating weak private keys.


https://seifried.org/lasg/encryption/

In order for encryption to be effective, especially on a large scale such as IPSec across many hosts, good sources of random, cryptographically secure data are needed. In Linux we have /dev/random and /dev/urandom which are good but not always great. Part of the equation is measuring 'random' events, manipulating that data and then making it available (via (u)random). These random events include: keyboard and mouse input, interrupts, drive reads, etc.

However, as many servers have no keyboard/mouse, and onsider the risk of it cnew "blackbox" products often contain no harddrive, sources of random data become harder to find. Some sources, like network activity, are not entirely appropriate because the attacks may be able to measure it as well (granted this would be a very exotic attack, but enough to worry people nonetheless).

A raspberry should be able to use an SD card in the same way a computer uses a hard drive. In this instance, it seems there may be a problem with how random the operating system can actually be at generating addresses.

You could always try producing 100 addresses and private keys to start with, wiping the pi and doing the same thing again.
If there are any anomalies this could be determined here (also check if the address has already been used might be a good idea as you know then that it isn't random).

[HI-TEC99]

Anyone here has any experience using raspberry and sites like bittaddress.org for creating a paper wallet?
I mean, Instead of using a PC, we use a raspberry to access the website, load the page, disconnect, create the wallet, print the wallet, then format the whole raspberry SD card.
Is it safe to do that?

As far as I know that should be safe to do. You may want to run a test on it first with a small amount just to check it works.

The only concern I have about it is how effective a raspberry is at generating random data. Normal PCs employ random events such as interrupts and hard drive reads. A raspberry has no hard drive, it lacks one of the biggest sources of random data available to PCs. I'm not sure if it matters, but I'd consider the risk of a raspberry generating weak private keys.


https://seifried.org/lasg/encryption/

In order for encryption to be effective, especially on a large scale such as IPSec across many hosts, good sources of random, cryptographically secure data are needed. In Linux we have /dev/random and /dev/urandom which are good but not always great. Part of the equation is measuring 'random' events, manipulating that data and then making it available (via (u)random). These random events include: keyboard and mouse input, interrupts, drive reads, etc.

However, as many servers have no keyboard/mouse, and onsider the risk of it cnew "blackbox" products often contain no harddrive, sources of random data become harder to find. Some sources, like network activity, are not entirely appropriate because the attacks may be able to measure it as well (granted this would be a very exotic attack, but enough to worry people nonetheless).

A raspberry should be able to use an SD card in the same way a computer uses a hard drive. In this instance, it seems there may be a problem with how random the operating system can actually be at generating addresses.

I don't know exactly how bitaddress.org generates its random. There's a discussion about it here, but I haven't looked into it further or reviewed the source code. Maybe it only uses human based mouse random input, but if it also collects random data from hard drives it's worth considering any risks. That particular issue discussed on github was that without mouse movement during the seeding the seed value was just the current time. It was fixed in 2013, but I don't know what additional sources of random they added since then, or if it only relies on mouse movements and the current time.

https://github.com/pointbiz/bitaddress.org/issues/35

You could always try producing 100 addresses and private keys to start with, wiping the pi and doing the same thing again.
If there are any anomalies this could be determined here (also check if the address has already been used might be a good idea as you know then that it isn't random).

I don't think producing 100 addresses is enough to test for anomalies. How would you test them?

NIST produced some software for conducting statistical testing on data produced by random number generators. However it requires compiling, and needs huge data sets to work with.

http://csrc.nist.gov/groups/ST/toolkit/rng/documents/SP800-22rev1a.pdf

This paper discusses some aspects of selecting and testing random and pseudorandom number generators.The outputs of such generators may be used in many cryptographic applications, such as the generation of key material. Generators suitable for use in cryptographic applications may need to meet stronger requirements than for other applications. In particular, their outputs must be unpredictable in the absence of knowledge of the inputs. Some criteria for characterizing  and selecting appropriate generators are discussed in this document. The subject of statistical testing and its relation to cryptanalysis is also discussed, and some recommended statistical tests are provided. These tests may be useful as a first step in determining whether or not a generator is suitable for a particular cryptographic application. However,no set of statistical tests can absolutely certify a generator as appropriate for usage in a particular application, i.e., statistical testing cannot serve as a substitute for cryptanalysis

This is the download link for the the NIST Statistical Test Suite software.

http://csrc.nist.gov/groups/ST/toolkit/rng/documentation_software.html


Testing if a sequence of numbers is random is incredibly difficult, as random.org points out.

https://www.random.org/analysis/

If you flip enough coins, you will get sequences of coin flips that seen in isolation from the rest of the sequence don't look random at all. Scott Adams has drawn this as a Dilbert strip, which is funny exactly because it is true:



What Dilbert is told is correct: It is impossible to prove definitively whether a given sequence of numbers (and the generator that produced it) is random. It could happen that the creature in the comic strip has been generating perfectly random numbers for many years and that Dilbert simply happens to walk in at the moment when there's six nines in a row. It's not very likely, but if the creature sits there for long enough (and Dilbert visits enough times), then it will eventually happen.

There is more software for testing randomness called dieharder. It doesn't run all the NIST tests yet, but earlier software it's based on (called diehard) required a default input to work on of ten million random numbers in a file. Dieharder requires much more data than that to run sensitive tests.



http://www.phy.duke.edu/~rgb/General/dieharder.php

Dieharder differs significantly from diehard in many ways. For example, diehard uses file based sources of random numbers exclusively and by default works with only roughly ten million random numbers in such a file. However, modern random number generators in a typical simulation application can easily need to generate 10^18 or more random numbers, generated from hundreds, thousands, millions of different seeds in independent (parallelized) simulation threads, as the application runs over a period of months to years. Those applications can easily be sensitive to rng weaknesses that might not be revealed by sequences as short as 10^7 uints in length even with excellent and sensitive tests. One of dieharder's primary design goals was to permit tests to be run on very long sequences.

*snip*

In addition to implementing all of the diehard tests it is expected that dieharder will eventually contain all of the NIST STS and a variety of tests contributed by users

[deus_vult]

You guys are not considering the fact that a raspberry can run other operational systems, such as:

Android (RTAndroid) actively updated, and here is a video tutorial
Angstrom Linux
Arch Linux ARM SD Images are no longer maintained for Raspberry. Installation is done from tarballs now with manual setup of partitions and file systems, see here.
Chromium OS
Debian ARM
Fedora ARM Pi 2/3 only.
Fedberry SD, a Fedora Remix for Pi 2 and 3
FreeBSD
Gentoo
IPFire
Kali Linux SD
LibreELEC
Meego MER + XBMC
Nard SDK SD (Embedded systems)
NetBSD
OpenELEC + XBMC SD
OpenWrt SD
OSMC SD, Open source media center
PiBang
Pidora SD, a Fedora Remix for Pi 1 [No longer maintained]
PwnPi SD, a Raspbian clone for penetration testing. Does not seem to be actively maintained. Last version from 2012 works on Pi 1. Replace the files on the /boot partition with those of latest Raspbian to make it work on Pi 2.
QtonPi
Plan 9 SD
Raspbian SD, a Debian derivative
Raspbmc SD is now OSMC
RaspBSD SD
RetroPie SD
Risc OS SD
Slackware ARM
SliTaz
Ubuntu Mate SD
Void Linux
Windows 10 IoT Core SD

References

This is a comprehensive list of OS available for the Raspberry Pi. The official site links to this eLinux wiki, so I presume this might be the most complete list at the moment.

Distribution List on eLinux Wiki
Official Downloads
Raspberry Pi on Wikipedia - includes an extensive list


The OS distributions that are available as an SD card image are marked with SD.

Beware not everything on that list will work on all models of Pi; non pi-specific GNU/Linux distros are usually for ARMv7+ and therefore only viable on the Pi 2/3. Some pi-specific images are also model 2/3 only, but this should be clearly indicated on the homepage if not here.

There are also (non pi-specific) ARMv8 64-bit ("aarch64") GNU/Linux distros that should be viable on the Pi 3 but this is largely untested.

Non pi-specific images (not having a dedicated SD card image is a clue to this) will probably at a minimum require you install the Raspberry Pi kernel; a generic ARM kernel will not work. See here for an example methodology regarding this.


Source: http://raspberrypi.stackexchange.com/questions/534/definitive-list-of-operating-systems

So what do you have to say about the randomizing part now?

[deus_vult]

Ubuntu Mate 16.04 On The Raspberry PI 3
https://www.youtube.com/watch?v=dytwxDFlyCQ

By the way, please someone have a look at this thread:
https://bitcointalk.org/index.php?topic=1841094.new;topicseen#new

[HI-TEC99]

You guys are not considering the fact that a raspberry can run other operational systems, such as:

Android (RTAndroid) actively updated, and here is a video tutorial
Angstrom Linux
Arch Linux ARM SD Images are no longer maintained for Raspberry. Installation is done from tarballs now with manual setup of partitions and file systems, see here.
Chromium OS
Debian ARM
Fedora ARM Pi 2/3 only.
Fedberry SD, a Fedora Remix for Pi 2 and 3
FreeBSD
Gentoo
IPFire
Kali Linux SD
LibreELEC
Meego MER + XBMC
Nard SDK SD (Embedded systems)
NetBSD
OpenELEC + XBMC SD
OpenWrt SD
OSMC SD, Open source media center
PiBang
Pidora SD, a Fedora Remix for Pi 1 [No longer maintained]
PwnPi SD, a Raspbian clone for penetration testing. Does not seem to be actively maintained. Last version from 2012 works on Pi 1. Replace the files on the /boot partition with those of latest Raspbian to make it work on Pi 2.
QtonPi
Plan 9 SD
Raspbian SD, a Debian derivative
Raspbmc SD is now OSMC
RaspBSD SD
RetroPie SD
Risc OS SD
Slackware ARM
SliTaz
Ubuntu Mate SD
Void Linux
Windows 10 IoT Core SD

References

This is a comprehensive list of OS available for the Raspberry Pi. The official site links to this eLinux wiki, so I presume this might be the most complete list at the moment.

Distribution List on eLinux Wiki
Official Downloads
Raspberry Pi on Wikipedia - includes an extensive list


The OS distributions that are available as an SD card image are marked with SD.

Beware not everything on that list will work on all models of Pi; non pi-specific GNU/Linux distros are usually for ARMv7+ and therefore only viable on the Pi 2/3. Some pi-specific images are also model 2/3 only, but this should be clearly indicated on the homepage if not here.

There are also (non pi-specific) ARMv8 64-bit ("aarch64") GNU/Linux distros that should be viable on the Pi 3 but this is largely untested.

Non pi-specific images (not having a dedicated SD card image is a clue to this) will probably at a minimum require you install the Raspberry Pi kernel; a generic ARM kernel will not work. See here for an example methodology regarding this.


Source: http://raspberrypi.stackexchange.com/questions/534/definitive-list-of-operating-systems

So what do you have to say about the randomizing part now?

The randomizing part relies on whatever choice of random number generation bitaddress uses, not the operating system.

In fact the raspberry has its own built in hardware random number generator discussed here. I'm sure most of the operating systems you listed are capable of using that random number generator, using suitable software.

https://security.stackexchange.com/questions/47475/testing-a-hardware-random-number-generator

However, for random number generation bitaddress uses the Arcfour algorithm (officially called RC4) in which multiple vulnerabilities have been discovered.

https://en.wikipedia.org/wiki/RC4

multiple vulnerabilities have been discovered in RC4, rendering it insecure. It is especially vulnerable when the beginning of the output keystream is not discarded, or when nonrandom or related keys are used. Particularly problematic uses of RC4 have led to very insecure protocols such as WEP.

As of 2015, there is speculation that some state cryptologic agencies may possess the capability to break RC4 when used in the TLS protocol. IETF has published RFC 7465 to prohibit the use of RC4 in TLS; Mozilla and Microsoft have issued similar recommendations

I had a quick look at the bitaddress source code and it appears to use the list of sources below (in combination with Arcfour) for random number generation in addition to mouse movements. However I only had a quick look and might be mistaken.

https://github.com/pointbiz/bitaddress.org/blob/master/src/securerandom.js#L125-L128

• Math.random()
• the current time (w/milliseconds)
• webcrypto if available
• screen size and color depth
• time zone offset
• user agent
• browser plugin details
• cookies and storage
• language
• history
• location

According to this stackoverflow post using Math.random() is problematic because it's weak. A weaknes was discovered in an early version, but apparently today's version is still weak.

http://stackoverflow.com/a/18507748

Math.random() was weak in most browsers in 2008 - Amit Klein's paper goes into excellent detail - and sadly is almost as weak today.

This is a link to Amit Klein's paper exposing the Math.random vulnerability in Google Chrome 6.0 and 7.0

http://www.securitygalore.com/files/Google_Chrome_6.0_and_7.0_Math.random_vulnerability.pdf

This is the mozilla discussion about replacing Math.random with something more secure.

https://bugzilla.mozilla.org/show_bug.cgi?id=322529

Disclaimer: I'm no expert so do your own research and draw your own conclusions.

[deus_vult]

Well, I don't mind about moving to another software.
Just tell me if that's possible to use a raspberry and some kind of software (Other than bittaddress) safely, please.
By the way, did you check my other post? It talks about using a playstation 2 and a linux redistribution to make the wallet.

[jackg]

Anyone here has any experience using raspberry and sites like bittaddress.org for creating a paper wallet?
I mean, Instead of using a PC, we use a raspberry to access the website, load the page, disconnect, create the wallet, print the wallet, then format the whole raspberry SD card.
Is it safe to do that?

As far as I know that should be safe to do. You may want to run a test on it first with a small amount just to check it works.

The only concern I have about it is how effective a raspberry is at generating random data. Normal PCs employ random events such as interrupts and hard drive reads. A raspberry has no hard drive, it lacks one of the biggest sources of random data available to PCs. I'm not sure if it matters, but I'd consider the risk of a raspberry generating weak private keys.


https://seifried.org/lasg/encryption/

In order for encryption to be effective, especially on a large scale such as IPSec across many hosts, good sources of random, cryptographically secure data are needed. In Linux we have /dev/random and /dev/urandom which are good but not always great. Part of the equation is measuring 'random' events, manipulating that data and then making it available (via (u)random). These random events include: keyboard and mouse input, interrupts, drive reads, etc.

However, as many servers have no keyboard/mouse, and onsider the risk of it cnew "blackbox" products often contain no harddrive, sources of random data become harder to find. Some sources, like network activity, are not entirely appropriate because the attacks may be able to measure it as well (granted this would be a very exotic attack, but enough to worry people nonetheless).

A raspberry should be able to use an SD card in the same way a computer uses a hard drive. In this instance, it seems there may be a problem with how random the operating system can actually be at generating addresses.

I don't know exactly how bitaddress.org generates its random. There's a discussion about it here, but I haven't looked into it further or reviewed the source code. Maybe it only uses human based mouse random input, but if it also collects random data from hard drives it's worth considering any risks. That particular issue discussed on github was that without mouse movement during the seeding the seed value was just the current time. It was fixed in 2013, but I don't know what additional sources of random they added since then, or if it only relies on mouse movements and the current time.

https://github.com/pointbiz/bitaddress.org/issues/35

You could always try producing 100 addresses and private keys to start with, wiping the pi and doing the same thing again.
If there are any anomalies this could be determined here (also check if the address has already been used might be a good idea as you know then that it isn't random).

I don't think producing 100 addresses is enough to test for anomalies. How would you test them?

NIST produced some software for conducting statistical testing on data produced by random number generators. However it requires compiling, and needs huge data sets to work with.

http://csrc.nist.gov/groups/ST/toolkit/rng/documents/SP800-22rev1a.pdf

This paper discusses some aspects of selecting and testing random and pseudorandom number generators.The outputs of such generators may be used in many cryptographic applications, such as the generation of key material. Generators suitable for use in cryptographic applications may need to meet stronger requirements than for other applications. In particular, their outputs must be unpredictable in the absence of knowledge of the inputs. Some criteria for characterizing  and selecting appropriate generators are discussed in this document. The subject of statistical testing and its relation to cryptanalysis is also discussed, and some recommended statistical tests are provided. These tests may be useful as a first step in determining whether or not a generator is suitable for a particular cryptographic application. However,no set of statistical tests can absolutely certify a generator as appropriate for usage in a particular application, i.e., statistical testing cannot serve as a substitute for cryptanalysis

This is the download link for the the NIST Statistical Test Suite software.

http://csrc.nist.gov/groups/ST/toolkit/rng/documentation_software.html


Testing if a sequence of numbers is random is incredibly difficult, as random.org points out.

https://www.random.org/analysis/

If you flip enough coins, you will get sequences of coin flips that seen in isolation from the rest of the sequence don't look random at all. Scott Adams has drawn this as a Dilbert strip, which is funny exactly because it is true:



What Dilbert is told is correct: It is impossible to prove definitively whether a given sequence of numbers (and the generator that produced it) is random. It could happen that the creature in the comic strip has been generating perfectly random numbers for many years and that Dilbert simply happens to walk in at the moment when there's six nines in a row. It's not very likely, but if the creature sits there for long enough (and Dilbert visits enough times), then it will eventually happen.

There is more software for testing randomness called dieharder. It doesn't run all the NIST tests yet, but earlier software it's based on (called diehard) required a default input to work on of ten million random numbers in a file. Dieharder requires much more data than that to run sensitive tests.



http://www.phy.duke.edu/~rgb/General/dieharder.php

Dieharder differs significantly from diehard in many ways. For example, diehard uses file based sources of random numbers exclusively and by default works with only roughly ten million random numbers in such a file. However, modern random number generators in a typical simulation application can easily need to generate 10^18 or more random numbers, generated from hundreds, thousands, millions of different seeds in independent (parallelized) simulation threads, as the application runs over a period of months to years. Those applications can easily be sensitive to rng weaknesses that might not be revealed by sequences as short as 10^7 uints in length even with excellent and sensitive tests. One of dieharder's primary design goals was to permit tests to be run on very long sequences.

*snip*

In addition to implementing all of the diehard tests it is expected that dieharder will eventually contain all of the NIST STS and a variety of tests contributed by users

There is definitely a problem of proving randomness of the data imported. I did just run a python program to produce 100000 numbers between zero to nine and it returned:

Code:

0: 9797
1: 9952
2: 10034
3: 10249
4: 9947
5: 9982
6: 9933
7: 9933
8: 10114
9: 9923

This was done on WINDOWS 7 and you can already spot a few anomalies that appear (0 and 3)

The code used was pretty simplistic (took about a minute to write

Code:

import random
numbers = [0,0,0,0,0,0,0,0,0,0]
for loop in range(100000):
	n = random.randint(0,9)
	numbers[n]+=1
print(numbers)

With a range of 100 numbers from 0 to 99:

Code:

[968, 952, 929, 1021, 999, 953, 1055, 1031, 1025, 1041, 1050, 1023, 1020, 1042, 1029, 964, 971, 974, 953, 946, 979, 1008, 1010, 1008, 1037, 1004, 939, 977, 974, 1004, 968, 975, 1005, 1025, 1020, 1010,
 1038, 963, 1031, 958, 989, 980, 1011, 985, 1016, 1045, 999, 1002, 973, 1014, 1049, 976, 1025, 1030, 966, 981, 1013, 1007, 1033, 989, 988, 1017, 1013, 1009, 969, 1005, 1009, 937, 971, 980, 1018, 1005,
 988, 987, 1000, 1028, 1007, 981, 1020, 1001, 932, 978, 1031, 999, 958, 1023, 996, 1030, 1030, 1059, 1025, 1015, 970, 997, 1029, 999, 990, 985, 1002, 1057]

I'd still say that 100000 is a little constraining with this idea...

I reran the code for selecting 10 numbers again and it returned:

Code:

[81583, 81809, 81464, 81847, 81529, 81790, 81536, 81104, 81295, 81521]

The problem with the randomness testing with the anomalies you suggested, there are fewer problems when looking at the overall statistic produced than if you look at them individually. For example, if you flip a coin continuously for a 12 hour period, you may eventually get several times where there are at least 12 continuous sides the same. but if you look at it generally, the result will be closer to 50% (probably, unless there are other errors).
There is also a problem that my computer may be not making random numbers as it is fairly evenly spread between each of the numbers that are there...

The analysis program on the .gov website attached above will be much better than my creations, mine is merely an example of probabilities.

[jackg]

Well, I don't mind about moving to another software.
Just tell me if that's possible to use a raspberry and some kind of software (Other than bittaddress) safely, please.
By the way, did you check my other post? It talks about using a playstation 2 and a linux redistribution to make the wallet.

The use of linux is the problem here.

If you want to use a raspberry Pi 2 then I would suggest you attempt to install a windows operating system onto it (7+) and use that in order to create numbers better.

You could try running the listed software but it might be difficult to compile and get corresponding data sets to test it.

[HI-TEC99]

Well, I don't mind about moving to another software.
Just tell me if that's possible to use a raspberry and some kind of software (Other than bittaddress) safely, please.
By the way, did you check my other post? It talks about using a playstation 2 and a linux redistribution to make the wallet.

A staff member here called Dabs suggests rolling dice to generate a truly random private key, then using that in the bitaddress webpage on a live CD to get the associated Bitcoin address. Using that technique on a raspberry should also work, and you never have to worry about a bug in a random number generator endangering your Bitcoins.

Most experts agree that using dice is truly random. You roll a dice 99 times, record the results following these rules: 1=1, 2=2, 3=3, 4=4, 5=5, 6=0

Then you click bitaddress's wallet details button, put that long 99 digit number into the text box, and click the view details button.

The bounty has been claimed, but I propose using an unbiased dice generation method.

Use base 6 for the 6 sided dice. Roll it about 100 times (really.) Write it down. Then convert that to hexadecimal and you have your private key with no bias. (Okay, maybe you need another dice roll?)

For example:

1001112400000533003453522130540400324355321453252515013101100231113332152441500 105310450123404240000

becomes

F213DA1F48C5B538B67BB9E25379B1CE0A8C8D8E205B03E3E68BDB35CDECA3A2

Then you plug that in to an offline copy of bitaddress.org on a computer that is never used for any other purpose (or uses a Live CD), and we get this:

Bitcoin Address (compressed): 1A2nR6q3aUQPJKpA2YFXjqRdh6XN8WAxKQ
Private Key WIF (compressed, 52 characters base58, starts with a 'K' or 'L'): L5LH5Sg1reynj5pKbVcUo6uvbQTnxnqQs1W1ghACrgdU5A1WJm3J

If that looks better, you can also send me a coin. If not, uh, I tried. hehe. (coin address in my signature.)

For the dice roll, subtract by 1 to get the base 6 digit.

1 = 0
2 = 1
3 = 2
4 = 3
5 = 4
6 = 5

Bitaddress also suggests using dice to ensure a private key is truly random, then using it in the webpage to get its associated Bitcoin address. There is a link that opens these instructions at the bottom of its webpage.


https://www.bitaddress.org/

How do I make a wallet using dice? What is B6?

An important part of creating a Bitcoin wallet is ensuring the random numbers used to create the wallet are truly random. Physical randomness is better than computer generated pseudo-randomness. The easiest way to generate physical randomness is with dice. To create a Bitcoin private key you only need one six sided die which you roll 99 times. Stopping each time to record the value of the die. When recording the values follow these rules: 1=1, 2=2, 3=3, 4=4, 5=5, 6=0. By doing this you are recording the big random number, your private key, in B6 or base 6 format. You can then enter the 99 character base 6 private key into the text field above and click View Details. You will then see the Bitcoin address associated with your private key. You should also make note of your private key in WIF format since it is more widely used.

The only situation where I wouldn't consider using that technique is one where the rolls obviously don't look random, like in the Dilbert cartoon. If I rolled ninety nine fives I wouldn't use them even if the sequence is "technically" random.

https://www.random.org/analysis/

If you flip enough coins, you will get sequences of coin flips that seen in isolation from the rest of the sequence don't look random at all. Scott Adams has drawn this as a Dilbert strip, which is funny exactly because it is true:



What Dilbert is told is correct: It is impossible to prove definitively whether a given sequence of numbers (and the generator that produced it) is random. It could happen that the creature in the comic strip has been generating perfectly random numbers for many years and that Dilbert simply happens to walk in at the moment when there's six nines in a row. It's not very likely, but if the creature sits there for long enough (and Dilbert visits enough times), then it will eventually happen.

Here's an example of one key I wouldn't use even if it was "technically" random.

Private Key Base6 Format (99 characters [0-5]):
1111111111111111111111111111111111111111111111111111111111111111111111111111111 11111111111111111111

[blockxx]

I woudnt trust a rpi for this