Are dices for generating seed words fair?

[dkbit98]

I recently saw interesting discussion about casino dices that are being used for generating seed words for Bitcoin, and someone asked a question can you really trust dices.
Dices need to be properly balanced if we want to have real random number generation, and many cheap chinese dices are often not balanced at all.
Easy way to check if your dices are balanced is by using something called Dice Caliper, and you can easily find them in Vegas and other places where gambling is popular.
There is also a way to 3d print your dice caliper (like shown in image below) or use alternative way for testing if your dices are balanced is by using salt water.


https://orange.surf/dice-calipers/

If you have 3d printer available you can even go step further and print your own weighted balanced dices, and be 100% sure you are getting random results.
OrangeSurf made all .stl and .step files available for free on his github page, but you can always support his work with donations.
I personally prefer version 1 dices with sharp edges, like they are used in casinos, version V3 is chamfered and it works just fine, version 4 is containing m8 nut inside and printer needs to pause for this.


https://github.com/orangesurf/weighted-die

Now let's start 3d printing and generating some true randomness

PS
If you find this information useful consider visiting OrangeSurf donation page.

[1714511430]

1714511430

[1714511430]

1714511430

[1714511430]

1714511430

[1714511430]

1714511430

[Welsh]

Anyone that's willing to use a known weighted dice, and compare the results to one that is completely balanced, would be appreciated . I'm guessing there would be some sort of bias, but I imagine it would still largely depend on the power/speed of the person throwing it.

In casinos, the throwers (if they aren't using a automatic machine) have very likely got into a habit, and therefore throw the same dice, the same way, at the same projective/angle/technique. However, my technique, and speed/power will differ from if you threw it. So, even though the dice might be weighted, you would assume we would get vastly different results regardless. There could be a small bias to a certain side of the dice due to the balancing issues, but without knowing what sort of bias that is, as it could be very small, I don't think it's something we really need to be worried about.

Personally, while it might be something to consider, I don't think checking if your dice are weighted perfectly is something that's totally necessary. If you are going to be generating a seed with dice, then just make sure you're throwing at a different angle, and intensity every time.

[pooya87]

Here is a complementary idea: mix the result

You want to make sure that the final key/seed you produce is not affected by any kind of bias then generate your entropy using the dice then generate another entropy using another source (easiest is using a computer RNG) and then mix the two results.
It could be a simple computation of HMACSHA256 to derive a 256 key (used as a private key or a seed to BIP39/32) where one entropy is your key and another is your message.

This way you aren't relying on one source of entropy and can eliminate the bias well enough.

[BlackHatCoiner]

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.

For example, let's assume that one of the dices you use has a 50% chance of returning the number 6. Let's also assume that your RNG is weakened. Now it's much easier for an attacker to hash the dices' entropy mixed with the semipredictable generated number. But, if you use the hash function twice, you've just made it two times more difficult. Do it a few million times and you've made it realistically impossible.

I can't believe how paranoid, schizophrenic and miserable I've become since I made an account here. 

[DaveF]

When throwing dice at a casino the shooter has to have the dice hit the back wall of the table. The casinos want that to happen because when the dice hit the back wall they believe the dice then become fully random. Many casinos tend have the wall covered in a multi angled surface. Doing it a home, not so much if you are just throwing them on your computer desk.

However, with the availability of dice with up to 120 sides you can actually come up with some really ways to do things.

-Dave

[pooya87]

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.

For example, let's assume that one of the dices you use has a 50% chance of returning the number 6. Let's also assume that your RNG is weakened. Now it's much easier for an attacker to hash the dices' entropy mixed with the semipredictable generated number. But, if you use the hash function twice, you've just made it two times more difficult. Do it a few million times and you've made it realistically impossible.

I can't believe how paranoid, schizophrenic and miserable I've become since I made an account here. 

That sounds like overkill to me because the dice has to be really broken to create a bias big enough to make the end result weak, same with the RNG. But hey it never hurts to add more cost to your process as long as you can endure the extra time it needs.
In that case I'd suggest using an expensive KDF such as scrypt to derive the key instead of increasing the number of hashes you compute. You can change scrypt parameters to use a lot of memory to maximize the expense.

[Dabs]

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.

I just bough a pack of 100 colored dice from amazon for kids to play with, but I keep it. They seem random enough and you can toss the whole bunch all at once, line them up at the bottom of a box and use that. Your physical security is more important than the perceived bias of the dice. Do it in a room where it is very noisy and under a blanket so that no one else can see or hear the dice rolls.

If you are writing it down, make sure there are no impressions left under the paper (use a clipboard or other hard surface to write on top of.)

[o_e_l_e_o]

Now i wonder how many throw deemed enough for comparison between 2 dices. I wouldn't bother throw 100 times for each dice.

You wouldn't need to roll both dice - you assume the fair die would produce a perfect spread of results given enough rolls, so 1/6th one, 1/6th two, and so on.

To test a die against this ideal, then you would want to use a Chi Squared test. Very simply, the steps would be:

• Roll the die x number of times
• Record how many times each number (from 1 to 6) shows up
• For each number, calculate the difference between how many times it actually showed up and how many times you would expect it to show up (which would be x/6)
• Square this number
• Divide the result by the number of times you would expect it to show up (x/6)
• Add up the 6 results to find your Chi Squared value
• Look up your result in a Chi Squared look up table (with 5 degrees of freedom for a 6 sided die), such as this one: https://people.richland.edu/james/lecture/m170/tbl-chi.html

The closer your Chi Squared result is to zero, the better. So, for example, at 5 degrees of freedom and a critical value of 0.10, that means that a fair die would produce a Chi Squared value of higher than 9.236 on only 10% of trials.

Now, this requires a minimum of 5 expected observations per possibility, so 30 rolls for a 6 sided die. But there fewer rolls you use, then the less certainty you have and the less likely you are to detect any bias, particularly small bias. I would be rolling at least 100 times to have a reasonable amount of certainty.

[LoyceV]

I'm all for paranoid security, but isn't this too much unnecessary? Even if your dice isn't perfect, and even if it throws a 6 for 20% of the time, there's no way someone is going to reproduce your results to get your private key.

[o_e_l_e_o]

Even if your dice isn't perfect, and even if it throws a 6 for 20% of the time, there's no way someone is going to reproduce your results to get your private key.

But how are you going to known your dice is "safe enough" unless you test it? Perhaps it throws a six 40% of the time instead. If you ended up with a string with more sixes than you expect, how do you know if it is just random chance or if your dice is flawed?

In your example of a dice which rolls a six 20% of the time, then you reduce the min-entropy of each dice roll from 2.585 bits to 2.322 bits. That's 0.263 bits per roll. Might not seem like much, but over 50 rolls, that becomes significant.

[Dabs]

Just go buy casino dice. They are clear so you can see inside and through, and the ones that actually are used or come out of casinos have been "tested".

Most dice, even low quality ones, are random enough, particularly if you are going to roll them a hundred times to generate a private key or a seed or something. Besides, you'll only do this once (or very few times.)

There are coin flips, shuffled decks of cards, and dice. Dice are a cheap method, if rather inconvenient.

If you plan to generate a whole bunch of random numbers, you might want to go with hardware RNGs; there are some you can plug into USB ports and are basically the equivalent of rolling dice continuously.

If you are going to make a seed phrase or use something like Electrum on an offline / airgapped machine, the OS takes care of all that for you, just leave the device running for a few hours, maybe a day or two, so it can collect entropy before generating the cold wallet.

[LoyceV]

But how are you going to known your dice is "safe enough" unless you test it?

I must admit it was based on an assumption, but given my own personal experience, I think I can affirm this statement:

Most dice, even low quality ones, are random enough

In your example of a dice which rolls a six 20% of the time, then you reduce the min-entropy of each dice roll from 2.585 bits to 2.322 bits. That's 0.263 bits per roll. Might not seem like much, but over 50 rolls, that becomes significant.

My point was that 20% is a huge deviation, much larger than any real flaw in a simple standard dice. So I personally wouldn't worry about someone brute-forcing my 100 dice throws.

[Dabs]

As an interesting project or experiment, go do a thousand dice rolls (which is good for 10 seeds) and track the results. I mean, write down how many got 1 and how many got 6, and everything in between.

You should be able to see a pattern, or if there is no bias then you should be able to see that each number is about 1/6 of a thousand. Basically 166 for each number, more or less. Since it is random, you might get 200, you might get 100, but the more rolls you do, the more each number will approach the 1/6 of xxxx.

If you have more than one dice, you'll have to do it for each one, or you do it as a whole for all of them. Since I have a hundred actual physical dice of different colors, I wouldn't even bother to check if each one is "fair" or square. I'd go measure the whole thing (in this case, roll them all at once, 10 times.)

That should be a fun afternoon... "Papa, why are you rolling dice but not playing any game?"

[o_e_l_e_o]

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?

I see this as similar to people who don't double check addresses and fall victim to clipboard malware. If you are planning to use dice to generate a super secure offline wallet, then you can spend 10 minutes to ensure those dice are fair. If you don't want to do that, then you should use something like a von Neumann debiasing approach, but given its inherent inefficiency, you'll probably end up rolling more dice than if you just tested whether your dice are fair to start with.

[LoyceV]

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?

The main difference is that I can easily verify a dice is (more or less) random, but it's very difficult to verify any wallet doesn't produce a pre-recorded seed. The wallet is a black box, while the dice has a very obvious "user interface".

[dkbit98]

Personally, while it might be something to consider, I don't think checking if your dice are weighted perfectly is something that's totally necessary. If you are going to be generating a seed with dice, then just make sure you're throwing at a different angle, and intensity every time.

This is not enough, and why would you use anything that is not fair and verified from beginning in the first place.
For truly random results you need random tools that is not dependent on your arm angle or intensity you throw them.

You want to make sure that the final key/seed you produce is not affected by any kind of bias then generate your entropy using the dice then generate another entropy using another source (easiest is using a computer RNG) and then mix the two results.
It could be a simple computation of HMACSHA256 to derive a 256 key (used as a private key or a seed to BIP39/32) where one entropy is your key and another is your message.

That is something like Trezor hardware wallet is doing, I don't like it and I think it's not good enough.
Computer RNG is not truly random, so I don't see any point in mixing random stuff with non-random, you are probably just reducing randomness.

Cool idea. But since since most people don't have 3D printer, i'll just stick to OS RNG and optionally my mouse movement.

fyi OS RNG is not generating true random result and it can be reporduced.
3d printers are very cheap today, and you can print anything locally even if you don't own one.

I'm all for paranoid security, but isn't this too much unnecessary? Even if your dice isn't perfect, and even if it throws a 6 for 20% of the time, there's no way someone is going to reproduce your results to get your private key.

I think we all saw movies and documentaries with weighted dices used for cheating, and testing if you dices are balanced is trivial job.
It's not like you have to put aluminum thin foil and fo complex math equasion to do it.

Just go buy casino dice. They are clear so you can see inside and through, and the ones that actually are used or come out of casinos have been "tested".

I wanted to order those clear dices and I found one cheap online, but than I found more information about this dice caliper.
There are some big shipping delay now from China, so I am not sure I could wait for them to arrive, but I would like to see if they are actually balanced or not.
I don't want to wait for hours waiting for computer that just can't generate true randomness that can't be reproduced.

[o_e_l_e_o]

The main difference is that I can easily verify a dice is (more or less) random

Yes, but only if you actually verify it. Just trusting that "Well, this die is probably good enough" is, well, not good enough. That approach is fine for a game of Dungeons and Dragons or Monopoly, but not for generating a bitcoin wallet.

Don't trust; verify.

[BlackHatCoiner]

Relative thread: How can you verify the randomness that's coming from a hardware?

Don't trust; verify.

There are different levels of trust, though.

You don't like trusting banks? Use bitcoin. Less trust? Run your own full node to verify that what you're viewing is true. Less trust? Verify the authenticity of your wallet software, to avoid being a hacker's victim. Less trust? Learn the programming language(s) the wallet software is written to and check every single line of the source code, to verify that the developers aren't dishonest. Less trust? Use an open-source OS. Less trust? Do the same procedure for the source code of it. Less trust? Be your own RNG.

Sure, don't trust; verify!, but you're nuts if you do all of the above. And you still have to trust your coding skills. 

[o_e_l_e_o]

Sure, don't trust; verify!, but you're nuts if you do all of the above.

Except I do most of the above. And if I'm spending hours and hours on verifying software, running a node, examining code, running airgapped set ups, running live OSs, creating secure back ups, and all the other things I do maximize my security, then it is unforgiveable that I wouldn't spend 10 minutes to check a die is fair before using it to generate a wallet.

[BlackHatCoiner]

Except I do most of the above.

That's the spirit. I'm just pointing out how falsely it is to use this phrase. For example, I rarely look into Bitcoin Core and there's no way I'll ever look into Linux Mint, which means I take the devs' word for it. I've verified ThomasV's signature, I'm running my own node, I'm using an open-source OS, there's no way I trust my savings to a reckless system.

I can say it out loud to not trust, but to verify; but to an extent.

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

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

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

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

[larry_vw_1955]

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.

0.9 bitcoin got lifted off the uncompressed address 20 minutes after they deposited it. i'm assuming whoever sent the money had no idea what they were doing. i guess "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855" looked random enough to them so they went with it...that will never happen with dice rolls no matter how bad the dice are biased.

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.

flaws in random number generator algorithms i think i heard about how someone exploited that to hack some private keys once. the algo was using the time as a seed or something.

[BlackHatCoiner]

looked random enough to them so they went with it...

But it wasn't. It doesn't matter if a number looks random or not if you're sure that it wasn't generated in a predictable way. In this case, the number might seem random, but all of us can verify that it was the hash of a non-random number. Anyway, I'm still not sure how's this incident related to dice rolls. The bitcoin may have been deposited and withdrawn by the same person who was testing the ecosystem back then. It's highly likely that there are bots that scan for this known keys to immediately spend in case someone sends money, though.

flaws in random number generator algorithms i think i heard about how someone exploited that to hack some private keys once. the algo was using the time as a seed or something.

Would you like to share a link?

[larry_vw_1955]

looked random enough to them so they went with it...

n this case, the number might seem random, but all of us can verify that it was the hash of a non-random number. Anyway, I'm still not sure how's this incident related to dice rolls.

it's not. simply to say that something like that would never happen with a dice roll though.

The bitcoin may have been deposited and withdrawn by the same person who was testing the ecosystem back then.

well, 0.8 bitcoins at the time was worth somewhere around $16,000.

It's highly likely that there are bots that scan for this known keys to immediately spend in case someone sends money, though.

call me ishmael.

flaws in random number generator algorithms i think i heard about how someone exploited that to hack some private keys once. the algo was using the time as a seed or something.

Would you like to share a link?

i just remember reading about how some people's private keys were weakened by some rng that used timestamps as a seed and someone realized that and took advantage. it wasn't cakewallet but it was similar sounding situation:

https://np.reddit.com/r/cakewallet/comments/n9yw6j/urgent_action_needed_for_bitcoin_wallets_in_cake/

[o_e_l_e_o]

0.9 bitcoin got lifted off the uncompressed address 20 minutes after they deposited it.

The other possibility is that this is a particularly stupid brainwallet, rather than flawed software.

that will never happen with dice rolls no matter how bad the dice are biased.

True, but you are simply trading one set of potential vulnerabilities for another. Just because thus particular one is impossible with dice, does not make dice inherently better or safer.

[larry_vw_1955]

0.9 bitcoin got lifted off the uncompressed address 20 minutes after they deposited it.

The other possibility is that this is a particularly stupid brainwallet, rather than flawed software.

well of course it's a stupid brainwallet. it's the empty string!

that will never happen with dice rolls no matter how bad the dice are biased.

True, but you are simply trading one set of potential vulnerabilities for another. Just because thus particular one is impossible with dice, does not make dice inherently better or safer.

what if you filled a bag with dice and blindly pick one die at a time and put it on the table and then look at the number on top. that eliminates any bias that is in the dice.

but again, i challenge anyone to show me a story where someone used dice to generate their bitcoin private key and then later said they got hacked. if they got hacked it's because of something else rather than a bad private key.

[BlackHatCoiner]

what if you filled a bag with dice and blindly pick one die at a time and put it on the table and then look at the number on top. that eliminates any bias that is in the dice.

That doesn't eliminate bias. You still need to use your hand, and pick... randomly! But since you're a human, you can't do that properly. Also, if the dices aren't fair, say the number 6 has a 50% chance to come up, then the bag is likely to give you mostly sixes.

but again, i challenge anyone to show me a story where someone used dice to generate their bitcoin private key and then later said they got hacked. if they got hacked it's because of something else rather than a bad private key.

Unfortunately, this is not how security works. Just because somebody hasn't fell for it, it doesn't mean you can't be the first. Figuring out a very complicated way to generate a Bitcoin wallet, might have a smaller attacking point, but it doesn't make it more secure. As I said before, I don't know a case of a person who used an airgapped machine to generate a Bitcoin wallet using the CSPRNG, and got ripped off, and that's the commonly known secure way, backed by experts.

[o_e_l_e_o]

well of course it's a stupid brainwallet. it's the empty string!

I mean it may well have been generated by someone deliberately hashing an empty string, just as all brainwallets are created by the user deliberately choosing a particular string to hash, as opposed to some flawed software hashing an empty string while the user believed it was doing much more than that.

what if you filled a bag with dice and blindly pick one die at a time and put it on the table and then look at the number on top. that eliminates any bias that is in the dice.

It doesn't eliminate any bias at all. It simply mixes the bias of each individual die among the bias of all the dice, and you hope that doing so is enough to maintain the security of your resulting entropy. And if you go out and buy a set of 100 dice to do this with, how do you know that every single dice in that set hasn't been subjected to the exact same manufacturing defect and therefore has the exact same bias as every other dice?

but again, i challenge anyone to show me a story where someone used dice to generate their bitcoin private key and then later said they got hacked. if they got hacked it's because of something else rather than a bad private key.

In addition to BlackHatCoiner's response, it is often impossible to pinpoint exactly how a seed phrase or private key was compromised, so asking for such an example is meaningless.

[larry_vw_1955]

what if you filled a bag with dice and blindly pick one die at a time and put it on the table and then look at the number on top. that eliminates any bias that is in the dice.

That doesn't eliminate bias. You still need to use your hand, and pick... randomly! But since you're a human, you can't do that properly. Also, if the dices aren't fair, say the number 6 has a 50% chance to come up, then the bag is likely to give you mostly sixes.

The human hand is not sensitive enough to detect which side of a particular die is heaviest. Otherwise we wouldn't need other ways of testing dice.

but again, i challenge anyone to show me a story where someone used dice to generate their bitcoin private key and then later said they got hacked. if they got hacked it's because of something else rather than a bad private key.

Unfortunately, this is not how security works. Just because somebody hasn't fell for it, it doesn't mean you can't be the first. Figuring out a very complicated way to generate a Bitcoin wallet, might have a smaller attacking point, but it doesn't make it more secure. As I said before, I don't know a case of a person who used an airgapped machine to generate a Bitcoin wallet using the CSPRNG, and got ripped off, and that's the commonly known secure way, backed by experts.

cakewallet had a csprng in the code the problem was it also had a fallback which kicked in if the csprng failed to return a seed. the fallback was using the system "current time" as the seed. the issue of whether someone could have generated their mnemonic seed with the cakewallet app while
"airgapped" is really irrelevant (although I would expect that they could) as is the argument that you require a "machine" to generate the seed. By machine I'm assuming you mean a desktop computer but a smartphone is also a machine. Which many people use.

The problem that these cakewallet users had is a common one which is if you haven't read through the source code yourself and understand how it works then you are at risk...if they had used dice to generate their seeds they wouldn't none of them would have lost money due to having an insecure seed. guaranteed.

well of course it's a stupid brainwallet. it's the empty string!

I mean it may well have been generated by someone deliberately hashing an empty string, just as all brainwallets are created by the user deliberately choosing a particular string to hash, as opposed to some flawed software hashing an empty string while the user believed it was doing much more than that.

bitaddress doesn't seem to allow a user to create a brainwallet using too short passphrases of which the empty string certainly meets that criterion but maybe some other software doesn't have that check. and the person thought they were generating a secure bitcoin address and not a brainwallet. it could happen. clearly they learned their lesson though as no new 0.9 btc deposits have been made since then.  

It doesn't eliminate any bias at all. It simply mixes the bias of each individual die among the bias of all the dice, and you hope that doing so is enough to maintain the security of your resulting entropy.

but no dice are being rolled. they're just sitting in a big bag and you jumble them around, reach in and grab one on whatever side you happen to. i dont think the bias of a particular die has any role in that procedure since die will not be able to necessarily achieve a particular position they might achieve if they were not in contact with other die.

And if you go out and buy a set of 100 dice to do this with, how do you know that every single dice in that set hasn't been subjected to the exact same manufacturing defect and therefore has the exact same bias as every other dice?

well they likely will all have the same bias in that case but i dont think that is going to be a problem with the particular procedure we're talking about here. just my opinion.

In addition to BlackHatCoiner's response, it is often impossible to pinpoint exactly how a seed phrase or private key was compromised, so asking for such an example is meaningless.

well in the cakewallet situation they know exactly how it happened. it was generating insecure seeds. so yes it is possible sometimes to know how or why something happened.

but i have yet to hear of anyone ever saying they are skeptical of dice because they once created a bitcoin private key by rolling dice and then someone stoled their funds from that address and they strongly suspected (even if they couldn't prove, of course they can't prove it) that it was because the dice rolled an insecure private key.

[o_e_l_e_o]

but no dice are being rolled

You are shaking the dice around (whether in your hand or in a bag) and then bouncing them off a surface (either a table or the other dice in the bag) to come to rest in a particular orientation. Any bias in the dice is still relevant.

just my opinion.

This is exactly what I'm arguing against. There is an awful lot of complete conjecture in this thread, this is what I think, this is my opinion, and so on. This is not good cryptography. The security of your private keys should be based on tried and tested methods, which are provably unbiased and are provably secure. It should not be based on guesswork and people saying "Well, I think this is probably safe enough".

[BlackHatCoiner]

The human hand is not sensitive enough to detect which side of a particular die is heaviest. Otherwise we wouldn't need other ways of testing dice.

It's not a matter of human hand bias (even though you do pick non-randomly from the bag). It's a matter of dice bias. As I said, if there's 50% chance to give 6, then it'll mostly give sixes, whether you use a bag in which you scramble them a hundred times, or not.

cakewallet had a csprng in the code the problem was it also had a fallback which kicked in if the csprng failed to return a seed.

I don't know what's cakewallet, if it's open-source, if it's peer reviewed, if it's a Bitcoin wallet etc. Would you mind sharing a link that describes the CSPRNG failure in that software? As far as open-source, reputable Bitcoin wallet software are concerned, such as Electrum, there has never been such case.

[larry_vw_1955]

but no dice are being rolled

You are shaking the dice around (whether in your hand or in a bag) and then bouncing them off a surface (either a table or the other dice in the bag) to come to rest in a particular orientation. Any bias in the dice is still relevant.

i wouldn't be bouncing them off any surface. they are taken one by one out of the bag and placed carefully onto a surface not bounced.

just my opinion.

This is exactly what I'm arguing against. There is an awful lot of complete conjecture in this thread, this is what I think, this is my opinion, and so on. This is not good cryptography. The security of your private keys should be based on tried and tested methods, which are provably unbiased and are provably secure. It should not be based on guesswork and people saying "Well, I think this is probably safe enough".

i understand that and i appreciate that.

It's not a matter of human hand bias (even though you do pick non-randomly from the bag). It's a matter of dice bias. As I said, if there's 50% chance to give 6, then it'll mostly give sixes, whether you use a bag in which you scramble them a hundred times, or not.

I'm not sure about that.

I don't know what's cakewallet, if it's open-source, if it's peer reviewed, if it's a Bitcoin wallet etc. Would you mind sharing a link that describes the CSPRNG failure in that software? As far as open-source, reputable Bitcoin wallet software are concerned, such as Electrum, there has never been such case.

https://cakewallet.com/

they claim to be open source on the website. but they dont seem to go out of their way to publish the github link for people to check it out but here it is: https://github.com/cake-tech/cake_wallet

https://github.com/cake-tech/cake_wallet/blob/main/cw_bitcoin/lib/bitcoin_mnemonic.dart is where i think they had the issue that generated insecure seeds

here's how it used to be:
https://github.com/cake-tech/cake_wallet/blob/b67bb0664f7268c31c24bd9fb9cbd438c691f5e3/lib/bitcoin/bitcoin_mnemonic.dart#L11-L22

explanation:
https://np.reddit.com/r/Monero/comments/n9yypd/urgent_action_needed_for_bitcoin_wallets_cake/gxqyscl/

[o_e_l_e_o]

i wouldn't be bouncing them off any surface. they are taken one by one out of the bag and placed carefully onto a surface not bounced.

They are bouncing off each other in the bag. If a dice is weighted to roll a 6 more frequently than it should otherwise, it doesn't matter if you are bouncing it off the floor, a table, the inside of a cup, other dice in a bag, dropping it down some stairs, or launching it in a trebuchet - it will still be more likely to roll a 6.

they claim to be open source on the website. but they dont seem to go out of their way to publish the github link for people to check it out but here it is: https://github.com/cake-tech/cake_wallet

Neither their Android nor their Apple apps are reproducible from their published code:
https://walletscrutiny.com/android/com.cakewallet.cake_wallet/
https://walletscrutiny.com/iphone/com.fotolockr.cakewallet/

Still, that error is horrendous. They are falling back on a function which the documentation specifically says is not suitable for cryptographic purposes, which apparently also defaults to a 64 bit number: https://devoncarew.github.io/papyrus.dart/dart.math.html#Random

Completely amateur mistake. Yet another reason that people should stop using all these random wallets which keep popping up and just stick to the tried and tested ones.

[larry_vw_1955]

They are bouncing off each other in the bag. If a dice is weighted to roll a 6 more frequently than it should otherwise, it doesn't matter if you are bouncing it off the floor, a table, the inside of a cup, other dice in a bag, dropping it down some stairs, or launching it in a trebuchet - it will still be more likely to roll a 6.

ultimately it is something that must be tested statistically. by doing alot of trials. i see what you're saying but i'm still not sure that other factors might play a greater role such as the randomness by which fingers would go into the bag and how they would grip a particular die. but i'm not willing to dismiss the entire thing as yet. for example, i had read somewhere that flipping a biased coin and catching it produces unbiased results. as long as you catch it and dont let it land. that was unexpected but someone was making that claim.

but then we get into other questions such as "what is an acceptable level of bias in an experiment where you perform it some number of times, be that 1000, or more?" I don't think anyone has a good answer for that. and i don't also think that anyone has a really good way to measure randomness. you can do a histogram of how many times each number is landed on but that doesn't mean they happened in a random order. for example: 111122223333444455556666.

Neither their Android nor their Apple apps are reproducible from their published code:
https://walletscrutiny.com/android/com.cakewallet.cake_wallet/
https://walletscrutiny.com/iphone/com.fotolockr.cakewallet/

Cool I was looking for that website, I had seen it once and then forgot its name 

Still, that error is horrendous. They are falling back on a function which the documentation specifically says is not suitable for cryptographic purposes, which apparently also defaults to a 64 bit number: https://devoncarew.github.io/papyrus.dart/dart.math.html#Random

Completely amateur mistake. Yet another reason that people should stop using all these random wallets which keep popping up and just stick to the tried and tested ones.

what's even more horrendous is how no one ever called them out on it until people started losing money. it's not like they were hiding the insecure code. apparently it was sitting there right on github for all to see. but no one did.

[o_e_l_e_o]

but then we get into other questions such as "what is an acceptable level of bias in an experiment where you perform it some number of times, be that 1000, or more?"

When considering generating private keys for bitcoin, then my answer is zero. I don't see why you would settle for anything less. This is why I advocate for using coin flips with von Neumann's algorithm, since by doing this you can be certain you have eliminated any bias in your coin, as well as not introduced any new bias by performing randomness extraction or other processes you don't fully understand on your data.

Any method of testing for bias can never rule out bias 100%, only make it less and less likely but after an exponential number of test flips/rolls.

what's even more horrendous is how no one ever called them out on it until people started losing money. it's not like they were hiding the insecure code. apparently it was sitting there right on github for all to see. but no one did.

People involved in bitcoin who have the ability to read and analyze code, as well as the time and motivation to do so for free, generally aren't using random low quality wallets like Cake which they stumble across on the app store, which might explain why nobody picked it up sooner.

[BlackHatCoiner]

It turns out, that they'd made this discussion before: https://github.com/iancoleman/bip39/issues/435#issuecomment-1145503821

As far as I can tell, Coldcard does also use the SHA256 hash of the input, which is likely the dice rolls: https://github.com/Coldcard/firmware/blob/master/docs/rolls.py#L15.
Interested discussion to this StackExchange question as well: https://crypto.stackexchange.com/questions/10402/how-much-entropy-is-lost-via-hashing-when-you-add-known-or-low-entropy-data

[larry_vw_1955]

but then we get into other questions such as "what is an acceptable level of bias in an experiment where you perform it some number of times, be that 1000, or more?"

When considering generating private keys for bitcoin, then my answer is zero. I don't see why you would settle for anything less. This is why I advocate for using coin flips with von Neumann's algorithm, since by doing this you can be certain you have eliminated any bias in your coin, as well as not introduced any new bias by performing randomness extraction or other processes you don't fully understand on your data.

yeah now that you put it that way, i guess it does make sense. why settle for less? i looked into shuffling a card deck to generate entropy once but i'm not sure if that is as safe as this von neumann method. but i dont see how shuffling a card deck could be biased as long as you shuffle it enough times.
also it's alot faster than flipping coins.

Any method of testing for bias can never rule out bias 100%, only make it less and less likely but after an exponential number of test flips/rolls.

that's why it's hard to test something and people forego that, at their own peril of course  

People involved in bitcoin who have the ability to read and analyze code, as well as the time and motivation to do so for free, generally aren't using random low quality wallets like Cake which they stumble across on the app store, which might explain why nobody picked it up sooner.

I mean they got a pretty large user base from what it looks like. 100k+ downloads off google play is not such small potatoes. Not every random low quality bitcoin wallet has XMR/BTC/LTC swapping going on either. Surely alot of people that used Monero used it for that exact reason...

Cake Wallet allows you to safely store, exchange, and spend your Monero, Bitcoin, Litecoin, and Haven. Cake Wallet is focused on an excellent transaction experience.

Cake Wallet
Cake Labs
3.7
star
965 reviews
100K+
Downloads
Content rating
Everyone
info

[larry_vw_1955]

It turns out, that they'd made this discussion before: https://github.com/iancoleman/bip39/issues/435#issuecomment-1145503821

As far as I can tell, Coldcard does also use the SHA256 hash of the input, which is likely the dice rolls: https://github.com/Coldcard/firmware/blob/master/docs/rolls.py#L15.
Interested discussion to this StackExchange question as well: https://crypto.stackexchange.com/questions/10402/how-much-entropy-is-lost-via-hashing-when-you-add-known-or-low-entropy-data

honestly, i would personally want to avoid any entropy scheme that relied on a hashing function. shouldn't be necessary.

[o_e_l_e_o]

but i dont see how shuffling a card deck could be biased as long as you shuffle it enough times.
also it's alot faster than flipping coins.

There are hundreds of ways to end up with a not entirely random arrangement of cards after a shuffle, most commonly as lots of people simply aren't very good at properly shuffling cards. You could reduce this bias by repeated shuffles and washes, but this adds a lot more time and is still not a guarantee. More importantly, though, is how do you convert your series of cards to a usable string of bits without losing entropy or introducing bias? It is not a trivial problem.

The only real implementation of cards to seed phrase I am aware is that on https://iancoleman.io/bip39/. I am not a fan of how it works, though. It assigns different bit values to each card. 32 cards are assigned a 5 bit string, 16 cards are assigned a 4 bit string, and 4 cards are assigned a 2 bit string. 32+16+4 = 52. There are two main issues with this. First of all, it makes some cards 8 times "more secure" than other cards, by way of them contributing 5 bits instead of 2. This simply doesn't make sense. Secondly, it encourages someone to shuffle a deck of cards and then draw them one by one, meaning that once a card has been drawn it can never be drawn again. This reduces entropy, since that particular string of bits will never occur again.

A better way of doing it would be to assign each of the four suits a 2 bit value - spades 00, clubs 01, diamonds 10, hearts 11 - for example. Then draw a single card, write down your two bits, shuffle that card back in to the deck thoroughly, and repeat. This would take much longer than simply flipping a coin though, and still does not eliminate any unknown bias in your shuffles.

I mean they got a pretty large user base from what it looks like. 100k+ downloads off google play is not such small potatoes.

I pay zero attention to such metrics. It is easy to fake these numbers with bots, and indeed many malicious wallets do just that to make their app seem more legitimate.

[BlackHatCoiner]

Cake Wallet allows you to safely store, exchange, and spend your Monero, Bitcoin, Litecoin, and Haven. Cake Wallet is focused on an excellent transaction experience.

Besides shilling a shitcoin, that is Haven, I wouldn't trust a developer who chooses to work on creating a closed-source Bitcoin, Monero and Litecoin wallet, not only for his intentions, but for the fact that he's likely to mess things up, and he did apparently. Open source projects that focus on just one cryptocurrency, and that are reviewed by literally hundreds of developers (such as Electrum) do have some issues presented every now and then. Let alone a brand new, closed-source, multi-crypto environment.

honestly, i would personally want to avoid any entropy scheme that relied on a hashing function. shouldn't be necessary.

Honestly, I don't understand why they're passing the entropy through a hash function, and I wouldn't want it either. But, does it harm? Very little according to StackExchange. Essentially zero.

[larry_vw_1955]

but i dont see how shuffling a card deck could be biased as long as you shuffle it enough times.
also it's alot faster than flipping coins.

More importantly, though, is how do you convert your series of cards to a usable string of bits without losing entropy or introducing bias? It is not a trivial problem.

Well there are 52! ways different possible orderings of a full deck of cards. that's about 225 bits. bitcoin private keys only have 128 bits of security. a little entropy loss is probably not a big deal. but it would need to be quantifiable as to how much.

The only real implementation of cards to seed phrase I am aware is that on https://iancoleman.io/bip39/. I am not a fan of how it works, though.

Ian's encoding scheme seems somewhat problematic in some sense.  For example, a Ten of spades "ts": "00", followed by jack of spades "js": "01" cannot be distinguished from a single 8 of hearts "8h": "0001". what that does is reduces entropy since different arrangements can lead to the same raw entropy string overall. the question is "how much of a factor does this entropy loss play overall in his encoding scheme?" the issue is not just present with 2-bit/4-bit strings but also 4-bit/5-bit strings. and then other combos like 2+4=6 and so chunks of size 30 bits cannot be resolved as 6 cards each 5 bits or some other combination. the entropy loss seems like it could be significant.

I'm not sure Ian really analyzed all of that before jumping in and coding this thing. Unfortunately. Because I guess now he can't change it.


  "6h": "11111",
        "7h": "0000",
        "8h": "0001",
        "9h": "0010",
        "th": "0011",
        "jh": "0100",
        "qh": "0101",
        "kh": "0110",
        "as": "0111",
        "2s": "1000",
        "3s": "1001",
        "4s": "1010",
        "5s": "1011",
        "6s": "1100",
        "7s": "1101",
        "8s": "1110",
        "9s": "1111",
       "ts": "00",
        "js": "01",
        "qs": "10",
        "ks": "11",

It assigns different bit values to each card. 32 cards are assigned a 5 bit string, 16 cards are assigned a 4 bit string, and 4 cards are assigned a 2 bit string. 32+16+4 = 52. There are two main issues with this. First of all, it makes some cards 8 times "more secure" than other cards, by way of them contributing 5 bits instead of 2.

Well I wouldn't necessarily call them "more secure" just because they contribute more bits. those bits are fixed in a particular order so they are just like a single "object" they can't be rearranged. no matter how many bits a particular card uses, it doesn't matter. the real issue with his encoding has to do with the entropy loss I referred to previously. And it is unfortunate. I don't think it has to be that way but you can't just go cowboy and do something without thinking it all the way through.

This simply doesn't make sense. Secondly, it encourages someone to shuffle a deck of cards and then draw them one by one, meaning that once a card has been drawn it can never be drawn again. This reduces entropy, since that particular string of bits will never occur again.

that's not how his tool is supposed to work though. you shuffle the deck and the order of the cards is the raw entropy but the problem is his encoding scheme is somewhat strange and I don't know if he really knew what he was doing when he made it up. that's just being honest.

A better way of doing it would be to assign each of the four suits a 2 bit value - spades 00, clubs 01, diamonds 10, hearts 11 - for example. Then draw a single card, write down your two bits, shuffle that card back in to the deck thoroughly, and repeat. This would take much longer than simply flipping a coin though, and still does not eliminate any unknown bias in your shuffles.

I would definitely say that is a terrible use of 225 bits of entropy. And a waste of time too. As you pointed out. The better way is to develop a true mapping of the 225 bits of entropy 1-1 into bitcoin private keys. simple as that. without using a hash function. But ian didn't take that route. In fact, I think he takes that sha256 of the raw entropy unless you're doing the 3 words with 1 bit checksum option.

[o_e_l_e_o]

Well there are 52! ways different possible orderings of a full deck of cards. that's about 225 bits. bitcoin private keys only have 128 bits of security. a little entropy loss is probably not a big deal. but it would need to be quantifiable as to how much.

And yet Ian Coleman's method generates a string of 32*5 + 16*4 + 4*2 = 232 bits if you draw the entire deck once, which is above this upper limit of entropy.

But still, how are you going to convert a string of cards to bits? Are you going to use Ian Coleman's method, which as discussed I don't like. Or do you just write your cards out as a string of 7h9sKdAc and so on and hash it? Some other method? How has your method been analyzed and tested? As I said, it is not a trivial problem.

Well I wouldn't necessarily call them "more secure" just because they contribute more bits. those bits are fixed in a particular order so they are just like a single "object" they can't be rearranged.

I don't think they are actually any more secure, hence why I put "more secure" in quotation marks. But if I can draw 4 cards and up with 8 bits of "entropy" or 20 bits of "entropy" depending on the cards, then that's a problem. If I shuffle a deck randomly, then the top card has a set amount of entropy. That amount of entropy doesn't change when I turn the card over and see what it is.

The better way is to develop a true mapping of the 225 bits of entropy 1-1 into bitcoin private keys. simple as that.

Rounding errors aside, there are 2³¹ more private keys than card orders, so by doing this you are excluding 99.99999995% of all possible private keys.

[larry_vw_1955]

And yet Ian Coleman's method generates a string of 32*5 + 16*4 + 4*2 = 232 bits if you draw the entire deck once, which is above this upper limit of entropy.

it may pump out a 232 bit string but that doesn't mean 232 bits of entropy. and therein lies the problem with his little scheme. i call it a scheme because i don't take it seriously.

But still, how are you going to convert a string of cards to bits?

I am sure there must be a way of doing that but it has to be lossless encoding. Unlike Coleman's scheme.

Are you going to use Ian Coleman's method, which as discussed I don't like. Or do you just write your cards out as a string of 7h9sKdAc and so on and hash it? Some other method?

I wouldn't use his method under any circumstances.  As for hashing the string, that's better than how he handles it but still not ideal. I like to think hashing is unnecessary.

How has your method been analyzed and tested? As I said, it is not a trivial problem.

Taking the Sha256 hash of the cards as a string is kind of like pushing the problem into the hash function. It's not really solving anything at a very fundamental level. What do you think makes this a non-trivial problem exactly? A deck of cards has 225 real bits of entropy. No more no less. They should be able to be used directly as is. Now you ask me about my method. I don't have a method yet.

The better way is to develop a true mapping of the 225 bits of entropy 1-1 into bitcoin private keys. simple as that.

Rounding errors aside, there are 2³¹ more private keys than card orders, so by doing this you are excluding 99.99999995% of all possible private keys.

There are 2^96 more bitcoin private keys than addresses. That never bothered anyone... I mean I see your point and mathematically you are correct but I'm not sure if it's a real issue. Otherwise, no one would ever have suggested using card decks for entropy right?

[BlackHatCoiner]

I am sure there must be a way of doing that but it has to be lossless encoding. Unlike Coleman's scheme.

The only way you can avoid entropy loss with a deck is to shuffle it, choose one card, put it back, shuffle again, and then repeat it for X times. Shuffling, and letting the entropy be equal with the series of cards reduces entropy, as said above.

Taking the Sha256 hash of the cards as a string is kind of like pushing the problem into the hash function.

If x is not a cryptographically secure pseudo-random number, then SHA256(x) is not either.

There are 2^96 more bitcoin private keys than addresses.

This is not true. Addresses can have various types. There's legacy, segwit native, segwit nested, taproot. Native SegWit multi-sig addresses are 256 bits, for example. Secondly, messing up with private keys is prone to introduce problems. I know no expert who suggests that 225 bits, in a 256-bit elliptic curve, are cryptographically secure enough.

[o_e_l_e_o]

What do you think makes this a non-trivial problem exactly? A deck of cards has 225 real bits of entropy. No more no less. They should be able to be used directly as is. Now you ask me about my method. I don't have a method yet.

The fact that we don't have a good method makes it a problem. The only implementation of cards to seed phrase I am aware of is Ian Coleman's, which as we have already discussed here is not great. I am not aware of any other implementation, and I'm certainly not going to propose one. They obviously can't be used "as is" since a seed phrase or a private key needs to be presented in bits, and a string of cards is not in bits nor directly convertible to bits without applying some kind of transformation.

This gets us back to the original discussion regarding converting a string of dice rolls in to a string of bits, which as I argued before, should not just be a case of applying a hash function and assuming you now have a cryptographically secure random number and you are perfectly safe.

So again, I would say that if you don't trust /dev/urandom for some reason, then stick to flipping a coin to produce a string of bits directly. Anything else is more complicated, more time consuming, and potentially less secure.

[larry_vw_1955]

The fact that we don't have a good method makes it a problem.

Well that's that I thought too but maybe we were wrong.

The only implementation of cards to seed phrase I am aware of is Ian Coleman's, which as we have already discussed here is not great.

Check out Aaron Toponce's implementation called Deckware.

https://pthree.org/2021/02/18/introducing-deckware-a-224-bit-entropy-extractor/

Plus he put it on github and it's as easy as downloading a single html file.
https://github.com/atoponce/deckware
 
Props to that dude for his hard work.

I am not aware of any other implementation, and I'm certainly not going to propose one. They obviously can't be used "as is" since a seed phrase or a private key needs to be presented in bits, and a string of cards is not in bits nor directly convertible to bits without applying some kind of transformation.

The key to extracting entropy for card decks is the ability to form a bijective map from the set of permutations of the symmetric group on n objects to the set of integers from 1 to n!. It's very simple in fact. Just maybe not easy to come up with on your own but once you see how it works, it makes sense.  

I think Aaron has a pretty good tool there, wouldn't hesitate to use it but first I would need to duplicate his results for some trial runs to make sure it works as expected. But it couldn't be made any simpler than his drag and drop idiot proof interface  

This gets us back to the original discussion regarding converting a string of dice rolls in to a string of bits, which as I argued before, should not just be a case of applying a hash function and assuming you now have a cryptographically secure random number and you are perfectly safe.

So again, I would say that if you don't trust /dev/urandom for some reason, then stick to flipping a coin to produce a string of bits directly. Anything else is more complicated, more time consuming, and potentially less secure.

Well yes, nothing is more simple than flipping a coin and getting your 256 bits that way. But it's nice to know that someone actually put in the hard work to extract the entropy from a deck of cards. Now I can just use their tool rather than trying to invent my own. With all of that said, I'm sure you'll have hesitations about this card deck entropy extracting method but it's better than anything else I've seen for card decks. Plus he bumped up the entropy level to 237 bits if you notice. since he includes the 2 jokers. problem is if you don't have the 2 jokers, you need to find some since his tool won't work without them.

[LoyceV]

More importantly, though, is how do you convert your series of cards to a usable string of bits without losing entropy or introducing bias? It is not a trivial problem.

Wouldn't a "brain wallet" be a trivial solution?
Just type: "diamonds 8, spades Queen, diamonds Jack, clubs 3, ..............", you see my point. Type it all, no entropy gets lost, and you have a private key.

once a card has been drawn it can never be drawn again

This shouldn't be a problem, as long as you use enough cards. A full deck of cards is more than enough: 52! >> 2¹⁶⁰.

[o_e_l_e_o]

Check out Aaron Toponce's implementation called Deckware.

Now this seems interesting. The underlying method of Lehmer code certainly looks preferable to Ian Coleman's implementation, although it requires using a third party's code. Although the code is simple, the whole point of using a physical method of entropy generation is to avoid doing this, and if someone doesn't trust /dev/urandom to securely generate entropy, then relying on code written by one person and (as far as I can tell from a web search) not reviewed or even discussed by anyone else ever is a bad idea. I suppose it would be possible to calculate your code manually using an airgapped computer and a simple calculator package, but the chances of making a mistake with this process are very high.

And as I said earlier in the thread, given that I have no formal training in cryptography, I cannot rule out that there is some glaring vulnerability of which I am unaware. I am not willing to risk the safety of my coins by using something which I cannot verify. I'll stick to my simple, secure, quick, and easy coin flips.

Wouldn't a "brain wallet" be a trivial solution?

Maybe. But the whole point of the argument I'm making here is that I'm not a cryptographer, so I can't say for sure. And neither is anyone else in this thread, by the looks of things.

People without extensive medical knowledge don't tend to attempt surgery (unless they are very stupid), and so we shouldn't be attempting to create our own ad hoc cryptography, especially when there already exists better tried, tested, and verified methods.

Also, a slight niggle: You do lose a small amount of entropy (<1 bit) when you hash a string for a brain wallet.

[larry_vw_1955]

Check out Aaron Toponce's implementation called Deckware.

Now this seems interesting. The underlying method of Lehmer code certainly looks preferable to Ian Coleman's implementation, although it requires using a third party's code.

To be fair, we always use third party code when generating bitcoin wallets and things. Including Ian Coleman tool. From just a brief inspection, Ian Coleman's code looks harder to read through than this particular Deckware, which looks very simple in comparison.

Although the code is simple, the whole point of using a physical method of entropy generation is to avoid doing this, and if someone doesn't trust /dev/urandom to securely generate entropy, then relying on code written by one person and (as far as I can tell from a web search) not reviewed or even discussed by anyone else ever is a bad idea.

that's probably because using a card deck for entropy is a very niche thing and not many people are willing to go to the effort of doing it. certainly not your average joe bitcoin user. so who else is there? just tech nerds maybe.

I suppose it would be possible to calculate your code manually using an airgapped computer and a simple calculator package, but the chances of making a mistake with this process are very high.

flipping a coin is simplest and probably superior to dice and cards. i think we can agree on that. dice probably come in 2nd due to their simplicity compared to cards. cards are last because it takes special processing to get your entropy. assuming one does not backup their entropy, they can use the card deck as a store of their entropy which you really can't do with dice or coins. unless you want to store 256 pennies stacked up. and then good luck not spilling them when you try and read them out.

And as I said earlier in the thread, given that I have no formal training in cryptography, I cannot rule out that there is some glaring vulnerability of which I am unaware. I am not willing to risk the safety of my coins by using something which I cannot verify. I'll stick to my simple, secure, quick, and easy coin flips.

240 bit numbers there just aren't as many of them as there are 256 bit ones. you made that point loud and clear. and you're probably right that coin flips is superior method over everything. but for someone that has a bunch of card decks lying around they might as well play around with the possibilities  

Oh I should also mention that if someone think they are going to just take the output of this Deckware and punch it into Ian Coleman, it doesn't work that way exactly. Bip39 doesn't work with 240 bit entropy. it only works with these:

|  ENT  | CS | ENT+CS |  MS  |
+-------+----+--------+------+
|  128  |  4 |   132  |  12  |
|  160  |  5 |   165  |  15  |
|  192  |  6 |   198  |  18  |
|  224  |  7 |   231  |  21  |
|  256  |  8 |   264  |  24  |

So you have to come up with a "fix" for that otherwise, I believe the Ian Coleman tool operates outside of any specification such as bip39.

[o_e_l_e_o]

To be fair, we always use third party code when generating bitcoin wallets and things.

That's the whole point of this thread - not using third party code to generate your entropy. You can flip a coin 128 times (or more, using von Neumann's approach) and encode your resulting number in to a seed phrase manually. The only third party code you need to use is a hash function to calculate the checksum. You obviously need to then use wallet software to turn that seed phrase in to a wallet, but even if you cannot read code yourself you can check two different pieces of software (such as use both Ian Coleman and Electrum) to check they both generate the same addresses from your seed phrase.

assuming one does not backup their entropy, they can use the card deck as a store of their entropy which you really can't do with dice or coins.

The whole point of generating a seed phrase is that seed phrases are easy to back up. Storing a deck of cards in a particular order is an incredibly risky idea. Anyone who finds it might use the deck without realizing what it is. You yourself might forget it is in order and absent-mindedly use it or shuffle it. Even if you are clumsy or slip when removing it from the packet and drop a few cards, or even if one end of the packet unexpectedly pops open, good luck trying to access your wallet again.

but for someone that has a bunch of card decks lying around they might as well play around with the possibilities  

This is a mindset I have always disagreed with. People create all kinds of stupid methods for generating wallets. The most recent one I remember commenting on was using emojis, with people defending it by saying "Well, it's just for fun!" Even if the author created it "just for fun", there is a not insignificant chance that someone will use it and end up losing all their coins.

[LoyceV]

Storing a deck of cards in a particular order is an incredibly risky idea. Anyone who finds it might use the deck without realizing what it is. You yourself might forget it is in order and absent-mindedly use it or shuffle it. Even if you are clumsy or slip when removing it from the packet and drop a few cards, or even if one end of the packet unexpectedly pops open, good luck trying to access your wallet again.

That's easy to prevent, by keeping multiple backups on different locations.

This is a mindset I have always disagreed with. People create all kinds of stupid methods for generating wallets.

Despite that, I'm pretty sure I can come up with many different methods that will never get hacked. I wouldn't recommend it to anyone, but if I get a deck of cards and shuffle it, I'm certain nobody will ever brute-force the Bitcoin address I create out of it.

[o_e_l_e_o]

That's easy to prevent, by keeping multiple backups on different locations.

That's what everyone should already be doing for every back up, but even so, that doesn't mean we should opt to use fragile back ups which are easily rendered useless.

Despite that, I'm pretty sure I can come up with many different methods that will never get hacked.

I know I don't have to point this out to you, but not getting hacked is not the only aspect to consider when creating a new wallet. No point using some overly complex method to ensure you will get hacked which then results in you being unable to restore your wallet.

[larry_vw_1955]

To be fair, we always use third party code when generating bitcoin wallets and things.

That's the whole point of this thread - not using third party code to generate your entropy.

That's what I was confused about when you acted like I was using Deckware to generate entropy. Deckware doesn't do that. Shuffling the cards does that. Then you just use Deckware to convert your card order into a hex string. The raw entropy was created by the physical act of shuffling the cards. Deckware is just a tool to transform that raw entropy into a hex string. But it's not really adding to it or removing any enotropy from it.

The whole point of generating a seed phrase is that seed phrases are easy to back up. Storing a deck of cards in a particular order is an incredibly risky idea. Anyone who finds it might use the deck without realizing what it is. You yourself might forget it is in order and absent-mindedly use it or shuffle it. Even if you are clumsy or slip when removing it from the packet and drop a few cards, or even if one end of the packet unexpectedly pops open, good luck trying to access your wallet again.

Yes you are right about the cards slipping out of ones' hand and that could cause a disaster. Had that almost happen to me because new cards can be slippery and so you're right about that issue. There is a fix for that though, if you take a magic marker and mark a big X along the width of the card deck. That way they could be put back into order. Never tried it but I heard about that trick. problem is if you do that then you can only do it once obviously.

This is a mindset I have always disagreed with. People create all kinds of stupid methods for generating wallets. The most recent one I remember commenting on was using emojis, with people defending it by saying "Well, it's just for fun!" Even if the author created it "just for fun", there is a not insignificant chance that someone will use it and end up losing all their coins.

What do you think about a little bingo machine that has a bunch of balls in it numbered like 1 to 80 or something? I think that could be a good way to generate entropy. It rolls them all around inside the cage and takes one out on ever turn. I'd be willing to put my life savings in it for a few days that's how confident I would be in the quality of the raw entropy it provides. Same with dice rolls or maybe even a card deck. I'm not dumb. Thing is, with that little bingo cage I still havent figured out how to convert the result into raw entropy but I think it would be similar to the card deck but not exactly the same since there are more than 54 bingo balls...

[o_e_l_e_o]

Deckware is just a tool to transform that raw entropy into a hex string. But it's not really adding to it or removing any enotropy from it.

But you only know that if you can audit the code, and the reason many people opt for a physical means of generating entropy is because they cannot audit the code of their wallet to confirm how it is creating entropy in the first place. If you cannot audit the code, how do you know there isn't some fatal flaw or maliciousness which means it is spitting out one of a very few number of possible results, or it is introducing a heavy bias?

There is a fix for that though, if you take a magic marker and mark a big X along the width of the card deck.

I've not tried this obviously, but I would imagine any two adjacent cards would be incredibly similar and therefore difficult to be 100% sure of your order. Compound two swapped cards a dozen or so times, and your coins become almost impossible to access.

What do you think about a little bingo machine that has a bunch of balls in it numbered like 1 to 80 or something?

But why? What do you think you are achieving with this over much simpler and provably secure methods like /dev/urandom or unbiased coin flips?

[BlackHatCoiner]

Honestly, Larry, what are you trying to achieve? There are nearly infinite ways to generate entropy yourself, some are simple and safe such as unbiased coin flips that have been suggested, and some are just prone to error such as shuffling a deck and use the order of cards as entropy, or playing bingo, or taking pictures of your puppies, or hashing your recorded self talking gibberish, or even a combination of those methods. The fact is, you're making it more complicated and potentially less secure.

[LoyceV]

There is a fix for that though, if you take a magic marker and mark a big X along the width of the card deck.

I've not tried this obviously, but I would imagine any two adjacent cards would be incredibly similar and therefore difficult to be 100% sure of your order.

It's easy to test: I took a brand new deck of cards, kept the original order (for my own convenience), and asked my wife to draw a line (it would be better to get a clamp next time):


Then, it "accidentally" slipped my hands

It's not even that bad: many cards were still in order and I carefully picked them up:


Face-down, I restored the line as much as possible:


Checking the front confirms they're in the original order again.

It kinda defeats the purpose of hiding data in cards though: you could just as well number the cards to make it even more obvious there's something special with them.

[o_e_l_e_o]

Well, fair enough. Although I'm sure there would be a way to draw a line which doesn't make the correct order obvious, such as at a steeper angle or with a marker pen with less defined edges. And of course most people would probably not realize until it was too late since most people don't properly test their back ups.

And I'd still argue that whole thing is unnecessarily complex, both from generating the entropy to backing it up. And obviously you need to reproduce your back up at least once, but preferably more times. Given that people make mistakes writing down 12 distinct words, there is a far higher risk of ordering a second deck incorrectly when you consider how similar many cards look.

Complexity is the enemy of security. Flip a coin, generate seed phrase, write it down. Safe, secure, simple.

[LoyceV]

draw a line which doesn't make the correct order obvious

Not for the faint of heart: draw a line, then shuffle the deck for safe keeping Storing your seed phrase in one line Much cooler than the 100 dots I was working on months ago (but never completed due to lack of steel plate). ^{(seriously reader, don't do this!)}

And obviously you need to reproduce your back up at least once, but preferably more times. Given that people make mistakes writing down 12 distinct words, there is a far higher risk of ordering a second deck incorrectly when you consider how similar many cards look.

That's easy to prevent by being thorough, and testing each individual backup.

[philipma1957]

hmm how about a pair of bingo machines with ping pong balls in it?

numbers 1-75

https://www.amazon.com/MR-CHIPS-Professional-Bingo-Balls/dp/B0813WSDWF?th=1

spin for 1 minute out pops a number 1-75 seems pretty random but not enough to give all the words on the list..

 is not the list 2048 words.

so use 32 numbers in one bingo machine 1-32

and 64 numbers in second bingo machine 1-64

if first machine pops a 1

and second machine pops a 1

your 1-1 is the first word on the list of 2048


if your first machine spins a 32
and your second machine spins a 64

it is the 2048 word on the list

this methods does allow for repeated words which is okay and

spinning two machines for 1 minute gives 1 random word.

so 24 minutes gives you a 24 word list.

pretty fucking random i think.

as to storing the 24 words good luck with that different topic.

1 of 32 :
0001) abandon
0002) ability
0003) able
0004) about
0005) above
0006) absent
0007) absorb
0008) abstract
0009) absurd
0010) abuse
0011) access
0012) accident
0013) account
0014) accuse
0015) achieve
0016) acid
0017) acoustic
0018) acquire
0019) across
0020) act
0021) action
0022) actor
actress
actual
adapt
add
addict
address
adjust
admit
adult
advance
advice
aerobic
affair
afford
afraid
again
age
agent
agree
ahead
aim
air
airport
aisle
alarm
album
alcohol
alert
alien
all
alley
allow
almost
alone
0057) alpha
0058) already
0059) also
0060) alter
0061) always
0062) amateur
0063) amazing
0064) among


32/32


1984) way     =number 32 first ball  number   1 second ball
1985) wealth =number 32 first ball number    2 second ball
1986) weapon = number 32 first ball number 3 second ball
1987) wear
1988) weasel
1989) weather
1990) web
1991) wedding
1992) weekend
1993) weird
welcome
west
wet
whale
what
wheat
wheel
when
where
whip
whisper
wide
width
wife
wild
will
win
window
wine
wing
wink
winner
winter
wire
wisdom
wise
wish
witness
wolf
woman
wonder
wood
wool
word
work
world
worry
worth
wrap
wreck
wrestle
wrist
write
wrong
yard
2040) year
2041) yellow
2042) you
2043) young
2044) youth
2045) zebra
2046) zero
2047) zone
2048) zoo  = ball number 32 first ball  number 64 second ball


seems like it will be fun to build this.

[larry_vw_1955]

If you cannot audit the code, how do you know there isn't some fatal flaw or maliciousness which means it is spitting out one of a very few number of possible results, or it is introducing a heavy bias?

well you don't. simple as that. which is why code audits are important. when looking over deckware, i can see that it doesn't seem to be trying to connect to the internet anywhere in the code. so that's good. obviously though more analysis of its implementation of the lehmer code would be needed to see if it really is working correctly. not saying it's not but i would need to verify. especially since it's not something alot of people use and if there was bugs in it, you might not be able to just "google it".

But why? What do you think you are achieving with this over much simpler and provably secure methods like /dev/urandom or unbiased coin flips?

the more ways to do something the better. let's say metal coins went out of circulation and became a rarity. isn't that almost happening as the world transforms into a digital economy via bitcoin and credit cards and such? people might not have coins to flip. not everyone has coins lying around since why would they? they use digital money. i'd be willing to bet there are people out there who have no coins at all lying around in their possession. probably alot!

Complexity is the enemy of security. Flip a coin, generate seed phrase, write it down. Safe, secure, simple.

the more ways i look into gathering entropy the more I agree with the above statement as far as flipping a coin being the simplest, safest, most secure PHYSICAL method. we can't argue with that.

hmm how about a pair of bingo machines with ping pong balls in it?

the way you described it at first it looks like a good idea but then after i thought a bit more i realize it has a problem.

this methods does allow for repeated words which is okay and

i'm not sure it is ok. unless all words get repeated with the same frequency. but i don't think that's the case so it suffers from BIAS. not all integers have the same number of factorizations.

seems like it will be fun to build this.

even just one bingo cage is fun.  you get to rolling those things around in the cage and its like looking randomness in the face.

[NotATether]

More importantly, though, is how do you convert your series of cards to a usable string of bits without losing entropy or introducing bias? It is not a trivial problem.

Wouldn't a "brain wallet" be a trivial solution?
Just type: "diamonds 8, spades Queen, diamonds Jack, clubs 3, ..............", you see my point. Type it all, no entropy gets lost, and you have a private key.

once a card has been drawn it can never be drawn again

This shouldn't be a problem, as long as you use enough cards. A full deck of cards is more than enough: 52! >> 2¹⁶⁰.

The problem here is not with the security but with the naming. If you do not standardize the card names, then you'll end up having any of "Queen", "queen", "Q", "q" as possible names and similarly for the four card classes, and the spaces and commas (or lack of them) could also be written incorrectly which will make it impossible to remember the generating phrase.

[o_e_l_e_o]

the more ways to do something the better.

Disagree. The more ways there are to do something then the more chance that one of those ways is fundamentally flawed, that one of those ways is not secure, that one of those ways is too complex to back up, and so on. Far better to stick to a small number of reviewed, tested, and verified methods, than just coming up with a dozen new ones just for the sake of it.

let's say metal coins went out of circulation and became a rarity.

Flip anything using von Neumann's algorithm, and the bias doesn't matter. Doesn't strictly have to be a coin. A key would be a suitable alternative - robust, heavy enough to easily flip, and most keys have some writing or engraving which is different on each side.

[philipma1957]

If you cannot audit the code, how do you know there isn't some fatal flaw or maliciousness which means it is spitting out one of a very few number of possible results, or it is introducing a heavy bias?

well you don't. simple as that. which is why code audits are important. when looking over deckware, i can see that it doesn't seem to be trying to connect to the internet anywhere in the code. so that's good. obviously though more analysis of its implementation of the lehmer code would be needed to see if it really is working correctly. not saying it's not but i would need to verify. especially since it's not something alot of people use and if there was bugs in it, you might not be able to just "google it".

But why? What do you think you are achieving with this over much simpler and provably secure methods like /dev/urandom or unbiased coin flips?

the more ways to do something the better. let's say metal coins went out of circulation and became a rarity. isn't that almost happening as the world transforms into a digital economy via bitcoin and credit cards and such? people might not have coins to flip. not everyone has coins lying around since why would they? they use digital money. i'd be willing to bet there are people out there who have no coins at all lying around in their possession. probably alot!

Complexity is the enemy of security. Flip a coin, generate seed phrase, write it down. Safe, secure, simple.

the more ways i look into gathering entropy the more I agree with the above statement as far as flipping a coin being the simplest, safest, most secure PHYSICAL method. we can't argue with that.

hmm how about a pair of bingo machines with ping pong balls in it?

the way you described it at first it looks like a good idea but then after i thought a bit more i realize it has a problem.

this methods does allow for repeated words which is okay and

i'm not sure it is ok. unless all words get repeated with the same frequency. but i don't think that's the case so it suffers from BIAS. not all integers have the same number of factorizations.

seems like it will be fun to build this.

even just one bingo cage is fun.   you get to rolling those things around in the cage and its like looking randomness in the face.

Okay 2048 numbers

2048/32 = 64

so machine a with balls 1-32
machine b with balls 1-64


 spin both machines a and b will always be a 1/2048 chance to get a word

as 32x64 = 2048

every word has a 2 ball assignment.

Machine a say 1
Machine b say 1 is the first word on the list    abandon


Machine a say 1
Machine b say 2 is the second word on the list ability


I do not see how it fails to not be a 1/2048 chance every time  since repeats are allowed.

and if real lists do not allow for a repeat simply skip the repeats if they occur.

I seem to recall getting a list that repeated a word but it was years ago.

Code:

abandon
0001) ability = (  bingo a 1) + ( bingo b 1 )
0002) able    = ( bingo a  1) + ( bingo b 2 )
0003) about  = ( bingo a  1) + ( bingo b 3 )
0004) above
0005) absent
absorb
abstract
absurd
abuse
access
accident
account
accuse
achieve
acid
acoustic
acquire
across
act
action
actor
actress
actual
adapt
add
addict
address
adjust
admit
adult
advance
advice
aerobic
affair
afford
afraid
again
age
agent
agree
ahead
aim
air
airport
aisle
alarm
album
alcohol
alert
alien
all
alley
allow
almost
alone
alpha
already
also
alter
always
amateur
amazing
among
0065) amount (bingo a 2) + (bingo b 1)
amused
analyst
anchor
ancient
anger
angle
angry
animal
ankle
announce
annual
another
answer
antenna
antique
anxiety
any
apart
apology
appear
apple
approve
april
arch
arctic
area
arena
argue
arm
armed
armor
army
around
arrange
arrest
arrive
arrow
art
artefact
artist
artwork
ask
aspect
assault
asset
assist
assume
asthma
athlete
atom
attack
attend
attitude
attract
auction
audit
august
aunt
author
auto
autumn
average
avocado
avoid
awake
aware
away
awesome
awful
awkward
axis
baby
bachelor
bacon
badge
bag
balance
balcony
ball
bamboo
banana
banner
bar
barely
bargain
barrel
base
basic
basket
battle
beach
bean
beauty
because
become
beef
before
begin
behave
behind
believe
below
belt
bench
benefit
best
betray
better
between
beyond
bicycle
bid
bike
bind
biology
bird
birth
bitter
black
blade
blame
blanket
blast
bleak
bless
blind
blood
blossom
blouse
blue
blur
blush
board
boat
body
boil
bomb
bone
bonus
book
boost
border
boring
borrow
boss
bottom
bounce
box
boy
bracket
brain
brand
brass
brave
bread
breeze
brick
bridge
brief
bright
bring
brisk
broccoli
broken
bronze
broom
brother
brown
brush
bubble
buddy
budget
buffalo
build
bulb
bulk
bullet
bundle
bunker
burden
burger
burst
bus
business
busy
butter
buyer
buzz
cabbage
cabin
cable
cactus
cage
cake
call
calm
camera
camp
can
canal
cancel
candy
cannon
canoe
canvas
canyon
capable
capital
captain
car
carbon
card
cargo
carpet
carry
cart
case
cash
casino
castle
casual
cat
catalog
catch
category
cattle
caught
cause
caution
cave
ceiling
celery
cement
census
century
cereal
certain
chair
chalk
champion
change
chaos
chapter
charge
chase
chat
cheap
check
cheese
chef
cherry
chest
chicken
chief
child
chimney
choice
choose
chronic
chuckle
chunk
churn
cigar
cinnamon
circle
citizen
city
civil
claim
clap
clarify
claw
clay
clean
clerk
clever
click
client
cliff
climb
clinic
clip
clock
clog
close
cloth
cloud
clown
club
clump
cluster
clutch
coach
coast
coconut
code
coffee
coil
coin
collect
color
column
combine
come
comfort
comic
common
company
concert
conduct
confirm
congress
connect
consider
control
convince
cook
cool
copper
copy
coral
core
corn
correct
cost
cotton
couch
country
couple
course
cousin
cover
coyote
crack
cradle
craft
cram
crane
crash
crater
crawl
crazy
cream
credit
creek
crew
cricket
crime
crisp
critic
crop
cross
crouch
crowd
crucial
cruel
cruise
crumble
crunch
crush
cry
crystal
cube
culture
cup
cupboard
curious
current
curtain
curve
cushion
custom
cute
cycle
dad
damage
damp
dance
danger
daring
dash
daughter
dawn
day
deal
debate
debris
decade
december
decide
decline
decorate
decrease
deer
defense
define
defy
degree
delay
deliver
demand
demise
denial
dentist
deny
depart
depend
deposit
depth
deputy
derive
describe
desert
design
desk
despair
destroy
detail
detect
develop
device
devote
diagram
dial
diamond
diary
dice
diesel
diet
differ
digital
dignity
dilemma
dinner
dinosaur
direct
dirt
disagree
discover
disease
dish
dismiss
disorder
display
distance
divert
divide
divorce
dizzy
doctor
document
dog
doll
dolphin
domain
donate
donkey
donor
door
dose
double
dove
draft
dragon
drama
drastic
draw
dream
dress
drift
drill
drink
drip
drive
drop
drum
dry
duck
dumb
dune
during
dust
dutch
duty
dwarf
dynamic
eager
eagle
early
earn
earth
easily
east
easy
echo
ecology
economy
edge
edit
educate
effort
egg
eight
either
elbow
elder
electric
elegant
element
elephant
elevator
elite
else
embark
embody
embrace
emerge
emotion
employ
empower
empty
enable
enact
end
endless
endorse
enemy
energy
enforce
engage
engine
enhance
enjoy
enlist
enough
enrich
enroll
ensure
enter
entire
entry
envelope
episode
equal
equip
era
erase
erode
erosion
error
erupt
escape
essay
essence
estate
eternal
ethics
evidence
evil
evoke
evolve
exact
example
excess
exchange
excite
exclude
excuse
execute
exercise
exhaust
exhibit
exile
exist
exit
exotic
expand
expect
expire
explain
expose
express
extend
extra
eye
eyebrow
fabric
face
faculty
fade
faint
faith
fall
false
fame
family
famous
fan
fancy
fantasy
farm
fashion
fat
fatal
father
fatigue
fault
favorite
feature
february
federal
fee
feed
feel
female
fence
festival
fetch
fever
few
fiber
fiction
field
figure
file
film
filter
final
find
fine
finger
finish
fire
firm
first
fiscal
fish
fit
fitness
fix
flag
flame
flash
flat
flavor
flee
flight
flip
float
flock
floor
flower
fluid
flush
fly
foam
focus
fog
foil
fold
follow
food
foot
force
forest
forget
fork
fortune
forum
forward
fossil
foster
found
fox
fragile
frame
frequent
fresh
friend
fringe
frog
front
frost
frown
frozen
fruit
fuel
fun
funny
furnace
fury
future
gadget
gain
galaxy
gallery
game
gap
garage
garbage
garden
garlic
garment
gas
gasp
gate
gather
gauge
gaze
general
genius
genre
gentle
genuine
gesture
ghost
giant
gift
giggle
ginger
giraffe
girl
give
glad
glance
glare
glass
glide
glimpse
globe
gloom
glory
glove
glow
glue
goat
goddess
gold
good
goose
gorilla
gospel
gossip
govern
gown
grab
grace
grain
grant
grape
grass
gravity
great
green
grid
grief
grit
grocery
group
grow
grunt
guard
guess
guide
guilt
guitar
gun
gym
habit
hair
half
hammer
hamster
hand
happy
harbor
hard
harsh
harvest
hat
have
hawk
hazard
head
health
heart
heavy
hedgehog
height
hello
helmet
help
hen
hero
hidden
high
hill
hint
hip
hire
history
hobby
hockey
hold
hole
holiday
hollow
home
honey
hood
hope
horn
horror
horse
hospital
host
hotel
hour
hover
hub
huge
human
humble
humor
hundred
hungry
hunt
hurdle
hurry
hurt
husband
hybrid
ice
icon
idea
identify
idle
ignore
ill
illegal
illness
image
imitate
immense
immune
impact
impose
improve
impulse
inch
include
income
increase
index
indicate
indoor
industry
infant
inflict
inform
inhale
inherit
initial
inject
injury
inmate
inner
innocent
input
inquiry
insane
insect
inside
inspire
install
intact
interest
into
invest
invite
involve
iron
island
isolate
issue
item
ivory
jacket
jaguar
jar
jazz
jealous
jeans
jelly
jewel
job
join
joke
journey
joy
judge
juice
jump
jungle
junior
junk
just
kangaroo
keen
keep
ketchup
key
kick
kid
kidney
kind
kingdom
kiss
kit
kitchen
kite
kitten
kiwi
knee
knife
knock
know
lab
label
labor
ladder
lady
lake
lamp
language
laptop
large
later
latin
laugh
laundry
lava
law
lawn
lawsuit
layer
lazy
leader
leaf
learn
leave
lecture
left
leg
legal
legend
leisure
lemon
lend
length
lens
leopard
lesson
letter
level
liar
liberty
library
license
life
lift
light
like
limb
limit
link
lion
liquid
list
little
live
lizard
load
loan
lobster
local
lock
logic
lonely
long
loop
lottery
loud
lounge
love
loyal
lucky
luggage
lumber
lunar
lunch
luxury
lyrics
machine
mad
magic
magnet
maid
mail
main
major
make
mammal
man
manage
mandate
mango
mansion
manual
maple
marble
march
margin
marine
market
marriage
mask
mass
master
match
material
math
matrix
matter
maximum
maze
meadow
mean
measure
meat
mechanic
medal
media
melody
melt
member
memory
mention
menu
mercy
merge
merit
merry
mesh
message
metal
method
middle
midnight
milk
million
mimic
mind
minimum
minor
minute
miracle
mirror
misery
miss
mistake
mix
mixed
mixture
mobile
model
modify
mom
moment
monitor
monkey
monster
month
moon
moral
more
morning
mosquito
mother
motion
motor
mountain
mouse
move
movie
much
muffin
mule
multiply
muscle
museum
mushroom
music
must
mutual
myself
mystery
myth
naive
name
napkin
narrow
nasty
nation
nature
near
neck
need
negative
neglect
neither
nephew
nerve
nest
net
network
neutral
never
news
next
nice
night
noble
noise
nominee
noodle
normal
north
nose
notable
note
nothing
notice
novel
now
nuclear
number
nurse
nut
oak
obey
object
oblige
obscure
observe
obtain
obvious
occur
ocean
october
odor
off
offer
office
often
oil
okay
old
olive
olympic
omit
once
one
onion
online
only
open
opera
opinion
oppose
option
orange
orbit
orchard
order
ordinary
organ
orient
original
orphan
ostrich
other
outdoor
outer
output
outside
oval
oven
over
own
owner
oxygen
oyster
ozone
pact
paddle
page
pair
palace
palm
panda
panel
panic
panther
paper
parade
parent
park
parrot
party
pass
patch
path
patient
patrol
pattern
pause
pave
payment
peace
peanut
pear
peasant
pelican
pen
penalty
pencil
people
pepper
perfect
permit
person
pet
phone
photo
phrase
physical
piano
picnic
picture
piece
pig
pigeon
pill
pilot
pink
pioneer
pipe
pistol
pitch
pizza
place
planet
plastic
plate
play
please
pledge
pluck
plug
plunge
poem
poet
point
polar
pole
police
pond
pony
pool
popular
portion
position
possible
post
potato
pottery
poverty
powder
power
practice
praise
predict
prefer
prepare
present
pretty
prevent
price
pride
primary
print
priority
prison
private
prize
problem
process
produce
profit
program
project
promote
proof
property
prosper
protect
proud
provide
public
pudding
pull
pulp
pulse
pumpkin
punch
pupil
puppy
purchase
purity
purpose
purse
push
put
puzzle
pyramid
quality
quantum
quarter
question
quick
quit
quiz
quote
rabbit
raccoon
race
rack
radar
radio
rail
rain
raise
rally
ramp
ranch
random
range
rapid
rare
rate
rather
raven
raw
razor
ready
real
reason
rebel
rebuild
recall
receive
recipe
record
recycle
reduce
reflect
reform
refuse
region
regret
regular
reject
relax
release
relief
rely
remain
remember
remind
remove
render
renew
rent
reopen
repair
repeat
replace
report
require
rescue
resemble
resist
resource
response
result
retire
retreat
return
reunion
reveal
review
reward
rhythm
rib
ribbon
rice
rich
ride
ridge
rifle
right
rigid
ring
riot
ripple
risk
ritual
rival
river
road
roast
robot
robust
rocket
romance
roof
rookie
room
rose
rotate
rough
round
route
royal
rubber
rude
rug
rule
run
runway
rural
sad
saddle
sadness
safe
sail
salad
salmon
salon
salt
salute
same
sample
sand
satisfy
satoshi
sauce
sausage
save
say
scale
scan
scare
scatter
scene
scheme
school
science
scissors
scorpion
scout
scrap
screen
script
scrub
sea
search
season
seat
second
secret
section
security
seed
seek
segment
select
sell
seminar
senior
sense
sentence
series
service
session
settle
setup
seven
shadow
shaft
shallow
share
shed
shell
sheriff
shield
shift
shine
ship
shiver
shock
shoe
shoot
shop
short
shoulder
shove
shrimp
shrug
shuffle
shy
sibling
sick
side
siege
sight
sign
silent
silk
silly
silver
similar
simple
since
sing
siren
sister
situate
six
size
skate
sketch
ski
skill
skin
skirt
skull
slab
slam
sleep
slender
slice
slide
slight
slim
slogan
slot
slow
slush
small
smart
smile
smoke
smooth
snack
snake
snap
sniff
snow
soap
soccer
social
sock
soda
soft
solar
soldier
solid
solution
solve
someone
song
soon
sorry
sort
soul
sound
soup
source
south
space
spare
spatial
spawn
speak
special
speed
spell
spend
sphere
spice
spider
spike
spin
spirit
split
spoil
sponsor
spoon
sport
spot
spray
spread
spring
spy
square
squeeze
squirrel
stable
stadium
staff
stage
stairs
stamp
stand
start
state
stay
steak
steel
stem
step
stereo
stick
still
sting
stock
stomach
stone
stool
story
stove
strategy
street
strike
strong
struggle
student
stuff
stumble
style
subject
submit
subway
success
such
sudden
suffer
sugar
suggest
suit
summer
sun
sunny
sunset
super
supply
supreme
sure
surface
surge
surprise
surround
survey
suspect
sustain
swallow
swamp
swap
swarm
swear
sweet
swift
swim
swing
switch
sword
symbol
symptom
syrup
system
table
tackle
tag
tail
talent
talk
tank
tape
target
task
taste
tattoo
taxi
teach
team
tell
ten
tenant
tennis
tent
term
test
text
thank
that
theme
then
theory
there
they
thing
this
thought
three
thrive
throw
thumb
thunder
ticket
tide
tiger
tilt
timber
time
tiny
tip
tired
tissue
title
toast
tobacco
today
toddler
toe
together
toilet
token
tomato
tomorrow
tone
tongue
tonight
tool
tooth
top
topic
topple
torch
tornado
tortoise
toss
total
tourist
toward
tower
town
toy
track
trade
traffic
tragic
train
transfer
trap
trash
travel
tray
treat
tree
trend
trial
tribe
trick
trigger
trim
trip
trophy
trouble
truck
true
truly
trumpet
trust
truth
try
tube
tuition
tumble
tuna
tunnel
turkey
turn
turtle
twelve
twenty
twice
twin
twist
two
type
typical
ugly
umbrella
unable
unaware
uncle
uncover
under
undo
unfair
unfold
unhappy
uniform
unique
unit
universe
unknown
unlock
until
unusual
unveil
update
upgrade
uphold
upon
upper
upset
urban
urge
usage
use
used
useful
useless
usual
utility
vacant
vacuum
vague
valid
valley
valve
van
vanish
vapor
various
vast
vault
vehicle
velvet
vendor
venture
venue
verb
verify
version
very
vessel
veteran
viable
vibrant
vicious
victory
video
view
village
vintage
violin
virtual
virus
visa
visit
visual
vital
vivid
vocal
voice
void
volcano
volume
vote
voyage
wage
wagon
wait
walk
wall
walnut
want
warfare
warm
warrior
wash
wasp
waste
water
wave
way
wealth
weapon
wear
weasel
weather
web
wedding
weekend
weird
welcome
west
wet
whale
what
wheat
wheel
when
where
whip
whisper
wide
width
wife
wild
will
win
window
wine
wing
wink
winner
winter
wire
wisdom
wise
wish
witness
wolf
woman
wonder
wood
wool
word
work
world
worry
worth
wrap
wreck
wrestle
wrist
write
wrong
yard
year
yellow
you
young
youth
zebra
zero
zone
zoo

[o_e_l_e_o]

I do not see how it fails to not be a 1/2048 chance every time  since repeats are allowed.

No, you are right. Each word in this set up has exactly one combination which will generate it, so provided all your balls have an exactly equal chance of being drawn, then this would work. However, the tests required to ensure no bias in this set up are significantly longer and more complex than those for flipping a coin, which as I pointed out earlier in this thread would still require ~16,000 flips to even begin to approach being comfortable that the bias was small enough to not significantly reduce the security of your entropy. So again, this is yet another method I would not recommend.

I seem to recall getting a list that repeated a word but it was years ago.

Yes, words can repeat in seed phrases. There is around a 1 in 31 chance of this happening in 12 word seed phrases, and around a 1 in 8 chance in 24 word seed phrases.

[philipma1957]

I do not see how it fails to not be a 1/2048 chance every time  since repeats are allowed.

No, you are right. Each word in this set up has exactly one combination which will generate it, so provided all your balls have an exactly equal chance of being drawn, then this would work. However, the tests required to ensure no bias in this set up are significantly longer and more complex than those for flipping a coin, which as I pointed out earlier in this thread would still require ~16,000 flips to even being to approach being comfortable that the bias was small enough to be irrelevant. So again, this is yet another method I would not recommend.

I seem to recall getting a list that repeated a word but it was years ago.

Yes, words can repeat in seed phrases. There is around a 1 in 31 chance of this happening in 12 word seed phrases, and around a 1 in 8 chance in 24 word seed phrases.

Yeah I suppose the balls do not have exactly equal shape and size and weight. So in theory B1 in the 32 ball setup could be 1 in 30 not 1 in 32 due to an uneven shape/size/weight

and or B1 in the 64 ball setup could be a 1 in 61 not 1 in 64 due to an uneven shape/size/weight

But knowing dice and coins  are often bias I guess perfect randomness is hard to insure.

[larry_vw_1955]

Disagree. The more ways there are to do something then the more chance that one of those ways is fundamentally flawed, that one of those ways is not secure, that one of those ways is too complex to back up, and so on. Far better to stick to a small number of reviewed, tested, and verified methods, than just coming up with a dozen new ones just for the sake of it.

all I'm saying is this bingo cage method seems pretty solid to me. is this bingo cage method for everyone? absolutely not. its probably not for anyone unless they are willing to learn how to convert permutations into numbers using some programming language. and all that that entails. but when did some trial runs of my bingo cage and drew the numbers out one by one, I felt like it was producing some high quality randomness. so of course that made me motivated to see it to its full conclusion. it took about 10 to 15 minutes to generate the full sequence of numbers. and then a few minutes to record them onto a piece of paper.

there's something about generating entropy in a physical fashion that beats doing it on a computer. I've done it using /dev/random on linux. done it using dice. the physical way though just feels like it's more secure.

let's say metal coins went out of circulation and became a rarity.

Flip anything using von Neumann's algorithm, and the bias doesn't matter. Doesn't strictly have to be a coin. A key would be a suitable alternative - robust, heavy enough to easily flip, and most keys have some writing or engraving which is different on each side.

so one of my things on my todo list is flipping a coin 256 times. i'm not sure if i'll use the von neumann method on it but i would like to just do the coin flipping thing to see how that feels. a random coin shoudn't really contain much bias anyway i wouldn't think. so for just a one-off trial run, i should be ok doing it that way to start.

I do not see how it fails to not be a 1/2048 chance every time  since repeats are allowed.

ok well maybe i misunderstood how it worked so yeah maybe you're right. if one doesn't mind doing alot of spinning of the bingo cages i guess it works but i would be concerned that when i replace the ball after it comes out, am i spinning the cage enough to give it the proper chance to be selected again on the next draw. or maybe if i don't spin the cage enough the chances of that ball getting selected again are lower or higher than they really should be. i don't know.

[o_e_l_e_o]

this bingo cage method seems pretty solid to me
I felt like it was producing some high quality randomness
the physical way though just feels like it's more secure

Forgive me for butchering your quote and adding emphasis, but this seems to be where we fundamentally disagree. Something feeling secure and something being secure are not the same thing. We have seen countless examples on this forum of people who have come up with their own methods for generating private keys or backing up wallets which they think are safe and secure, and the end up with all their coins being stolen or their wallets being irretrievably lost. People think they are good at being random and picking passwords, for example, when we know that human generated passwords are usually the weakest there are.

I'm not interested in how secure something feels. I'm interested in hard data which proves it is secure. And the fact is that to prove to a reasonable certainty that there is no bias in this kind of bingo system takes complex math and hundreds of thousands of trial runs, which no one will ever do. Therefore you shouldn't use this system.

[LoyceV]

I'm not interested in how secure something feels. I'm interested in hard data which proves it is secure.

I like to think I'm in the same boat, but many (if not most) people are the opposite, because risk isn't something you understand intuitively.

[larry_vw_1955]

this bingo cage method seems pretty solid to me
I felt like it was producing some high quality randomness
the physical way though just feels like it's more secure

Forgive me for butchering your quote and adding emphasis, but this seems to be where we fundamentally disagree. Something feeling secure and something being secure are not the same thing.

I'm not interested in how secure something feels. I'm interested in hard data which proves it is secure. And the fact is that to prove to a reasonable certainty that there is no bias in this kind of bingo system takes complex math and hundreds of thousands of trial runs, which no one will ever do. Therefore you shouldn't use this system.

i think we can say that if lotteries use variants of the bingo cage system (they blow air into the balls and let one ball come through a tube at a time) if it's good enough for handing out 500 million dollars to someone that can pick the winning balls then i think it's good enough to secure my bitcoin or whatever crypto i'm trying to store. now is that what makes me think my bingo cage is producing high quality entropy otherwise i wouldn't really feel confident? of course not. some things are just obvious. like radioactive decay being random. can you prove that? do you demand proof of it before you would accept it? probably not. in fact, you can't prove it. all you can do is say based on observations so far it seems to....

We have seen countless examples on this forum of people who have come up with their own methods for generating private keys or backing up wallets which they think are safe and secure, and the end up with all their coins being stolen or their wallets being irretrievably lost.

yeah, well I don't know what examples you're talking about but i doubt they have anything to do with with this bingo cage method. if they would have used it instead they probably wouldn't have lost their coins. and when I say used it i mean used it responsibly and correctly. which means you get your entropy and then seed and then backup the seed in a correct way.

trying to be clever by backing things up in a non-standard way though is an ideal way to lose your bitcoin, i would agree 

People think they are good at being random and picking passwords, for example, when we know that human generated passwords are usually the weakest there are.

who said anything about trying to pick passwords out of my head? i'm not trying to do that at all

[philipma1957]

this bingo cage method seems pretty solid to me
I felt like it was producing some high quality randomness
the physical way though just feels like it's more secure

Forgive me for butchering your quote and adding emphasis, but this seems to be where we fundamentally disagree. Something feeling secure and something being secure are not the same thing. We have seen countless examples on this forum of people who have come up with their own methods for generating private keys or backing up wallets which they think are safe and secure, and the end up with all their coins being stolen or their wallets being irretrievably lost. People think they are good at being random and picking passwords, for example, when we know that human generated passwords are usually the weakest there are.

I'm not interested in how secure something feels. I'm interested in hard data which proves it is secure. And the fact is that to prove to a reasonable certainty that there is no bias in this kind of bingo system takes complex math and hundreds of thousands of trial runs, which no one will ever do. Therefore you shouldn't use this system.

I beg to differ for a lot of reasons,but I do agree that the 1/2048 for every word is more likely to be in a range of 1/2000 to 1/2100 for each word on the list.

than it is to be a perfect 1/2048


but no one will have tested and found out which is 1/2000 or 1/2100.  since testing this is actually not possible.

reason being wear and tear on the equipment will shift the odds.

So the ability to know what the true likely of the 2048 combos is makes it another kind of randomness.

Lets say I am a magical person or lets say in an imaginary situation the range is from 1/2000 to 1/2100

only the magical person would know which combo is bias to 1/2000 and even if the magical person perfectly  
determines the true bias of each and every number  1/2000 to the 24th power is almost as big as 1/2048 to the 24th power in terms of the likely hood of cracking the bingo code.

I would think the mechanical bingo method is good enough if you do a 24 word key.


oh make it more fun spin the bingo blind folded and use a 60 second timer

get your  1 to 32

walk to next machine spin it blind folded with a 60 second timer bell . when it rings get your number

granted if you do 24 words it is two spins a word. so at least 48 minutes but it is pretty fucking random.


just not exactly 1/2048 to the 24 power random.

I kind of like the non exact randomness on a conceptual level.

[o_e_l_e_o]

i think we can say that if lotteries use variants of the bingo cage system (they blow air into the balls and let one ball come through a tube at a time) if it's good enough for handing out 500 million dollars to someone that can pick the winning balls then i think it's good enough to secure my bitcoin or whatever crypto i'm trying to store.

And do you have a high grade, thoroughly tested, independently audited, state or national level lottery machine in your house? Or do you have some kids toy you bought for 20 bucks? They are not comparable.

like radioactive decay being random. can you prove that? do you demand proof of it before you would accept it? probably not. in fact, you can't prove it. all you can do is say based on observations so far it seems to....

That's pretty much how all of science works. We have mountains of data from hundreds of years of global study that says that radioactive decay is random. How much data do you have on your little bingo machine at home?

This is again my point. I don't want entropy I think is random. I want entropy which has been proven to be random.

I would think the mechanical bingo method is good enough if you do a 24 word key.

There we go again. "I would think". What you are proposing may well be safe enough, but we don't know that. And the amount of time and complexity required to exclude bias from a bingo machine is out of reach of the average Joe.

[larry_vw_1955]

And do you have a high grade, thoroughly tested, independently audited, state or national level lottery machine in your house? Or do you have some kids toy you bought for 20 bucks? They are not comparable.

Just a kids toy. That's why it was made anyway.

That's pretty much how all of science works. We have mountains of data from hundreds of years of global study that says that radioactive decay is random. How much data do you have on your little bingo machine at home?

I have about 7 full test runs completed. Where i drew out all the balls one by one in each test run and recorded the order in which they came out. I was careful to not store the sequences of numbers online. As I'm not wasting all that time for nothing. Except for one of them I did store it online as a test vector for further processing purposes later on. (conversion to a mnemonic phrase).

This is again my point. I don't want entropy I think is random. I want entropy which has been proven to be random.

I doubt you will find any research papers of people trying to assess the entropy quality of bingo machines. There doesn't seem to be much interest in the topic. Although there surely is with dice.

[philipma1957]

i think we can say that if lotteries use variants of the bingo cage system (they blow air into the balls and let one ball come through a tube at a time) if it's good enough for handing out 500 million dollars to someone that can pick the winning balls then i think it's good enough to secure my bitcoin or whatever crypto i'm trying to store.

And do you have a high grade, thoroughly tested, independently audited, state or national level lottery machine in your house? Or do you have some kids toy you bought for 20 bucks? They are not comparable.

like radioactive decay being random. can you prove that? do you demand proof of it before you would accept it? probably not. in fact, you can't prove it. all you can do is say based on observations so far it seems to....

That's pretty much how all of science works. We have mountains of data from hundreds of years of global study that says that radioactive decay is random. How much data do you have on your little bingo machine at home?

This is again my point. I don't want entropy I think is random. I want entropy which has been proven to be random.

I would think the mechanical bingo method is good enough if you do a 24 word key.

There we go again. "I would think". What you are proposing may well be safe enough, but we don't know that. And the amount of time and complexity required to exclude bias from a bingo machine is out of reach of the average Joe.

No one can perfectly determine the bias on a bingo machine.

First weigh every ball
Second do dozens of diameter and circumference measurements.

If you do this put the balls in and rotate machine for a minute the very act of rotation will alter the balls at they hit each other and even if they were not bias at the beginning of the roll they will be be the end of the roll.

What you are missing is that the bias created by rotating the machine and bouncing the balls would be random.

What you are missing is 2 machines 32 balls in machine one always change their bias with each and every roll

What you are missing is second machine with 64 balls changes the bias a tiny bit with every section.

compound an unknown bias which changes with every roll by 24 + 24 rolls it is random actually more random then is measurable by any mechanical means.  

It is perfectly random" No it is randomly random. Nuff said

as I won't be able to convince you that buying a pair of 100 usd dollar bingo machines is pretty much mechanical perfection

with 2 givens just weigh the balls and measure the circumference of them.

If the balls are within 0.001 grams and 0.001mm my guess is it is far better than any other method.

Obviously if a ball is too big it may never be picked very easy to see if the balls are far too big or too small. Simply have a few precise holes

say
1 and 1/64 inch
1 inch
63/64 inch
31/32 inch

see at what point the ball fits if they are within 1/64 of an inch the bias won't do much.

if they should weigh 10 grams allow 9.99 to 10.01 grams

those would not greatly alter the bias.

who cares if it is not random but has an unknown bias to:

 pick  abandon  1001 out of 2,048,000 picks
 pick  zoo           999 out of 2,048,000 picks

the reality is no one will spin the machines enough to get a true number and the next spin can alter the math as the balls get worn.

so math would say it is not provable that it is random.  which is what you are doing.

I agree it it not provable.  In fact it is unlikely to be truly random, but it is not predictable via measuring techniques that we have.

so first word you got was a 1/2047 as predicted be a being with magical skill
second word you got was a 1/2048
third word you got was a 1/2049
fourth word you got was a 1/2047

so 24 words all picked and all very likely to be in the range of 1/2000 to 1/2100

vs a perfect 1/2048 pretty much is good enough in this world as it is cheap and easy to do.

vs dice which are easy to load
vs coins which are easy to load

vs random generators which are very hard to program truly random.

just saying if I need to make a list of 24 words for storing 1 million bucks.

 I would prefer that I used the 2 bingo machines to pick the 24 words.

[o_e_l_e_o]

No one can perfectly determine the bias on a bingo machine.

So why use it at all, when you can use a von Neumann approach to flipping a coin to have a system which provably has zero bias? Not to mention simpler and quicker as well.

First weigh every ball
Second do dozens of diameter and circumference measurements.

Obviously almost no one would actually do this, which means all your assumptions which follow of the bias being too small to make a difference are flawed. It you don't test what your bias is, then you have no idea if it is too small to make a difference.

[philipma1957]

No one can perfectly determine the bias on a bingo machine.

So why use it at all, when you can use a von Neumann approach to flipping a coin to have a system which provably has zero bias? Not to mention simpler and quicker as well.

First weigh every ball
Second do dozens of diameter and circumference measurements.

Obviously almost no one would actually do this, which means all your assumptions which follow of the bias being too small to make a difference are flawed. It you don't test what your bias is, then you have no idea if it is too small to make a difference.

so reading Neumann method for an unknown coin bias.

to get a bit of 0 or 1 means a minimum of 2 tosses of a coin

so to randomly pick from 1 to 2048 means many coin tosses . x 24

lets see if you were perfectly or magically lucky and did 2 tosses per bit

the fastest you could get a word is

24 coin flips

as

100000000000 is 2048

so it is a 12 bit number and you need at least 2 tosses to get a bit

of course you could get lots of h+h or t+t maybe it takes about 96 tosses per word.

or close to 2400 tosses but technically it would give you 1/2048 to the 24th power.

I am thinking that rolling my bingo machines a and b takes 48 minutes.

fairly easy to chart. and yeah it wont likely be 1/2048 to the 24th power but it is easier to do and while I won’t  be  as sure as tossing the unknown  coin 600 to 2400 tosses it is likely good enough.

more fun to do. and easier.

since I wont have 1000000 usd in btc anytime soon I wont worry.  and if I ever do get that much maybe i will do both just for fun.

[larry_vw_1955]

since I wont have 1000000 usd in btc anytime soon I wont worry. 

i would be more worried if i generated entropy using a computer and put that much money into the wallet then if i did it with a bingo machine...that's just me though. i'm sure your bingo machine method is solid enough to handle that type of cash.

[o_e_l_e_o]

of course you could get lots of h+h or t+t maybe it takes about 96 tosses per word.

You don't do it per word - you do it per bit. 2 tosses per bit, and assuming a close to 50% rejection rate for a minimally biased coin, then you need on average 512 flips for a 128 bit number encoding a 12 word seed phrase.

Quicker, simpler, more secure, and provably unbiased, when compared to the bingo machine suggestion (or any other physical entropy suggestion, for that matter).

[Jon_Hodl]

I recently saw an interesting discussion about casino dice that are being used for generating seed words for Bitcoin, and someone asked a question can you really trust dice?

I had this exact same thought and until recently, I didn't really understand how dice rolls translate into a private key. After doing some research, I think I understand.

I was using both ColdCard and SeedSigner with 99 dice rolls to generate seed phrases but it just take so long to roll dice 99 times, write them all down, and enter them into both devices to verify that I get the same exact seed phrase on both devices and then write down the seed phrase.

Recently, I came across SeedSticks (https://seedsticks.org/) and that seemed like the best solution for me to be able to generate truly random seed phrases in a lot less time.

Dice are cheap and readily available and so are playing cards but I like how simple it is to just randomly pick 23 words out of a bag, calculate the final checksum word with my SeedSigner, and then have a 24-word seed phrase with all 256 bits of entropy.

I don't think I can find a faster way to securely generate a seed phrase.

[BlackHatCoiner]

I don't think I can find a faster way to securely generate a seed phrase.

I disagree. Rolling a fair dice is a tested, and peer-reviewed way of generating entropy securely. To spend less time on fairness, toss a coin, preferably using Von Neumann's trick.

On the other hand, SeedSticks is not tested nor reputable, requires you to spend an extra $120, wait for it to arrive, verify that the words you've received are the same as in BIP39 wordlist, and in the end, it introduces bias parameters such as the manner you'll pick words from the bag.

[Jon_Hodl]

I don't think I can find a faster way to securely generate a seed phrase.

I disagree. Rolling a fair dice is a tested, and peer-reviewed way of generating entropy securely. To spend less time on fairness, toss a coin, preferably using Von Neumann's trick.

Von Neumann's trick is interesting. I'll have to experiment with that. What would be required for SeedSticks to be tested and peer-reviewed?

On the other hand, SeedSticks is not tested nor reputable, requires you to spend an extra $120, wait for it to arrive, verify that the words you've received are the same as in BIP39 wordlist, and in the end, it introduces bias parameters such as the manner you'll pick words from the bag.

What makes something tested and reputable? I checked all of the words I received against the BIP 39 seed list and it's a perfect match.

I hear you on the bias but isn't there a bias with how I roll dice? Is there a Von Neumann's trick for rolling dice?

[o_e_l_e_o]

Of all the physical methods other than flipping a coin, I actually dislike this one the least. It's still not perfect, but there is far less that can go wrong with blindly picking individual words from the full list of 2048 when compared to rolling dice or shuffling cards and trying to apply conversions and entropy extraction algorithms on your output to generate secure entropy.

The biggest problems here will be human error and bias, rather than any failure of the system itself. Not shuffling well between drawing words, not returning used words to the bag, or more likely, discarding words and trying again to get something "more" random. If someone draws the same word twice in the same seed phrase, they might decide that's not random and choose a different word. Or if they draw "boss" followed by "box", again, they might decide that's not random enough. To be completely sure there is no bias you would need to weigh every single individual tile on scales accurate enough to detect milligrams (which most people don't have). And finally the cost is another issue, and $120 for something you can do for free with a coin seems unnecessary.

So not the worst solution out there, but I would still stick to flipping a coin.

I hear you on the bias but isn't there a bias with how I roll dice? Is there a Von Neumann's trick for rolling dice?

Yes, but it is significantly more complicated than when applied to a coin (and adds a significant length of time to your generation process). I've outlined it in a previous post here: https://bitcointalk.org/index.php?topic=5395587.msg61126349#msg61126349. But having said that, I think dice are a poor choice anyway (exactly because it is difficult to detect any bias), so I wouldn't recommend using this over simply flipping a coin.

[larry_vw_1955]

Of all the physical methods other than flipping a coin, I actually dislike this one the least.

you're never going to budge off the coin flipping method. i'm surprised you even conceded this much to the seed stick method which i never heard of before but it does look quite simple.

The biggest problems here will be human error and bias, rather than any failure of the system itself. Not shuffling well between drawing words, not returning used words to the bag, or more likely, discarding words and trying again to get something "more" random.

define "shuffling well" for seedsticks

If someone draws the same word twice in the same seed phrase, they might decide that's not random and choose a different word. Or if they draw "boss" followed by "box", again, they might decide that's not random enough. To be completely sure there is no bias you would need to weigh every single individual tile on scales accurate enough to detect milligrams (which most people don't have).

that's probably going to be a problem then as most digital scales for weighing food and things might have a resolution of a single gram. but defintelyl not 1/1000th of a gram. that would probably cost you alot more than the seedsticks. 

And finally the cost is another issue, and $120 for something you can do for free with a coin seems unnecessary.

in theory you could make your own seedsticks. all they are is small pieces of plastic. with words on them.

So not the worst solution out there, but I would still stick to flipping a coin.

yeah but that requires more technical expertise i would think. they have to know how to convert their entropy into a seed phrase. seed sticks do that for you. it's like the difference between getting fast food and going to the store and shopping for ingredients to prepare a meal.  i guess to each their own.

[o_e_l_e_o]

you're never going to budge off the coin flipping method.

Because flipping a coin and using von Neumann's debiasing approach is the only physical method I can convince myself is both provably random and free from bias, as well as requiring no transformation or randomness extraction on the final result which could introduce new weaknesses. It is also simple and quick.

define "shuffling well" for seedsticks

Exactly. Difficult to do, and therefore difficult to ensure is not biased.

yeah but that requires more technical expertise i would think. they have to know how to convert their entropy into a seed phrase.

It's a simple look up table from number to word. The complicated bit is calculating the checksum, but that is the same for any physical method, seedsticks included.

[larry_vw_1955]

you're never going to budge off the coin flipping method.

Because flipping a coin and using von Neumann's debiasing approach is the only physical method I can convince myself is both provably random and free from bias, as well as requiring no transformation or randomness extraction on the final result which could introduce new weaknesses.

you've updated your boilerplate statement to indict some of the other forms of generating a seed phrase mechanically. you do that when you throw in the term "requiring no transformation or randomness extraction". using sha256 to extract randomness from a card deck is one thing but when you have something more pure than that then that's another.

It is also simple and quick.

In concept it is very simple. The simplest way there is to generate a 256-bit number. The problem is, it is not quick. Even if you don't use the von Neumann trick. It still is flipping a coin 256 times. that's not quick. Only geeks and nerds probably ever did that.   Everyone else just uses an app.

Can it be made quicker? Sure. Get 256 coins and flip them all at the same time. But you still have to record every single one of them. that's what takes the most time no matter which way you do it. But I know you would never agree to doing it this way. not ever.

define "shuffling well" for seedsticks

Exactly. Difficult to do, and therefore difficult to ensure is not biased.

but don't you think that method has merits? for people that can't use a computer it's the only way.

It's a simple look up table from number to word.

From decimal number to word. somehow you have to convert your 11-bit numbers into decimal though. that seems like a potential source for errors to happen.

The complicated bit is calculating the checksum, but that is the same for any physical method, seedsticks included.

yeah but it's simpler than trying to convert 11-bit binary numbers into decimal so you can then look them up on the word list.

Also, i'm sure you're going to say there are bip39 wordlists that convert binary 11-bit numbers into words. maybe there are but even that is fraught with potential errors since you have to compare 11 bits very carefully. chances of error are high when you go to try and match things up. thus seedsticks.  

now if you can come up with a mechanical way to get the final checksum word then you are good to go.

[LoyceV]

Can it be made quicker? Sure. Get 256 coins and flip them all at the same time.

That doesn't work, it makes the order in which you pick the coins up a factor that can be biased.
Also: who has 256 coins nowadays?

[o_e_l_e_o]

you've updated your boilerplate statement to indict some of the other forms of generating a seed phrase mechanically. you do that when you throw in the term "requiring no transformation or randomness extraction".

I've not change my stanced and I've been pretty explicit since the first page of this thread on this topic:

How can you be sure whatever randomness extraction algorithm you choose won't amplify your weak entropy?

Taking a non-binary output (such as dice rolls or the order of a deck of cards) and transforming it in to a binary string to use as a private key is not a benign process. And as I've also said before in this thread, there is a whole field of study on randomness extraction, on which I am by no means an expert, but I know enough to know that someone who does not understand it will almost certainly mess up in a way they don't even comprehend. Therefore, it is a bad choice.

The problem is, it is not quick.

Can be done in half an hour. That's pretty quick in the grand scheme of things. How many hours have we spent discussing it?

But I know you would never agree to doing it this way. not ever.

Correct. Because it is biased.

Also, i'm sure you're going to say there are bip39 wordlists that convert binary 11-bit numbers into words.

Correct. https://github.com/hatgit/BIP39-wordlist-printable-en. Bonus with this one is that it includes decimal as well. So you can convert your binary to decimal, look up the decimal word, and then check the binary decoding against your original binary to ensure you have not made any mistakes.

[larry_vw_1955]

Can it be made quicker? Sure. Get 256 coins and flip them all at the same time.

That doesn't work, it makes the order in which you pick the coins up a factor that can be biased.

who said anything about picking them up?

Also: who has 256 coins nowadays?

who has 50 dice?

I've not change my stanced and I've been pretty explicit since the first page of this thread on this topic:

How can you be sure whatever randomness extraction algorithm you choose won't amplify your weak entropy?

ok fair enough, i went back and saw you were talking about that before we got into talking about the bingo machine method.

Taking a non-binary output (such as dice rolls or the order of a deck of cards) and transforming it in to a binary string to use as a private key is not a benign process.

i would say that's a vast generalization to make based on just one particular "transformation" which apparently you are referring to using SHA-256 as the transformation in that thread. Well, no one understands how well sha-256 works as a transformation to extract entropy. That's kind of one of those things where you "hope and pray" it does well enough. there's no reason to think that it wouldn't though. but from a purist perspective or a cryptographer's perspective, it probably would not past muster.

And as I've also said before in this thread[/url], there is a whole field of study on randomness extraction, on which I am by no means an expert, but I know enough to know that someone who does not understand it will almost certainly mess up in a way they don't even comprehend. Therefore, it is a bad choice.

For me, if I understand the mathematics behind how something works, I don't feel that I need a rubber stamp of approval from some so-called expert in the field. They aren't going to understand anymore about it than I do, most likely. Since if I took the time to study it and program it and understand how it works from the bottom up, they haven't even taken the time to do that, why would I need to listen to someone like that? I'm very capable of forming my own conclusions about the security of the particular transformation.

Now, I don't mess with things I don't fully understand though. Thus why I shy away from using something such as SHA256 to extract entropy. There is something better. I don't make conclusions about things I don't understand.

 

[BlackHatCoiner]

Can it be made quicker? Sure. Get 256 coins and flip them all at the same time.

How can you flip 256 coins at the same time? And why?

Only geeks and nerds probably ever did that.

The topic of this discussion isn't to whom these methods address to. It's to which are the tradeoffs. For the average Joe who wants self-custody and has no technical competence of the field, maybe his best course is to just buy a hardware wallet.

[larry_vw_1955]

How can you flip 256 coins at the same time? And why?

I'll answer the 2nd question for you. to save time.

[o_e_l_e_o]

who said anything about picking them up?

Or the order you read them and record the result. Same result - you introduce a bias.

Well, no one understands how well sha-256 works as a transformation to extract entropy. That's kind of one of those things where you "hope and pray" it does well enough.

I'm sure there are people out there who do, but I am not one of them. And I'm afraid I'm not willing to risk the security of my coins on a hope and a prayer.

I have methods which I know are secure. Why on Earth would I use something I hope is secure instead?

[larry_vw_1955]

who said anything about picking them up?

Or the order you read them and record the result. Same result - you introduce a bias.

well if you take 50 die, and arrange them in a 5x10 rectangle, you don't have to visually look at them to do that necessarily. but i know you're still going to argue that there is bias and some dies might go into a certain position more often than they go into other positions. you got me in a unwinning situation there. 

I'm sure there are people out there who do, but I am not one of them. And I'm afraid I'm not willing to risk the security of my coins on a hope and a prayer.

I have methods which I know are secure. Why on Earth would I use something I hope is secure instead?

that's why i wouldn't want to use sha-256 to get the entropy out of a deck of cards. if sha-256 is a one-to-one function then i would say it is probably a suitable thing to use for entropy extraction of a deck of cards. if it's not a one-to-one function then it probably is not ideal and i would prefer instead to use something that is one-to-one. when we talk about one-to-one, obviously it is not one-to-one for an unlimited domain size but if we restrict to say a set of size 52! = 80658175170943878571660636856403766975289505440883277824000000000000 then it is an open question. so maybe not the best way of extracting or transforming entropy. and for that matter as i think you may have pointed out in the past, 52! is rather small in comparison to the entire universe of possible bitcoin private keys so there's that too, but that can be overcome i believe. 

[o_e_l_e_o]

and arrange them in a 5x10 rectangle, you don't have to visually look at them to do that necessarily.

But as you correctly predicted, I'll point out that it requires you to manually arrange them, which will not be a random process, regardless of how random you think you are being. Anything which introduces a human choice introduces a subconscious bias.

obviously it is not one-to-one for an unlimited domain size

Just to be pedantic, but the domain isn't quite unlimited - it is any string up to length 2⁶⁴ - 1 bits, which is any string up to 2 million terabytes in length.

but if we restrict to say a set of size 52! = 80658175170943878571660636856403766975289505440883277824000000000000 then it is an open question.

And impossible to answer without cycling through the entire set of possible inputs, which is similarly impossible.

[larry_vw_1955]

But as you correctly predicted, I'll point out that it requires you to manually arrange them, which will not be a random process, regardless of how random you think you are being. Anything which introduces a human choice introduces a subconscious bias.

i would think the arrangement of them is similar to shuffling a card deck but if you don't think its possible to shuffle a card deck by hand then I don't guess I could convince you it is possible with dice either. but i've done it and it seemed pretty random to me.  me personally i'm not concerned that there is some large bias that would cause an issue in that process, having done it quite a large number of times in fact in the past. but i know that doesn't convince you of anything...

Just to be pedantic, but the domain isn't quite unlimited - it is any string up to length 2⁶⁴ - 1 bits, which is any string up to 2 million terabytes in length.

right. the number of possible strings like that is mind boggling.

And impossible to answer without cycling through the entire set of possible inputs, which is similarly impossible.

we don't have to worry about that answer if we avoid using SHA-256 to extract the entropy from some permuation of objects such as a card deck. SHA-256 is a really complicated way of doing something simple in that instance...

[o_e_l_e_o]

i would think the arrangement of them is similar to shuffling a card deck but if you don't think its possible to shuffle a card deck by hand then I don't guess I could convince you it is possible with dice either.

It is of course possible to shuffle a deck of cards by hand, but the difference here is that you aren't looking at the cards as you do it. Once you've already rolled the dice and can see the results, then ordering them manually can introduce bias. Maybe you don't arrange four 5s in a row because that isn't random enough.

SHA-256 is a really complicated way of doing something simple in that instance...

That's the point I'm making though - turning an arrangement of a deck of cards in to a binary string is not something that is trivial. It is very possible that your method of randomness extraction does not result in a completely secure result.

[larry_vw_1955]

It is of course possible to shuffle a deck of cards by hand, but the difference here is that you aren't looking at the cards as you do it.

I'm not looking at each individual die either while I'm arranging them into the grid.

Once you've already rolled the dice and can see the results, then ordering them manually can introduce bias.

i don't inspect the results. i only inspect them after they are already in the grid. and i don't make any changes. no matter what.

Maybe you don't arrange four 5s in a row because that isn't random enough.

not how it works.  

That's the point I'm making though - turning an arrangement of a deck of cards in to a binary string is not something that is trivial.

it is a solved problem. and easily understandable. it's way simpler than converting a bitcoin private key into a public key. just for comparison's sake.

It is very possible that your method of randomness extraction does not result in a completely secure result.

it's not rocket science. it's pretty much just basic math. anyone can understand it who wants to. for the purposes of analyzing the "security" as you seem to be so worried about, I would submit that one does not  even need to know anything about how the one-to-one function works (i.e., its internals). So if you don't like my particular one-to-one function that I'm using you can invent your own. And yours will be just as strong as mine. Same security guarantee. It is secure simply by that fact that it is one-to-one on a large enough set aka 52! or even higher if you like. A set which cannot be brute forced through. And that's the end of that story.

[o_e_l_e_o]

Maybe if you were to wear a blindfold when arranging the dice in the grid you could convince me you have not introduced a bias, but otherwise you have. You may think you haven't, you may think you aren't paying attention to the numbers on the dice, you may think you are being totally random, but you aren't, because humans can't be. And we both know that many people if told to wear a blindfold to arrange the dice would just skip that step, thinking it was a waste of time because they are sure they are being random (just as you are), when they aren't.

I would submit that one does not  even need to know anything about how the one-to-one function works (i.e., its internals).

And I would counter that there is no way I personally will be using a process I know nothing about to generate my private keys. But YMMV.

So if you don't like my particular one-to-one function that I'm using you can invent your own.

I already have a perfect one - flipping a coin. The outcomes of 256 fair flips are perfectly and provably matched one-to-one with the set of 256 bit numbers.

[larry_vw_1955]

Maybe if you were to wear a blindfold when arranging the dice in the grid you could convince me you have not introduced a bias, but otherwise you have.

ok well i know i can do it wearing a blindfold. the grid might not be 5x10 it might be some other size to make it easier to do but i know i don't need to look at them.
 

You may think you haven't, you may think you aren't paying attention to the numbers on the dice, you may think you are being totally random, but you aren't, because humans can't be.

for my process, it happens very fast. the entire procedure is only about maybe 15 seconds so there's really no way to be examining each individual number on each die. maybe i see 3 or 4 of them and put them into place manually but that's about it.

And we both know that many people if told to wear a blindfold to arrange the dice would just skip that step, thinking it was a waste of time because they are sure they are being random (just as you are), when they aren't.

i think it's a waste of time but i'm willing to do it anyway once just so i can see if it makes any difference but i know it won't. because i'm already close to being at that point anyway.

And I would counter that there is no way I personally will be using a process I know nothing about to generate my private keys.

i told you some good news though. you don't need to understand how a one-to-one function works to have a security guarantee from it. that's good news right?  

But YMMV.

you think my mileage varies in that regard? that's disappointing to me. because i'm really particular about what kind of tool i would trust. hint: it needs to be something i created or programmed or whatnot. not just gonna go and generate a private key on my android phone and throw some bitcoin in it.

I already have a perfect one - flipping a coin. The outcomes of 256 fair flips are perfectly and provably matched one-to-one with the set of 256 bit numbers.

yes you do have a perfect one-to-one functon there. the problem is it can't work with the type of things mine does. like bingo balls or card decks or anything where you have a set of objects which you are permuting. mine on the other hand is transferrable over to being able to map flips of a coin 256 times into bitcoin private keys. (not that i would be particularly interested in using it for that but i could!) actually i'm not sure about that last statement. i'll have to think about how i would go about that process...

the point being though that permuting a group of objects is fast while flipping coins is slow. the tech to convert each process's raw entropy into a private key is different. i would say the former is more powerful. but indeed as you have mentioned if you want to guarantee no bias then yours is the gold standard. maybe we can leave it at that.

[o_e_l_e_o]

maybe we can leave it at that.

Yeah, I think we are going to have to simply agree to disagree on this one. You will never convince me that any process which requires human selection or ordering will generate truly random entropy (because humans cannot be truly random), and I will never advocate using a system like bingo balls which has an unmeasured bias and requires unnecessary transformation of the final result. If you want to use a physical method to generate a seed phrase or private key, flip a coin. If you don't, use /dev/urandom. Making it more complicated than this is just introducing errors and biases which don't need to be there.

[TalkativeCoin]

I would say that using dice to generate seed words can be considered fair, as long as the dice are rolled properly and the numbers are generated randomly. However, it is important to note that the quality of the randomness of the seed words will ultimately depend on the quality of the random number generator that is used. Therefore, I always recommend at least using a high-quality random number generator in order to ensure the security of your seed words.

[BlackHatCoiner]

[...]

Topic asides, but answer me this question of mine: why do you want to mess with unreliable, untested, and hard to test methods for generating entropy, when there are already tested, reviewed and comparably faster methods to do it already? I mean, let me emphasize: this number you're generating isn't going to keep some conversation with your friends, or perhaps even some nude photos secret. We're talking about property here. Real, hard money. Why do you want to play with the security of your property?

It's like making up your own door with your own lock, because you think you've thought of something that lock experts (which have spent about decades of studying more than you), haven't thought before. And it's even worse, because we all know that stuff such as math, cryptography etc. are more abstract, and require more dedication than a lock design.

[larry_vw_1955]

Yeah, I think we are going to have to simply agree to disagree on this one. You will never convince me that any process which requires human selection or ordering will generate truly random entropy (because humans cannot be truly random), and I will never advocate using a system like bingo balls which has an unmeasured bias and requires unnecessary transformation of the final result.

we measure the bias every time we do another trial run and compare the output to previous ones. is it a long and arduous, tedious process? yes. is it worth it? sure. it's always worth it to do something no one else has ever done. you make some valid points but you're very pessimistic about my method. don't you think that it is not unreasonable to want to be able to extract entropy from a set of identical objects (aka, bingo balls or cards in a card deck) when they are ordered in a randomized fashion without having to resort to a function like sha-256 which is not known to be 1-1? please answer yes. but i know you won't.

If you want to use a physical method to generate a seed phrase or private key, flip a coin. If you don't, use /dev/urandom. Making it more complicated than this is just introducing errors and biases which don't need to be there.

I don't want to do things other people have already done necessarily. I mean not that I haven't done them, because I have. But I wanted to do something more than that. Something no one ever did. So I treated it like a challenge. Something to overcome if I ran into any obstacles. I embrace those kinds of challanges though. For example, a bingo ball cage is 75 balls. 75! is way bigger than the number of bitcoin private keys. How do we deal with that issue? How do we ensure when dealing with that issue that we aren't introducing any significant bias? You don't think I've considered these questions? Well let me tell you, I have. I'm not just some idiot that doesn't think things through and trusts what other people say. I trust what I can prove.

Topic asides, but answer me this question of mine: why do you want to mess with unreliable, untested, and hard to test methods for generating entropy, when there are already tested, reviewed and comparably faster methods to do it already? I mean, let me emphasize: this number you're generating isn't going to keep some conversation with your friends, or perhaps even some nude photos secret. We're talking about property here. Real, hard money. Why do you want to play with the security of your property?

It's like making up your own door with your own lock, because you think you've thought of something that lock experts (which have spent about decades of studying more than you), haven't thought before. And it's even worse, because we all know that stuff such as math, cryptography etc. are more abstract, and require more dedication than a lock design

i didn't invent the technology but i applied it to a bingo ball machine. 

[o_e_l_e_o]

we measure the bias every time we do another trial run and compare the output to previous ones. is it a long and arduous, tedious process? yes. is it worth it? sure.

No, it isn't worth it. As I calculated earlier in this thread, you are looking at over 16k flips to be relatively sure of excluding a bias from a coin flip, which has 2 possible outcomes. The number of runs to exclude bias from a bingo ball machine with 75 balls would number in the millions. Absolutely not worth it.

it's always worth it to do something no one else has ever done.

People coming up with their own methods of generating keys, backing up their seed phrases, creating difficult to access wallets, etc., is a leading cause of people losing their coins. Just because someone hasn't done something before, does not mean it is worth doing it nor that it is a good idea.

don't you think that it is not unreasonable to want to be able to extract entropy from a set of identical objects (aka, bingo balls or cards in a card deck) when they are ordered in a randomized fashion without having to resort to a function like sha-256 which is not known to be 1-1? please answer yes. but i know you won't.

No, I don't. You are attempting to create a solution for a problem which doesn't exist. We already have easy, simple, quick, and provably secure ways to generate private keys. We do not need to reinvent the wheel.

So I treated it like a challenge.

If you want to treat it as a challenge for a bit of fun, then I can't stop you. But I would never recommend using it to generate private keys or wallets you will use to actually store funds.

[larry_vw_1955]

No, it isn't worth it. As I calculated earlier in this thread, you are looking at over 16k flips to be relatively sure of excluding a bias from a coin flip, which has 2 possible outcomes. The number of runs to exclude bias from a bingo ball machine with 75 balls would number in the millions. Absolutely not worth it.

absolutely not true. you can measure the sizes and weights of the balls and any other characteristics you deem important if you like to see if they are within a close enough specification of each other. that eliminates the need to actually go through "millions" of trial runs. if you're paranoid you can do all of that. i'm not that paranoid. i realize that for the intents and purposes of creating bitcoin private keys the setup i have is more than random enough. it's just common sense. now if everyone in the whole world was using MY machine to generate their seed phrase well maybe then a bit more formal testing, as I have alluded to, would be more preferable. but even then it would perform that function just fine. generating millions if not billions of seed phrases and there would be no security issue whatsoever. that's just how it is. i know you disagree. but that is the truth.

[LoyceV]

People coming up with their own methods of generating keys, backing up their seed phrases, creating difficult to access wallets, etc., is a leading cause of people losing their coins.
~
You are attempting to create a solution for a problem which doesn't exist.

The only reason I can think of to create your own solution, is so you can hide it in plain sight. I've never felt completely secure with seed phrases laying around, but I can think of many different ways to come up with my own entropy source.
Example: I take a picture. That's 12 million pixels, each with 16 million color options. Even though none of it is very random, I'm pretty sure it contains much, much more entropy than 2²⁵⁶. I could even use only the last 100,000 bytes of the JPG as input to produce a hash, and store the picture with all my other pictures (including backups, of course) without ever worrying about it.
Disclaimer: I haven't tried this, and most people probably shouldn't attempt it.

[o_e_l_e_o]

-snip-

Again, agree to disagree. If you want to use a kids' toy to generate private keys then no one can stop you, but it is not a method you should be recommending to anyone else.

I could even use only the last 100,000 bytes of the JPG as input to produce a hash, and store the picture with all my other pictures (including backups, of course) without ever worrying about it.

Except you can never have a physical back up, only a digital one. And what if your OS automatically resizes the picture? Or what if your cloud storage compresses it? Or chooses a different color encoding scheme? Or converts the format? Or even so much as changes the metadata. Any of these things, most of which you probably wouldn't even notice happening, will result in your back up being useless and impossible to recover.

If you don't like a seed phrase lying around, then either hide it better, encrypt it, or use it as part of a multi-sig or passphrased set up so it is useless on its own.

[larry_vw_1955]

Except you can never have a physical back up, only a digital one. And what if your OS automatically resizes the picture? Or what if your cloud storage compresses it? Or chooses a different color encoding scheme? Or converts the format? Or even so much as changes the metadata. Any of these things, most of which you probably wouldn't even notice happening, will result in your back up being useless and impossible to recover.

which is why that method is not useful. which is why steganography really isn't useful. unless you're willing to zip up your image files which introduces the possibility of corruption...and then can't use image storage services.

If you don't like a seed phrase lying around, then either hide it better, encrypt it, or use it as part of a multi-sig or passphrased set up so it is useless on its own.

what about printing your seed phrase in a microscopic size so that it could only be viewed under high magnification? that seems like a cool method but kind of technically challenging. you could then have it lying around anywhere and the worst thing that could happen is it gets lost.

[o_e_l_e_o]

what about printing your seed phrase in a microscopic size so that it could only be viewed under high magnification? that seems like a cool method but kind of technically challenging. you could then have it lying around anywhere and the worst thing that could happen is it gets lost.

This is an interesting idea, but very few people have the equipment or expertise needed to do this. And of course you should never even considering asking a professional or other third party service to do it for you.

There are plenty of ways to hide a seed phrase in your house which would make it near impossible to be found. A favorite of mine that I've talked about before is to hide it in the house itself. Unscrew an electrical socket or a light fitting and hide it in your wall or ceiling. Pull up a carpet and a floorboard and hide it under there. Take a door off its hinges, cut a little hole out of the bottom of the door (the thin side against the ground) and hide it in there. Or if you want it on metal, then use a flat plate and screw that plate on to some wooden beams or similar so it blends in with your foundations, roof truss, or similar. All of these are incredibly easy to do with the most basic of tools. A thief is never going to find these unless they have a week to systemically take apart your entire house, and if that's happening, then you've probably got bigger things to worry about.

[larry_vw_1955]

This is an interesting idea, but very few people have the equipment or expertise needed to do this.

there's a movie where they microprinted some information into the eyeball of some person on a postage stamp. there was like 4 or 5 stamps on the envelope but only one of the eyeballs had the microprinting in it.  

And of course you should never even considering asking a professional or other third party service to do it for you.

yeah, that would be very dumb indeed.

There are plenty of ways to hide a seed phrase in your house which would make it near impossible to be found.

Me crossing off all of those ways since they are now public knowledge... The first place someone is going to be looking now that you've mentioned it not only here but probably elsewhere.

A favorite of mine that I've talked about before is ...

Well and here's the thing. Those are all fine and dandy ways of hiding somethhing IF

#1) you don't end up forgetting about what things you have hidden and where. if you end up forgetting where you hid it, then you are pretty much never going to want to move out of your house! so what you'll have to do is record where you hid it. and then keep that record safe as you would your own private key which kind of defeats the entire purpose of the entire thing in the first place since just record your private key instead of its location.
#2) say you move out of the house and forget to bring it with you and maybe someone is doing some home maintenance then they find what you hid. your private key has now been revealed. there's a much greater chance of that than someone brute forcing it using a computer.

[o_e_l_e_o]

there's a movie where they microprinted some information into the eyeball of some person on a postage stamp. there was like 4 or 5 stamps on the envelope but only one of the eyeballs had the microprinting in it.  

I would imagine that such tiny printing would be incredibly fragile. A microscopic tear in the paper or even a smudged fingerprint could render the writing illegible.

Me crossing off all of those ways since they are now public knowledge... The first place someone is going to be looking now that you've mentioned it not only here but probably elsewhere.

If an attacker breaks in to your home and the first thing they do is start unscrewing all your electrical sockets and taking your doors off their hinges, instead of helping themselves to your other valuables, then you have suffered a complete failure of your opsec and your privacy. There are countless TV shows and movies where people hide things under floor boards or inside walls. This is not a new concept. For an attacker to start doing this to your house, then they must already know that you own a large amount of bitcoin, your address, you have it in a wallet which only requires one back up to compromise (as opposed to an additional passphrase or a multi-sig), and that you have said back up stored on site. And if an attacker already knows all that, then you have already lost all your security.

#1) you don't end up forgetting about what things you have hidden and where.

If you forget which outlet you've hidden it in, you could probably unscrew and check every outlet in your house in under an hour. Not a huge issue.

#2) say you move out of the house and forget to bring it with you and maybe someone is doing some home maintenance then they find what you hid. your private key has now been revealed. there's a much greater chance of that than someone brute forcing it using a computer.

So don't use a system where compromise of a single back up can lead to loss of coins. And simply move all your coins to new wallets when you move house.

[larry_vw_1955]

I would imagine that such tiny printing would be incredibly fragile. A microscopic tear in the paper or even a smudged fingerprint could render the writing illegible.

actually a better way would be to put it on film that way it is pretty durable and you could still hide it underneath the postage stamp which is probably a better location for it anyway.

If you forget which outlet you've hidden it in, you could probably unscrew and check every outlet in your house in under an hour. Not a huge issue.

"honey, what are you looking for?"

"oh nothing much but i might need to tear the house down to find it because if it's not in one of these electrical sockets then somehow it must have gotten moved into one of the wall spaces..."

So don't use a system where compromise of a single back up can lead to loss of coins. And simply move all your coins to new wallets when you move house.

so you thought you had found all your hidden private keys so you didn't move anything to new wallets. just so happens the new tenants didn't like the color of your old carpet so they had someone come and replace it. and guess what they found underneath your old carpet? a way to get your money.

[o_e_l_e_o]

"honey, what are you looking for?"

"oh nothing much but i might need to tear the house down to find it because if it's not in one of these electrical sockets then somehow it must have gotten moved into one of the wall spaces..."

If you've lost one of your back ups, then you simply retrieve a different one (since you should always have more than one back up) and move the coins within to a new wallet. Simple.

so you thought you had found all your hidden private keys so you didn't move anything to new wallets.

Losing a back up and then failing to move the coins within is a problem with any and every back up and is not unique to my method in any way. If you can't find a back up or aren't sure if you've found them all because you can't remember how many you made, then obviously you should assume the worst (an attacker now has access to that back up) and move your coins to a fresh set of wallets. This is just common sense.

[larry_vw_1955]

If you've lost one of your back ups, then you simply retrieve a different one (since you should always have more than one back up) and move the coins within to a new wallet. Simple.

that's the first time i ever heard someone say "you should always have more than one back up". if that were the case then why not make 1000 backups. more is better right? obviously not. every additional backup opens up a new possibility that your backup could be discovered by someone without your knowledge. example: you store a backup seed phrase in your bank deposit box even though you already have one at your home. now you just opened yourself up to an entirely new attack vector: someone getting into your bank deposit box and stealing your bitcoin. how many more additional backups like that do you want?

Losing a back up and then failing to move the coins within is a problem with any and every back up and is not unique to my method in any way.

the problem is, people don't necessarily always realize they have "lost" a backup do they? if they're not even keeping track of how many different places they stored it, how are they going to know one of them is lost? how are they going to keep track of everywhere they stored the backup? using google docs?

If you can't find a back up or aren't sure if you've found them all because you can't remember how many you made, then obviously you should assume the worst (an attacker now has access to that back up) and move your coins to a fresh set of wallets. This is just common sense.

i'm not sure anything is common sense when it comes to being organized and keeping information organized so that you can manage all your information.

[Lida93]

This is an interesting idea, but very few people have the equipment or expertise needed to do this.

there's a movie where they microprinted some information into the eyeball of some person on a postage stamp. there was like 4 or 5 stamps on the envelope but only one of the eyeballs had the microprinting in it.  

And of course you should never even considering asking a professional or other third party service to do it for you.

yeah, that would be very dumb indeed.

There are plenty of ways to hide a seed phrase in your house which would make it near impossible to be found.

Me crossing off all of those ways since they are now public knowledge... The first place someone is going to be looking now that you've mentioned it not only here but probably elsewhere.

A favorite of mine that I've talked about before is ...

Well and here's the thing. Those are all fine and dandy ways of hiding somethhing IF

#1) you don't end up forgetting about what things you have hidden and where. if you end up forgetting where you hid it, then you are pretty much never going to want to move out of your house! so what you'll have to do is record where you hid it. and then keep that record safe as you would your own private key which kind of defeats the entire purpose of the entire thing in the first place since just record your private key instead of its location.
#2) say you move out of the house and forget to bring it with you and maybe someone is doing some home maintenance then they find what you hid. your private key has now been revealed. there's a much greater chance of that than someone brute forcing it using a computer.

Like the saying goes, " where a man's treasure is, that's where his heart lies", so for someone to forget to move out with his private key then he must be moving out with something 3times bigger than what his private keys hold access to else why will you forget except maybe such a person is suffering from a memory loss issues.
Another thing which I find risky in hiding a seed phrase in the house could end up becoming a bad idea in the event of a natural disaster like earthquakes or man-made disaster like fire engulfing the whole building maybe out of carelessness while cooking.

[o_e_l_e_o]

that's the first time i ever heard someone say "you should always have more than one back up".

That's pretty standard advice, not just in bitcoin but in general. The problem with creating only a single back up is you have zero redundancy in your system. One mistake or event is all it takes for you to lose everything, especially considering the majority of people who create a single back up store it in the same location as their wallets themselves - at home.

Yes, you have to balance protection against loss versus risk of discovery, but two back ups in different locations should be the minimum.

now you just opened yourself up to an entirely new attack vector: someone getting into your bank deposit box and stealing your bitcoin.

Then you use a system in which compromise of one back up does not lead to loss of funds, such as an additional passphrase or multi-sig.

the problem is, people don't necessarily always realize they have "lost" a backup do they?

That's a separate problem and is common to every back up system. If you have a standard approach to all your wallets, then this issue is minimized.

Another thing which I find risky in hiding a seed phrase in the house could end up becoming a bad idea in the event of a natural disaster like earthquakes or man-made disaster like fire engulfing the whole building maybe out of carelessness while cooking.

Correct. Hence my point about always having more than one back up in separate physical locations.

[larry_vw_1955]

Yes, you have to balance protection against loss versus risk of discovery, but two back ups in different locations should be the minimum.

I understand the importance of general data backups but I thought one backup for a bitcoin seed phrase on a durable medium like a metal plate was sufficient. Maybe I got brainwashed by all this people that are using metal plates who seem to think that. Bet they dont have a second backup.

Then you use a system in which compromise of one back up does not lead to loss of funds, such as an additional passphrase

and where are you going to store your passphrase?  a multi-step system has a weakness in that it requires more than one part to be able to recover the whole. so you just made recovery efforts harder for yourself.

or multi-sig.

and who is the other party/parties? how do we know they can be trusted?

That's a separate problem and is common to every back up system.

it's really not common to every backup system just the ones you are used to using. consider a backup system where the seed phrase was not visible to the naked eye. with something like that, seems like you could store it in alot of places. if you happen to forget where you put a few of them, no big deal. not like anyone else is going to be able to take advantage...

[o_e_l_e_o]

I understand the importance of general data backups but I thought one backup for a bitcoin seed phrase on a durable medium like a metal plate was sufficient. Maybe I got brainwashed by all this people that are using metal plates who seem to think that. Bet they dont have a second backup.

So a metal plate is obviously more durable than a piece of paper, but it is not indestructible and it is not immune to loss either. What if there is a gas explosion at your house? You are going to spend weeks manually sifting through the rubble looking for a tiny metal plate? Would your local authority even permit you to do that? What if there is a flood or a hurricane? Your metal plate could now be anywhere in a 20 kilometer radius? Good luck finding that. Regardless of what medium your seed phrase is on, a single back up in the same location as your wallets themselves (i.e. at home) is not safe.

and where are you going to store your passphrase?

On a separate piece of paper in a separate location to my seed phrase.

and who is the other party/parties? how do we know they can be trusted?

Me. I'm the other party. I can set up a 2-of-2 multi-sig and back up my two seed phrases separately. An attacker would need to find both to compromise by wallet.

if you happen to forget where you put a few of them, no big deal. not like anyone else is going to be able to take advantage...

I'd prefer if the security of my wallets was not based on random chance and hoping that someone doesn't stumble across a seed phrase that I've hidden in plain sight.

[larry_vw_1955]

Regardless of what medium your seed phrase is on, a single back up in the same location as your wallets themselves (i.e. at home) is not safe.

ok i'm not going to disagree with that. based on the argument you provided yet we know most people don't do that. they have one metal plate and call it a day. just the reality of things. that's how they have been led to believe is all they have to do. plus these metal plate systems are not cheap which discourages them from doing additional backups.

On a separate piece of paper in a separate location to my seed phrase.

your protocol is getting complicated now. lets see, you have to store the seed phrase in at least 2 different physical locations and then you need to store the passphrase in 2 additional physical locations. so that's 4 different physical locations at the very least. then you have to have a way to remember where all those locations are. not impossible to do but you'll need a good memory.

Me. I'm the other party. I can set up a 2-of-2 multi-sig and back up my two seed phrases separately. An attacker would need to find both to compromise by wallet.

unless you have some special software for doing that it doesn't sound like it would be very userfriendly to actually use a wallet setup like that. unless you just plan to use the same bitcoin address over and over ignoring best use practices.

I'd prefer if the security of my wallets was not based on random chance and hoping that someone doesn't stumble across a seed phrase that I've hidden in plain sight.

so you go and hide your metal plate in some hole in the ground somewhere and you think that is safe. what happens if someone comes along with a metal detector? hopefully you dug your hole deep enough.  

[o_e_l_e_o]

that's how they have been led to believe is all they have to do. plus these metal plate systems are not cheap which discourages them from doing additional backups.

Completely agree. It's akin to how centralized exchanges have convinced people that they are too stupid to write down 12 words and need to leave their coins in the custody of a third party. Now these metal plate manufacturers convince people that paper isn't safe, when in reality two pieces of paper in separate locations is exponentially more robust (and cheaper) than one metal plate kept at home.

Nothing wrong with using metal plates, but you still need redundancy in your set up. And you can buy a stainless steel plate for 5 bucks at a hardware store. No need to pay upwards of $100 for the same thing.

not impossible to do but you'll need a good memory.

True. I also have a wife who knows about the back ups too. More redundancy.

unless you have some special software for doing that it doesn't sound like it would be very userfriendly to actually use a wallet setup like that. unless you just plan to use the same bitcoin address over and over ignoring best use practices.

It's fairly easily done. You could do it on your main computer using Electrum and two different hardware wallets, for example. Or if you've got two old laptops/computers/devices which you can airgap.

so you go and hide your metal plate in some hole in the ground somewhere and you think that is safe. what happens if someone comes along with a metal detector? hopefully you dug your hole deep enough.  

I would put that under the heading of "random chance". All my back up locations are physical secured - someone would need to physically break in, either to the building itself, a locked safe or similar, or both, in order to compromise them. They will not be randomly stumbled across.

[larry_vw_1955]

Nothing wrong with using metal plates, but you still need redundancy in your set up. And you can buy a stainless steel plate for 5 bucks at a hardware store. No need to pay upwards of $100 for the same thing.

the metal plates themselves are not what form the bulk of the cost. the tools needed to create the seed phrases on the metal plates do and does the hardware store have those too? but still i would imagine 2 metal plates $10, the tools to do the stamping maybe $50.

I would put that under the heading of "random chance". All my back up locations are physical secured - someone would need to physically break in, either to the building itself, a locked safe or similar, or both, in order to compromise them. They will not be randomly stumbled across.

https://www.nytimes.com/2019/07/19/business/safe-deposit-box-theft.html

dude lost $10 million. not to theft but the bank just made a mistake. not sure if he got reimbursed or not.

[o_e_l_e_o]

but still i would imagine 2 metal plates $10, the tools to do the stamping maybe $50.

A quick web search and I can find metal engraving pen for $10-15, and a set of metal letter stamps for hammering in to the metal for $15-20. So still significantly cheaper than any proprietary piece of kit.

dude lost $10 million. not to theft but the bank just made a mistake. not sure if he got reimbursed or not.

Another great argument for having more than one back up then.

[larry_vw_1955]

A quick web search and I can find metal engraving pen for $10-15, and a set of metal letter stamps for hammering in to the metal for $15-20. So still significantly cheaper than any proprietary piece of kit.

ok yeah that's true. i'll have to look into those "metal engraving pens" not sure how well they work. or how long they last but i guess they don't have to last very long to engrave a seed phrase one or two times.

dude lost $10 million. not to theft but the bank just made a mistake. not sure if he got reimbursed or not.

Another great argument for having more than one back up then.

i doubt it's a great argument for anything other than not storing your seed phrase in a place like a bank deposit box or storage unit that you pay for rent to keep. as the story shows, you're at the mercy of the company that manages the thing. so are you going to admit that storing your seed phrase in such a place is highly risky?

you did read the story, right? they drilled out the locks on his box and yeah that was a mistake on their part. but they didn't realize they were making a mistake. but they had the wrong box. could happen to anyone right? then the contents of his box got sent to some other storage facility but at some point during that process, the "good stuff" got taken. stolen. get the point?

[o_e_l_e_o]

so are you going to admit that storing your seed phrase in such a place is highly risky?

Not necessarily.

I'm not a fan of any back up system for seed phrases where the compromise of a single back up results in you losing your coins. Because of this, I exclusively use either wallets generated from both a seed phrase and an additional passphrase, or multi-sig wallets. And as I have said before, I would always recommend having at least two back ups of any important information. So in such a case where I am storing a back up in a safe deposit box, then if the bank makes a mistake and drills out my box, I have not lost my wallet since I have additional back ups elsewhere, and my funds cannot be stolen since one back up on its own is insufficient to compromise my wallets.

If you only have one back up, and someone discovering that one back up gives them all the information required to steal your coins, then you are already in a highly risky situation.

[larry_vw_1955]

Not necessarily.

ok thanks for the clarification. seems like you thought of everything.

[LoyceV]

but then we get into other questions such as "what is an acceptable level of bias in an experiment where you perform it some number of times, be that 1000, or more?"

When considering generating private keys for bitcoin, then my answer is zero. I don't see why you would settle for anything less. This is why I advocate for using coin flips with von Neumann's algorithm, since by doing this you can be certain you have eliminated any bias in your coin, as well as not introduced any new bias by performing randomness extraction or other processes you don't fully understand on your data.

By coincidence, I stumbled upon an article about bias in coin tosses. It reminded me about this topic, hence the 10 month bump.

TL;DR: if you start a coin toll with heads up, there's a 50.8% chance you'll end up with heads.

"According to the Diaconis model, precession causes the coin to spend more time in the air with the initial side facing up," a new team writes in a pre-print paper that has not yet been peer-reviewed. "Consequently, the coin has a higher chance of landing on the same side as it started (i.e., ‘same-side bias’)."

Diaconis found, from a smaller ideal number of coin tosses recorded and analyzed, that coins land on the same side they were tossed from around 51 percent of the time. The new team recruited 48 people to flip 350,757 coins from 46 different currencies, finding that overall, there was a 50.8 percent chance of the coin showing up the same side it was tossed from.

Delving into the data further, they found that coin tosses are highly variable between people, with some showing a strong same-side bias and others having none at all – coin tosses may come down (ever so slightly) to the tosser.

Further reading: Fair coins tend to land on the same side they started: Evidence from 350,757 flips.

There are older articles also claiming a similar (51/49) distribution, but as far as I've found the recent research had the largest sample size.

[philipma1957]

but then we get into other questions such as "what is an acceptable level of bias in an experiment where you perform it some number of times, be that 1000, or more?"

When considering generating private keys for bitcoin, then my answer is zero. I don't see why you would settle for anything less. This is why I advocate for using coin flips with von Neumann's algorithm, since by doing this you can be certain you have eliminated any bias in your coin, as well as not introduced any new bias by performing randomness extraction or other processes you don't fully understand on your data.

By coincidence, I stumbled upon an article about bias in coin tosses. It reminded me about this topic, hence the 10 month bump.

TL;DR: if you start a coin toll with heads up, there's a 50.8% chance you'll end up with heads.

"According to the Diaconis model, precession causes the coin to spend more time in the air with the initial side facing up," a new team writes in a pre-print paper that has not yet been peer-reviewed. "Consequently, the coin has a higher chance of landing on the same side as it started (i.e., ‘same-side bias’)."

Diaconis found, from a smaller ideal number of coin tosses recorded and analyzed, that coins land on the same side they were tossed from around 51 percent of the time. The new team recruited 48 people to flip 350,757 coins from 46 different currencies, finding that overall, there was a 50.8 percent chance of the coin showing up the same side it was tossed from.

Delving into the data further, they found that coin tosses are highly variable between people, with some showing a strong same-side bias and others having none at all – coin tosses may come down (ever so slightly) to the tosser.

Further reading: Fair coins tend to land on the same side they started: Evidence from 350,757 flips.

There are older articles also claiming a similar (51/49) distribution, but as far as I've found the recent research had the largest sample size.

So if you have a 51 to 49 percent bias on all your picks it still to the 24th power.

so effectively the bias mean a 24 word seed is more like a 22 word seed or am I wrong

[Medusah]

So if you have a 51 to 49 percent bias on all your picks it still to the 24th power.

What number are you raising to the 24?

If there is 50.8% chance for heads and 49.2% for tails, then you can calculate the entropy like that:

Code:

H(X) = - P(heads) * log2(P(heads)) - P(tails) * log2(P(tails)) = - 0.508 * log2(0.508) - 0.492 * log2(0.492) = 0.999815327

So tossing a coin gives you 0.999815327 bits of entropy.  If you toss it 256 times, it will give you 255.95 bits which are sufficient.

[LoyceV]

If there is 50.8% chance for heads and 49.2% for tails, then you can calculate the entropy like that:

Code:

H(X) = - P(heads) * log2(P(heads)) - P(tails) * log2(P(tails)) = - 0.508 * log2(0.508) - 0.492 * log2(0.492) = 0.999815327

I read it, but can't believe it. That would mean a dice that rolls heads 3.25% times more often than it rolls tails would only lose 0.02% of the entropy after 256 rolls.
I know it's been a while since I studied statistics, so bear with me. Let's say we have a 3-sided coin, with 2 sides heads and 1 side tails.
Using your formula, that gives:

Code:

- 0.6667 * log2(0.6667) - 0.3333 * log2(0.3333) = 0.9183

I would expect this 2-to-1-dice to create much less entropy. Please convince me you used the correct formula.

[Medusah]

I read it, but can't believe it. That would mean a dice that rolls heads 3.25% times more often than it rolls tails would only lose 0.02% of the entropy after 256 rolls.

Yes.

I would expect this 2-to-1-dice to create much less entropy. Please convince me you used the correct formula.

You are correct.  I used Shannon's formula.  There are many good answers about the "why" part in here:  https://math.stackexchange.com/questions/331103/intuitive-explanation-of-entropy

[o_e_l_e_o]

TL;DR: if you start a coin toll with heads up, there's a 50.8% chance you'll end up with heads.

I think far more interesting than that headline figure is the data they have given in Table 1. Of their 48 participants, 10 had the opposite result and showed a bias to the coin landing on the opposite side it started, and there were a handful of participants with a very severe bias, with one showing a bias of 60/40. So they key take away I think is not "51/49 bias of the same side you started with", but rather "everyone has their own individual bias when flipping a coin".

Given that, and given that each coin itself will also have its own intrinsic bias, then again the solution is the simple one I've outlined many times before - use a von Neumann debiasing approach, but with the additional caveat that you should start each flip from the same position (i.e. heads face up). That way any bias in either the coin or your technique is completely eliminated and you will always end up with a completely random result.

[larry_vw_1955]

Given that, and given that each coin itself will also have its own intrinsic bias, then again the solution is the simple one I've outlined many times before - use a von Neumann debiasing approach, but with the additional caveat that you should start each flip from the same position (i.e. heads face up). That way any bias in either the coin or your technique is completely eliminated and you will always end up with a completely random result.

the thing about that von neumann method is if the person rolling the dice knows they are using it then they also know that only the first flip matters. the 2nd flip never affects anything. except whether to use the result of the first flip or not. with all of that information in their head, they're not going to be flipping the first and second flips the same way. probably not.

example lets say you had this series of flips:

HH HT HT HT and then say your next flip was H you would be thinking "I don't want this to be T because we shouldn't be having too many H in a row"...so subconsciously your mind would be making you flip the coin so that the coin landed on H.

so i don't think it can get rid of that type of bias.

[o_e_l_e_o]

so i don't think it can get rid of that type of bias.

I don't think many people have the ability to alter their coin flipping technique to make one side or the other more likely. But even so, if you wanted to protect against this then don't learn the results, and that way the results cannot bias your flipping technique.

Two options for this. If you have someone you trust completely with your bitcoin (such as a spouse), then have them note the results from the flips for you, while you don't even look. If you don't have someone you trust completely, then film the process using an airgapped device and watch the video back after you have made several hundred flips (on average with an unbiased coin you will need to make 512 flips to generate 128 bits of entropy).

[Medusah]

(on average with an unbiased coin you will need to make 512 flips to generate 128 bits of entropy).

For anyone who does not know:  the von Neumann method involves counting results only half of the time ('HH', 'TT' are not counted).  So for every two coin tosses which are 'HT' or 'TH' you add 1 bit.  So 1 bit for every 4 coin tosses on average.

I have not tried it.  Sounds the most secure, but tiring too.   

[o_e_l_e_o]

For anyone who does not know:  the von Neumann method involves counting results only half of the time ('HH', 'TT' are not counted).  So for every two coin tosses which are 'HT' or 'TH' you add 1 bit.  So 1 bit for every 4 coin tosses on average.

You can actually make it more efficient, but I've never bothered to talk about how you would do this on the forum since it is far easier and safer to just stick to the basic method and keep flipping until you have enough entropy. The more efficient method involves considering more than just pairs of flips. We know that HT and TH are equally probable, so by the same logic HH TT and TT HH are also equally probable. And these runs of matching pairs do not need to be consecutive. HH HT TT and TT HT HH are also equally probable, for example.

So you flip your coin, and for every HT you write down 0, and for every TH you write down 1. But then you also generate a completely separate second level sequence. For every HH you write down H in this second level sequence, and for every TT you write down T. You then run von Neumann's algorithm across this new sequence as well, generating 0s and 1s as before, but also generating Hs and Ts as described in a new third level sequence.

You can iterate this as many times as you like, and theoretically approach the maximum possible entropy you can extract from each flip. In practice, additional efficiency gains after probably the third level or so are probably outweighed by the increased complexity.

[larry_vw_1955]

I don't think many people have the ability to alter their coin flipping technique to make one side or the other more likely. But even so, if you wanted to protect against this then don't learn the results, and that way the results cannot bias your flipping technique.

that's correct. that's only way to make sure.

Two options for this. If you have someone you trust completely with your bitcoin (such as a spouse), then have them note the results from the flips for you, while you don't even look.

the only way i would accept that solution is if you hand over your completed private key and wallet details to your spouse once done.

If you don't have someone you trust completely, then film the process using an airgapped device and watch the video back after you have made several hundred flips (on average with an unbiased coin you will need to make 512 flips to generate 128 bits of entropy).

correct. that's what i thought you might say.  thats what i would have said.  

so under the assumption that HT and TH have equal probability that method seems good for eliminating bias but there is that assumption. i guess most people accept it as a fact. which seems not unreasonable to want to do i guess.   to test that assumption one could take their particular coin and toss it a million times and see how often HT and TH showed up. should be about 500k times each. not sure where the cutoff would be to determine the assumption was problematic. maybe around 480k vs 520 ?

[o_e_l_e_o]

so under the assumption that HT and TH have equal probability that method seems good for eliminating bias but there is that assumption.

That's not an assumption - it's pure math.

Let's say your coin is biased to 60% heads, 40% tails. The probability of HT is 0.6*0.4 = 0.24. The probability of TH is 0.4*0.6 = 0.24. The probability is identical. This is the whole premise behind von Neumann's algorithm - you know HT and TH are equally probable without the need to perform any statistical testing of your coin.

[NotATether]

By coincidence, I stumbled upon an article about bias in coin tosses. It reminded me about this topic, hence the 10 month bump.

TL;DR: if you start a coin toll with heads up, there's a 50.8% chance you'll end up with heads.

This is the important part:

Delving into the data further, they found that coin tosses are highly variable between people, with some showing a strong same-side bias and others having none at all – coin tosses may come down (ever so slightly) to the tosser.

Some people have the bias and others don't.

It makes me think: What would a device with a spring to launch the coin do? It would almost certainly eliminate all bias in coin tosses - provided it is engineered properly - and it could even be made into a wearable on your hand that you can use to emulate a traditional coin toss.

[larry_vw_1955]

That's not an assumption - it's pure math.

you're assuming that the outcome of one coin toss does not have any affect on the outcome of the one after it. you model that as though they are "independent" events but that needs to be tested to make sure that is actually the case, don't you think? otherwise how do you know?

Let's say your coin is biased to 60% heads, 40% tails. The probability of HT is 0.6*0.4 = 0.24. The probability of TH is 0.4*0.6 = 0.24. The probability is identical. This is the whole premise behind von Neumann's algorithm - you know HT and TH are equally probable without the need to perform any statistical testing of your coin.

forget about the formulas. talk about the real world tests that justify why they are independent. what tests have you done?   did you flip a coin 10,000 times and count how many HT and TH you got? if not then there could be some systematic bias in the situation that you just arent aware of.

now i'm not saying that this method is inferior to just flipping a biased coin, surely its better than just that.

[o_e_l_e_o]

you're assuming that the outcome of one coin toss does not have any affect on the outcome of the one after it.

As far as the coin goes, it makes no difference. The coin doesn't remember the previous result, and so previous tosses have no bearing on future tosses.

As far as you go, then the solution is as above. If you don't learn the outcome of the first toss, then it cannot bias any subsequent tosses.

[LoyceV]

It makes me think: What would a device with a spring to launch the coin do? It would almost certainly eliminate all bias in coin tosses - provided it is engineered properly - and it could even be made into a wearable on your hand that you can use to emulate a traditional coin toss.

My gut feeling tells me this spring would create the same result every time, because the initial conditions are the same. Unless the spring tension varies, in that case the spring tension becomes your random and you need to make sure there's no bias in it. Or the way you load the coin into the machine.
Just for fun: here's a Machine Flips a Coin 10,000 Times.

[philipma1957]

so under the assumption that HT and TH have equal probability that method seems good for eliminating bias but there is that assumption.

That's not an assumption - it's pure math.

Let's say your coin is biased to 60% heads, 40% tails. The probability of HT is 0.6*0.4 = 0.24. The probability of TH is 0.4*0.6 = 0.24. The probability is identical. This is the whole premise behind von Neumann's algorithm - you know HT and TH are equally probable without the need to perform any statistical testing of your coin.

This finally hit me why it is wrong. The flipping must be done blindfolded and gloved to avoid a biased flipper that does not like your method.

Your assumption is that the coin is biased not the flipper. If it is the flipper your method is not good. Ie the flipper may subconsciously be able to take a neutral perfect coin and make it do heads 60-40

or tails 40-60 on any toss. So he would ruin the neumann method. unless he flips it gloved and blindfolded.

[pinggoki]

My gut feeling tells me this spring would create the same result every time, because the initial conditions are the same. Unless the spring tension varies, in that case the spring tension becomes your random and you need to make sure there's no bias in it. Or the way you load the coin into the machine.
Just for fun: here's a Machine Flips a Coin 10,000 Times.

Wouldn't the coin itself a factor to this too? Especially if you're not using the same coin to do the same flip on the machine and another factor is the atmosphere of the surrounding area and the hardness of the surface where the coin is going to land, the air resistance is always neglected in theory but in practical application, that's always considered right? And regarding the hardness of the surface, there's also the small grooves if the surface isn't smooth. Am I pedantic over this stuff or those can be considered a factor to the fairness of the flip?

We did that kind of experiment back in my freshmen year in college although it's a programming test where we set the times a coin is flipped and then the computer returns the results of the set times that the coin was flipped.

[larry_vw_1955]

Wouldn't the coin itself a factor to this too? Especially if you're not using the same coin to do the same flip on the machine and another factor is the atmosphere of the surrounding area and the hardness of the surface where the coin is going to land, the air resistance is always neglected in theory but in practical application, that's always considered right? And regarding the hardness of the surface, there's also the small grooves if the surface isn't smooth. Am I pedantic over this stuff or those can be considered a factor to the fairness of the flip?

they don't have any affect at all on the randomness apparently. as long as one does the von neuman method it doesn't matter about all of those external factors.  
just make sure to keep the conditions identical throughout the entire coin flipping process and don't let any of those factors vary. should be a piece of cake.

[pinggoki]

~

they don't have any affect at all on the randomness apparently. as long as one does the von neuman method it doesn't matter about all of those external factors.  
just make sure to keep the conditions identical throughout the entire coin flipping process and don't let any of those factors vary. should be a piece of cake.

But if those factors don't affect the flip, wouldn't that mean your second statement should be ignored because it says to keep the conditions identical and those conditions are the factors that I have talked about right? But I guess you're right, it's not like those factors can quickly change unless there's a physical intervention.

[larry_vw_1955]

But if those factors don't affect the flip, wouldn't that mean your second statement should be ignored because it says to keep the conditions identical and those conditions are the factors that I have talked about right? But I guess you're right, it's not like those factors can quickly change unless there's a physical intervention.

for example, lets say the surface you are doing the flips on has a high temperature. then whatever side the coin lands on will get heated up more than the side that lands face up. you will need to take that into account. maybe wait in between flips until both sides equalize to room temperature. for that, you would need a device that can measure the temperature of each side of the coin simultaneously.

[LoyceV]

you would need a device that can measure the temperature of each side of the coin simultaneously.

There won't be any temperature difference between sides, metals are excellent heat conductors.

[Medusah]

This finally hit me why it is wrong. The flipping must be done blindfolded and gloved to avoid a biased flipper that does not like your method.

How can the person have bias?  The whole point of tossing coins is that the outcome is completely unpredictable for the person.  You do not randomly press keys which would have bias on pressing "j" more often than "+" (example).  Just take a coin and flip it using the same initial conditions (e.g. thumb nail touches tails).

[LoyceV]

You do not randomly press keys which would have bias on pressing "j" more often than "+" (example).

Really? When I hit my keyboard 3 times with my non-mouse-hand, I get this: safdsafdsafd. I can easily reproduce it: safdsafdsafd. Again? safdsafdsafd.

[Medusah]

Really? When I hit my keyboard 3 times with my non-mouse-hand, I get this: safdsafdsafd. I can easily reproduce it: safdsafdsafd. Again? safdsafdsafd.

It was just an example.  If you mess with your keyboard, I expect to see "j" appearing more frequently than "+", because it is in the center of the keyboard.

Let me try.  Deep breath...

Code:

jolzxcioadsfjopas9-f0-AS0-ASJ9J90-ASIASF890HASFh90-

See? 
Anyway, just an example!

[larry_vw_1955]

you would need a device that can measure the temperature of each side of the coin simultaneously.

There won't be any temperature difference between sides, metals are excellent heat conductors.

pennies these days are made of mainly zinc like 95 percent with a copper coating. zinc is not quite as good of a heat conductor as copper.

lets say room temperature is 85 deg F and your hand is 95 deg F. That's a temperature differential of 10 degrees. You have the coin sitting in the palm of your hand with one face exposed to 95 deg F and the other side exposed to room temperature. There is going to be some temperature differential when you actually toss the coin and the sides will not get into thermal equilibrium before the coin lands.

So what i'm saying is the way you hold the coin and how long it is in contact with your hand and in what way those things can have an effect. probably not large ones but i haven't tested it.

[LoyceV]

pennies these days are made of mainly zinc like 95 percent with a copper coating. zinc is not quite as good of a heat conductor as copper.

lets say room temperature is 85 deg F and your hand is 95 deg F. That's a temperature differential of 10 degrees. You have the coin sitting in the palm of your hand with one face exposed to 95 deg F and the other side exposed to room temperature. There is going to be some temperature differential when you actually toss the coin and the sides will not get into thermal equilibrium before the coin lands.

Okay, I'll bite. But in normal units. Let's assume there's a 1^oC (or 1K) temperature difference between both sides of the penny. And let's assume it's made of 100% zinc (Wiki: 97.5% Zn, 2.5% Cu).
The diameter is 19.05 mm, and it's 1.52 mm thick (Wiki). That means the surface area is 285 mm². The thermal conductivity is 112.2 W/mK.

It's been a while, so I had to look it up:

The thermal conductivity of a material is described by the following formula:

K = (QL)/(AΔT)

Where,

    K is the thermal conductivity in W/m.K
    Q is the amount of heat transferred through the material in Joules/second or Watts
    L is the distance between the two isothermal planes
    A is the area of the surface in square meters
    ΔT is the difference in temperature in Kelvin

So:
K=112.2 W/mK
Q=<unknown> W
L=0.00152 m
A=0.000285 m²
ΔT=1 K

That means:
Q = K * A * ΔT / L = 112.2 * 0.000285 * 1 / 0.00152 = 21 W.

This confirms what I expected: you'll need to transfer massive amounts of energy through a penny to get a small temperature difference between both sides.
The specific heat of Zinc is 0.387 J/g K. A penny weights 2.5 g. That means adding 21 W for 1 second would be enough to raise the temperature of a penny by almost 21.7 K. It's safe to say you won't transfer 21W from your hand or a slightly warm surface into a penny, and it's safe to say the heat transfer inside the penny is large enough to keep both sides at almost exactly the same temperature.

[o_e_l_e_o]

Just heat the room and every object in it including the coin to body temperature, and then there will be no net transfer to heat to or from any object.

But what about the fact that the heads and tails side have different engravings, meaning photons will hit them at a different angle, and that will produce a bias so imperceptibly small that it wouldn't even affect a single flip if you flipped a coin from now until the heat death of the universe? Better flip in a pitch black room just to be safe!

These ever more ridiculous scenario are just that - ridiculous. Using von Neumann's algorithm and the same starting conditions for each flip is all that is needed to product a complete random string of bits. If someone is genuinely concerned about the different sides of the coin having a difference of a one degree and that somehow heating up the adjacent air enough to bias the flip, then they should be absolutely terrified of the security of literally everything else in their life, which won't be as random as this.

[LoyceMobile]

Using von Neumann's algorithm and the same starting conditions

Let's add Heisenberg's uncertainty principle to the equation to make sure we can't ever know the exact starting conditions, and thus never reproduce it exactly. Now that I think about it: in this case, that's actually a good thing. You're going to need a very small coin.

[larry_vw_1955]

Just heat the room and every object in it including the coin to body temperature, and then there will be no net transfer to heat to or from any object.

you would also need to do the coin flip in a vacuum since if there is air pressure then the side facing up will get exposed to a headwind which will tend to cool it off relative to the side that was exposed to the hand.

These ever more ridiculous scenario are just that - ridiculous. Using von Neumann's algorithm and the same starting conditions for each flip is all that is needed to product a complete random string of bits.

you may be right but lets not pretend we are capable of ensuring the "same starting conditions" for each flip. that is impossible. due to heat, air pressure and things of that nature. and variations in the hardness of the surface being used, etc, etc. you assume they all even out. "even out". as though anyone really understands what that even means.

Okay, I'll bite. But in normal units. Let's assume there's a 1oC (or 1K) temperature difference between both sides of the penny.

That was a very thorough analysis. But I do disagree that there might only be a 1 deg C temp difference. Human body temp is 98.6 F and room temp could be 20 degrees less. I'm not saying we should assume the temp difference is 20 deg F but its probably more than just 1 deg C. Maybe 5 times that.

[satscraper]

But what about the fact that the heads and tails side have different engravings, meaning photons will hit them at a different angle, and that will produce a bias so imperceptibly small that it wouldn't even affect a single flip if you flipped a coin from now until the heat death of the universe? Better flip in a pitch black room just to be safe!

Ha, there is even more interesting scenario, that can be taken into account by paranoiacs.

Due to not zero entanglement of the distant electrons someone, let's say on the opposite side of universe, flipping his coins may influence your results here on Earth.  

[LoyceV]

That was a very thorough analysis. But I do disagree that there might only be a 1 deg C temp difference.

I've seen you do this in more topics: you make a ridiculous claim, and stick to it despite overwhelming evidence of being wrong. Your first statement was there's a temperature difference between sides of the coin. I debunked that. Now you're saying the coin can get warmer. Nobody says a coin doesn't get warm if you hold it in your hand, but that's irrelevant for flipping the coin.

[larry_vw_1955]

I've seen you do this in more topics: you make a ridiculous claim, and stick to it despite overwhelming evidence of being wrong. Your first statement was there's a temperature difference between sides of the coin. I debunked that. Now you're saying the coin can get warmer. Nobody says a coin doesn't get warm if you hold it in your hand, but that's irrelevant for flipping the coin.

you didn't debunk anything. all you did is make an assumption that the temperature difference between the two sides was 1 deg C. I said I thought it should be higher than that given that body temp is 98.6 and room temp is about 75. what's so ridiculous about that? at least I'm not assuming anything. like you.

maybe i don't understand the physics involved but if you have a laser thermometer maybe you can do this test and report back.

[LoyceV]

all you did is make an assumption that the temperature difference between the two sides was 1 deg C.

You're taking it out of context. This assumption was needed to calculate the required amount of heat transfering through the coin, and the result of the calculation made it clear it requires an unrealistic amount of heat.

I said I thought it should be higher than that given that body temp is 98.6 and room temp is about 75.

That means you'll have to transfer 400 W of heat through a coin to reach a 20 degree temperature difference between sides. If you're not seeing how ridiculous this is, I give up.

To quote satoshi:

If you don't believe me or don't get it, I don't have time to try to convince you, sorry.

maybe i don't understand the physics involved

That's an understatement.

[larry_vw_1955]

This assumption was needed to calculate the required amount of heat transfering through the coin, and the result of the calculation made it clear it requires an unrealistic amount of heat.

now i realize the concern with your assumption that I have. you're assuming steady state i guess. who said anything about steady state? how fast does a penny achieve thermal equilibrium when it is sitting in the palm of someone's hand? you didn't even think about that and the model you plugged into only deals with "steady state".

[philipma1957]

That was a very thorough analysis. But I do disagree that there might only be a 1 deg C temp difference.

I've seen you do this in more topics: you make a ridiculous claim, and stick to it despite overwhelming evidence of being wrong. Your first statement was there's a temperature difference between sides of the coin. I debunked that. Now you're saying the coin can get warmer. Nobody says a coin doesn't get warm if you hold it in your hand, but that's irrelevant for flipping the coin.

yeah but do you agree the flipper of the coin must be blindfolded and toss the coin down a laundry chute into different room.

and a second person records the results

In the second room.

this eliminates the issue that the tosser can subconsciously influence and corrupt the von Neumann algorithm method.

[o_e_l_e_o]

If we are collectively going to be this ridiculous about flipping a coin, then you might as well just get a Geiger counter and point it at the banana you have in your kitchen, given that radioactive decay is a truly random process.

(But what about if the banana is really big or really small!? Or what if it has a slightly difference concentration of potassium-40 than average!? What if the laws of quantum physics are slightly different in my kitchen than in yours!?)

[LoyceV]

given that radioactive decay is a truly random process.

Is it? Or is there some structure behind it on the quantum level that we just don't understand yet? And even if it's truely random, your measurements can still get compromised.

Then again:

The generation of random numbers is too important to be left to chance.

But also:

Only God can make random selections.

[Medusah]

I do not know about you, but I believe anyone compromising these levels of randomness deserves the bitcoin.

[o_e_l_e_o]

Or is there some structure behind it on the quantum level that we just don't understand yet?

We can never prove there isn't, because you obviously cannot prove a negative. I cannot prove that all radioactive decay is not actually caused by a sentient and ominpotent Russell's teapot choosing individual atoms to decay at an instant of its choice. What we do know is that there are no experiments or indeed even mainstream interpretations of quantum physics which say that radioactive decay is anything other than random chance (bound by the half life of the particular isotope in question).

And if all of science can't predict the decay any better than random chance, then someone trying to hack in to your wallet couldn't either.

[ABCbits]

If we are collectively going to be this ridiculous about flipping a coin, then you might as well just get a Geiger counter and point it at the banana you have in your kitchen, given that radioactive decay is a truly random process.

I'd suggest using few lava lamps instead for these reasons,
1. You don't have to worry about spoiled banana.
2. Lava lamp is nice decoration for your guest room.
3. You can use your phone camera if you don't want to buy CCTV/security camera.
4. Big company such as CloudFlare already do that, https://blog.cloudflare.com/lavarand-in-production-the-nitty-gritty-technical-details/.

But on serious side, /dev/urandom is more than enough.

[larry_vw_1955]

I'd suggest using few lava lamps instead for these reasons,
1. You don't have to worry about spoiled banana.
2. Lava lamp is nice decoration for your guest room.
3. You can use your phone camera if you don't want to buy CCTV/security camera.
4. Big company such as CloudFlare already do that, https://blog.cloudflare.com/lavarand-in-production-the-nitty-gritty-technical-details/.

hmm i saw this story a few years ago and it didn't make any sense at all. what's so special about lava lamps? do they have some type of usb port where they're spitting our random numbers? you could literally set up a video camera at a mall and take snapshots every 10 seconds and guaranteed the images will have different hashes. same thing.

i thought maybe they were doing something more exciting with lava lamps like they had some electronic eye that counted how many blobs were in it every 20 seconds or something but no. nothing like that...

[o_e_l_e_o]

I'd suggest using few lava lamps instead for these reasons,

You don't even need to do any of that. As I discussed way back on page 2 of this thread, pointing your phone at a light source is enough to capture the shot noise, which is another truly random process and will produce truly random numbers. Here's a paper describing the process: https://arxiv.org/pdf/1405.0435.pdf

what's so special about lava lamps?

Nothing. They simple produce an ever changing picture which is impossible to predict.

[dkbit98]

I suggest everyone to watch this video made by Crypto Guide, it is very much related with this topic.
He explains how some unsecure hardware wallets (read Coldcard) are allowing owners to use weak dice method of generating seed phrases, that resulted in people losing coins.
Video is less than 10 minutes long:
https://www.youtube.com/watch?v=oj_W3xOlt6U

This doesn't mean we shouldn't use dices anymore, but we need to use them properly with high enough entropy.

[larry_vw_1955]

what's so special about lava lamps?

Nothing. They simple produce an ever changing picture which is impossible to predict.

yeah but the way of gathering entropy is kind of like cave man style. as you pointed out, just taking periodic pictures of almost ANYTHING even if nothing moves would still result in a different hash of the image. which is all they are doing anyway. if the lava lamp had some type of electronics that counted blobs per unit time and measured their sizes and velocities and turned that raw data into a binary sequence then that would be worth writing a story about. but not if they are just using lava lamps for publicity when they aren't really even needed. and they aren't as you already admitted.

[BlackHatCoiner]

Video is less than 10 minutes long:
https://www.youtube.com/watch?v=oj_W3xOlt6U

Good watch. Coldcard shouldn't allow anyone to create a wallet with just a dice roll. Or, if they really felt they want to give the option for the user to test dangerous stuff, then maybe create a security option defaulted to true. Or maybe just show a proper warning -- "Your funds aren't safe with x dice rolls, are you sure you want to continue?". Anything below 50 is insecure, because even for a completely unbiased dice, 49 rolls give less than 128 bits.

But on serious side, /dev/urandom is more than enough.

It might be more than enough in terms of entropy, but it is horrible in terms of verifiability.

[LoyceV]

It might be more than enough in terms of entropy, but it is horrible in terms of verifiability.

You can have both: just add two random numbers (and wrap around the maximum). That way you have both: one part that's more than good enough on a cryptographic level, and one part that you can verify and do whatever you want with.

Example: I want a random number from 1 to 256. I use random.org to generate 159. I flip a coin 8 times: 10111001. That's 185. Add them, and subtract 256: I get 88. As long as at least one of my 2 inputs is random, my end result is random too.

[BlackHatCoiner]

You can have both: just add two random numbers (and wrap around the maximum).

You can do a host variety of things if you're creative, but it'd be an overdose. Just toss the coin, simple and tested.

[BlackHatCoiner]

Linux kernel is open source, people with sufficient skill and time can verify /dev/urandom. Although if you mean directly check or inspect how specific data is generated while knowing exact input was used, AFAIK it's very difficult task.

I meant that you cannot be 100% certain you don't use malicious / backdoored hardware. And even if you do, it's much more difficult task than tossing a coin.

[LoyceV]

Linux kernel is open source, people with sufficient skill and time can verify /dev/urandom.

Let's be realistic: how many people actually do that? And even if you do, there's far too much software to be able to check everything.

[o_e_l_e_o]

You can have both: just add two random numbers (and wrap around the maximum).

You have to be very careful with such an approach not to introduce a modulo bias. And given most people probably don't even know what this is, I wouldn't recommend this method. A better approach would be to take two bit strings the same length as your entropy and XOR them.

But again, this is all adding needless complexity which simply increases the risk of the user doing something wrong and ending up with an insecure wallet. Just use dev/urandom. If you can't verify it and don't trust it, then flip a coin with von Neumann's. Done.

[albert0bsd]

Linux kernel is open source, people with sufficient skill and time can verify /dev/urandom.

I did it for the FreeBSD kernel and I can tell you guys that the urandom device on that system is very secure, unless you can broke any AES256 cypher text

I post something about that on twitter: https://twitter.com/albertobsd/status/918201595921403904

I haven't done that for the Linux Urandom for i think that it is very similar.

About the Linux urandom you should read this link: https://www.2uo.de/myths-about-urandom/

And here is my password generator snippet for bash

Code:

</dev/urandom tr -dc 'A-Za-z0-9!"#$%&'\''()*+,-./:;<=>?@[\]^_`{|}~' | head -c 40 ; echo

Here is a privatekey generator:

Code:

</dev/urandom tr -dc 'A-F0-9' | head -c 64  ; echo

Example:

[o_e_l_e_o]

And here is my password generator snippet for bash

Nice. That's almost the exact same command that I use: https://bitcointalk.org/index.php?topic=5470444.msg63006181#msg63006181

Instead of listing all the characters, you can just use [:print:] for the set of 95 printable ASCII characters, or [:graph:] to exclude space. And with a character set of either 95 or 94, then a length of 20 characters still provides more than 128 bits of entropy.

[albert0bsd]

Wow, nice to know  thank you they look more clean i am going to start to using them.

In any case it need the extra echo command to add a carriage return

A password

Code:

< /dev/urandom tr -cd "[:graph:]" | head -c 20 ; echo

A privatekey (hex upppercase)

Code:

< /dev/urandom tr -cd "A-F0-9" | head -c 64 ; echo

A privatekey (hex lowercase)

Code:

< /dev/urandom tr -cd "a-f0-9" | head -c 64 ; echo

About the amount of entropy you are right 20 characters are enough for more than 128 bits, Check:

Code:

>>> 94**20
2901062411314618233730627546741369470976
>>> 2**128
340282366920938463463374607431768211456
>>> 94**20 > 8* 2**128
True
>>> 94**20 > 9* 2**128
False

Actully  it is 8 times more than 128 bits

[BlackHatCoiner]

A privatekey

Code:

< /dev/urandom tr -cd "[:xdigit:]" | head -c 64 ; echo

Two things to be noted in here, for educational purposes.

• The maximum value for a Bitcoin private key is a little less than 2^256-1, which is the maximum number this Unix command can return. Generating a private key using a regular Unix command isn't advisable.
• This particular command can generate uppercase and lowercase hexadecimal characters. You wouldn't want to do that. You should replace "[:xdigit:]" with "0-9a-f".

[LoyceV]

A password

Code:

< /dev/urandom tr -cd "[:graph:]" | head -c 40 ; echo

Bookmarked (and edited to 40 characters in my quote). This is faster than my password manager, although I'd still need that to store it. I like shell commands

[albert0bsd]

This particular command can generate uppercase and lowercase hexadecimal characters. You wouldn't want to do that. You should replace "[:xdigit:]" with "0-9a-f".

Thank you, yes it seems a little weird, i already edited that post to add two varians "a-f0-9" lowercase and "A-F0-9" personally I preffer uppercase.

Bookmarked (and edited to 40 characters in my quote).

Yep 40 characters is my personal choice too, i never did the calculation before this post, but 40 characers are more than 256 bits, actually it is 262 bits

Code:

>>> 94**40
8416163114342587184481256383580844806830463920246539841882654902287234106392576
>>> 2**256
115792089237316195423570985008687907853269984665640564039457584007913129639936
>>> 94**40 > (2**262)
True
>>> 94**40 > (2**263)
False

[testingelcrypto]

i couldnt read all the answers and from what i read i cant still say if rolling dices is safe.

Seedsigner has that feature do you think someone who uses that for a 24 word seed with 5 dices and 1 coin like this protocol says : https://bitbox.swiss/blog/roll-the-dice-generate-your-own-seed/ gets a seed impossible to crack?

[testingelcrypto]

after reading more about the subject i come to the conclusion that dice rolling is better even if i dont use fair dice.

i used this calculator https://planetcalc.com/2476/ and i found that a die that comes 50% number 1 and the rest of numbers just 10% if i roll it 100 times i still get 216 bits of entrupy.

Am i thinking correct?

[BlackHatCoiner]

after reading more about the subject i come to the conclusion that dice rolling is better even if i dont use fair dice.

It is faster, and most likely sufficient if rolled enough.

Am i thinking correct?

Yes, if you roll it 100 times, then even if it seems completely biased towards 1, it will generate enough entropy. That's the Shannon equation for measuring uncertainty.

I have demonstrated it in here. The probability of a number being 50%, and the rest 5 being 10% each, still gives 2.16 bits of entropy on each roll, which is 0.42 less than in a completely unbiased dice, but enough nevertheless if you simply roll it a few times more.

It simply takes time to verify that the dice won't fare worse than that. In contrast, coin flipping using von Neumann's method necessitates no precautionary measures.

[testingelcrypto]

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.

Is this really necessary ? A coin that flips 0.75 heads and 0.25 tails still has 0.81 entropy. just flip it 156 times to be sure you have a good seed phrase. And if you are paranoid go for 200 flips and you are good to go. You only get cracked if the coin is really a bad coin where it goes tails only less than 15% of the time.

Do you agree?

[testingelcrypto]

is the entropy for a die really over 1 bit? if the seed its all zeros and one even if the die has 6 faces its always 50% 50% because we will have to do something like from 1 to 3 choose ZERO from 4 to 6 choose ONE.

[BlackHatCoiner]

does anybody really trust casino dices?

It is said that casino dice is the most fair piece of dice.

is the entropy for a die really over 1 bit? if the seed its all zeros and one even if the die has 6 faces its always 50% 50% because we will have to do something like from 1 to 3 choose ZERO from 4 to 6 choose ONE.

As I have showed in here, a dice that produces near 1 bit of entropy is understandably insecure from the human eye. You can check out how frequent '1's I have got with 75% frequency, it makes a splash. And that's 1.29, with 1 bit it's even more clear that you shouldn't use that dice.

[testingelcrypto]

As I have showed in here, a dice that produces near 1 bit of entropy is understandably insecure from the human eye. You can check out how frequent '1's I have got with 75% frequency, it makes a splash. And that's 1.29, with 1 bit it's even more clear that you shouldn't use that dice.

a  perfect dice doesnt show 1 bit. what i mean is :

a word in the bitcoin seed is something like this : 00011111101

By using a dice i assume people have to say: if dice comes 1 to 3 i will choose number 0 if dice come to 4 to 6 choose number 1

So this is always a 50% 50% making that dice like a coinflip. Am i thinking right?

[BlackHatCoiner]

So this is always a 50% 50% making that dice like a coinflip. Am i thinking right?

Well.. no. That's the case only if the dice is completely unbiased (which is never the case). If, say, {1, 2, 3} have 20% each, then {4, 5, 6} have 13.3% each. This will produce the same result as a coin that is 60% heads and 40% tails.

It doesn't make sense to roll a dice as if you're tossing a coin; toss the coin in the first place using von Neumann's method. It will eliminate any bias and produce theoretically complete randomness.

[testingelcrypto]

The BIP 39 list of words are seemingly random words, in alphabetical order, numbered 0 to 2047. Each word represents an 11 bit number (eleven 0’s and 1’s).

how do you convert the 1 to 6 in a dice to 0 and 1 to get a seed word?
i assume you have to do 1 to 3 is a 0 and 3 to 6 is a 1. This makes like a coinflip.

[BlackHatCoiner]

how do you convert the 1 to 6 in a dice to 0 and 1 to get a seed word?

There are lots of ways. One simple way is to hash the dice result record, e.g. sha256("262351..."); this one might decrease the entropy by a little (here's why). Another simple way is to count bits according to this array:

Code:

1: 00
2: 01
3: 10
4: 11
5: 0
6: 1

That's faster than counting {1, 2, 3} as 0 and {4, 5, 6} as 1, because it adds 1.66 bits on every dice roll, on average.

[testingelcrypto]

Another simple way is to count bits according to this array:

Code:

1: 00
2: 01
3: 10
4: 11
5: 0
6: 1

I like this. Do you like the ideia of adding a coin flip when i am at 10 numbers in order to get the number 11  or this is bad for entropy?

[BlackHatCoiner]

Do you like the ideia of adding a coin flip when i am at 10 numbers in order to get the number 11  or this is bad for entropy?

I like the idea of using von Neumann's method and not some sketchy method you just invented. Use what is tested and reviewed.

[o_e_l_e_o]

Is this really necessary ?

I'll refer you to an answer I gave in another thread on this topic:

Maybe. Maybe not. The numbers given so far in this thread discuss the Shannon entropy, but have you calculated the min-entropy you would achieve from doing this? What randomness extractor algorithm are you planning to use to turn those dice rolls in to usable entropy? How are you converting those dice rolls to binary without introducing modulo bias? It's not as simple as just "roll the dice more" - it's a very complex topic which most people do not fully understand (and I do not profess to either), which is why whenever the topic of manually generating entropy comes up, I always suggest von Neumann's coin flips to simply, quickly, and most importantly verifiably generate 128 or 256 bits of provably unbiased entropy.

If the answer to generating true random numbers was as simple as "Take any old non-random and biased process and just repeat it a bunch of times", there would not be an entire field of research dedicated to it.

We have methods were are provable and verifiable. Why risk everything by coming up with your own ad hoc scheme?

[larry_vw_1955]

We have methods were are provable and verifiable. Why risk everything by coming up with your own ad hoc scheme?

would you consider using a trezor or ledger or some hardware device that you can't really visibly verify what is going on you have to trust that it is generating random numbers? i have a hard time with that. every time i ever thought about using some hardware wallet to do that, i thought maybe i should do one or two just to get it "warmed up" so that's how little i trust an electronic device.

[LoyceV]

would you consider using a trezor or ledger or some hardware device that you can't really visibly verify what is going on you have to trust that it is generating random numbers? i have a hard time with that.

This is one of the reasons I'd never trust a hardware wallet with a lot. But the solution, at least for this part, is simple: create your own seed from flipping coins.

[philipma1957]

does anybody really trust casino dices?

In major casinos they are likely close to 1/6 per spot.

As a very astute player may detect a large bias and bet to their advantage.

[o_e_l_e_o]

would you consider using a trezor or ledger or some hardware device that you can't really visibly verify what is going on you have to trust that it is generating random numbers?

Ledger no, because it is closed source and actively malicious. Trezor maybe since it is open source, but there are a variety of reasons I don't trust Trezor as a company so I'm never going to buy one of their products. I would use an entirely open source hardware wallet like Passport, though, where I can see exactly how it is generating its random numbers.

[larry_vw_1955]

Ledger no, because it is closed source and actively malicious.

and you have stuff like this:

https://www.coindesk.com/business/2023/12/14/defi-protocol-sushis-cto-warns-of-possible-exploit/

It confirmed that a former Ledger employee fell victim to a phishing attack, which allowed a hacker to insert malicious code into Ledger's Connect Kit.


Imagine that, you lose your money because some employee was dumb and let someone else put some wallet draining code into the Ledger. Software attack. I guess part of that wallet draining code had the hacker's Ethereum address so it could send everyone's tokens to him or her. that's really bad security on ledgers part that something like that could even be theoretically possible.

Trezor maybe since it is open source, but there are a variety of reasons I don't trust Trezor as a company so I'm never going to buy one of their products.

plus they're kind of pricey too. but all hardware wallets seem to be really pricey these days. what's the problem with Trezor as a company though, just curious.

I would use an entirely open source hardware wallet like Passport, though, where I can see exactly how it is generating its random numbers.

so if you were storing $1,000,000 (or whatever you consider to be a large amount of money  ) you wouldn't have any issue slapping in 2 AAA batteries into it and the first seed phrase it generates you go with that one?  what if there was some type of electronic glitch?

This is one of the reasons I'd never trust a hardware wallet with a lot.

Yeah I can see why. I don't think I could either. Imagine losing all your bitcoin and then saying "if only I would have just flipped a coin..."

But the solution, at least for this part, is simple: create your own seed from flipping coins.

so you can create your seed phrase by flipping a coin and then use that on the hardware wallet? they let you put in your own seed phrase, i'm assuming. would that be an acceptable thing for you?

[LoyceV]

so you can create your seed phrase by flipping a coin and then use that on the hardware wallet? they let you put in your own seed phrase, i'm assuming. would that be an acceptable thing for you?

Ledger hardware wallets can "phone home" to send your seed phrase, so no, connected to an online computer I still wouldn't trust them. It's basically a hot wallet nowadays.

[larry_vw_1955]

Ledger hardware wallets can "phone home" to send your seed phrase, so no, connected to an online computer I still wouldn't trust them. It's basically a hot wallet nowadays.

i see what you mean: https://cointelegraph.com/news/crypto-community-reacts-to-ledger-wallet-s-secret-recovery-phrase-service

[o_e_l_e_o]

what's the problem with Trezor as a company though, just curious.

They are anti-privacy and actively support blockchain analysis via their partnership with Wasabi.

so if you were storing $1,000,000 (or whatever you consider to be a large amount of money  ) you wouldn't have any issue slapping in 2 AAA batteries into it and the first seed phrase it generates you go with that one?

I'm probably never going to store that much money in a hardware wallet (or indeed, in a single wallet at all). Multiple separate cold storage wallets is the way to go.

Although I would also be using a separately generate and secure passphrase, so even if my seed phrase was compromised my funds would still be protected.

so you can create your seed phrase by flipping a coin and then use that on the hardware wallet? they let you put in your own seed phrase, i'm assuming. would that be an acceptable thing for you?

For an open source and airgapped hardware wallet, yes. For a Ledger device, no.

[testingelcrypto]

Is this really necessary ?

I'll refer you to an answer I gave in another thread on this topic:

Maybe. Maybe not. The numbers given so far in this thread discuss the Shannon entropy, but have you calculated the min-entropy you would achieve from doing this? What randomness extractor algorithm are you planning to use to turn those dice rolls in to usable entropy? How are you converting those dice rolls to binary without introducing modulo bias? It's not as simple as just "roll the dice more" - it's a very complex topic which most people do not fully understand (and I do not profess to either), which is why whenever the topic of manually generating entropy comes up, I always suggest von Neumann's coin flips to simply, quickly, and most importantly verifiably generate 128 or 256 bits of provably unbiased entropy.

If the answer to generating true random numbers was as simple as "Take any old non-random and biased process and just repeat it a bunch of times", there would not be an entire field of research dedicated to it.

We have methods were are provable and verifiable. Why risk everything by coming up with your own ad hoc scheme?

I would use casino grade dices and test it for its bias before using it. To convert it to binary without bias i would use this model : number1 : 1 number2: 0 number3: 00 number4: 01 number5: 10 number6: 11.

I would then use https://iancoleman.io/bip39/ on an old offline pc to get to 24 words and then burn the pc on my furnace.

Do you think this is a a valid method?

[LoyceV]

I would use casino grade dices and test it for its bias before using it.

How are you going to test this?

[o_e_l_e_o]

I would use casino grade dices and test it for its bias before using it.

Which statistical tests are you going to use? What degree of bias are you trying to exclude? What p value are you happy with? How many rolls does that require?

To convert it to binary without bias i would use this model : number1 : 1 number2: 0 number3: 00 number4: 01 number5: 10 number6: 11.

This method has always "felt" like the best way to turn dice rolls in to bits to me, but I am not a cryptographer and I cannot rule out some bias or other flaw of which I am unaware. And this is why I always recommend that people don't come up with their own ad hoc schemes and instead stick to the tried, tested, and verified methods.

It will be far quicker using a Von Neumann approach to flipping a coin to generate a provably random stream of bits than it will be to even begin to test the fairness of your dice.

[testingelcrypto]

Which statistical tests are you going to use? What degree of bias are you trying to exclude? What p value are you happy with? How many rolls does that require?

I will runt it 500 times and see if theres a bias.I accept a bias of 30% for one side since it still has good entropy if i go for 24 word seed. Even though i know it cant have that bias since they are casino dice


this method is from iancoleman website. Do you think its not good enough since he is the creator of the bip39? why do you think the coin flip method is better?

[larry_vw_1955]

I would use casino grade dices and test it for its bias before using it. To convert it to binary without bias i would use this model : number1 : 1 number2: 0 number3: 00 number4: 01 number5: 10 number6: 11.

that sounds sketchy. but it could be valid. i have no idea. the thing is though that think about it. you're trying to get a 256-bit binary string. 4,5 and 6 reduce the entropy because they take more information to encode but they have the same probability of occuring as all the other numbers. that seems problematic maybe i'm not sure.

also, you have no idea how many dice rolls are going to be needed to generate your 256 bit number that seems problematic too. it could be 256 rolls but it could be 128 or anything in between which brings up another question: what if you roll the dice and have collected 255 bits and then on your final roll, you happen to roll a 4,5 or 6? then you have a problem.   it means you have to start all over again. i guess.

I would then use https://iancoleman.io/bip39/ on an old offline pc to get to 24 words

partly correct but you would not need to do all that fancy stuff you mentioned above since ian coleman has a "base 6" option. you can just enter your rolls using the digits 2-6. for example, 2342356533533225644331....

Do you think this is a a valid method?

not as valid as using  o_e_l_e_o's coin flipping bias eliminator method. it's in this thread...

[o_e_l_e_o]

I will runt it 500 times and see if theres a bias.

Rolling a die 500 times to look for bias is grossly insufficient. You need thousands of flips to exclude a small bias from a coin which only has two possible outcomes (which is why it is faster to not bother and just use a Von Neumann approach). For a die with (presumably) 6 possible outcomes you are looking at tens of thousands of rolls.

I accept a bias of 30% for one side since it still has good entropy if i go for 24 word seed.

You're sure about that? As soon as you deviate from a uniform distribution, then min entropy becomes more import than Shannon entropy. What's the min entropy of your biased die? If you don't know what I'm talking about, then how do you know your system is safe?

this method is from iancoleman website. Do you think its not good enough since he is the creator of the bip39? why do you think the coin flip method is better?

Ian Coleman did not create BIP39. You might also be interested in this discussion of bias on his GitHub: Bias in dice based entropy

A Von Neumann's coin flip method is better because it is faster, it is simpler, there is no possibility to introduce various biases such as modulo bias, and most importantly, it is verifiably random.

[larry_vw_1955]

I accept a bias of 30% for one side since it still has good entropy if i go for 24 word seed.

You're sure about that?

if one side had a 30% bias, that's almost double the normal theoretical bias of 1/6. there would have to be something REALLY wrong with a dice if it was that far off.