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

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.

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.

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.

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.

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


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.

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.

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.

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

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

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

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.

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



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

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

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.

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.

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.


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


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.

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.

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.

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.

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