Are dices for generating seed words fair?

[o_e_l_e_o]

Maybe not something better but maybe you're putting "full time cryptographers" on a bit of a pedastal.

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.

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

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.

[1714534210]

1714534210

[1714534210]

1714534210

[1714534210]

1714534210

[1714534210]

1714534210

[1714534210]

1714534210

[BlackHatCoiner]

That's a weird code! It basically generates the random bits but uses it as a string instead of binary!

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.

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?

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)

[larry_vw_1955]

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

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.

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.

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.

[pooya87]

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

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.

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.

[larry_vw_1955]

When you convert the result of a dice roll which is from 1 to 6 to a byte which is 256 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.

a byte is only 8 bits not 256 bits.

[o_e_l_e_o]

kind of like you.

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.

a byte is only 8 bits not 256 bits.

8 bits can have 2⁸ = 256 different values.

[BlackHatCoiner]

why does it matter which way you do it, treating it as a string vs a number though?

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.

[larry_vw_1955]

why does it matter which way you do it, treating it as a string vs a number though?

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.

i don't know if i follow the logic about the "false sense of security" thing. in typical applications like say converting a bitcoin hex private key into a wif format, you are dealing with a 32 digit long hex number. like this one: 8147786C4D15106333BF278D71DADAF1079EF2D2440A4DDE37D747DED5403592

now the point is that you treat it however you want to but just because you assign more bits to each character doesn't mean it has more security. there are only the same number of such 32-length objects no matter what naming convention you use thus it doesn't matter how you represent them with regards to how many bytes they use for storage purposes.

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.

that's irrelevant though.

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.

I think it is pointless to try and use a randomness extractor from any type of process like dice rolls or coin tosses. You're not going to improve the randomness by doing that. I think it's harder to model the physics of a dice roll than a coin toss though. It's much more complicated thus harder to predict the outcome. I'm not sure how biased an average die is and if that really has any significant affect that can be exploited on a very small sample size because no one is going to use a single die to generate more than a few bitcoin addresses most likely. Not all coins are fair either. How do you test that?

[pooya87]

i don't know if i follow the logic about the "false sense of security" thing. in typical applications like say converting a bitcoin hex private key into a wif format, you are dealing with a 32 digit long hex number. like this one: 8147786C4D15106333BF278D71DADAF1079EF2D2440A4DDE37D747DED5403592

now the point is that you treat it however you want to but just because you assign more bits to each character doesn't mean it has more security. there are only the same number of such 32-length objects no matter what naming convention you use thus it doesn't matter how you represent them with regards to how many bytes they use for storage purposes.

There is a difference between using a different encoding and actually padding the bits you have with arbitrary values, and you are confusing these two.
Padding is when you add extra bits to for example if we are only producing 3 bits 1 with padding is 0b00000001 and the next value 2 with the same padding is 0b00000010. If we add these two we get 0b0000000100000010. But actually encoding the bits you have produced without padding will give you this: 001+010=0b001010

The hex you posted from a private key was produced by generating all bits in each byte without needing any pads. To do the same padding in this base means producing something like this: 0x008100470078...

[o_e_l_e_o]

I'm not sure how biased an average die is

Exactly the point. If you have no idea how biased your dice are, then why would you feel comfortable using them to generate something as sensitive as a bitcoin private key or seed phrase? That's just irresponsible.

Not all coins are fair either. How do you test that?

Depends how certain you want to be that your coin is fair. You can never be 100% sure your coin is fair, but you can asymptotically approach 100% with increasing confidence of ruling out ever smaller biases. For example, to exclude a 55/45 bias with 99% confidence, you would need to flip the coin 664 times. However, to exclude a 51/49 bias with 99% confidence, you would need to flip the coin 16,589 times.

A more practical approach would be to simply use the von Neumann approach I alluded to above. Take any coin and flip it in twice. If the first flip is heads and the second flip is tails, write down 0. If the first flip is tails and the second flip is heads, write down 1. If the two flips are both heads or both tails, don't write down anything. Repeat until you have 128 zeros or ones written down. This method completely eliminates any bias in the coin and produces a uniformly distributed output. It will require a lot less flips than any method to test whether or not your coin is actually fair.

[BlackHatCoiner]

you are dealing with a 32 digit long hex number. like this one: 8147786C4D15106333BF278D71DADAF1079EF2D2440A4DDE37D747DED5403592

That's a 64 digit number. Did you perhaps mean 32 bytes?

now the point is that you treat it however you want to but just because you assign more bits to each character doesn't mean it has more security.

There's no more or less security, given that the bits of the string are (about six time) more than the bits of the number. Whether you chose the bytes of string "123456" or the bytes of number (123456)₆ as your entropy, it would be of the exact same security, but the bits would not be equal. Specifically, the string is 6 bytes, but the number is about 1 byte, so you should be careful when comparing bits' security. 128 bits of a string are going to be less secure than 128 bits of a base 6 number.

@o_e_l_e_o, I've started a question at stackexchange: https://crypto.stackexchange.com/questions/102227. Let's see how this goes. Also, I read this: https://nitter.net/raw_avocado/status/1497110041131769856. Basically, while exceeding my knowledge, it says that entropy loss is logarithmic, and even a very biased coin can create a secure seed if tossed enough times.

[larry_vw_1955]

I'm not sure how biased an average die is

Exactly the point. If you have no idea how biased your dice are, then why would you feel comfortable using them to generate something as sensitive as a bitcoin private key or seed phrase? That's just irresponsible.

maybe it is. but i think there's worse things someone could do to generate a private key than rolling a dice. like using a computer connected to the internet and generating it right off a live website such as bitaddress. how many people have been hacked that used a private key generated by rolling some dice? haven't heard of that happening...

not every bitcoin private key has exactly 2 hex characters of each digit...so for most private keys there is going to be one hex character at least one that appears more than the others. whether that came about through a biased dice or a random number generator on a computer, you would have no way of knowing.

A more practical approach would be to simply use the von Neumann approach I alluded to above. Take any coin and flip it in twice. If the first flip is heads and the second flip is tails, write down 0. If the first flip is tails and the second flip is heads, write down 1. If the two flips are both heads or both tails, don't write down anything. Repeat until you have 128 zeros or ones written down. This method completely eliminates any bias in the coin and produces a uniformly distributed output. It will require a lot less flips than any method to test whether or not your coin is actually fair.

never heard of that method but after analyzing it, I guess it does work since the probability of TH and HT are equal. Which is all you're counting. When you get HH or TT, you ignore it. maybe that same method could be applied to rolling a single die but it's not clear how.

[BlackHatCoiner]

maybe it is. but i think there's worse things someone could do to generate a private key than rolling a dice.

There are obviously worse habits when generating a wallet. We're trying to minimize the risks.

like using a computer connected to the internet and generating it right off a live website such as bitaddress

That definitely inherits some risks. But, if you've verified the authenticity of bitaddress on a transparent operating system, which works air-gapped, you've minimized the risks.

not every bitcoin private key has exactly 2 hex characters of each digit...so for most private keys there is going to be one hex character at least one that appears more than the others. whether that came about through a biased dice or a random number generator on a computer, you would have no way of knowing.

What does this have to do with anything? A private key in which one character appears more than once doesn't make it less secure than one which doesn't.

[o_e_l_e_o]

but i think there's worse things someone could do to generate a private key than rolling a dice. like using a computer connected to the internet and generating it right off a live website such as bitaddress.

That is undoubtedly a terrible idea, but that doesn't mean we should be promoting other risky ideas in its place.

never heard of that method but after analyzing it, I guess it does work since the probability of TH and HT are equal. Which is all you're counting. When you get HH or TT, you ignore it. maybe that same method could be applied to rolling a single die but it's not clear how.

It can, but it is significantly more complicated. Essentially you would roll the dice three times, and make a note of all three numbers. If any number is repeated, you discard the rolls and start a new set of three. You then note if the second number is higher (H) or lower (L) than the first number, and then if the third number is higher than both the first and second numbers (HH), lower than both the first and second numbers (LL), or between the first and second numbers (B). This allows you to generate 6 possibilities from your three dice rolls:

HHH
HLL
HB
LHH
LLL
LB

You map each of these six possibilities to a number from 1 to 6, and repeat until you have as many numbers as you need.

This works because rolling 1,3,5 is equally as likely as rolling 1,5,3 or 3,1,5 or 3,5,1 or 5,1,3 or 5,3,1, regardless of the bias towards any individual face of the dice.

[larry_vw_1955]

not every bitcoin private key has exactly 2 hex characters of each digit...so for most private keys there is going to be one hex character at least one that appears more than the others. whether that came about through a biased dice or a random number generator on a computer, you would have no way of knowing.

What does this have to do with anything? A private key in which one character appears more than once doesn't make it less secure than one which doesn't.

that's exactly the point I was trying to make. along with the fact that if I give you some 32 character HEX string where one HEX symbol appears more than 2 times, you don't have anyway of knowing what caused that to come about - be it just a random happening or something that was caused by a bias towards that particular hex digit.

It can, but it is significantly more complicated. Essentially you would roll the dice three times, and make a note of all three numbers. If any number is repeated, you discard the rolls and start a new set of three.

Interesting but it seems like that would basically multiply the number of rolls required by at least a factor of 6. that's a bit unrealistic to force someone to roll a dice around 600 times just to generate a single bitcoin private key. the chances they make a mistake at some point are high. maybe a way to shortcut that process would be to take 3 dice and roll them all at the same time.

[o_e_l_e_o]

that's a bit unrealistic to force someone to roll a dice around 600 times just to generate a single bitcoin private key.

Exactly. Which is part of the reason I am arguing against using dice. If you instead want to test whether a single die has no bias and be reasonably confident in your conclusions, then it would require even more rolls than the ~16,000 coin flips I gave above to test for a coin. Why take the risk, when there are safer, simpler, and quicker methods available?

maybe a way to shortcut that process would be to take 3 dice and roll them all at the same time.

That wouldn't work. You need to decide in advance which die will be your first number, which will be the second, and which will be the third, as if you wait until after you have rolled to pick the order then you introduce bias. In such a scenario, if die 1 has a bias towards 1 and die 2 has a bias towards 2, then ending up with HHH will be more likely than any other combination.

The method only works on a single die because each individual roll has the exact same chance to be biased as every other roll.

[BlackHatCoiner]

that's exactly the point I was trying to make. along with the fact that if I give you some 32 character HEX string where one HEX symbol appears more than 2 times, you don't have anyway of knowing what caused that to come about - be it just a random happening or something that was caused by a bias towards that particular hex digit.

I'm still having a hard time comprehending your point. That if I give you a number you can't know if it has a certain bias?

that's a bit unrealistic to force someone to roll a dice around 600 times just to generate a single bitcoin private key.

First of all, it's not for a single private key; it can work as a seed, which can be later used to derive nearly infinite private keys. Secondly, you should absolutely force nobody do nothing; especially regarding this matter. It's a process that concerns you, individually. Same as with using bitcoin.

While paranoid, I still prefer tossing a coin, or rolling a fair dice, than using an RNG from a computer I don't trust. In my case that I have two computers, one that I'm currently typing, and another I don't trust with all that software I've installed over time. (I say paranoid, because I've never heard anything of "RNG exploitation")

[larry_vw_1955]

that's a bit unrealistic to force someone to roll a dice around 600 times just to generate a single bitcoin private key.

Exactly. Which is part of the reason I am arguing against using dice. If you instead want to test whether a single die has no bias and be reasonably confident in your conclusions, then it would require even more rolls than the ~16,000 coin flips I gave above to test for a coin. Why take the risk, when there are safer, simpler, and quicker methods available?

i mean you outlined one safer method which is flipping the coin twice and eliminating rolls where you had a duplicate. i guess that's "safer simpler and quicker" than rolling a dice with unknown bias. not sure what other methods you had in mind though. i'm not yet convinced that other factors don't play a greater role in flipping a coin though like the way the coin is flipped. without any control over that process, someone could maybe affect the outcome slightly (introduce a bias).

I'm still having a hard time comprehending your point. That if I give you a number you can't know if it has a certain bias?

yeah that's what i thought but when i think about it again, i realize if it lands on one number too often then the number on the opposite side is less often so there's 2 clues it might be generated using a biased dice. but i don't know if that is exploitable.

First of all, it's not for a single private key; it can work as a seed, which can be later used to derive nearly infinite private keys.

i guess. wasn't aware of exactly what steps were involved in that but that would be better so you don't have to spend hours every so often rolling dice.

While paranoid, I still prefer tossing a coin, or rolling a fair dice, than using an RNG from a computer I don't trust.

I don't think that's paranoid at all. It's probably smart. Ever heard of someone that sent 1 bitcoin to the sha hash of "" ? i bet their computer did that to them.

so then the way you figured out your dice was fair is you put it in saltwater if not then not sure how you could know it is fair. and even then, i'm not sure that's a 100% guarantee. does a dice need to be retested for bias every so often?

[BlackHatCoiner]

i guess. wasn't aware of exactly what steps were involved in that but that would be better so you don't have to spend hours every so often rolling dice.

Theoretically, given a function that produces cryptographically secure pseudo-random numbers, computers would need no RNGs. Generation of the entropy could be done once outside the machine, and be submitted during the installation of the operating system. Every time a program requested a random number, the computer could feed the function with the entropy with a nonce.

Ever heard of someone that sent 1 bitcoin to the sha hash of "" ? i bet their computer did that to them.

Well, I don't know how does this enriches the discussion, but SHA256 of an empty value is "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855". The (compressed) WIF of this is "L4rK1yDtCWekvXuE6oXD9jCYfFNV2cWRpVuPLBcCU2z8TrisoyY1", with a P2PKH address "1F3sAm6ZtwLAUnj7d38pGFxtP3RVEvtsbV" that has totally received 1.19592036 BTC.

It is a little paranoid, because I've never heard of anyone losing bitcoin because of flawed CSPRNGs, and probably most valuable private keys have been generated using CSPRNGs. On the other hand, very few roll dices to generate their entropy, and is therefore less clear what's more prone to human error.

[o_e_l_e_o]

not sure what other methods you had in mind though.

Either flipping a coin or using Bitcoin Core on a clean, airgapped Linux machine.

without any control over that process, someone could maybe affect the outcome slightly (introduce a bias).

True, but even if they do, such a bias will be eliminated by using von Neumann's algorithm as above.