Topic: How can you verify the randomness that's coming from a hardware? - page 4. (Read 1583 times)

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

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.

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

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.

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.

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

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.


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

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.

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.


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.

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

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.

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

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.

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.

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.

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

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.

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.

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

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.

That was indeed my point.

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

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


There is a lot more information there.

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

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

Not knowing is what makes me paranoid

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?

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.

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.

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.

---

---