How can you verify the randomness that's coming from a hardware?

[BlackHatCoiner]

Warning: I don't know much from hardware. And when I say much, I mean nothing.

I had created a thread regarding this in the Hardware Wallet section, but I choose to broaden it in the Dev & Tech board. Pretty simple question, but I've come to realize that it's much more difficult to answer than it seems.

When we say that a wallet software is closed source, we're afraid it may have access to our keys via the internet, sell our IP addresses and other info, or simply generate predictable entropy to steal our money in the smoothest way possible. We choose open source, so we can have a peace of mind.

So, how do we verify that the hardware doesn't generate predictable entropy, regardless of whether the wallet developers have bad intentions or not? I don't care about the OS, let's assume you use an open-source one; my focus is on those who build the hardware that is used to generate randomness.

[1714943742]

1714943742

[1714943742]

1714943742

[1714943742]

1714943742

[1714943742]

1714943742

[1714943742]

1714943742

[garlonicon]

We cannot do much. Unless it is Open Hardware, where you can know all design details, you can create your own CPU architecture from scratch, you can change everything and design anything. Then, you can assume that you have full control. But still, you are limited by the laws of physics. You cannot see small things, you can use other devices, such as microscopes, to display that things in a huge zoom. You cannot have objectively trustless randomness. You can only have things that are random enough for your purposes, that is all you can get. And to test that, you can get some samples and check some basic things. For example, when you roll a dice, you can check that you are not getting four every time. But if you would, could you call it random? https://xkcd.com/221/

[BlackHatCoiner]

For example, when you roll a dice, you can check that you are not getting four every time. But if you would, could you call it random?

Well, it depends. If I have tested the dice and I've verified that, on average, all of the values have a ~16.66% chance to return, then it's safe to assume it's random. At least, that's the definition according to Wikipedia:

In common parlance, randomness is the apparent or actual lack of pattern or predictability in events.

I know it sounds paranoid, but I don't know what to answer if one ever made me such question. Like, sure, most of the hardware is very unlikely to have this kind of weakness, but what about hardware wallets? They're designed for solely transacting bitcoins and their random number generator, as in all hardware, isn't apparent.

Couldn't one of all these hardware wallet companies implement something like that and steal millions of dollars worth of BTC, in just one moment? It would probably be the worst scandal of the crypto space.

[witcher_sense]

Well, it depends. If I have tested the dice and I've verified that, on average, all of the values have a ~16.66% chance to return, then it's safe to assume it's random. At least, that's the definition according to Wikipedia:

In common parlance, randomness is the apparent or actual lack of pattern or predictability in events.

I know it sounds paranoid, but I don't know what to answer if one ever made me such question. Like, sure, most of the hardware is very unlikely to have this kind of weakness, but what about hardware wallets? They're designed for solely transacting bitcoins and their random number generator, as in all hardware, isn't apparent.

Couldn't one of all these hardware wallet companies implement something like that and steal millions of dollars worth of BTC, in just one moment? It would probably be the worst scandal of the crypto space.

In the case of dice rolls, you can be sure the number you got was random only because you were generating it yourself without trusting anybody. You have to be a witness of the whole process to verify randomness. But if you come and tell me that a certain number was generated randomly with dice rolls or coin flips or with something else, I have no way to verify your claims. In the case of hardware, it is simply impossible to follow the whole process of generation, so you can't be a witness by definition. The best you can do is test numbers for pseudorandomness by generating billions of numbers and trying to find a pattern.

This thread may also be helpful: https://bitcointalk.org/index.php?topic=5317199.0

[Welsh]

Couldn't one of all these hardware wallet companies implement something like that and steal millions of dollars worth of BTC, in just one moment? It would probably be the worst scandal of the crypto space.

Technically could, although there would be no way to prove this as far as I'm aware, so there isn't a way to verify it either. It would be a pretty sophisticated attack though, it reminds me how computer forensics would freeze computers in the past, specifically the ram in order to extract data. Also, I do believe that some programs in the past, which I can't recall right now would give you supposedly random data, i.e a password generation based on the temperature of the device, and various other things.

I'm not sure how plausible this kind of attack would be though.

[ABCbits]

So, how do we verify that the hardware doesn't generate predictable entropy, regardless of whether the wallet developers have bad intentions or not?

Unless you have capability to understand the design of the hardware or at least perform randomness test[1], you either trust the hardware company or someone who audit the hardware. I'm fairly sure there are decent amount of cryptography auditor, but i've no idea how common auditor for hardware design/architecture.

[1] https://en.wikipedia.org/wiki/Randomness_test#Specific_tests_for_randomness

[bitmover]

So, how do we verify that the hardware doesn't generate predictable entropy, regardless of whether the wallet developers have bad intentions or not? I don't care about the OS, let's assume you use an open-source one; my focus is on those who build the hardware that is used to generate randomness.

I took a look at ledger nano and trezor hardwares. I found that there is a certification called AIS31-certified RNG which is the best in the world when talking about entropy.
As Ledger is not fully open source, they have such certification

https://support.ledger.com/hc/en-us/articles/360010073520-Quality-of-randomness?docs=true

Ledger hardware wallets use the Random Number Generator (RNG) embedded in the Secure Element to generate the confidential recovery phrase (also known as mnemonic seed). This RNG has been evaluated by a third-party laboratory and has obtained the highest level of certification: EAL5+, AIS-31.
...
Hardware RNGs like the one used in Ledger hardware wallets use several sources of randomness. On top of that, we also implemented standard post-processing retreatment. Clearly, AIS31-certified RNGs are the best RNGs in the world in terms of entropy, unpredictability, and robustness. For more information, please refer to the relevant certification methodology.
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Zertifizierung/Interpretationen/AIS_31_Functionality_classes_evaluation_methodology_for_true_RNG_e.pdf?__blob=publicationFile

Trezor doesn't have such a certification. However,  as it is open source you could  verify  their randomness in github.
It would be interesting to see the verification or audition of a professional
https://wiki.trezor.io/Recovery_seed

[alexeyneu]

but what hardware you're talking about? say you have onboard temp sensor and system time. tell exactly what you wanna

[dkbit98]

So, how do we verify that the hardware doesn't generate predictable entropy, regardless of whether the wallet developers have bad intentions or not? I don't care about the OS, let's assume you use an open-source one; my focus is on those who build the hardware that is used to generate randomness.

Last year I wrote a topic about seed generation in hardware wallets and you can find some useful information there, but true randomness is a problem for software wallets also.
I think that software wallets are even worse than hardware wallets and it doesn't really matter much if they are open source or not.
Hardware wallets are mostly using combination of several elements mixing entropy of computer and device, and some are using closed source secure element for that.
Only verifiable seed generation for hardware wallets I was able to find was for Passport, Kestone, Coldcard, Trezor and BitBox02 walllet, others are more like a black box.

One true way to be sure that seed phrase is truly random is by using properly tested casino dices, so you don't have to trust any chips or computers that create fake random results that can be reproduced.

[alexeyneu]

So, how do we verify that the hardware doesn't generate predictable entropy, regardless of whether the wallet developers have bad intentions or not? I don't care about the OS, let's assume you use an open-source one; my focus is on those who build the hardware that is used to generate randomness.

Last year I wrote a topic about seed generation in hardware wallets and you can find some useful information there, but true randomness is a problem for software wallets also.
I think that software wallets are even worse than hardware wallets and it doesn't really matter much if they are open source or not.
Hardware wallets are mostly using combination of several elements mixing entropy of computer and device, and some are using closed source secure element for that.
Only verifiable seed generation for hardware wallets I was able to find was for Passport, Kestone, Coldcard, Trezor and BitBox02 walllet, others are more like a black box.

One true way to be sure that seed phrase is truly random is by using properly tested casino dices, so you don't have to trust any chips or computers that create fake random results that can be reproduced.

fractional part of onboard temp is unique. when system board has this sensor

[BlackHatCoiner]

One true way to be sure that seed phrase is truly random is by using properly tested casino dices, so you don't have to trust any chips or computers that create fake random results that can be reproduced.

I'm not paranoid enough to do that, I just wanted to know if this kind of function is verifiable. It doesn't matter if I roll a dice or not when the overwhelming majority uses hardware and software wallets. If, say, Trezor is proved to generate predictable entropy and steals everyone's funds in just one moment, it'll harm the entire bitcoin economy.

[NeuroticFish]

how do we verify that the hardware doesn't generate predictable entropy

I don't think that we can. While we expect they rather keep their business running than stealing people's money, we cannot know if they indeed play fair and go random, or generate their numbers by a rule. But...

In theory if they do this, the seeds the devices will generate will be a rather small subset of all the possible seeds (so they can brute force them in a reasonable amount of time).
However, if this would happen, there's a very big chance collision would happen, and rather often, between different users' seeds/wallets. If this happens, most do post about it (especially if it's them losing money).
Yes, I know, if this happens, people tend to point to hacks and unsafe storage of the keys, but still.. there would be much more of those imho.
Also I'd expect some users be nice and, instead of stealing, start writing about it.

Imho for now it's pretty safe to assume they did play fair until now.

[vjudeu]

Also remember one thing: you don't need true randomness. You need randomness that is useful for your purpose. If you want to get a random number from 1 to 10000, getting {4,4,4,4,4} is unlikely, but still possible. However, not many random number generators will give you that result, because it will fail many tests. And that means some "nice, non-randomly looking values" are excluded, so here you have another potential attack vector.

[PrimeNumber7]

For example, when you roll a dice, you can check that you are not getting four every time. But if you would, could you call it random?

Well, it depends. If I have tested the dice and I've verified that, on average, all of the values have a ~16.66% chance to return, then it's safe to assume it's random. At least, that's the definition according to Wikipedia:

In common parlance, randomness is the apparent or actual lack of pattern or predictability in events.

I know it sounds paranoid, but I don't know what to answer if one ever made me such question. Like, sure, most of the hardware is very unlikely to have this kind of weakness, but what about hardware wallets? They're designed for solely transacting bitcoins and their random number generator, as in all hardware, isn't apparent.

Couldn't one of all these hardware wallet companies implement something like that and steal millions of dollars worth of BTC, in just one moment? It would probably be the worst scandal of the crypto space.

Dice rolls are not the same as generating a seed. With a dice roll there are six possible outcomes, generating a seed, there are many more possible outcomes.

If you are using a dice roll to generate a seed, you should care more than just that each outcome has the same probability. You also care that a particular outcome does not affect the next outcome, in other words, that each outcome is independent of all other outcomes.

[garlonicon]

Dice rolls are not the same as generating a seed. With a dice roll there are six possible outcomes, generating a seed, there are many more possible outcomes.

And that's the only difference. If you want to get some 256-bit number, it does not matter if you call some function that will return true/false 256 times, or if you call another function, that will return 256-bit value directly. If you have a state, then you can get it bit-by-bit and execute exactly the same algorithm. For deterministic outputs, you could get exactly the same results if you have a state. For random results, you can still get many samples and check if it is random enough, just by running the same randomness tests.

You also care that a particular outcome does not affect the next outcome, in other words, that each outcome is independent of all other outcomes.

If you have a stateless function, then it is theoretically possible to get {4,4,4,4,4} result, mentioned above. If you have some kind of state, then you can design your algorithm differently, just to pass some randomness tests. And that will make your outputs more random, but also less resistant to some attacks, because then you can assume that you will never get {4,4,4,4,4}, just because that value will fail some randomness tests. Of course, usually the size of the output will protect you from those attacks, and you will not even notice that potential weakness.

[dkbit98]

fractional part of onboard temp is unique. when system board has this sensor

Sensor-based random number generators are not truly random, and gaining control over sensor is making all data coming out compromised.
This is part of PRNG or Pseudorandom number generator that is probably deterministic and it is not strong enough to be used for bitcoin seed phrases.
One proven truly random stuff  I know that can be used is radioactive decay, and some people are working to do something similar with FM radio signals.

[goldkingcoiner]

Warning: I don't know much from hardware. And when I say much, I mean nothing.

I had created a thread regarding this in the Hardware Wallet section, but I choose to broaden it in the Dev & Tech board. Pretty simple question, but I've come to realize that it's much more difficult to answer than it seems.

When we say that a wallet software is closed source, we're afraid it may have access to our keys via the internet, sell our IP addresses and other info, or simply generate predictable entropy to steal our money in the smoothest way possible. We choose open source, so we can have a peace of mind.

So, how do we verify that the hardware doesn't generate predictable entropy, regardless of whether the wallet developers have bad intentions or not? I don't care about the OS, let's assume you use an open-source one; my focus is on those who build the hardware that is used to generate randomness.

Predictable entropy? Not sure I understand? Like the rate of oxidation on microelectronic metal pins which can mess with the electrical flow in such ways that one could possibly guess which metals were being used in the chip or something and use that info to identify the part?

If predicting entropy is your game then from a physics perspective, that is impossible to tell at a certain tiny point but at a larger scale can be perhaps easier. But never with 100% accuracy.

Although I very much doubt we have the technology to measure the teeny tiny differences, even if you were to make all the hardware parts 99.999999% the same there still would be random noise from tiny differences.

So no, I very much doubt you can verify the randomness accurately.

[larry_vw_1955]

If you are using a dice roll to generate a seed, you should care more than just that each outcome has the same probability. You also care that a particular outcome does not affect the next outcome, in other words, that each outcome is independent of all other outcomes.

dice rolls are independent of one another. that's just a fact. the harder thing is for each outcome to have the same probability. but if it's a fair dice then it's probably close enough.

[kaggie]

Check out this thread started by nullius: https://bitcointalk.org/index.php?topic=5326468.0

The problem with randomness is that you don't know whether something isn't random until there has been enough data measured and checked.

Even though you can't verify randomness, you could combine multiple sources of randomness to make it "more random" as long as your combination algorithm isn't causing additional bias and your sources are independent. The best route imo is to color one kind of randomness with other kinds of randomness. If one sensor is mostly random, then are two sensors more random? You could color your hardware randomness with a memory-given random seed generated from a second location, and the combined number would probably be just a little bit more random if used correctly.

So, how do we verify that the hardware doesn't generate predictable entropy, regardless of whether the wallet developers have bad intentions or not? I don't care about the OS, let's assume you use an open-source one; my focus is on those who build the hardware that is used to generate randomness.

Predictable entropy? Not sure I understand? Like the rate of oxidation on microelectronic metal pins which can mess with the electrical flow in such ways that one could possibly guess which metals were being used in the chip or something and use that info to identify the part?

If predicting entropy is your game then from a physics perspective, that is impossible to tell at a certain tiny point but at a larger scale can be perhaps easier. But never with 100% accuracy.

Predictable entropy could be low entropy? It would encompass measurements of distribution, determinism, and independence.

One kind of predictability would be the distribution. There could be different random distributions: pink, brown, grey, etc noise are all types of noise and perfectly independent and random, but don't all have the same exact entropy. You would want a flat frequency spectrum, all values equally possible over all periods of time. "Random" is itself not the desired factor, but flatly distributed random with independence.

A predictably random distribution could also be something like Pi, which is dependent and deterministic, but is it random? Depends on the definition? Irrational numbers like pi are perfect examples of "predictable entropy". Pi looks entirely random. Pi is evenly distributed for each of 0-9 to 1,000,000,000,000 digits. There are no correlations with its own sequences of numbers as far as can be detected (https://doi.org/10.1080/00031305.2000.10474501). Pi is a deterministic sequence that will be calculated again and again as computers get more powerful. The gaps between prime numbers also come to mind as a predictable randomness.

I know it sounds paranoid, but I don't know what to answer if one ever made me such question. Like, sure, most of the hardware is very unlikely to have this kind of weakness, but what about hardware wallets? They're designed for solely transacting bitcoins and their random number generator, as in all hardware, isn't apparent.
..
If you are using a dice roll to generate a seed, you should care more than just that each outcome has the same probability. You also care that a particular outcome does not affect the next outcome, in other words, that each outcome is independent of all other outcomes.

It's not entirely paranoid. There was a flaw in a javascript code generating random numbers in some early addresses:
https://www.bleepingcomputer.com/news/security/old-javascript-crypto-flaw-puts-bitcoin-funds-at-risk/

You could use dice rolls, but you have to not influence the distribution with how you calculate the number. If you were to use a 6 sided dice, you could roll the dice log_6(2^256)= 99.03 times and convert a base-6 number to a 256-bit number.

If you wanted to be even more random - evenly distributed and independent - with dice, you could get a 20-sided dice but then collect the data in base-2 by saying every even number was 1 and odd number was zero, rolling it 256 times, and then converting that 256 bit number to a 32 hex / 64 byte character representation. This would reduce the bias towards any particular number. Obviously a bit of work, but this gets around that you might possibly have a small non-flat distribution in your dice rolls.

-

As for hardware, it depends on whether you need future randomness or something where you can control the historical randomness. Every system has flaws that prevent randomness in a very controlled future scenario.

There isn't anything that could be purely random without influence under the most controlled of circumstances (except maybe radioactivity, and that's a maybe). If you built your system off of thermal randomness, then I could cool your system. Radiofrequency waves? I could put your system in a shielded room. Even with radioactive decay, it's random but not a flat-spectrum and has exponential decay distributions. I'm not entirely convinced that it's always random - there are reports (which could be wrong) that radioactive decay is influenced by our distance from the sun http://arxivblog.com/?p=596 . Physics is such a beast that there could be a discovery on how to make radioactive decay not-random.

but if it's a fair dice then it's probably close enough.

I agree with your "it's close enough" here. If you have 64 characters of complete entropy that no computer can crack for trillions of years, then do you need 10,000 bytes of entropy? Maybe, but hopefully not! At some point, we all make a choice as to what is good enough based on competing costs.

You can always be more random, independent, and evenly distributed. But where is good enough?

[larry_vw_1955]

If you were to use a 6 sided dice, you could roll the dice 8-byte/6-dice * 128 = 171 times and convert a base-6 number to a 128-byte base-8 number.

You only need to roll a dice 99 times to get a 256-bit number. Which gives you a bitcoin private key.

If you wanted to be even more random - evenly distributed and independent - with dice, you could get a 20-sided dice but then collect the data in base-2 by saying every even number was 1 and odd number was zero,

The thing is, a 20 sided dice has more biases than a 6 sided dice. The more sides the more bias. So that might not be a good idea.

Physics is such a beast that there could be a discovery on how to make radioactive decay not-random.

you can't cause or  influence when an atom undergoes radioactive decay. plus you don't know exactly when it will decay. look it up.

[kaggie]

If you were to use a 6 sided dice, you could roll the dice 8-byte/6-dice * 128 = 171 times and convert a base-6 number to a 128-byte base-8 number.

You only need to roll a dice 99 times to get a 256-bit number. Which gives you a bitcoin private key.

Only 99?
I have corrected the calculation. Oh, exponential numbers..

Still, 171 times could be used to create even more entropy, even if you are using less information than you collect.

If you wanted to be even more random - evenly distributed and independent - with dice, you could get a 20-sided dice but then collect the data in base-2 by saying every even number was 1 and odd number was zero,

The thing is, a 20 sided dice has more biases than a 6 sided dice. The more sides the more bias. So that might not be a good idea.

A 20-sided dice is acting like a 2-sided dice with less bias than a natural 2-sided dice in this scheme.

I doubt anyone would disagree that a 2-sided dice has potential bias from one side having more weight than another, often because of larger marks. In practice, any of these biases would be minimal against other biases of the thrower, but we are discussing idealisations. A 20-sided dice should reduce the bias of a 2-sided by distributing the weight from slight changes in paint more evenly, especially after mapping the 20 numbers to only two numbers. A 50-sided dice mapped to create only two values would be even better because it should distribute whatever weights and rough edges to an increased number of values, all of which gets lost when mapping to only two values.

A 6 sided dice is worse than either a 2 or 20 sided dice in some way, so we can ignore 6 sides when imagining the ideal scenario.

Physics is such a beast that there could be a discovery on how to make radioactive decay not-random.

you can't cause or  influence when an atom undergoes radioactive decay. plus you don't know exactly when it will decay. look it up.

I had given a reference.

[PrimeNumber7]

You also care that a particular outcome does not affect the next outcome, in other words, that each outcome is independent of all other outcomes.

If you have a stateless function, then it is theoretically possible to get {4,4,4,4,4} result, mentioned above. If you have some kind of state, then you can design your algorithm differently, just to pass some randomness tests. And that will make your outputs more random, but also less resistant to some attacks, because then you can assume that you will never get {4,4,4,4,4}, just because that value will fail some randomness tests. Of course, usually the size of the output will protect you from those attacks, and you will not even notice that potential weakness.

A dice roll should have a 1/6 chance of any given number being chosen. If for example, if a "roll" was a 4, then the chances of the next roll are:
1 - 95%
2 - 1%
3 - 1%
4 - 1%
5 - 1%
6 - 1%

if the previous roll was a 5, each of the above probabilities could be rotated by one index, so the probabilities would be 1, 95, 1, 1, 1, 1%. The probabilities could be similarly rotated for all six numbers.

The above weighting of the dice I believe would still pass randomness tests, because, over many tests, each number would be chosen 1/6 of the time.

If you are using a dice roll to generate a seed, you should care more than just that each outcome has the same probability. You also care that a particular outcome does not affect the next outcome, in other words, that each outcome is independent of all other outcomes.

dice rolls are independent of one another. that's just a fact. the harder thing is for each outcome to have the same probability. but if it's a fair dice then it's probably close enough.

A dice roll *should* be independent of one another. Often times, when someone is generating a private key via "dice rolls" they are actually generating a private key via some kind of simulated dice roll.

[DaveF]

Eliminating a lot of things, if you are using a wallet that has off the shelf parts and a list of what they use with a diagram and they publish the source code then *in theory* so long as you know the actual chip(s) they are using for RNG then you can be mostly assured it's safe.

Hardware wallets are a very very very small segment of what hardware randomness is used for. If people can't trust them then think about the number of devices that use them that would be impacted. Think about the number of video slots and stuff in casinos. If they are not random the amount that would be lost could be minor compared to any particular BTC hardware wallet.

-Dave

[goldkingcoiner]

Check out this thread started by nullius: https://bitcointalk.org/index.php?topic=5326468.0

The problem with randomness is that you don't know whether something isn't random until there has been enough data measured and checked.

Even though you can't verify randomness, you could combine multiple sources of randomness to make it "more random" as long as your combination algorithm isn't causing additional bias and your sources are independent. The best route imo is to color one kind of randomness with other kinds of randomness. If one sensor is mostly random, then are two sensors more random? You could color your hardware randomness with a memory-given random seed generated from a second location, and the combined number would probably be just a little bit more random if used correctly.

So, how do we verify that the hardware doesn't generate predictable entropy, regardless of whether the wallet developers have bad intentions or not? I don't care about the OS, let's assume you use an open-source one; my focus is on those who build the hardware that is used to generate randomness.

Predictable entropy? Not sure I understand? Like the rate of oxidation on microelectronic metal pins which can mess with the electrical flow in such ways that one could possibly guess which metals were being used in the chip or something and use that info to identify the part?

If predicting entropy is your game then from a physics perspective, that is impossible to tell at a certain tiny point but at a larger scale can be perhaps easier. But never with 100% accuracy.

Predictable entropy could be low entropy? It would encompass measurements of distribution, determinism, and independence.

One kind of predictability would be the distribution. There could be different random distributions: pink, brown, grey, etc noise are all types of noise and perfectly independent and random, but don't all have the same exact entropy. You would want a flat frequency spectrum, all values equally possible over all periods of time. "Random" is itself not the desired factor, but flatly distributed random with independence.

A predictably random distribution could also be something like Pi, which is dependent and deterministic, but is it random? Depends on the definition? Irrational numbers like pi are perfect examples of "predictable entropy". Pi looks entirely random. Pi is evenly distributed for each of 0-9 to 1,000,000,000,000 digits. There are no correlations with its own sequences of numbers as far as can be detected (https://doi.org/10.1080/00031305.2000.10474501). Pi is a deterministic sequence that will be calculated again and again as computers get more powerful. The gaps between prime numbers also come to mind as a predictable randomness.

I know it sounds paranoid, but I don't know what to answer if one ever made me such question. Like, sure, most of the hardware is very unlikely to have this kind of weakness, but what about hardware wallets? They're designed for solely transacting bitcoins and their random number generator, as in all hardware, isn't apparent.
..
If you are using a dice roll to generate a seed, you should care more than just that each outcome has the same probability. You also care that a particular outcome does not affect the next outcome, in other words, that each outcome is independent of all other outcomes.

It's not entirely paranoid. There was a flaw in a javascript code generating random numbers in some early addresses:
https://www.bleepingcomputer.com/news/security/old-javascript-crypto-flaw-puts-bitcoin-funds-at-risk/

You could use dice rolls, but you have to not influence the distribution with how you calculate the number. If you were to use a 6 sided dice, you could roll the dice log_6(2^256)= 99.03 times and convert a base-6 number to a 256-bit number.

If you wanted to be even more random - evenly distributed and independent - with dice, you could get a 20-sided dice but then collect the data in base-2 by saying every even number was 1 and odd number was zero, rolling it 32*16 times, and then converting that 32*16 bit number to a 32 hex / 64 byte character representation. This would reduce the bias towards any particular number. Obviously a bit of work, but this gets around that you might possibly have a small non-flat distribution in your dice rolls.

-

As for hardware, it depends on whether you need future randomness or something where you can control the historical randomness. Every system has flaws that prevent randomness in a very controlled future scenario.

There isn't anything that could be purely random without influence under the most controlled of circumstances (except maybe radioactivity, and that's a maybe). If you built your system off of thermal randomness, then I could cool your system. Radiofrequency waves? I could put your system in a shielded room. Even with radioactive decay, it's random but not a flat-spectrum and has exponential decay distributions. I'm not entirely convinced that it's always random - there are reports (which could be wrong) that radioactive decay is influenced by our distance from the sun http://arxivblog.com/?p=596 . Physics is such a beast that there could be a discovery on how to make radioactive decay not-random.

but if it's a fair dice then it's probably close enough.

I agree with your "it's close enough" here. If you have 128 bytes of complete entropy that no computer can crack for trillions of years, then do you need 10,000 bytes of entropy? Maybe, but hopefully not! At some point, we all make a choice as to what is good enough based on competing costs.

You can always be more random, independent, and evenly distributed. But where is good enough?

Unfortunately even with entropy as low as in the super-cooled superconductors of quantum computers you would still hit the wall for physical measurements that we call Heisenberg's Uncertainty Principle.

"Decoherence and the Appearance of a Classical World in Quantum Theory" by H. D. Zeh is a great related-topic read, I recommend it.

From a mathematical perspective, random is defined as: different events are observed following identical initial circumstances. Currently such a definition of random cannot exist within our deterministic laws of physics.

You can generate the randomness artificially with mathematics and code alone, yes. Low entropy would be technically impossible to detect if you ignore the physics perspective and don't create your randomness generator with only a few lines of code and a limited output or input.

So I think that the point of entropy detection is moot.
 

[kaggie]

Unfortunately even with entropy as low as in the super-cooled superconductors of quantum computers you would still hit the wall for physical measurements that we call Heisenberg's Uncertainty Principle.

You can generate the randomness artificially with mathematics and code alone, yes. Low entropy would be technically impossible to detect if you ignore the physics perspective and don't create your randomness generator with only a few lines of code and a limited output or input.

Or fortunately that quantum computers have this as a problem, leaving security for all of banking!

I think there are a few different questions here:
1) What is random enough to provide security for generational wealth?
2) What is the most random system that you could ever create?
3) Are there sources that we think are random that could ever be backtraced or controlled?
4) Even if you have a purely random source, how do you ensure a flat spectral density?

It doesn't take much to make something be impossibly random.
I recommend a very different style of book, "A Short Stay in Hell", which deals with a man who has to overcome randomness to get out of hell.

[LoyceV]

I know it sounds paranoid
~
Couldn't one of all these hardware wallet companies implement something like that and steal millions of dollars worth of BTC, in just one moment?

That's always on my mind too. I use hardware wallets, but it always feels like I can't fully trust them.

I'm not sure how plausible this kind of attack would be though.

Not knowing is what makes me paranoid

I took a look at ledger nano and trezor hardwares. I found that there is a certification called AIS31-certified RNG which is the best in the world when talking about entropy.

embedded in the Secure Element

Can you check if it's actually in there? What if some of the devices are shipped with a compromised RNG instead of the certified one?

If, say, Trezor is proved to generate predictable entropy and steals everyone's funds in just one moment, it'll harm the entire bitcoin economy.

Isn't it much more likely to happen from a software wallet? Say someone manages to push a compromised update, that uploads the wallet when it gets unlocked.

In theory if they do this, the seeds the devices will generate will be a rather small subset of all the possible seeds (so they can brute force them in a reasonable amount of time).
However, if this would happen, there's a very big chance collision would happen, and rather often, between different users' seeds/wallets. If this happens, most do post about it (especially if it's them losing money).

This is a good point. To prevent a collision, the number of possible wallets has to be much larger than the square of the number of wallets they sell. So, say they sell 10 million wallets and want less than 1% chance of a collision, there should be at least a billion different combinations per existing hardware wallet. That's still possible to brute-force, but doing all of them would mean 10¹⁶ combinations.

Imho for now it's pretty safe to assume they did play fair until now.

I think so too.

The best route imo is to color one kind of randomness with other kinds of randomness. If one sensor is mostly random, then are two sensors more random?

One easy way to do that is by creating a split-key vanity address. If you create both parts on different hardware with different software, it doesn't matter if one of them is compromised.

I find it easier to trust generic hardware (and software for that matter), than anything dedicated to Bitcoin. Just like I find it easier to buy generic hardware than buying a hardware wallet. I don't mind that any shop knows I own a printer, but I wouldn't want them to know I own a hardware wallet.

The generation of random numbers is too important to be left to chance.
Robert R. Coveyou, Oak Ridge National Laboratory

[garlonicon]

In theory if they do this, the seeds the devices will generate will be a rather small subset of all the possible seeds (so they can brute force them in a reasonable amount of time).
However, if this would happen, there's a very big chance collision would happen, and rather often, between different users' seeds/wallets. If this happens, most do post about it (especially if it's them losing money).

They can attack in a better way and make it much more clever. For example: some company could create some random 256-bit seed. Then, that seed can be used to derive public keys and to save some sample public key on each device, just by using some standard derivation path, or just by using things like device serial number to derive keys. Then, it could be possible to create 1-of-2 multisig each time when user needs a new key. And then, it is possible to just silently wait. To remain unnoticed, they can wait a lot of time and sweep coins only from some wallets, for example after a customer will notify them about lost keys. Then, they could sweep them and pretend that the user was hacked by using bad security practices (which, ironically, would be true, because he trusted that wallet).

[bitmover]

I took a look at ledger nano and trezor hardwares. I found that there is a certification called AIS31-certified RNG which is the best in the world when talking about entropy.

embedded in the Secure Element

Can you check if it's actually in there? What if some of the devices are shipped with a compromised RNG instead of the certified one?

You can check the hardware integrity by following this guide by the manufacturer

It shows how to open the hardware and check by yourself if everything is as expected.  There are even pictures of what to expect inside

https://support.ledger.com/hc/en-us/articles/4404382029329-Check-hardware-integrity?support=true

All Ledger devices pass the genuine check during the onboarding process and then each time when they connect to Manager in Ledger Live. Genuine Ledger devices hold a secret key that is set during manufacture. Only a genuine Ledger device can use its key to provide the cryptographic proof required to connect with Ledger’s secure server.

Advanced users additionally can check the hardware integrity of the Ledger device to check that it has not been tampered with. This article contains detailed technical information about the security of your device.
Important notice

    Please note that opening your Ledger device will void the warranty.
    Once opened, your Ledger device will no longer be refundable or exchangeable.
...

As an additional check, you can open the device to verify that no additional chip has been added, compared with the images below, and that the MCU is an STM32WB55 (on revisions 1, 2, 3) and STM32WB35 (on revision 4).
Hardware revisions


...

There is a lot more information there.

[NeuroticFish]

Can you check if it's actually in there? What if some of the devices are shipped with a compromised RNG instead of the certified one?

I'm not sure it's so much relevant. If they're evil enough they can easily show nice hardware and use internally their own rigged software random generator.
I mean if we go paranoid, there are plenty of ifs and buts...

[LoyceV]

You can check the hardware integrity by following this guide by the manufacturer

The hardware integrity check will only show tampering by third parties. This topic is about verifying the original hardware, and if the manufacturer changed the internals of a component, they could make it look the same.

If they're evil enough they can easily show nice hardware and use internally their own rigged software random generator.
I mean if we go paranoid, there are plenty of ifs and buts...

That was indeed my point.

[dkbit98]

What is the most random system that you could ever create?

I don't have to invent the wheel all over again, and most human beings don't have the skills to create random systems.
People are generally very bad and randomness and very good in repeating things, but using casino dices as random system is working just fine for centuries if not ages.
For most people this will be enough, but for going extreme you can always use radioactive decay with geigers counter, that is something you can't fake.

If they're evil enough they can easily show nice hardware and use internally their own rigged software random generator.

All software random generators are not giving true random results, that is why nobody is using them for anything serious.
I think that gambling websites and casinos are using them a lot, and you know what they say - house always wins

[NeuroticFish]

If they're evil enough they can easily show nice hardware and use internally their own rigged software random generator.

All software random generators are not giving true random results, that is why nobody is using them for anything serious.
I think that gambling websites and casinos are using them a lot, and you know what they say - house always wins

I think that you've missed the point of this topic.
The idea is not how would you make a really good system. The idea is: what if the HW contains a ticking bomb?
And since the point is to *not* create actual randomness while pretending to .. even software generator may do.

[dkbit98]

I think that you've missed the point of this topic.

I think that you are missing the point, and I was just replying to your statement about software random generators.
Title of this topic is about randmoness from hardware, and casino dices are perfect simple hardware that can be verified and it doesn't have any software that can be exploited.

The idea is not how would you make a really good system. The idea is: what if the HW contains a ticking bomb?

Someone can hide ticking bomb almost anywhere, but I didn't saw OP talking about bombs here, so your ''ideas'' doesn't make any sense to me...

[goldkingcoiner]

Unfortunately even with entropy as low as in the super-cooled superconductors of quantum computers you would still hit the wall for physical measurements that we call Heisenberg's Uncertainty Principle.

You can generate the randomness artificially with mathematics and code alone, yes. Low entropy would be technically impossible to detect if you ignore the physics perspective and don't create your randomness generator with only a few lines of code and a limited output or input.

Or fortunately that quantum computers have this as a problem, leaving security for all of banking!

I think there are a few different questions here:
1) What is random enough to provide security for generational wealth?
2) What is the most random system that you could ever create?
3) Are there sources that we think are random that could ever be backtraced or controlled?
4) Even if you have a purely random source, how do you ensure a flat spectral density?

It doesn't take much to make something be impossibly random.
I recommend a very different style of book, "A Short Stay in Hell", which deals with a man who has to overcome randomness to get out of hell.

Unfortunate for the curious 
Interesting questions indeed. I will try a stab at them but I am sure everyone else in the Development & Technical Discussion subforum knows a lot more about it than me. So take my answers with a grain of salt.

1. I think you can make anything infinitely random but that all means nothing if someone reads your code to understand how the randomness is generated. So your randomness is only as good as your security.
2. Perhaps data from as many high entropy sources as possible for the input and a multitude of security layers? I really don't know how to express something as truly random so I have no idea.
3. For example weather. Even with current technology we cannot accurately predict the weather. Nobody technically knows if next week will be 1 degrees hotter or colder than predicted. Although it can be easily guessed/predicted due to the fact there are not many viable temperature numbers to choose from.  
4. Not sure. Perhaps by adding white noise to the intensity in discrete time sequences?


edit: Thanks for the book recommendation. Sound interesting.

[LoyceV]

human beings don't have the skills to create random systems.

That's only true for reproducible "random" systems, like passwords. Creating something random as a human is very easy: if I draw something on a piece of paper, scan it, and hash it, there's no way anyone (including me) can ever reproduce it! Doesn't that make it random?

In fact, I think it's harder for a computer: I've seen (old) computers that started with the same "random" number after each reboot, because they had nothing "random" in there. Any kid with a pencil creates random data if you look close enough.

[dkbit98]

That's only true for reproducible "random" systems, like passwords. Creating something random as a human is very easy: if I draw something on a piece of paper, scan it, and hash it, there's no way anyone (including me) can ever reproduce it! Doesn't that make it random?

I could always find digital copy of your scan and reproduce your drawing easily, how do you think people created fake money, coins and paintings since the beginning of time.
If I can reproduce your painting in any way that means it's not truly random, and there is a bunch of academic papers and research that can prove why you wrong, and why you need to read more about this to understand it better.
People are bad not only bad in creating but they are also bad in detecting randomness because it's hard, and you can read more about it in this Berkeley study:
https://cocosci.princeton.edu/tom/papers/hard.pdf

[BlackHatCoiner]

if I draw something on a piece of paper, scan it, and hash it, there's no way anyone (including me) can ever reproduce it!

It'll definitely be messed up, but not random, or at least not as much as in other ways. There's a significant percentage of the human factor, how does your hand move, which shapes will you think of, at which rate will you repeat the shame shapes etc. It's the same as the mouse detector RNG of bitaddress.org.

That's the best I can do is: Take few dices, put them on a cup, start mixing them, verify that they're fair, redo it to generate entropy for the seed.

[n0nce]

if I draw something on a piece of paper, scan it, and hash it, there's no way anyone (including me) can ever reproduce it!

It'll definitely be messed up, but not random, or at least not as much as with other ways. There's a significant percentage of the human factor, how does your hand move, which shapes will you think of, at which rate will you repeat the shame shapes etc. It's the same as the mouse detector RNG of bitaddress.org.

That's the best I can do is: Take few dices, put them on a cup, start mixing them, verify that they're fair, redo it to generate entropy for the seed.

If you trust a few dice trows to verify the randomness / entropy / fairness of the coins, actually I remember some hardware wallets do have a 'random dice throw' feature. Of course, an evil chip manufacturer could theoretically generate the seeds with bad randomness and use the actual RNG just for the dice throw applet.

Most aspects have already been brought up, like RNG chips being used in other applications outside Bitcoin hardware wallets, but one thing I'd like to touch on is the legal side and open-source aspect. There are two attack vectors I can think of: (a) the chip is not doing what it's supposed to, and (b) the chip installed on the PCB is not the one they claim to be using.
The first one is only really viable if the company that makes the hardware wallet also makes the chips and if they manage to fool everyone in the business to manufacture something other than what is shown in the source files without any of this leaking to the public.

Since I don't think any wallet manufacturer today is making their own chip, I'd tend towards option (b): rebranded, faked secure elements. They could have the same pinout but have another chip inside and the correct writings on the package.
To really make sure this is not happening, the devices would need to be disassembled, the chip desoldered and via direct connection you could verify that it at least runs the communication protocol that it's supposed to and returns data as per the datasheet.
I'm not sure how thorough entities like OSHWA^{OSHWA Certification provides an easy and straightforward way for producers to indicate that their products meet a uniform and well-defined standard for open-source compliance} are, but so far I'm aware of two hardware wallets that were certified by them, out of which one has a secure element: Passport OSHWA certificate.

In theory, they should have verified that (b) is not happening and the devices are built to the open-source spec (with the correct chips and logic board whose files are released publicly).

[NotATether]

To everyone mentioning trying to eliminate a "4" from dice rolls:

If you don't want that particular outcome from a dice just use a 5-sided dice without a 4...

And similarly, if you want to exclude particular outcomes from a software RNG, just keep regenerating it until you get an acceptible value, this comes at no loss of entropy.

Intel RNGs in their procesors are intelligency-agency backdoored, from information I've gathered several months ago, so definately don't rely on RDRAND for anything important. I don't think AMD even has an RNG hardware instruction.

AIS13 (or was it 31 ) sounds good as well as whatever ARM is coming up with - it's an open standard anyway so you're free to trust an individual vendor that their impl. is free from tampering.

1) What is random enough to provide security for generational wealth?
2) What is the most random system that you could ever create?
3) Are there sources that we think are random that could ever be backtraced or controlled?

You generally only need 60-70 bits to ensure a random sequence that is unbreakable by criminals and govts. for the next ten years (never extrapolate beyond 10 years as the technological situation can change drastically by then).

There is no upper ceiling for entropy, but it'll be increasing proportionally to the length of the output sequence e.g. passwords.

CPU core temperatures can be artificially modulated by the hardware so that is not a particularly trustworthy source of entropy. Sound (from coil whine) would probably be a better choice as this can't be supressed by hardware.

[n0nce]

I just checked the Foundation Passport's security model again and it actually doesn't use the (closed source) secure element for randomness! I had this in my mind since another wallet does this and I looked up something about it recently.

Microchip ATECC608A secure element. This security chip is explicitly designed to safeguard private keys, but is simple enough that it does not execute any code. We use the 608a primarily for its secure key storage slots.

So the chip is only for storage, not for key generation / RNG like I hinted to earlier - at least on this hardware wallet_~n0nce~
[...]

Avalanche noise source. This open source implementation of a true random number generator allows for a provable source of entropy without any black-box silicon. Same general design used by bunnie in the Betrusted project.

The project they mention is this: https://betrusted.io/
It correctly states:

On-die RNGs such as ring-oscillator based RNGs leverage the metastability of sampling circuits to translate timing jitter into a random stream of bits. These are area and power efficient but are also tricky to verify. They are particularly vulnerable to subtle mask-editing attacks.

It then goes on to explain this 'Avalanche Noise Source' in great detail, which is very interesting and fascinating to me. The circuit is pretty simple and cheap to manufacture and doesn't require 'black box' components. Very clever. It allows companies like Foundation Devices to have an open-source RNG, even though the secure storage chip is closed-source.

[NotATether]

If you wanted to be even more random - evenly distributed and independent - with dice, you could get a 20-sided dice but then collect the data in base-2 by saying every even number was 1 and odd number was zero,

The thing is, a 20 sided dice has more biases than a 6 sided dice. The more sides the more bias. So that might not be a good idea.

Be very careful about the kind of dice you use because some brands of 6-sided dice are intentionally biased for larger numbers. In any case I suppose that a 2-sided dice (i.e. a coin) has the least bias of them all, and for this particular application has the benefit of being a factor of 256 (exactly 256 tosses).

[BlackHatCoiner]

You only need to roll a dice 99 times to get a 256-bit number. Which gives you a bitcoin private key.

Given that 4 out of the 6 results add 2 bits and 2 out of the 6 results add 1 bit, then each dice roll gives on average ~1.66 bits. That's 256/1.66 = ~154 times. But, there's no reason to do this for a bitcoin private key and not for a seed, which will then generate infinite keys.

[LoyceV]

if I draw something on a piece of paper, scan it, and hash it, there's no way anyone (including me) can ever reproduce it!

It'll definitely be messed up, but not random, or at least not as much as in other ways. There's a significant percentage of the human factor, how does your hand move, which shapes will you think of, at which rate will you repeat the shame shapes etc.

It's not only about the drawing, it's about the scanning. Or take a picture: you'll get millions of pixels, and each of them will be slightly different. Even if you draw the same thing, or even if you scan the same piece of paper again, it will be different. Hashing it means a totally different result.

[BlackHatCoiner]

Even if you draw the same thing, or even if you scan the same piece of paper again, it will be different.

But you will be closer to the answer, that's the weakness. While by rolling a fair dice, there's no human factor involved, meaning that if you tried a combination and failed, you have to restart from 0. Especially with the recognition and the abrupt development of neural networks, I wouldn't even want to bother with "random images".

[n0nce]

if I draw something on a piece of paper, scan it, and hash it, there's no way anyone (including me) can ever reproduce it!

It'll definitely be messed up, but not random, or at least not as much as in other ways. There's a significant percentage of the human factor, how does your hand move, which shapes will you think of, at which rate will you repeat the shame shapes etc.

It's not only about the drawing, it's about the scanning. Or take a picture: you'll get millions of pixels, and each of them will be slightly different. Even if you draw the same thing, or even if you scan the same piece of paper again, it will be different. Hashing it means a totally different result.

I would say it's infeasible today (and maybe even forever) to crack, however the entropy is definitely lower than true randomness, since images are generally not truly random pixel distributions. The scanning software and hardware could also add artifacts that are very repeatable patterns (even though invisible to the human eye), which weakens the randomness further.

It's common knowledge that 'humans can't really understand large numbers'.

For example, we know that a million, a billion and a trillion are massive numbers — but most people have a hard time understanding how significant the difference is between them.

There are theories about our brains working on a log scale instead of linear and ideas like this, but I don't know if anything's really proven today.
I digress; you're right when you say there's no way anyone (including me) can ever reproduce it, but that doesn't mean it's nearly 'as random' as coin tosses.

[dkbit98]

I just checked the Foundation Passport's security model again and it actually doesn't use the (closed source) secure element for randomness! I had this in my mind since another wallet does this and I looked up something about it recently.

This is correct, and I saw this last year when I was investigating how all hardware wallets are doing entropy and generating seed words.
Even if Passport wallet forked from original ColdCard device, they are using very much different approach, they improved original design and they taken best parts from different hardware wallets.
Avalanche noise source is really interesting and I think that only Passport is using it from all hardware wallets, I think Coldcard is using internal true random number generator from same secure element, or they use D6 Dice Rolls.

I would say it's infeasible today (and maybe even forever) to crack, however the entropy is definitely lower than true randomness, since images are generally not truly random pixel distributions. The scanning software and hardware could also add artifacts that are very repeatable patterns (even though invisible to the human eye), which weakens the randomness further.

Exactly!
Remember those invisible yellow dots that many printers have?
I bet scanner have something similar or even worse, and we all know that when you take photo with camera you are getting all metadata info in package.
Even old typing machines had unique pattern for some letters so you could identify them, even if you try to type differently.

It's not only about the drawing, it's about the scanning. Or take a picture: you'll get millions of pixels, and each of them will be slightly different. Even if you draw the same thing, or even if you scan the same piece of paper again, it will be different. Hashing it means a totally different result.

This is simply not a true randomness, even if you think it is.

[n0nce]

I just checked the Foundation Passport's security model again and it actually doesn't use the (closed source) secure element for randomness! I had this in my mind since another wallet does this and I looked up something about it recently.

This is correct, and I saw this last year when I was investigating how all hardware wallets are doing entropy and generating seed words.
Even if Passport wallet forked from original ColdCard device, they are using very much different approach, they improved original design and they taken best parts from different hardware wallets.
Avalanche noise source is really interesting and I think that only Passport is using it from all hardware wallets, I think Coldcard is using internal true random number generator from same secure element, or they use D6 Dice Rolls.

I looked it up; ColdCard uses the closed-source RNG inside the main processor chip!

The COLDCARD uses the hardware TRNG (True Random Number Generator), inside the main chip. This is a dedicated hardware subsystem that measures analog noise produced by a special transistor.

The main processor is a STM32L496RGT6; a closed-source 32-bit processor from STmicroelectronics.

The new chip (STM32L496RGT6) has 320 KiB: an increase of 2.5 times. This is the only major difference in the new chip, and it does come at a slight cost increase, as you would expect.

I'd much rather trust Passport's Avalance noise source circuit that is documented and open-source, built right on the PCB instead of something that resides in a black-box chip.
In fact, CoinKite themselves recommend to at least add some entropy through dice rolls or to use just dice rolls, but I doubt how many users will actually do that. They even sell dice; maybe a sign of them not being very confident about this 'TRNG' entropy.

During seed picking process, you have the option of "adding dice rolls" to increase the entropy and/or mitigate any possible manipulation. You can add as many rolls as you wish, and the entropy (about 2.5 bits per roll) will be added to the 256 bits of entropy already picked.

You may completely bypass the above seed picking method, and use just dice rolls if desired. This process is documented in great depth here on our docs and includes a number of different ways to verify our SHA256 math for yourself. We even sell a package of 100 tiny dice so you can roll 256 bits of your own entropy in a single toss.

[j2002ba2]

You only need to roll a dice 99 times to get a 256-bit number. Which gives you a bitcoin private key.

Given that 4 out of the 6 results add 2 bits and 2 out of the 6 results add 1 bit, then each dice roll gives on average ~1.66 bits. That's 256/1.66 = ~154 times. But, there's no reason to do this for a bitcoin private key and not for a seed, which will then generate infinite keys.

This looks very wrong.

Rolling a dice gives certainly more than 2 bits uncertainty, since 2 bits is one of 4 choices, while the dice is one in 6.

The correct way of calculating it is log₂6 = 2.5849...

Indeed 256 bits of uncertainty is very slightly more than 99 dice rolls.

You are loosing information when ignoring that there are 2 more choices in the first case, and 4 more in the second.

It is easy to do a check: write down the number 555..5 (99 times) in base 6, and convert it to hexadecimal (base 16).
The result is very close to 2²⁵⁶
F0BB8A1BBDE9163B9E053E8F918BF8E4D34034D7FFFFFFFFFFFFFFFFFFFFFFFF
One more roll makes it overflow (100 rolls)
5A4653CA673768565B41F775D6947D55CF3813D0FFFFFFFFFFFFFFFFFFFFFFFFF

Look at it this way: rolling 2 dices gives one in 36 choices, which is more than 5 bits (1 in 32). Using your scheme we get at most 4 bits, and sometimes even 2.

[BlackHatCoiner]

Rolling a dice gives certainly more than 2 bits uncertainty, since 2 bits is one of 4 choices, while the dice is one in 6.

I don't follow. In 4 out of the 6 results, it gives 2 bits (00, 01, 10, 11) while in 2 out of the 6 results, it gives 1 bit (0, 1). Isn't this (4*2 + 2*1)/6 = 10/6 = 1.666 bits in each result on average?

[Pmalek]

I'd much rather trust Passport's Avalance noise source circuit that is documented and open-source, built right on the PCB instead of something that resides in a black-box chip.

I certainly don't have the technical skills or coding knowledge to verify these things myself, so all I can do is ask. How long has it been around? Has it been thoroughly tested and verified by industry experts that can be trusted? Besides being open-source, what else does this implementation of a true random number generator offer compared to closed-source models? At least on paper since no one can check what happens in a close-source environment. 

[Welsh]

So, going back to the original threads discussion point, and deviating ever so slightly. Are we ever going to see truly open source hardware in personal computers, since not everyone using Bitcoin is going to be purchasing a hardware wallet, so while hardware wallets likely will need to be implementing open source chips in order to compete with each other, the issue is that the hardware that we use every day, is the real issue.

If we achieve mass adoption, then that's the problem for me. Since, technically most computer users are either using intel or AMD, that's effectively decentralising Bitcoin, if the hardware is compromised, since everyone who has generated a private key on that machine could be compromised, which lets face it is probably the majority.

Do we think there's a big enough market, and enough demand to make it profitable to create open source hardware? It seems to me we are going down the path of making things more obscured. Take phones for example, the charging ports changing every couple of years, specialised ports being made to make it difficult for cheaper brands to replicate, removable batteries now a thing of the past, all to make sure that you continue buying new hardware, but not just that buying hardware from those that are putting these restrictions in their products in the first place.

My fear is, that even if this question is a little bit paranoid right now, is it going to be paranoid to be worried about such things down the line? After all, it seems manufacturers have a tactic in hand to keep you buying from only them, and for the large part don't care about longevity of their devices any more, and instead want to keep you buying new products, which I think could be argued to being unethical already. While compromising private keys or the way entropy is generated then, on their devices might not be the target vector of choice, collecting data is a huge one. We see it baked into every piece of software out there these days, and I imagine it's only a matter of time that the hardware itself collects data on you.
 

In fact, CoinKite themselves recommend to at least add some entropy through dice rolls or to use just dice rolls, but I doubt how many users will actually do that. They even sell dice; maybe a sign of them not being very confident about this 'TRNG' entropy.

Yeah, but there should be a easier way of going about it. Maybe, something that is provably fair using their software, rather than suggesting an alternative method that to be honest is probably only suggested for advanced users. I like to think we should be making it as simple as possible to have the upmost security, and this should be achievable by anyone, with or without technical knowledge. At the moment, we're a long way off that. However, if we truly want mass adoption, then we need to convince people they don't need banks, and they can rely on it without having too much knowledge. I don't think we're quite there yet, despite hardware wallets definitely taking us leaps, and bounds to where we were before them.

[n0nce]

Rolling a dice gives certainly more than 2 bits uncertainty, since 2 bits is one of 4 choices, while the dice is one in 6.

I don't follow. In 4 out of the 6 results, it gives 2 bits (00, 01, 10, 11) while in 2 out of the 6 results, it gives 1 bit (0, 1). Isn't this (4*2 + 2*1)/6 = 10/6 = 1.666 bits in each result on average?

Oh no, no, no, you can't do that! You can't just split and add probabilities at will.

Entropy works like this:

So, of course, in our case P(x_i) is always 1/6 and we get
H(X) = -1 * ((1/6)*log₂(1/6))*6
     = -1 * (1/6) * 6 * (log₂(1/6))
     = -1 * -2.5849625...
     = 2.5849625...

I'd much rather trust Passport's Avalance noise source circuit that is documented and open-source, built right on the PCB instead of something that resides in a black-box chip.

I certainly don't have the technical skills or coding knowledge to verify these things myself, so all I can do is ask. How long has it been around? Has it been thoroughly tested and verified by industry experts that can be trusted? Besides being open-source, what else does this implementation of a true random number generator offer compared to closed-source models? At least on paper since no one can check what happens in a close-source environment. 

Good questions! Avalanche noise is a concept that has been around a long time now. I can't find when exactly it was discovered, but it's like decades old as far as I know.
Of course, I don't know if any independent experts have tested Foundation Devices' implementation of it, but the actual possibility of it being tested simply doesn't exist in a closed-off chip. There is no way for anyone to really verify the randomness / entropy from a closed-source chip, while you could verify the entropy of an open PCB's avalanche noise circuit.
I hope this answers your question about 'what does this implementation of a true random number generator offer compared to closed-source models?'.

I'll look more into this topic in the future and might try my own luck at measuring the circuit's characteristics myself to try drawing some conclusions.

Do we think there's a big enough market, and enough demand to make it profitable to create open source hardware? It seems to me we are going down the path of making things more obscured. Take phones for example, the charging ports changing every couple of years, specialised ports being made to make it difficult for cheaper brands to replicate, removable batteries now a thing of the past, all to make sure that you continue buying new hardware, but not just that buying hardware from those that are putting these restrictions in their products in the first place.

It's a bit off-topic, but we've seen good developments with RISC-V in the last few years, there are free FPGA cores and also hardware chips available to purchase, such as in the very readily available M5Stick-V that someone even used to build a signer with.
The Bitcoin community is not the only group of people that tries to get more open-source hardware to be built, but I don't know much more about the topic; I'd be happy to see more of this being developed, though!

In fact, CoinKite themselves recommend to at least add some entropy through dice rolls or to use just dice rolls, but I doubt how many users will actually do that. They even sell dice; maybe a sign of them not being very confident about this 'TRNG' entropy.

Yeah, but there should be a easier way of going about it.

One solution would be to have an open-source circuit on the PCB like the Foundation Passport. No need to use dice there.

[dkbit98]

Do we think there's a big enough market, and enough demand to make it profitable to create open source hardware?

Some people are working hard to make this happen and there is already a lot of open source open OSHWA certified hardware and computer components, that is how Passport and Trezor got certified.
There is also RISC-V chips that are alternative for commercial widely used AMD and Intel chips, they are open source and you can even find RISC-V boards and whole computers.
It is still early to say for sure, but I can see a future with this being used everywhere as alternative for more popular solutions we have now.
Let's not forget that Trezor is also working on their open-source-ish chip that should have general use case for many other devices, not just for hardware wallets.

Take phones for example, the charging ports changing every couple of years, specialised ports being made to make it difficult for cheaper brands to replicate, removable batteries now a thing of the past, all to make sure that you continue buying new hardware, but not just that buying hardware from those that are putting these restrictions in their products in the first place.

This is not the case only with smartphones, but with laptops and netbooks also, even for professional machines.
They are integrating batteries and few years ago they removed option to separately upgrade and change CPU's, so most of the things are now soldered on board.

[LoyceV]

Are we ever going to see truly open source hardware in personal computers

I don't think that's going to help. It will allow other manufacturers to produce the same chips, and the customer can choose which one to buy. But if any of those manufacturers changes something (say a fake random generator) in the hardware, it will be impossible for the customer to detect.

Rolling a dice gives certainly more than 2 bits uncertainty, since 2 bits is one of 4 choices, while the dice is one in 6.

I don't follow. In 4 out of the 6 results, it gives 2 bits (00, 01, 10, 11) while in 2 out of the 6 results, it gives 1 bit (0, 1). Isn't this (4*2 + 2*1)/6 = 10/6 = 1.666 bits in each result on average?

Oh no, no, no, you can't do that! You can't just split and add probabilities at will.

Aren't both j2002ba2 and BlackHatCoiner right? Yes, a dice roll produces 2.58 bits of entropy, but no, you're not using all of it when writing down dice rolls. If you roll 1, 2, 3 or 4, you treat the dice as if it's a 4-sided dice that produces 2 bits of entropy. And if you roll 5 or 6, you treat the dice as if you flipped a coin. So you end up with 1.66 bits of entropy on average per roll.

[n0nce]

Are we ever going to see truly open source hardware in personal computers

I don't think that's going to help. It will allow other manufacturers to produce the same chips, and the customer can choose which one to buy. But if any of those manufacturers changes something (say a fake random generator) in the hardware, it will be impossible for the customer to detect.

If you market your laptop as open-source, running stock RISC-V, but have something else under the hood, I'm pretty sure that's considered fraud. I don't know if as a business (e.g. if pressured by agencies or whatnot), I'd rather just go back to AMD / Intel (with some excuse for the customers) than having a fake RISC-V chip produced and hoping nobody leaks anything (factory, production line, engineers, ...) about this fraud.
Also never forget 'making a chip' is a very involved process that costs a ton of money, so if someone finds out, you can't just 'quickly remove the backdoor again' or so. The stencil masks are already made and manufacturing them anew will cost millions again.

Rolling a dice gives certainly more than 2 bits uncertainty, since 2 bits is one of 4 choices, while the dice is one in 6.

I don't follow. In 4 out of the 6 results, it gives 2 bits (00, 01, 10, 11) while in 2 out of the 6 results, it gives 1 bit (0, 1). Isn't this (4*2 + 2*1)/6 = 10/6 = 1.666 bits in each result on average?

Oh no, no, no, you can't do that! You can't just split and add probabilities at will.

Aren't both j2002ba2 and BlackHatCoiner right? Yes, a dice roll produces 2.58 bits of entropy, but no, you're not using all of it when writing down dice rolls. If you roll 1, 2, 3 or 4, you treat the dice as if it's a 4-sided dice that produces 2 bits of entropy. And if you roll 5 or 6, you treat the dice as if you flipped a coin. So you end up with 1.66 bits of entropy on average per roll.

That's how people use dice rolls for deducing a seed? They handle it differently based on the number they get? Then the formula from BlackHatCoiner makes sense, but it seems like a questionable way to create a seed. At that point just toss a coin or just use the dice as a 50/50 randomness; 0 bit for even and 1 for odd number on top.

[LoyceV]

That's how people use dice rolls for deducing a seed? They handle it differently based on the number they get? Then the formula from BlackHatCoiner makes sense, but it seems like a questionable way to create a seed. At that point just toss a coin or just use the dice as a 50/50 randomness; 0 bit for even and 1 for odd number on top.

A dice is slightly faster than a coin, because it produces 2 bits most of the time.

[n0nce]

That's how people use dice rolls for deducing a seed? They handle it differently based on the number they get? Then the formula from BlackHatCoiner makes sense, but it seems like a questionable way to create a seed. At that point just toss a coin or just use the dice as a 50/50 randomness; 0 bit for even and 1 for odd number on top.

A dice is slightly faster than a coin, because it produces 2 bits most of the time.

I know; I'm honest, I haven't thought through all the probabilities yet, but it feels wrong somehow. Like, those 2-bit throws are 2x as likely as the 1-bit throws, so it should be all fine, but to fully trust this technique, I'd either need to write it out or save myself that time and just spend a bit more time doing it with a coin..
For convenience, I prefer to have an open-source, probe-able circuit that I can verify. So in the near future I'll probably open up the Passport and fire up the oscilloscope.

[LoyceV]

I know; I'm honest, I haven't thought through all the probabilities yet, but it feels wrong somehow. Like, those 2-bit throws are 2x as likely as the 1-bit throws, so it should be all fine, but to fully trust this technique, I'd either need to write it out

To me, this feels perfectly fine and logical
If you roll a dice, the first bit is either a 0 or a 1, and both have 50% chance. The same for the second bit. It doesn't matter if the bits from from 1-4 or from 5-6. I can extrapolate from there

[larry_vw_1955]

Aren't both j2002ba2 and BlackHatCoiner right? Yes, a dice roll produces 2.58 bits of entropy, but no, you're not using all of it when writing down dice rolls. If you roll 1, 2, 3 or 4, you treat the dice as if it's a 4-sided dice that produces 2 bits of entropy. And if you roll 5 or 6, you treat the dice as if you flipped a coin. So you end up with 1.66 bits of entropy on average per roll.

All you have to do is roll a dice 99 times. There's no need to do what you are suggesting. It just takes longer that way. You could even be more anal about it and treat 1,2,3 as heads and 4,5,6 as tails but there's no benefit to doing that. The downside is it takes way longer. Another thing to keep in mind about your method is it could sometimes generate invalid private keys. That means you will have to have a way to detect that and then repeat the entire procedure all over again.

[larry_vw_1955]

Are we ever going to see truly open source hardware in personal computers

I don't think that's going to help. It will allow other manufacturers to produce the same chips, and the customer can choose which one to buy. But if any of those manufacturers changes something (say a fake random generator) in the hardware, it will be impossible for the customer to detect.

what's wrong with using RDRAND or RDSEED? i know there's people that have a conspiracy theory that those are having a backdoor but it's intel. come on! bonus points is, if you have a modern computer, you're good to go.

[n0nce]

Are we ever going to see truly open source hardware in personal computers

I don't think that's going to help. It will allow other manufacturers to produce the same chips, and the customer can choose which one to buy. But if any of those manufacturers changes something (say a fake random generator) in the hardware, it will be impossible for the customer to detect.

what's wrong with using RDRAND or RDSEED? i know there's people that have a conspiracy theory that those are having a backdoor but it's intel. come on! bonus points is, if you have a modern computer, you're good to go.

Are you seriously suggesting that Intel chips have a zero chance to include a backdoor?
Because I've got a newsflash for you: https://fossbytes.com/intel-processor-backdoor-management-engine/

As well as: https://meltdownattack.com/
Intel did not disclose their knowledge of these vulnerabilities with the public and / or release fixes, until security researchers discovered them. There is no way of knowing for sure if or who they shared these vulnerabilities with or if they're even built-in by design. But I wouldn't put too much trust in Intel chips when it comes to having really good hardware entropy.
https://www.macrumors.com/2018/02/22/intel-government-meltdown-spectre-disclosure/

Keep in mind it's not just about backdoors; RNGs can also simply be implemented badly, which would be hard to test / identify.

[dkbit98]

what's wrong with using RDRAND or RDSEED? i know there's people that have a conspiracy theory that those are having a backdoor but it's intel. come on! bonus points is, if you have a modern computer, you're good to go.

YOu are digging up moths old topic from death and than you are speaking nonsense like this  
It's no conspiracy theories, it's well know fact that Intel has hidden operating system inside that is called Intel Management (AMD has it's own version) and they are sending information all the time.
Only way I know that people managed to mitigate this threat is with flashing open source firmware Coreboot, but you need to use second device for that, and it's not exactly newbie friendly procedure.
Even if we disregard that, bottom line is that this is not giving true random results.

Intel did not disclose their knowledge of these vulnerabilities with the public and / or release fixes, until security researchers discovered them. There is no way of knowing for sure if or who they shared these vulnerabilities with or if they're even built-in by design. But I wouldn't put too much trust in Intel chips when it comes to having really good hardware entropy.

Funny thing about Spectre and Meltdown is that fixes slow down processors speed considerably, so Intel gave more reason for people to buy new chips that didn't have much better speed initially

[larry_vw_1955]

Are you seriously suggesting that Intel chips have a zero chance to include a backdoor?
Because I've got a newsflash for you: https://fossbytes.com/intel-processor-backdoor-management-engine/

ok in no way am I an expert on computer cpu architecture but that article is from 2016. 8 years ago. maybe things have changed since then. with new cpus that intel put out. at this point we are talking about 8+ year old cpus. maybe it's time to upgrade if someone has concerns about the safety of their computing platform.

As well as: https://meltdownattack.com/
Intel did not disclose their knowledge of these vulnerabilities with the public and / or release fixes, until security researchers discovered them. There is no way of knowing for sure if or who they shared these vulnerabilities with or if they're even built-in by design.

Well, I think that's kind of an esoteric vulnerability given that even on the webpage, it admits "they don't know".

Has Meltdown or Spectre been abused in the wild?
We don't know.

As well, I'm not sure intel deserves to have their balls busted big time of something that old that long ago.

But I wouldn't put too much trust in Intel chips when it comes to having really good hardware entropy.
https://www.macrumors.com/2018/02/22/intel-government-meltdown-spectre-disclosure/

I don't see what that situation has anything to do with the RDRAND and RDSEED features in their cpus though. In general I think Intel is a competent company with high quality cpus. That's why they have stayed the king for ever since PCs became a thing. Oh and before we bash them too much, they did get into making bitcoin miners too.

Keep in mind it's not just about backdoors; RNGs can also simply be implemented badly, which would be hard to test / identify.

Intel has provided documentation about how their RDRAND and RDSEED work. Believe it or not. Trust it or not. But they provided the docs.

Even if we disregard that, bottom line is that this is not giving true random results.

Well I don't know how you come to that conclusion but the only way I would believe it is if I seen it with my own eyes. I'd like to test RDSEED out and see what it can do. But in the mean time, feel free to share a 10 MB file of output from it so it can be statistically analyzed. Then we have something to talk about.

[o_e_l_e_o]

ok in no way am I an expert on computer cpu architecture but that article is from 2016. 8 years ago. maybe things have changed since then.

They haven't. Intel's Management Engine is still being included in every chip they produce.

As well, I'm not sure intel deserves to have their balls busted big time of something that old that long ago.

6 years is "long ago"? Hardly. And how long is enough to forgive a company for sneaking a government funded backdoor in to billions of devices?

Intel has provided documentation about how their RDRAND and RDSEED work. Believe it or not. Trust it or not. But they provided the docs.

And you expect a company which might be putting a backdoor in to their products to release documentation which says they have put a backdoor in to their products?

Further reading: https://archive.nytimes.com/www.nytimes.com/interactive/2013/09/05/us/documents-reveal-nsa-campaign-against-encryption.html

[LoyceV]

ok in no way am I an expert on computer cpu architecture but that article is from 2016. 8 years ago. maybe things have changed since then.

They haven't. Intel's Management Engine is still being included in every chip they produce.

It's quite naive to assume a company stops including back doors after being discovered. If anything, the question to ask should be whether or not they added new ones that haven't been discovered yet.

[ABCbits]

ok in no way am I an expert on computer cpu architecture but that article is from 2016. 8 years ago. maybe things have changed since then. with new cpus that intel put out. at this point we are talking about 8+ year old cpus. maybe it's time to upgrade if someone has concerns about the safety of their computing platform.

Nothing changed since then. It's still exist on newest Intel CPU (12th gen Alder Lake). It's explicitly mentioned on their product brief[6].

Keep in mind it's not just about backdoors; RNGs can also simply be implemented badly, which would be hard to test / identify.

Intel has provided documentation about how their RDRAND and RDSEED work. Believe it or not. Trust it or not. But they provided the docs.

Let's see their documentation[1].

RDRAND retrieves a hardware-generated random value from the SP800-90A compliant DRGB and

RDSEED retrieves a hardware-generated random seed value from the SP800-90B and

Both of them are standard from NIST[2-3]. Based on leak by Edward Snowden, NSA influence NIST to make weaker standard[4] and it's been predicted by expert since 2007[5].

[1] https://www.intel.com/content/www/us/en/developer/articles/guide/intel-digital-random-number-generator-drng-software-implementation-guide.html
[2] https://csrc.nist.gov/publications/detail/sp/800-90a/rev-1/final
[3] https://csrc.nist.gov/publications/detail/sp/800-90b/final
[4] https://web.archive.org/web/20130910030443/http://fcw.com/Articles/2013/09/06/NSA-NIST-standards.aspx
[5] https://archive.ph/20120919094854/http://www.wired.com/politics/security/commentary/securitymatters/2007/11/securitymatters_1115
[6] https://www.intel.com/content/www/us/en/products/docs/processors/embedded/12th-gen-iot-desktop-processors-brief.html

[NotATether]

Are you seriously suggesting that Intel chips have a zero chance to include a backdoor?
Because I've got a newsflash for you: https://fossbytes.com/intel-processor-backdoor-management-engine/

ok in no way am I an expert on computer cpu architecture but that article is from 2016. 8 years ago. maybe things have changed since then. with new cpus that intel put out. at this point we are talking about 8+ year old cpus. maybe it's time to upgrade if someone has concerns about the safety of their computing platform.

Now I know that Management Engine has no reason to be used on home systems the way it is designed, but if someone really doesn't like this feature, they can run a version of the Linux kernel that has disabled vPro support (and whatever the counterpart is called in AMD). No need for strange rituals of using ancient hardware with obscure distributions like what Richard Stallman is doing.

[dkbit98]

Well I don't know how you come to that conclusion but the only way I would believe it is if I seen it with my own eyes. I'd like to test RDSEED out and see what it can do. But in the mean time, feel free to share a 10 MB file of output from it so it can be statistically analyzed. Then we have something to talk about.

You already believe in so many things in your life that you never saw with your own eyes, so I don't know why this would be any different.
It's common sense and you can ask any tech expert that understands more how to achieve random results, but if you want to continue playing this game, than go for it.

They haven't. Intel's Management Engine is still being included in every chip they produce.

Their main competition is called AMD Platform Security Processor (PSP), but it is almost the same thing like in Intel microchips.
It's not impossible to minimize both of this processes in some machines, but this is not exactly newbie friendly task.

Now I know that Management Engine has no reason to be used on home systems the way it is designed, but if someone really doesn't like this feature, they can run a version of the Linux kernel that has disabled vPro support (and whatever the counterpart is called in AMD). No need for strange rituals of using ancient hardware with obscure distributions like what Richard Stallman is doing.

It's impossible to really disable this with kernel or any software patch, because this is hardware based problem.
Even with installing special BIOS version that have option to disable Intel Management, you are not really disabling anything.

[larry_vw_1955]

6 years is "long ago"? Hardly. And how long is enough to forgive a company for sneaking a government funded backdoor in to billions of devices?

6 years is long enough to know if there was some affect from this supposed backdooring of "billions of devices". you would think if its happening to "billions of devices", it would be happening to all of us right now too.

And you expect a company which might be putting a backdoor in to their products to release documentation which says they have put a backdoor in to their products?

well let's take a look at what intel themself says about IME:

At system initialization, the Intel® Management Engine loads its code from system flash memory. This allows the Intel® Management Engine to be up before the main operating system is started. For run-time data storage, the Intel® Management Engine has access to a protected area of system memory (in addition to a small amount of on-chip cache memory for faster and more efficient processing).

So what exactly was the result of those 32 lawsuits? https://www.theverge.com/2018/2/16/17020048/intel-spectre-meltdown-class-action-lawsuits

Further reading: https://archive.nytimes.com/www.nytimes.com/interactive/2013/09/05/us/documents-reveal-nsa-campaign-against-encryption.html

that document never mentions Intel though.

at any rate, i dont see intel as a bad guy and would just like to sometime testout rdseed to see how random its output looks. if it looks random enough maybe it's good enough. but at some point i would like one of those usb hardware RNGs because i think they might be above this type of criticism. but they do cost a good bit. like $60 or $70. for the TrueRNG. off amazon. but then i wouldn't have to worry about if my output was truly random or known by some 3rd party too.

[o_e_l_e_o]

6 years is long enough to know if there was some affect from this supposed backdooring of "billions of devices".

Why is it? Have you seen just how much mass surveillance the US government was undertaking in secret before the Snowden leaks? And there is no telling what other programs they are running, unbeknownst to the general population.

So what exactly was the result of those 32 lawsuits?

As far as I am aware, and someone can correct me if I'm wrong, the lawsuits in question were only to determine whether or not Intel were liable for making statements which were misleading or not fully revealing the details of their products. They had nothing to do with whether or not a backdoor actually existed or who funded it.

that document never mentions Intel though.

And I wouldn't expect it to. They are obviously not going to go naming individual companies, since if the document leaked (as it has done) then adversaries know exactly which companies are complicit. But "Insert vulnerabilities in to commercial encryption systems, IT systems, networks, and endpoint communications devices" is pretty clear.

[n0nce]

6 years is long enough to know if there was some affect from this supposed backdooring of "billions of devices".

Why is it? Have you seen just how much mass surveillance the US government was undertaking in secret before the Snowden leaks? And there is no telling what other programs they are running, unbeknownst to the general population.

That's the nasty thing about surveillance: without whistleblowers / leaks, there is no way of knowing whether you're affected. Creating a false sense of security. Combine that with powerful 'nothing to hide propaganda'.. The rest is history.

would just like to sometime testout rdseed to see how random its output looks. if it looks random enough maybe it's good enough.

Do you already have a plan for evaluating the entropy of it?

I mentioned it earlier in this thread; I think it's just much easier to trust physical entropy (like dice throws) or a relatively straight-forward open-source 'avalanche' circuit on a PCB.

[larry_vw_1955]

Do you already have a plan for evaluating the entropy of it?

I used https://www.fourmilab.ch/random/ in the past to measure the "entropy" of linux /dev/random from one of my machines. I assume I would do the same thing with this one. Their ent program the output is kind of confusing except for the option that shows character counts. Which is what I basically go off of. They claim:

We interpret the percentage as the degree to which the sequence tested is suspected of being non-random. If the percentage is greater than 99% or less than 1%, the sequence is almost certainly not random.

But they don't explain why or how.

I did my own chi-square test and it concluded do not reject the null hypothesis (I already knew it would though based on the histogram output) so I'm not worried about it. Their program doesn't appear to be open source (CORRECTION:actually it IS open source: they have a github link on the web page) all you get is an exe file. All you need is the exe file and just run it from a command line. in windows!

With all of that said, to have RDSEED the CPU needs to be intel 5th gen cpu or higher. only one of my machines is that

I mentioned it earlier in this thread; I think it's just much easier to trust physical entropy (like dice throws) or a relatively straight-forward open-source 'avalanche' circuit on a PCB.

Yeah physical entropy is the way to go for low volume needs which most of us fall into. I trust that the most at the end of the day. Not any of these electronic methods as good as they might seem, you can't really see what is going on. You have to trust what you can't see. Trust past results, trust that it is performing the same as past results. The electronic methods are fun though to investigate. And they might find uses in higher volume applications.

[n0nce]

Do you already have a plan for evaluating the entropy of it?

I used https://www.fourmilab.ch/random/ in the past to measure the "entropy" of linux /dev/random from one of my machines. I assume I would do the same thing with this one. Their ent program the output is kind of confusing except for the option that shows character counts. Which is what I basically go off of. They claim:

I don't think this is suited for your application. This program gives you the entropy per byte / character for evaluating data density of a file. It should give a high entropy result, even if the PRNG was seeded with a known seed which would then be used to reconstruct the randomness.
I may be wrong, but I think a program that gives you entropy 'per 64-byte seed' (instead of per-byte) across a large set of generated seeds, instead of calculating entropy across a stream of bytes.

I mentioned it earlier in this thread; I think it's just much easier to trust physical entropy (like dice throws) or a relatively straight-forward open-source 'avalanche' circuit on a PCB.

Yeah physical entropy is the way to go for low volume needs which most of us fall into. I trust that the most at the end of the day. Not any of these electronic methods as good as they might seem, you can't really see what is going on. You have to trust what you can't see. Trust past results, trust that it is performing the same as past results. The electronic methods are fun though to investigate. And they might find uses in higher volume applications.

Well, the 'avalanche noise source' electronic method can actually be observed ('see what is going on'); you do need some lab equipment, though. Keep in mind that just visually inspecting the circuit can already give you some confidence that you received the circuit actually specified in the schematic. Inspecting the schematic tells you what the circuit does, so sneaking in some backdoor is going to be pretty hard on such a device.

[larry_vw_1955]

I don't think this is suited for your application. This program gives you the entropy per byte / character for evaluating data density of a file.

yeah probably it's not but at least I can see character counts and get a good idea of there's any bias in them. not sure of a tool that could take a file of hex private keys and do what you're suggesting.

It should give a high entropy result, even if the PRNG was seeded with a known seed which would then be used to reconstruct the randomness.

it gave Entropy = 4.053136 bits per byte.
that was for a file that had 125,000 hex private keys in it.
apparently it treat each character as 8 bits.

When i ran it with the -b option i was kind of surprised though that 1s and 0s did not seem to occur at an equal frequency at all. there was a pretty big imbalance there. but i'm not sure if that's an issue. but we're talking not 50/50 not even close.

I may be wrong, but I think a program that gives you entropy 'per 64-byte seed' (instead of per-byte) across a large set of generated seeds, instead of calculating entropy across a stream of bytes.

If you're using the H(X) formula for entropy you mentioned earlier in the thread then I don't see how that formula could really be useful since if you're taking your universe of possible outcomes to be all 64-byte seeds, then it would be highly unlikely that any of them were duplicated even in a massive file. Thus you would obtain maximum entropy every time on every test run. Doesn't tell you anything. You will never find a duplicate so all your "objects" will be distinct and have the same probability of happening. nothing useful about that.

I think a useful tool would need not only to calculate frequencies of each hex character but of combinations (permutations) of twos, threes and so on. And analyze if there was any bias in any of those character counts. I don't know of a tool that does that though.

Well, the 'avalanche noise source' electronic method can actually be observed ('see what is going on'); you do need some lab equipment, though. Keep in mind that just visually inspecting the circuit can already give you some confidence that you received the circuit actually specified in the schematic. Inspecting the schematic tells you what the circuit does, so sneaking in some backdoor is going to be pretty hard on such a device.

i'd love to have one of those devices but i don't think i can get an oscilloscope and things to help build it. that's the problem i think you need that type of thing.  building the thing while i guess its tedious would not be the hardest part the harder part would be figuring out how to interface it to something and do data collection. hence why you don't see people doing this all the time. and the people that do, they just show a short video of the output on their screen nothing to learn there.

[n0nce]

It should give a high entropy result, even if the PRNG was seeded with a known seed which would then be used to reconstruct the randomness.

it gave Entropy = 4.053136 bits per byte.
that was for a file that had 125,000 hex private keys in it.
apparently it treat each character as 8 bits.

Character = byte = 8 bits.

Well, the 'avalanche noise source' electronic method can actually be observed ('see what is going on'); you do need some lab equipment, though. Keep in mind that just visually inspecting the circuit can already give you some confidence that you received the circuit actually specified in the schematic. Inspecting the schematic tells you what the circuit does, so sneaking in some backdoor is going to be pretty hard on such a device.

i'd love to have one of those devices but i don't think i can get an oscilloscope and things to help build it. that's the problem i think you need that type of thing.  building the thing while i guess its tedious would not be the hardest part the harder part would be figuring out how to interface it to something and do data collection. hence why you don't see people doing this all the time. and the people that do, they just show a short video of the output on their screen nothing to learn there.

All the information is laid out nicely here: https://betrusted.io/avalanche-noise.html
I just made a quick web search and seriously surprised that there's no ready-made PCB / DIY kit or similar, that you can plug in and get randomness e.g. through cat /dev/tty.usbrandomdevice.

[alexeyneu]

you can use high precision temperature indicator. a lot of these pcb's are on the market

[n0nce]

you can use high precision temperature indicator. a lot of these pcb's are on the market

I'm pretty sure that temperature readings don't have great entropy, right. Or what's the idea there?
Something along the lines of the coastline paradox? That if you measure too accurately, the results are (within some range) going to be 'all over the place'?

Honestly, I'd prefer a circuit actually made for generating high entropy than using something that has good entropy as a side effect.

[larry_vw_1955]

All the information is laid out nicely here: https://betrusted.io/avalanche-noise.html

yes it is but that's a really complicated process and i wouldn't recommend anyone to try it. they might end up with something that doesn't even work right and has low entropy!  

I just made a quick web search and seriously surprised that there's no ready-made PCB / DIY kit or similar, that you can plug in and get randomness e.g. through cat /dev/tty.usbrandomdevice.

probably because it is a real pain to make them and they would have to charge so much that no one would buy it they would just buy something like this: https://www.amazon.com/TrueRNG-V3-Hardware-Random-Generator/dp/B01KR2JHTA

i heard someone made one using a geiger counter and detecting radiation. not sure how hard that is to diy. but maybe it's simpler than this zener diode thing.

[alexeyneu]

you can use high precision temperature indicator. a lot of these pcb's are on the market

I'm pretty sure that temperature readings don't have great entropy, right. Or what's the idea there?
Something along the lines of the coastline paradox? That if you measure too accurately, the results are (within some range) going to be 'all over the place'?

Honestly, I'd prefer a circuit actually made for generating high entropy than using something that has good entropy as a side effect.

right away i found temp chip with 24 bit resolution and temp+humidity one with 14 bit. So  last  13 bits from former can be used and 3 from latter. say it updates every 0.2 s and after 4s you'll have 32b seed

https://www.te.com/commerce/DocumentDelivery/DDEController?Action=showdoc&DocId=Data+Sheet%7FTSYS01%7FA%7Fpdf%7FEnglish%7FENG_DS_TSYS01_A.pdf%7FG-NICO-018

https://www.renesas.com/kr/en/document/dst/hs300x-datasheet

[Welsh]

you can use high precision temperature indicator. a lot of these pcb's are on the market

Someone can correct me if I'm misremembering, but I believe this has been exploited in the past. I unfortunately don't have a reference, because I can't quite seem to pinpoint what it was exactly. However, it was to do with a computer generating something based on the operating temperature. It might be have been a game, rather than a password or key, but it was easily exploited since most users computers temperatures will be within a range, in fact the vast majority would be.

Only those that are running specialised systems or have poor ventilation to the extreme would be outliers, and even then the temperatures would be easily to emulate. For entropy you need to be as random as possible. A human or the temperature of a room or machine isn't random, in fact it's incredibly easy to predict with a small degree of error.

Ultimately, the conclusion is that using anything which would have a common value among users, and isn't in fact random at all is a terrible idea when it comes to generating sensitive data.

[alexeyneu]

we'll grab it as 23.548753℃ . what i offer is to use this 0.008753℃ . you can't predict it in any way . and you can't exploit it. At best you'll get random_num + your_num

[n0nce]

All the information is laid out nicely here: https://betrusted.io/avalanche-noise.html

yes it is but that's a really complicated process and i wouldn't recommend anyone to try it. they might end up with something that doesn't even work right and has low entropy! 

Actually it's not complicated at all. Of course your average Joe won't build his own avalanche noise PCB, but someone with electrical engineering skills should be able to whip a circuit up and order a PCB within an afternoon. It's honestly a simple circuit.

I just made a quick web search and seriously surprised that there's no ready-made PCB / DIY kit or similar, that you can plug in and get randomness e.g. through cat /dev/tty.usbrandomdevice.

probably because it is a real pain to make them and they would have to charge so much that no one would buy it they would just buy something like this: https://www.amazon.com/TrueRNG-V3-Hardware-Random-Generator/dp/B01KR2JHTA

Trust me, it's not a pain. Foundation Devices have such circuits in their hardware wallets and the USB RNG you linked to, may have the exact same thing inside it, as well.

I appreciate the open-source and verifiable avalanche noise source (actual circuit from few simple components) on the Passport hardware wallet.
And obviously the ability to import your own custom seed phrase. This allows you to generate it with dice or whatever you deem secure.

But again; these avalanche noise circuits are amazing. You can literally see them on the PCB, take an oscilloscope to it and verify that it does what it's supposed to and that there's no deterministic bullshit going on.

i heard someone made one using a geiger counter and detecting radiation. not sure how hard that is to diy. but maybe it's simpler than this zener diode thing.

Sampling radiation measurements won't be much simpler than sampling the avalanche noise source, and you'll need specialized components.

Here's actually a project of someone building a Geiger based RNG, DIY, not cheap, though. And I wouldn't vouch for its entropy; there are many steps that can go wrong and introduce bias, e.g. in the ADC.
https://www.instructables.com/Arduino-True-Random-Number-Generator/

[alexeyneu]

24bit temp chip is on sale for $6

[larry_vw_1955]

Actually it's not complicated at all. Of course your average Joe won't build his own avalanche noise PCB, but someone with electrical engineering skills should be able to whip a circuit up and order a PCB within an afternoon. It's honestly a simple circuit.

I mean as far as general electronics circuits go, I guess it is simple if you compare it to something like a computer motherboard but that doesn't mean it is simple to understand how it works. And why it needs so many components to work. I didnt count them all but it looks like around 50 discrete components. I don't understand why it needs that many. I thought just one single zener diode is all you need.

Trust me, it's not a pain. Foundation Devices have such circuits in their hardware wallets and the USB RNG you linked to, may have the exact same thing inside it, as well.

I think it does:

The TrueRNG Hardware Random Number Generator uses the avalanche effect in a semiconductor junction to generate true random numbers. The avalanche effect has long been used for generation of random number / noise and is a time-tested and proven random noise source.


The cost to buy theirs would probably be less than the cost to try and make one yourself. Not only monetary cost but time costs. Thing I don't like about any of these though is how they use "whitening".

The new TrueRNG v3 algorithm uses a more advanced whitening technique to reduce the bias below levels where it can be measured reliably.

If something is truly random then it doesn't need any type of post-processing. Shouldn't need. But you don't get a choice if you use their device...

Sampling radiation measurements won't be much simpler than sampling the avalanche noise source, and you'll need specialized components.

Here's actually a project of someone building a Geiger based RNG, DIY, not cheap, though. And I wouldn't vouch for its entropy; there are many steps that can go wrong and introduce bias, e.g. in the ADC.
https://www.instructables.com/Arduino-True-Random-Number-Generator/

Low bit rate, kind of pricey setup but the theory of its operation as explained in that instructable is much simpler to understand. you don't even need uranium. just a banana or two might suffice. 

[LoyceV]

we'll grab it as 23.548753℃ . what i offer is to use this 0.008753℃ . you can't predict it in any way . and you can't exploit it.

Just because a sensor outputs 6 decimals, doesn't mean it accurately measures them. The last 5 digits could just as well be made up, and thus be predictable.

[n0nce]

Actually it's not complicated at all. Of course your average Joe won't build his own avalanche noise PCB, but someone with electrical engineering skills should be able to whip a circuit up and order a PCB within an afternoon. It's honestly a simple circuit.

I mean as far as general electronics circuits go, I guess it is simple if you compare it to something like a computer motherboard but that doesn't mean it is simple to understand how it works.

It's not that easy to understand from just a PCB picture, but combining it with the schematic, it gets a lot simpler. A true open-source-hardware device provides all of those files, just like here:
https://github.com/Foundation-Devices/passport-electronics/blob/master/Main%20Board/Documentation/Schematic%20Print/SCH_FD-JL-PCB-MB_E1.PDF

And why it needs so many components to work. I didnt count them all but it looks like around 50 discrete components. I don't understand why it needs that many. I thought just one single zener diode is all you need.

Well, the zener is the core component, but you need a driver and sampling circuit around it. Did you count the components or the pads? I count roundabout 20 components (~40 pads). The design by betrusted.io even manages to work with 14 components; look how tiny it is.

Again, if you check the schematic, it's definitely much easier to understand what it's doing, especially if you have such good resources online that help you understand it as well.

Trust me, it's not a pain. Foundation Devices have such circuits in their hardware wallets and the USB RNG you linked to, may have the exact same thing inside it, as well.

I think it does:
The TrueRNG Hardware Random Number Generator uses the avalanche effect in a semiconductor junction to generate true random numbers. The avalanche effect has long been used for generation of random number / noise and is a time-tested and proven random noise source.

The cost to buy theirs would probably be less than the cost to try and make one yourself. Not only monetary cost but time costs.

That just confirms that this is a good circuit. I just wasn't aware that they're sold under the simple term 'TRNG', as I couldn't find anything when looking for 'avalanche noise circuit PCB'.
It would be good if these devices came with schematics and board files to verify the circuit more easily.
(1) Compare product to PCB files
(2) Compare PCB files to schematics
(3) Check schematics to understand what the circuit does and verify that it's what you want it to do

we'll grab it as 23.548753℃ . what i offer is to use this 0.008753℃ . you can't predict it in any way . and you can't exploit it.

Just because a sensor outputs 6 decimals, doesn't mean it accurately measures them. The last 5 digits could just as well be made up, and thus be predictable.

I believe the biggest issue with temperature is that it typically increases / decreases gradually; the sequence of numbers coming from the sensor is going to have some inherent bias because of this.

[alexeyneu]

we'll grab it as 23.548753℃ . what i offer is to use this 0.008753℃ . you can't predict it in any way . and you can't exploit it.

Just because a sensor outputs 6 decimals, doesn't mean it accurately measures them. The last 5 digits could just as well be made up, and thus be predictable.

if $6 chip claims it has this resolution means there's one that really has.

I believe the biggest issue with temperature is that it typically increases / decreases gradually; the sequence of numbers coming from the sensor is going to have some inherent bias because of this.

this thing wraps back and forth like 8bit uint . it will do so with and without this gradually thing. it sould not have impact here but i can't say for sure without research

[NotATether]

we'll grab it as 23.548753℃ . what i offer is to use this 0.008753℃ . you can't predict it in any way . and you can't exploit it.

Just because a sensor outputs 6 decimals, doesn't mean it accurately measures them. The last 5 digits could just as well be made up, and thus be predictable.

I don't know of any temperature sensor driver that exposes the temperature in fractions of a degree.

That is to say, one degree is usually the highest granularity you'll get with tools like lm-sensors and HWinfo/CPU-Z.

[larry_vw_1955]

Well, the zener is the core component, but you need a driver and sampling circuit around it. Did you count the components or the pads? I count roundabout 20 components (~40 pads). The design by betrusted.io even manages to work with 14 components; look how tiny it is.

yeah that one is tiny but i'm sure if I tried to build something like that it's going to be way bigger. think breadboard size. because that's how you would have to get started is by breadboarding it up and seeing if what you constructed works and then once that passes muster, you can solder everything up. gonna be the size of 2.5 inch ssd most likely before you over and done with it. nothing wrong with that though i guess. bonus points if i dont have to actually understand how the thing works to build it...

That just confirms that this is a good circuit.

I would imagine all such usb devices use that technology in some way. They're definitely not sampling radioactive decay or something right?

I just wasn't aware that they're sold under the simple term 'TRNG', as I couldn't find anything when looking for 'avalanche noise circuit PCB'.

Because they want to be a bit cryptic about how exactly their device works. They don't want people to build one themself necessarily.

It would be good if these devices came with schematics and board files to verify the circuit more easily.

yeah there's no way that's happening with something like TrueRNG.

(1) Compare product to PCB files
(2) Compare PCB files to schematics
(3) Check schematics to understand what the circuit does and verify that it's what you want it to do

They don't want you doing that. No one want someone doing that to their product? The reason is simple. if you could do that, you could just build the thing yourself. and don't need to buy it from THEM.

Plus, presumably they've put in some R and D on the thing with some tweaks to make it better than the old off the shelf github circuit to give their product a competitive advantage in the marketplace.

[btc-room101]

Been running rng on my bitcoin hacking racks for +2 years now, works great

Increased my find of lost bitcoins 2x by using real random numbers and random seeds

https://github.com/room101-dev/Grand-Ultimate-BTC-Hacker

ONERNG I paid $40 usd ebay from czech, but two years ago, but like people here are showing you can roll your own, but unless your an electronic genius, I would spend the $40, and I'm an hw/sw scientist, so $40 is nothing

Couldn't one of all these hardware wallet companies implement something like that and steal millions of dollars worth of BTC, in just one moment? It would probably be the worst scandal of the crypto space.

Technically could, although there would be no way to prove this as far as I'm aware, so there isn't a way to verify it either. It would be a pretty sophisticated attack though, it reminds me how computer forensics would freeze computers in the past, specifically the ram in order to extract data. Also, I do believe that some programs in the past, which I can't recall right now would give you supposedly random data, i.e a password generation based on the temperature of the device, and various other things.

I'm not sure how plausible this kind of attack would be though.

In general I would always generate my own keys and NEVER use 3rd party sw, its just too easy on linux on one command line to generate a real good key that your certain that nobody on earth knows other than you.

But, HW random number generators have better uses than generating private keys for new wallets, the best use is as seed generators for finding ( hacking ) lost bitcoins

There are 300M used bitcoin addresses,  you put them into a 8gb bloom filter and on a GPU card you can do 1 billion cycles per second,, so that 8* 10**18 , so you want to make sure your seed is really random while on the hunt; now that is a use for hw random generators such as these devices

I'm fond of RNGONE from czech found on ebay and/or amazon back pre-CONVID

https://github.com/room101-dev/Grand-Ultimate-BTC-Hacker

[moderator's note: consecutive posts merged]

[n0nce]

That just confirms that this is a good circuit.

I would imagine all such usb devices use that technology in some way. They're definitely not sampling radioactive decay or something right?

When ordering from Amazon, there is a lot of trash to be honest. It's possible that you get a device that just uses a rand() C function on a microcontroller or something.
Worst-case even just spitting out numbers deterministically and not uniformly random.

That's why I'd prefer to buy a device with open-source hardware.

I just wasn't aware that they're sold under the simple term 'TRNG', as I couldn't find anything when looking for 'avalanche noise circuit PCB'.

Because they want to be a bit cryptic about how exactly their device works. They don't want people to build one themself necessarily.

You'd pay for the convenience of not spending hours on a new project and probably having to debug it as well.
Trezor and Foundation Devices have shown that open-source hardware is possible without your business going down due to the bad bad DIY scene.

It would be good if these devices came with schematics and board files to verify the circuit more easily.

yeah there's no way that's happening with something like TrueRNG.

(1) Compare product to PCB files
(2) Compare PCB files to schematics
(3) Check schematics to understand what the circuit does and verify that it's what you want it to do

They don't want you doing that. No one want someone doing that to their product? The reason is simple. if you could do that, you could just build the thing yourself. and don't need to buy it from THEM.

See my comment above.

[bkelly13]

Referring to the OP and writing from a smidgen of mathematics knowledge:
In here, talking about random, usually means a private key, 256 random bits.  Now think of them as a pattern.  a 256 bit long pattern.

Some, even many, patterns can be proven to not be random.  For example, if the bits make up the ASCII sequence "this is random" it definitely is not random.
But, it is almost impossible to prove randomness.  There may always be one more way to look at the number to find it not random.

So: As has been said, you must understand the hardware and software used to produce the number.  A difficult task.  Many have written words to the effect:  Don't try to generate a random number on your own.  It is extremely difficult.  When your number is not random, you won't know it until your coins are gone.

[larry_vw_1955]

When ordering from Amazon, there is a lot of trash to be honest. It's possible that you get a device that just uses a rand() C function on a microcontroller or something.
Worst-case even just spitting out numbers deterministically and not uniformly random.

Well, to be fair, I was talking about legitimate usb devices. Unlike say the flash drive market where fakes are all over the place I don't think that's the case for this type of device and the reason is simple. The market is small.

That's why I'd prefer to buy a device with open-source hardware.

then why not get the onerng. https://onerng.info/ you got something against it? seem like it checks off all your boxes. i doubt anything else comes close.

Trezor and Foundation Devices have shown that open-source hardware is possible without your business going down due to the bad bad DIY scene.

never heard of foundation devices before you mentioned them. but i'd say these are the exception rather than the rule. then you have to ask yourself, why.

So: As has been said, you must understand the hardware and software used to produce the number.  A difficult task.  Many have written words to the effect:  Don't try to generate a random number on your own.  It is extremely difficult.  When your number is not random, you won't know it until your coins are gone.

why would it be "extremely difficult"? give me a pen and paper, i'll write down a string of 1s and 0s of length 256. i bet no one ever came up with that private key before.

[o_e_l_e_o]

give me a pen and paper, i'll write down a string of 1s and 0s of length 256. i bet no one ever came up with that private key before.

Maybe not, but that doesn't mean the string you produce will be random. Studies have consistently and repeatedly shown that humans are bad at both generating and perceiving randomness. If you say to pick a number between 1 and 10, 7 is by far the most common. If you say to write down a random series of coin flips (which is the same as writing down a binary number), we consistently avoid runs of the same result (HHH/TTT/111/000) since these are perceived as being "less likely".

A unique string is not necessarily a random string, nor is a unique string necessarily a secure string. I could generate a brain wallet using the first line of text from a Shakespearean play which had never been used before. My brain wallet might be unique, but any coins I deposit on it would likely be stolen.

[BlackHatCoiner]

why would it be "extremely difficult"?

Because, humans aren't random number generators. What is randomness? Complete lack of determinism. If something can be accurately predicted, it's not random. A cryptographically secure random number generator comes with more unknown variables to predict, in comparison with a human brain.

give me a pen and paper, i'll write down a string of 1s and 0s of length 256. i bet no one ever came up with that private key before.

Begin writing. What's the first binary value, and why? You might think there isn't a reason you chose 0 (e.g.) but there is quite likely a reason you don't know.

[larry_vw_1955]

give me a pen and paper, i'll write down a string of 1s and 0s of length 256. i bet no one ever came up with that private key before.

Maybe not, but that doesn't mean the string you produce will be random.

it's not like a book where you just take out some sentence from it and hash it. just waiting to be discovered.

Studies have consistently and repeatedly shown that humans are bad at both generating and perceiving randomness. If you say to pick a number between 1 and 10, 7 is by far the most common.

Asking someone to pick a random number between 1 and 115792089237316195423570985008687907852837564279074904382605163141518161494337 is different than telling them to pick a number in that range that no one else would ever guess. Or be able to find. And if they did, they would lose all their money. They're going to think a bit about it before just blurting out "777777777777777777777777777777".

If you say to write down a random series of coin flips (which is the same as writing down a binary number), we consistently avoid runs of the same result (HHH/TTT/111/000) since these are perceived as being "less likely".

They are certainly less likely than HH or TT but the thing is, in some random bitcoin private key you're going to see 00000 and 11111 you might even see larger length repeats. So think about that. 000 and 111 will happen alot.

Example (I dont know how this bitcoin private key was generated but I'm sure it was probably done using software, as most of them are):

1011100000111010000010110010011011011000111110111100001001100011101000011110011010101000001111111110101101110100111100110011010101001000011010000110100001011011110101010010000100 1100000101100110000100100111000110100010010111110111011010111011010001001100

So obviously one needs to understand a little about what is the norm. Then go from there.

A unique string is not necessarily a random string, nor is a unique string necessarily a secure string. I could generate a brain wallet using the first line of text from a Shakespearean play which had never been used before. My brain wallet might be unique, but any coins I deposit on it would likely be stolen.

But there's a difference. your unique string has been published so that anyone in the world can get a copy of it. mine wouldn't have since I just generated it out of my head.

Because, humans aren't random number generators. What is randomness? Complete lack of determinism. If something can be accurately predicted, it's not random. A cryptographically secure random number generator comes with more unknown variables to predict, in comparison with a human brain.

If humans did not behave randomly (and unpredictably) then the stock market would be a science. Even with bitcoin, no one knows what the price is going to do. Why is that? because we don't know what people are going to do. their behavior is random. completely random. some of them buy, some sell. the overall result of that is anyone's guess.

Begin writing. What's the first binary value, and why? You might think there isn't a reason you chose 0 (e.g.) but there is quite likely a reason you don't know.

Well I wouldn't be able to tell you "why". There is no justification of why. it is just what I wanted it to be. At the particular moment in time. Just like all the  remaining 255 bits. There doesn't have to be a reason why. There is no way to say why. With that said, I have actually done this procedure of writing down a private key but in hex not binary. I would be confident enough to use it. Enough said.

[LoyceV]

For example, if the bits make up the ASCII sequence "this is random" it definitely is not random.

If you generate enough random 14-character sequences, you'll find it eventually

If you say to pick a number between 1 and 10, 7 is by far the most common.

These sources says 3 or 7. The interesting part is they're both prime numbers. Reddit shows 7 as a clear winner (28%).

While eating Zwartwitjes with the kids, I thought of a way to create random numbers:

Get one, write down a B or a W, eat it, get the next one. Repeat until nauseous. It's much faster than flipping a coin, and less boring

[o_e_l_e_o]

They're going to think a bit about it before just blurting out "777777777777777777777777777777".

I am making analogies, not literal comparisons, which you seem to be misunderstanding.

The point of these analogies is that human behavior is not random. You might think you are being random, but you aren't. Not truly. This has been studied and proven.

So think about that. 000 and 111 will happen alot.
So obviously one needs to understand a little about what is the norm. Then go from there.

Which makes thing even less random. Now you are thinking "I know that statistically I "should" have a run of 5 of the same at some point. I've not done that yet, so lets put that in now. Ok. Now we'll do a few much shorter runs of just 1 or 2 the same, because you probably wouldn't have 5 the same immediately followed by another 5 the same. Ok. What next?" And so on and so forth. This is not random. Not even close to it.

But there's a difference. your unique string has been published so that anyone in the world can get a copy of it. mine wouldn't have since I just generated it out of my head.

Another analogy. I'm simply saying that although you might generate a unique string that no one has generated before, it doesn't mean that string is safe or secure.

If humans did not behave randomly (and unpredictably) then the stock market would be a science. Even with bitcoin, no one knows what the price is going to do. Why is that? because we don't know what people are going to do. their behavior is random. completely random. some of them buy, some sell. the overall result of that is anyone's guess.

The final collective result of the behavior of a group of distinct and disconnected individuals is in no way comparable to a single person picking 0s and 1s.

Get one, write down a B or a W, eat it, get the next one. Repeat until nauseous. It's much faster than flipping a coin, and less boring

But of course there probably isn't an even number of blacks and whites in the bag, and with each one you eat you reduce the odds of that color appearing again. So overall a bad system.

[FatFork]

Get one, write down a B or a W, eat it, get the next one. Repeat until nauseous. It's much faster than flipping a coin, and less boring

But of course there probably isn't an even number of blacks and whites in the bag, and with each one you eat you reduce the odds of that color appearing again. So overall a bad system.

Yeah. From the looks of it, whites appear to outnumber blacks significantly - so it wouldn't be an effective entropy source at all.  
I do agree with the "less boring" part, though.

[n0nce]

That's why I'd prefer to buy a device with open-source hardware.

then why not get the onerng. https://onerng.info/ you got something against it? seem like it checks off all your boxes. i doubt anything else comes close.

That looks very good, indeed! I wasn't aware of it; might even pick one up (even though I don't need a secure RNG right now).

Trezor and Foundation Devices have shown that open-source hardware is possible without your business going down due to the bad bad DIY scene.

never heard of foundation devices before you mentioned them. but i'd say these are the exception rather than the rule. then you have to ask yourself, why.

It might be easier to make money off a closed source product in the current market, where most things are closed, too.

Fortunately, open source licenses have this clause that usually requires derivatives to be open, as well. This means if you want to use Trezor's tried and tested, ancient Bitcoin crypto library, your product (firmware at least) must be open-source too, allowing Trezor and anyone else to profit from your additions and innovations, to then further innovate themselves.

If you've never heard of Foundation Devices, you may be interested in my review of their first device; review for the latest generation is going to be posted very very soon, as well in the Hardware Wallet section.

I'd like to also mention https://betrusted.io/; they built the fully open-source Precursor so far.
Completely open-source to the very last detail.

why would it be "extremely difficult"? give me a pen and paper, i'll write down a string of 1s and 0s of length 256. i bet no one ever came up with that private key before.

Your brain won't select those 0s and 1s fully at random. It will unknowingly introduce patterns that decrease the entropy, i.e. how random your randomness really is.

Get one, write down a B or a W, eat it, get the next one. Repeat until nauseous. It's much faster than flipping a coin, and less boring

But of course there probably isn't an even number of blacks and whites in the bag, and with each one you eat you reduce the odds of that color appearing again. So overall a bad system.

You can significantly improve Loyce's system by counting and verifying an equal number of both colors (adjusting if necessary). You should also put the candies back into the bag after randomly drawing them and writing down B / W.

[larry_vw_1955]

That's why I'd prefer to buy a device with open-source hardware.

then why not get the onerng. https://onerng.info/ you got something against it? seem like it checks off all your boxes. i doubt anything else comes close.

That looks very good, indeed! I wasn't aware of it; might even pick one up (even though I don't need a secure RNG right now).

I'd seen it before but i didn't appreciate all that it has to offer at the time. Now i can appreciate it more fully since there's not alot of comparable devices out there. plus the price seems very reasonable. even though i wish it was easier to get as in a domestic shipper inside the usa. apparently it would come from china so overseas shipping. not sure how much that is or how long it takes. but from my experience on ebay, things from china can come pretty fast. for small stuff. maybe you can do a review for us on this thing once you get it.  

If you've never heard of Foundation Devices, you may be interested in my review of their first device; review for the latest generation is going to be posted very very soon, as well in the Hardware Wallet section.

you did an AMAZING job with the review but $299 is way outside of what I consider reasonable no matter how many features it has. it would have to be able to mine bitcoin at a profit to make me even consider it.

I'd like to also mention https://betrusted.io/; they built the fully open-source Precursor so far.
Completely open-source to the very last detail.

 a handheld device that costs almost $600. i guess it has its use cases but not for any average crypto user it doesnt.

Your brain won't select those 0s and 1s fully at random. It will unknowingly introduce patterns that decrease the entropy, i.e. how random your randomness really is.

Well that's why I don't rely on that method but anyhow, I got my bingo machine thing working. That, along with maybe dice and flipping a coin is all i ever need.

Another analogy. I'm simply saying that although you might generate a unique string that no one has generated before, it doesn't mean that string is safe or secure.

can you give me an example of such a string that would not be safe that no one has ever generated before? you might be suprised that it's not as easy as you think. but give it a try. i'll be the judge.  

[o_e_l_e_o]

Well that's why I don't rely on that method but anyhow, I got my bingo machine thing working. That, along with maybe dice and flipping a coin is all i ever need.

I'm not going to get in to this argument again, but I cannot fathom why you are so hell bent on using untested, biased, and insecure methods of generating entropy when everyone is repeatedly telling you it is a bad idea.

can you give me an example of such a string that would not be safe that no one has ever generated before?

Any string you generate by manually picking 0s and 1s. It might be safe enough that your coins aren't stolen, but it will not have 256 bits of entropy and it will definitely be less safe than a properly generated string.

[LoyceV]

Get one, write down a B or a W, eat it, get the next one. Repeat until nauseous. It's much faster than flipping a coin, and less boring

But of course there probably isn't an even number of blacks and whites in the bag, and with each one you eat you reduce the odds of that color appearing again. So overall a bad system.

When in doubt, you could of course apply the system where BW means B, WB means W, and BB or WW means ignore, but that means you'll have to eat at least 3 times more candy.

You should also put the candies back into the bag

(source)

[n0nce]

If you've never heard of Foundation Devices, you may be interested in my review of their first device; review for the latest generation is going to be posted very very soon, as well in the Hardware Wallet section.

you did an AMAZING job with the review but $299 is way outside of what I consider reasonable no matter how many features it has. it would have to be able to mine bitcoin at a profit to make me even consider it.

I found it too expensive, as well - it was just an example of a fully open-source hardware device.
And nobody even cloned it yet, even though it costs $299 and should be relatively cheap to reproduce!

Get one, write down a B or a W, eat it, get the next one. Repeat until nauseous. It's much faster than flipping a coin, and less boring

But of course there probably isn't an even number of blacks and whites in the bag, and with each one you eat you reduce the odds of that color appearing again. So overall a bad system.

When in doubt, you could of course apply the system where BW means B, WB means W, and BB or WW means ignore, but that means you'll have to eat at least 3 times more candy.

Manchester encoding?

[larry_vw_1955]

I'm not going to get in to this argument again, but I cannot fathom why you are so hell bent on using untested, biased, and insecure methods of generating entropy when everyone is repeatedly telling you it is a bad idea.

i'm not trying to get you into an argument again. but it is not untested since i've tested it. it may or may not have bias but it has significantly more entropy than 256 bits in the first place. so a little bias probably won't do any harm. it is not insecure. remember, i am doing it. you're not doing it. so you don't understand it. you just think you do. your philosophy is somewhat understandable but it does tend to seem to stand in the way of doing something that maybe no one has ever done before. i'd rather do something like that then try and invent a wheel that already existed. i didn't invent everything but i'm putting the pieces of the puzzle together. and that's pretty cool. now i have to get back to my python program that seems to have a bug in it since my generated private key seems a bit too large.  

Any string you generate by manually picking 0s and 1s. It might be safe enough that your coins aren't stolen, but it will not have 256 bits of entropy and it will definitely be less safe than a properly generated string.

ok cool.