Concordo, a falta de padronização para garantir a segurança das chaves privadas é um problema. A utilização de fontes de aleatoriedade do sistema operacional pode ser insuficiente para garantir a verdadeira randomicidade.

Hmm so such a test would have to be *before* hashing, clearly.

I think there should be some pooled funds to grind out what some low entropy public keys could look like and make the list public with a library you can easily make checks against. Something like that - probably could get quite far with 10 million.

I guess we get the coldcard list for free…

You can’t because you cannot control the environment the user is operating in. Instead of striving for the most convenient UX, force the user to provide the entropy. @SeedSigner does this well: roll dice or take a photo or GFY.

We did. Look at Veracrypt, up to this day it's gathering entropy from mouse movements and mixes it with other sources. One of the biggest mistakes is using HSMs. And "trusting" hardware black boxes which claim they generate proper RND. Those are not cryptographically safe methods to store and generate key material. The same with "phone encryption" and the 16 chars limit for android password which goes only through an scrypt() is just fucking insane. And no. Phone HSM doesn't count here. One day it may turn out, all smart cards for "signatures" had bad RNGs. But maybe, only maybe, there is a push, for invalid HSMs, to weaken cryptography. Shorter keys, weaker algo, no new AES. I don't like that.

I get the idea but I don't think it can work; say you make a list from 0 - 10 million; now that's only 23-24 bits of entropy, but the problem is, even if that list was big enough to be useful, and even if you were examining the raw 'entropy input', (and say the hashing output from that input follows a known algo) the problem is: the set of 32 byte values with only 24 bits of entropy is *not* only the numbers from 1 to 10million (or whatever); it's a vastly larger set (trivial example: highest order bits are filled in, instead of lowest order bits). whether a given output is in that set can be checked with a mathematical calculation, but listing all of them isn't realistically possible.

i'm not commenting on *how* you generate randomness here: i'm commenting on, by what process do you verify that you did it correctly ('sanity check'). mixing is, i agree, a great idea, but that's about the former, not the latter.

Yes, you are right, checking if entropy is "proper" is a problem, I'm not aware of any methods available right now which could be used Maybe that's why some are so paranoid about joining multiple sources to be sure to some degree without a possible check

Exactly. And where it goes wrong is where the randomness sources are fine (only needs one to be good!) but somehow the logic of combining them gets badly screwed up. 'After the event ' could catch that. But, tricky.

I’m not anywhere near as technical as you. I would love to see funds invested in maintaining trust (appreciate the irony) in trying to break common bitcoiner used tools with the most capable developers and AI. This seems like a thing that could easily be funded from industry players or whales. Maybe there is no incentive to do so but number won’t go up if these fuck ups keep happening.

How many random numbers do you need to generate to be able to reasonably verify the distribution is uniform? There could be a well tested lib that does that and that's included by the wallets? I guess the issue is that getting the randomness even for a single number takes too long?

Yeah it's very tricky. I'm not sure how to make it practical; it has to be the *souce* value that you're testing for uniformity. It doesn't have to be *perfectly* uniform, or even that close. But it has to be like 100 bits of genuine entropy... note for nonces that would not cut it, but for private keys it does. Not easy!

This explains running Health test as part of the generation. So maybe something of that nature. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/nist.sp.800-90b.pdf

You make some good points. I am leery of this whole 'mix in some more entropy' by adding more steps, however.

hash(0) looks random. Maybe hashing is evil? The entropy has to be inspected pre-hashing? Also if dice roll is the new standard which I hope we won't go for, it has to be standardized so that wallet X generates the same wallet as Y from the same dice roll or else we have no way of checking the working of wallet Y.

yep. resonate with this perspective

Why isn’t using Bitcoin core (the software with most peer review) the standard?

I have an intuitive idea what it means for the entropy to not look proper (random enough), but at same time I thought there isn't a way to define such a thing since all values are equally likely

There are plenty of ways of assessing if a specific bit stream is “random”. It basically comes down to measuring diversity of values and looking for patterns. The simplest check is “all zeros” or “all ones”. Those are obviously non-random at the scale of a Bitcoin seed (128 bits plus). But a repeating pattern is also non-random. So alternating zeros and ones (“010101010…01”) is also obviously non-random as is other alternating patterns (“00110011…0011”). The problem in the ColdCard case is that all of the seeds they produced would have passed these checks. The problem wasn’t in the diversity of zeros and ones in the seeds, or patterns resident within a specific seed. The problem was the distribution of seeds. No local check on the produced values can assert a global problem like that. The only way to detect that class of problem is by auditing the code, which no one sufficiently did until now.