Are dices for generating seed words fair?

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

[1714532714]

1714532714

[1714532714]

1714532714

[1714532714]

1714532714

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