Are dices for generating seed words fair?

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