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

[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).

[1714250280]

1714250280

[1714250280]

1714250280

[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.