Topic: Are dices for generating seed words fair? - page 11. (Read 3469 times)

SHA256 takes bytes as input. Each character from a dice rolls string takes 8 bits, whereas in a dice rolled number (integer with base 6), each character takes about 1.66 bits on average (1, 2, 3, 4 give 2 bits, while 5, 6 give 1 bit). Therefore, hashing a string would give you a false sense of security. For example, string "123456" is 6 bytes, but (123456)₆ is 6*1.66 = ~9.96 bits. which is about 1 byte.

To think it more simply, in a string, each character takes up to 2^8 = 256 different values (00000000, 00000001 [...], 11111110, 11111111), but a dice roll can only give up to 6 different values. Therefore, a 128-bit random number doesn't have the same security as a 128-bit string that is consisted of 16 dice rolled characters.

Well, I appreciate the vote of confidence, but I still wouldn't recommend using dice rolls to generate a seed phrase. Even ignoring everything we have discussed above about randomness extraction and hash functions, dice are more likely to be biased than coins, are more likely to be thrown in a non-random way, it would be harder and take longer to detect that bias, and the statistical methods and tests required are more complicated. To test your dice are actually fair before using them would take longer than just using coin flips in the first place, and there are many more ways you could mess up your dice rolls than a simple heads = 0 and tails = 1 with a coin.

8 bits can have 2⁸ = 256 different values.

a byte is only 8 bits not 256 bits.

When you convert the result of a dice roll which is from ~3 bits (1 to 6) to a byte which is 8 bit (0 to 256) you are padding each value with unnecessary bits. I don't think there is any "security" issue with this method but it is just a strange way of doing things.

why does it matter which way you do it, treating it as a string vs a number though? i never seen anyone address that issue, why treating it as a number is better for some unknown reason. sha256 is sha256 whether you do it on a string or a number doesn't really matter.

honestly there is incompetence in every field. no matter what field it is. a paper degree is fine but it doesn't mean someone is 100% competent and should be trusted. that's all I need to say about that. but consider satoshi. maybe he just did bitcoin as a side project and wasn't a "professional cryptographer". still i'd trust him more than someone that all they had is some paper degree with that title that had done nothing in the real world. it seems like the people that get things done in this world are not people that have some little tiny area of expertise but people that know a little bit about alot of things and learn what they need to do get what they need to done. kind of like you.

From what I can see, it takes the dice rolls as a string (e.g., "1642566[...]3231454"), converts the string into bytes, and performs SHA256 to that (as it can't do otherwise, you can only feed bytes to SHA256). In this code, encode() is used to convert the string into bytes.

Does it matter if they get paid to do research? Some do, some don't. It's pretty much of a fact that a cryptographer knows more than ordinary people know about cryptography.

Maybe a more secure approach for SeedSigner would be to generate the seed phrase in another way (e.g., Electrum), and have it imported later in SeedSigner. However, Electrum's standard for mnemonic isn't the one SeedSigner follows, that is the BIP39, and I'm not sure if just importing an Electrum seed phrase as a BIP39 would be equivalently secure.

At this point, I shouldn't be using SeedSigner, because it isn't as reviewed as Electrum is. That, alone, is enough in terms of security, but it's so confident and portable device, oppositely to a laptop. (And more secure as an idea, because information is transited in an airgapped way, with no external devices such as USBs)

Working in the medical field, I have become acutely familiar over the last 3 years with people who have no medical training, and indeed do not even comprehend just how little they understand, making wild, entirely unsubstantiated, and often downright impossible claims. I have seen it enough, and the dangerous outcomes such a self righteous Dunning-Kruger bias produces, to be alert to recognizing it in myself. I have no formal training or education in cryptography. I don't even have any formal training or education in any of the fields which underpin cryptography, computer science, mathematics, cybersecurity, programming, etc. I know a bit about these things, sure, but I am entirely self taught and I am under no illusion that what I do know barely scratches the surface of these fields. I know enough to know that I don't know nearly enough to start making up my own ad hoc entropy generation schemes.

Which is why I have advocated that if you want to generate your own entropy from a physical process, then to simply flip a fair coin 128/256 times (or more, using a von Neumann debiasing approach, if you can't be sure the coin is fair or you will flip it fairly), and turn that in to a seed phrase directly. Don't try to perform randomness extraction on a series of dice rolls when you've likely never even heard of that term before.

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.

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

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

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.

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.

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.

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 of which, though, are hash functions. Would you feel more confident if you had the dice rolls hashed by HMAC-SHA?

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.

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.

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

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

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.

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):
Is this in a manner of speaking? Who's Jim? 

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.

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

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.

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.

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:

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.

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.

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?

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. 

Footgun alert!



...

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”!)

---

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!