Are dices for generating seed words fair?

[dkbit98]

But unless you're talking about bad RNG or specific device environment, you can't simply reproduce it. For example, /dev/random and /dev/urandom use both hardware, user input and other source as entropy.

You can reproduce it, but if you are fine with that risk, go for it and use it.
RNG is not truly random, period, otherwise people won't waste all that time, money and research to create and use TRNG.

While it's far cheaper than 10 years ago, it's still not cheap on many parts of the world.

I don't know if someone is living as homeless gipsy, but even they can afford to buy 3d printer today for $100 or even cheaper if it's used.
They can later offer services to 3d print stuff for other people, earn all money back and even make profit.

[1714161548]

1714161548

[1714161548]

1714161548

[1714161548]

1714161548

[Dabs]

go to walmart or amazon or even your local board game store / big mall. Look for dice sets. Roll them a thousand times each. That's basically your test. It's not perfect, it does not guarantee anything, but you have an idea if the dice are biased or not.

Make sure to roll them for more than 2 seconds and it hits or bounces off something. If you have a shoe box or shaker cup, shake it for 2 seconds. Casinos that play dice games where you are not allowed to touch the dice have some mechanism to bounce the dice 3 times and you can just look at it from behind the glass.

[Synchronice]

But unless you're talking about bad RNG or specific device environment, you can't simply reproduce it. For example, /dev/random and /dev/urandom use both hardware, user input and other source as entropy.

You can reproduce it, but if you are fine with that risk, go for it and use it.
RNG is not truly random, period, otherwise people won't waste all that time, money and research to create and use TRNG.

Nor RNG, nor TRNG really exist and will never exist, maybe I'm wrong but I have a different opinion, let me make it clear.
Absolutely everything that happens is the result of absolutely everything that happens during the existence of the world, i.e. everything that happens is the result of the infinite past events.
Let's drop a coin from the top of one world trade center and who guesses the coin toss is the winner. Let's say you win and you'll probably say that you are lucky but wait, what about if I say that I did it so? The size of coin, the weight of coin, the height, the resistance, the gravity, me and my hand's movement, all of this in cooperation made the final result? If we would change the weight of the coin by one mg, wouldn't it affect that result? If we would change the size of coin, wouldn't it affect that result? If I move my hand one mm higher, wouldn't it affect the result? Sure it would, so how can we call it a truly random result?
True randomness doesn't exist, even if I go outside and big block falls on me, this happened because: Every past action of me, you and everyone led me to come to this moment, my mind that was matured from past events and the language I speak in my head and the very last moment and movement of my legs made me to go outside for that second moment and the obsolescence of concrete in that block was becoming severe and severe and when the last chain of atoms got separated, it felt down. At the same time, if someone wouldn't invent concrete block, this event wouldn't happen but also wouldn't happen other past events and probably I wouldn't exist. If the builder would use a little bit more cement, maybe this wouldn't happen. If the builder would put that concrete 1 minutes later, maybe this wouldn't happen. Do you understand what I mean?

That's why I think that randomness exists only subjectively within the minds of individuals and we call it randomness when something happens and we completely ignore the correlation, not even trying to truly find it.

[LoyceV]

Absolutely everything that happens is the result of absolutely everything that happens during the existence of the world, i.e. everything that happens is the result of the infinite past events.

That doesn't matter since you can't know the exact past events.
Off the top of my head I'm thinking of:

In quantum mechanics, the uncertainty principle (also known as Heisenberg's uncertainty principle) is any of a variety of mathematical inequalities[1] asserting a fundamental limit to the accuracy with which the values for certain pairs of physical quantities of a particle, such as position, x, and momentum, p, can be predicted from initial conditions.

The butterfly effect, an underlying principle of chaos, describes how a small change in one state of a deterministic nonlinear system can result in large differences in a later state (meaning that there is sensitive dependence on initial conditions).

[Synchronice]

Absolutely everything that happens is the result of absolutely everything that happens during the existence of the world, i.e. everything that happens is the result of the infinite past events.

That doesn't matter since you can't know the exact past events.

But the term still matters, we can't call it "True Random" but Random, yes, you are right until we understand it.

[dkbit98]

Nor RNG, nor TRNG really exist and will never exist, maybe I'm wrong but I have a different opinion, let me make it clear.

Not maybe, you are certainly wrong with your statement and I have to say that this is not philosophy class or new age mambo jumbo, it's just math.

Let's drop a coin from the top of one world trade center and who guesses the coin toss is the winner. Let's say you win and you'll probably say that you are lucky but wait, what about if I say that I did it so?

Let's say if your drop that coin from same world trade center but you do it 100 or 200 times, this is what we are talking about, not just one time flip of a coin.

That's why I think that randomness exists only subjectively within the minds of individuals and we call it randomness when something happens and we completely ignore the correlation, not even trying to truly find it.

Everything exists within the mind of individuals and you can't function in the world without mins, but I will repeat again, this is MATH and if result can be repeated that means it's not truly random.
That is why we saw fake Trezor devices showing up recently that create fake random seed word generation, that can be repeated and exploited my malicious actors.
I think that you don't really understand anything about this subject, and I am not saying that I am expert in any way.

[o_e_l_e_o]

You might be interested in reading this: https://en.wikipedia.org/wiki/Bell%27s_theorem

Essentially, Bell's theorem proves that quantum mechanics is not influenced by "local hidden variables". That is to say, there are not things happening which we are either unaware of or cannot measure which are influencing the outcome of quantum events. As such, certain quantum mechanical events can be said to be truly random.

The most common example of this is radioactive decay: https://en.wikipedia.org/wiki/Nuclear_decay
Another example is shot noise: https://en.wikipedia.org/wiki/Shot_noise. Interestingly, you can use a simple mobile phone camera pointed at an LED to create a true random number generator using this process: https://physicsworld.com/a/how-to-make-a-quantum-random-number-generator-from-a-mobile-phone/.

Also interestingly, like bitcoin mining, these processes follow a Poisson distribution.

[death_wish]

There is an analog method of using 2 or 3 dice rolls to "unbias" any biased dice rolls. Then you can use that as your RNG. Of course, for 256 bit equivalent, instead of rolling 100 times, you would roll 200 or 300 times. Or more. Not sure of the math.

Footgun alert!

Here is a complementary idea: mix the result

Extending the proposal: Use the hash function thousands of times. Not only you ensure that a dice bias isn't enough to betray you, but you also make it much harder for an attacker to find your entropy.

...

Recommendations:

3. Read the HKDF paper, to better understand the “extract and expand” model.  Not that it’s the canonical source of all wisdom:  I simply find it a good guide to start learning about this subject matter.  Then, review the literature about entropy extractors.  You are seeking an entropy extractor, without knowing what you seek.

2. 6-sided dice rolls output results from a uniform random distribution.  If your dice are physically perfect, you do not need any fancy-pants entropy extractor.  Assuming unbiased dice, you can use a simple algorithm to transform your base-6 dice rolls into uniformly distributed binary numbers, without modulo bias.  At this point, you will probably mess it up and utterly annihilate your own security; so...

1. Leave cryptography to the cryptographers.  Seriously.  Please.  For your safety and the safety of others.

Generating your own random numbers is low-level crypto.  >99% of programmers should never, ever touch low-level crypto directly.  This is not to insult your intelligence:  The smartest programmers in this space all either study up on their cryptography, or leave cryptography to the cryptographers.  Studying cryptography takes lots of smarts; knowing the limits of your own knowledge also takes lots of smarts.

(I am not a cryptographer.  You will see security wonks who are not cryptographers say this often:  I am not a Real Cryptographer(TM).  But at least, I am aware of entropy extraction, probability distributions, etc.; and I know enough cryptography to know that “a little knowledge is a dangerous thing”!)

I don't agree with the premise that dice will be "random enough" without testing that. If you don't trust the randomness of your OS, which has been designed, built, and tested by experts in the field of cryptography, and want to do things manually, then just picking up a bunch of random dice and shrugging your shoulders is irresponsible. If you don't test your dice, how can guarantee your min-entropy is sufficient? How can you guarantee your Shannon entropy is sufficient? How can you be sure whatever randomness extraction algorithm you choose won't amplify your weak entropy?

Keywords that I have rendered in bold indicate that this is someone who will not be blowing his own security away with a random footgun.

But I doubt that the quality of randomness from physical dice is the problem here.  The problem is that people who don’t even know the difference between min-entropy and Shannon entropy tend to destroy their own security by fetishizing “true randomness” or “physical randomness”.  A belief that randomness from physical dice is somehow better than CSPRNG output is itself a warning sign that someone should not mess with random number generation.

Random number generation is subtle and counterintuitive.  Get it just a little bit wrong, and you don’t even know that you just wrecked your security:  Everything still works, and everything still looks just fine to you.  Please, people, use a CSPRNG designed and implemented by cryptographers!

[larry_vw_1955]

Interestingly, you can use a simple mobile phone camera pointed at an LED to create a true random number generator using this process: https://physicsworld.com/a/how-to-make-a-quantum-random-number-generator-from-a-mobile-phone/.

Who is "you" though? Someone in a research lab with access to exotic hardware and custom made software? No one on this forum is going to be able to duplicate that. the article doesnt explain how to do it yourself. so it is really of no use. got any do it yourself options?

2. 6-sided dice rolls output results from a uniform random distribution.  If your dice are physically perfect, you do not need any fancy-pants entropy extractor.  Assuming unbiased dice, you can use a simple algorithm to transform your base-6 dice rolls into uniformly distributed binary numbers, without modulo bias.

an 8-sided or 4-sided dice would convert better into a binary number than a 6 sided one since they are power of 2.  with a 6-sided dice you have to do some type of reduction like let even numbers be 1 and odd numbers be 0.  might as well just be flipping a coin. you can't just use the numbers as displayed. and convert them to their binary form. 

[BlackHatCoiner]

an 8-sided or 4-sided dice would convert better into a binary number than a 6 sided one since they are power of 2.

In which way, other than speed, is it going to better to use an 8-sided dice over a 6-sided one? Yes, 8 is 2³, and can return all binary values between 000 and 111. In 6-sided dice, you have [0, 1, 00, 01, 10, 11]. An alternative way to generate entropy, is to not use the sum of the outputs as the seed, but write down the dice results (1, 2..., 6) and SHA256 the output. That way, you can have a fixed number of dice rolls.

[o_e_l_e_o]

An alternative way to generate entropy, is to not use the sum of the outputs as the seed, but write down the dice results (1, 2..., 6) and SHA256 the output. That way, you can have a fixed number of dice rolls.

I wouldn't do this. I am by no means knowledgeable in this field, but I know enough to know that by using SHA256 as a randomness extractor like this you will almost certainly end up with much less entropy than you think you are achieving.

Here are a few relevant quotes from the original HKDF paper:

We end by observing that most of today’s standardized KDFs (e.g., [4, 5, 57, 40]) do not differentiate between the extract and expand phases but rather combine the two in ad-hoc ways under a single cryptographic hash function (refer to Section 8 for a description and discussion of these KDF schemes). This results in ad-hoc designs that are hard to justify with formal analysis and which tend to “abuse” the hash function, requiring it to behave in an “ideally random” way even when this is not strictly necessary in most KDF applications (these deficiencies are present even in the simple case where the source of keying material is fully random)]

Efficient constructions of generic (hence randomized) statistical extractors exist such as those built on the basis of universal hash functions [15]. However, in spite of their simplicity, combinatorial and algebraic constructions present significant limitations for their practical use in generic KDF applications. For example, statistical extractors require a significant difference (called the gap) between the min-entropy m of the source and the required number m′ of extracted bits (in particular, no statistical extractor can achieve a statistical distance, on arbitrary sources, better than 2-((m-m′)/2) [60, 63]). That is, one can use statistical extractors (with its provable properties) only when the min-entropy of the source is significantly higher than the length of output. These conditions are met by some applications, e.g., when sampling a physical random number generator or when gathering entropy from sources such as system events or human typing (where higher min-entropy can be achieved by repeated sampling). In other cases, very notably when extracting randomness from computational schemes such as the Diffie-Hellman key exchange, the available gap may not be sufficient (for example, when extracting 160 bits from a DH over a 192-bit group). In addition, depending on the implementation, statistical extractors may require from several hundred bits of randomness (or salt) to as many bits of salt as the number of input bits.

However, there is little hope that one could prove anything like this for regular cryptographic hash functions such as SHA; so even if the assumption is well defined for a specific hash function and a specific group (or collection of groups), validating the assumption for standard hash functions is quite hopeless. This is even worse when requiring that a family of hash functions behaves as a generic extractor (i.e., suitable for arbitrary sources) as needed in a multi-purpose KDFs.

There is a lot more to securely generating entropy than just feeding what you think is a long enough, random enough string in to a SHA256 function and being happy with the output. I would stick to either /dev/urandom, or a physical process which can generate your entropy directly, such as flipping a coin. Anything beyond that introduces too many possibilities for error, many of which the average user is completely oblivious to the very existence of.

As I said previously in this thread, just rolling some dice and using the output without even thinking about your min-entropy among other things (if you've even heard of these terms at all) is a recipe for disaster.

[BlackHatCoiner]

[...]

I don't understand much from the texts you've quoted, but I know this: Hash functions can provide pseudo-randomness, and are used frequently in cryptographic applications for this purpose. Numbers derived from a random number are considered pseudo-random, but they're treated as equivalently cryptographically secure.

A long series of 6-sided dice results with values [1, 6] can provide the same randomness of a 36-sided dice, taken that they're tested properly. Whether you represent the seed with base 2, base 6, base 10, base 16 etc., it doesn't have a difference (and I don't think you're arguing against of that). Using the hash of the entropy as a seed should also make no difference, because as I said it's treated equally secure. You have to hash seeds and signature values either way in HD wallets.

[o_e_l_e_o]

I don't understand much from the texts you've quoted

Then that alone should be enough to convince you that there is more to consider here than just inputting a string in to SHA256 and being happy that whatever it outputs is secure enough to use as your entropy source.

Numbers derived from a random number are considered pseudo-random, but they're treated as equivalently cryptographically secure.

What you are talking about here is randomness extraction. This is a whole field of study on its own, and is much more complex than simply "Use SHA256".

Whether you represent the seed with base 2, base 6, base 10, base 16 etc., it doesn't have a difference

Except that you've now introduced a modulo bias.

But damn it Jim! I'm a doctor, not a cryptographer! As I say, I do not know enough about this topic to give you a full technical explanation, and that alone is enough for me to know that I shouldn't be using such methods as my own ad hoc entropy derivation scheme. Maybe someone more knowledgeable can come along and explain that just taking a SHA256 of some dice rolls is actually perfectly safe, but I doubt it, and until then I'm not willing to gamble the security of my wallets and my coins on an untested method I know I don't fully understand.

[BlackHatCoiner]

Then that alone should be enough to convince you that there is more to consider here than just inputting a string in to SHA256 and being happy that whatever it outputs is secure enough to use as your entropy source.

I refuse to accept that a random number once used as input in SHA256 gives non-cryptographically-secure result, not because I put myself above experts, but because experts say it. Take an ECDSA signature. In most Bitcoin wallets, value k is no longer generated using an RNG. Instead, it's a hash of the private key and the message.

Quoting the important part from RFC 6979 (which is the standard most such software follow):

This document defines a deterministic digital signature generation procedure.  Such signatures are compatible with standard Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures and can be processed with unmodified verifiers, which need not be aware of the procedure described therein.  Deterministic signatures retain the cryptographic security features associated with digital signatures but can be more easily implemented in various environments, since they do not need access to a source of high-quality randomness.

Besides ECDSA signatures, the second half part of HD wallets is deterministic. Hence, the entire structure relies on the fact that random numbers passed through hash functions are cryptographically secure.

But damn it Jim!

Is this in a manner of speaking? Who's Jim? 

[larry_vw_1955]

I refuse to accept that a random number once used as input in SHA256 gives non-cryptographically-secure result, not because I put myself above experts, but because experts say it. Take an ECDSA signature. In most Bitcoin wallets, value k is no longer generated using an RNG. Instead, it's a hash of the private key and the message.

if sha256 got broken, they could figure out your private key i guess. but if you used a k generated randomly that risk wouldn't exist.

[o_e_l_e_o]

I refuse to accept that a random number once used as input in SHA256 gives non-cryptographically-secure result

827 is a random number. Its SHA256 output is not secure enough to use as a private key.

My point is not that all SHA256 outputs are insecure, but rather you might very well generate one which is not nearly as secure as you think it is.

but because experts say it.

Correct me if I'm wrong, but I've never seen an expert say to feed some dice rolls to SHA256 and use the output to generate a wallet.

Instead, it's a hash of the private key and the message.
Besides ECDSA signatures, the second half part of HD wallets is deterministic

Both using HMAC-SHA(x), which is different from SHA(x).

Is this in a manner of speaking? Who's Jim? 

https://www.youtube.com/watch?v=MULMbqQ9LJ8

[BlackHatCoiner]

827 is a random number.

To be precise, I meant a pseudo-random number. Computers won't ever generate that number in a range of [1, 2^256], even if it's random, because it doesn't look random.

My point is not that all SHA256 outputs are insecure, but rather you might very well generate one which is not nearly as secure as you think it is.

Okay, I now think I understand what you're saying. Yes. There's a chance it returns me a number that doesn't look random.

Correct me if I'm wrong, but I've never seen an expert say to feed some dice rolls to SHA256 and use the output to generate a wallet.

Depends on the expert. Is it a cryptography expert? If that's so, I don't know any such person who's designing software. If it's a software engineering expert, there is one implementation of the function that takes the dice rolls as an input, and uses the SHA256 of that as a seed. SeedSigner.

Both using HMAC-SHA(x), which is different from SHA(x).

Both of which, though, are hash functions. Would you feel more confident if you had the dice rolls hashed by HMAC-SHA?

[o_e_l_e_o]

Computers won't ever generate that number in a range of [1, 2^256], even if it's random, because it doesn't look random.

There is exactly the same chance of it generating 827 as there is of it generating any other number.

Would you feel more confident if you had the dice rolls hashed by HMAC-SHA?

But HMAC requires a key and a message, which you don't have with a simple series of dice rolls. And no, I'm not suggesting we should use HMAC instead - I'm simply pointing out that there are gaps in your (and my) knowledge. When we often talk about not using closed source wallets because we can't know what they are doing, and we often talk about not coming up with your own encryption scheme for your back ups because you will almost certainly come up with something inferior or lock yourself out of your own wallets, then it doesn't make sense to advocate coming up with our own entropy generation schemes when we don't really understand the intricacies of what we are suggesting.

A lot of full time cryptographers have spent a lot of time working on methods to securely generate entropy. I'm not crazy enough to think that I, with no formal cryptography training, will be able to come up with something better.

[larry_vw_1955]

A lot of full time cryptographers have spent a lot of time working on methods to securely generate entropy. I'm not crazy enough to think that I, with no formal cryptography training, will be able to come up with something better.

Maybe not something better but maybe you're putting "full time cryptographers" on a bit of a pedastal. Exactly what is one of those? Do they work in some college and get paid to publish research papers? If they dont publish they get fired, you know? So they're not exactly a neutral 3rd party when it comes to whatever topic they're writing about as for some of them they are doing it because if they didn't, they would get fired. Maybe some of them are doing it because they really have something to offer but I'm skeptical of any statement that says a normal person can't do as well. I just don't buy the story that you need a 10 year degree to be able to do something as simple as rolling dice...

[pooya87]

there is one implementation of the function that takes the dice rolls as an input, and uses the SHA256 of that as a seed. SeedSigner.

That's a weird code! It basically generates the random bits but uses it as a string instead of binary! The computed hash is the hash of that string not exactly the same as using the bits directly. The developed possibly had no idea how to convert bits to bytes and compute that hash

P.S. Using HMACSHA would be useful to combine entropies. For example if you don't want to rely fully on computer generated random or fully on user (dice) generated random you could generate both and  then compute HMACSHA256 of them using one as the key and the other as the message. I haven't seen anybody do this either though.