SHA

simonmales

This is not SHA256 crunching, ASICs are useless in this search.

causefuckkarma

Quantum tech doesn't care about SHA-256—it targets ECDSA. This means Satoshi-era wallets holding over 1 million BTC are completely exposed. A quantum attack wouldn't even need to sell the coins; just moving them would trigger a historic panic, tanking Bitcoin’s price effectively to zero as the network's core security collapses.

Ill-Party8305

Far too late? Nah, you are overestimating what quantum would do at the first place. Even if we unlock the „quantum“ technology, it will still take practically forever to crack sha256. It‘s not like they just instantly vaporized sha256. Do you really think hah once quantum unlock every SHA256 is cracked in under 100 years?

12PALABRAS

Your reasoning is right, but two things are missing from this thread and they point in opposite directions. **The brute force is cheaper than "decades" suggests.** Once someone has your seed, guessing the passphrase happens entirely offline — no rate limit, no lockout, no device involved. And BIP-39 turns the phrase into a seed with PBKDF2-HMAC-SHA512 at **2048 iterations**, which by password-hashing standards is very cheap. Compare that to a modern password hash deliberately tuned to be slow. So "it's a password, it takes decades" is only true if the passphrase is genuinely high-entropy. A memorable phrase, a pet plus a year, a word with substitutions — those fall fast against hardware that isn't being throttled by anything. **And the decoy has a flaw people rarely think about.** Your plan is that he sees an empty wallet and moves on. But an address with a zero balance and no history at all is itself a tell — it says "this seed was generated and never used", which is exactly what a passphrase setup looks like from outside. If you want the deniability to actually work, the base wallet (seed, no passphrase) has to look like a wallet somebody used: some real history, a plausible amount left in it. An empty one advertises that there's a second door. **The thing that's more likely to cost you money isn't the attacker.** Your seed words carry a checksum — for a 12-word seed it's 4 bits, so a wrong word gets rejected roughly 15 times out of 16. **A passphrase has no checksum at all.** Every passphrase is valid. Type it with a trailing space, an autocorrected apostrophe, a capital you don't remember choosing, and your wallet opens a real, working, empty wallet and reports nothing wrong. There's no error to detect because, as far as the software is concerned, you asked for a different wallet and got it. That failure is silent and it's permanent, and it happens far more often than someone brute-forcing a strong phrase. So if you use one: write down that a passphrase exists and where the other half lives — that note isn't the secret and it's what your family will need — and do a full restore drill from what you wrote down, only what you wrote down, before you put real money behind it. Doing that drill after funding it is doing it in the worst possible order.

12PALABRAS

The answer is already in your own post, in the part you treated as a footnote: > when I take the HEX from the entropy section of the last one and paste that HEX into the first, it gives me "exclude" as the first word That is the whole thing. Feed them the same entropy and they agree. Feed them the same dice rolls and they don't. BIP-39 standardises entropy to mnemonic. Nothing standardises dice to entropy. That second step is each implementer's own choice, and there are at least three defensible ones: 1. Treat the roll string as a base-6 number and convert to binary. About 2.585 bits per roll, so your 99 rolls really are ~256 bits. Nothing discarded. 2. Map each die to bits with rejection — keep 1-4 as two bits and reroll 5 and 6, or fold 6 to 0 and take one bit each. Unbiased and checkable by hand, but wasteful. This is why one tool told you 99 rolls was "176 bits" and asked for 256. It is not disagreeing about your entropy, it is counting differently because it throws rolls away. 3. Hash the roll string with SHA-256 and use the digest. All three are reasonable, and they produce completely different entropy from identical dice. So the seeds differ and nothing underhanded happened. Which means the advice you remembered — run the same input through several generators to catch tampering — is right in spirit but applied one layer too early. Compare at the hex entropy, not at the dice. That is the layer where a shared specification exists, so a disagreement there is real information. At the dice layer you are comparing tools that never agreed to do the same thing: disagreement tells you nothing, and agreement tells you nothing either. Two of yours landing on "exclude" does not make them more trustworthy, it means they happened to pick the same conversion. I say this having just been burned by the other side of it. I hand-rolled BIP-32 derivation for a small tool and it passed the published BIP test vectors. Then I compared 1000 random derivations against an unrelated implementation and found a bug the published vectors had missed: without lifting the internal key to even Y before the TapTweak, Taproot produces a perfectly valid address for a different wallet, roughly half the time. Comparing implementations is the best check available. It just has to happen where both sides implement the same spec. Two practical notes. Your instinct about the printed PDF is good — the value of a method you can execute by hand is that you can check it, not that it is offline. And whatever you end up using, before you fund it, confirm the wallet reproduces the first address you expect. A mnemonic being valid says nothing about it being the one you meant to create; there is no error state for "wrong seed". Write the derivation path and script type down next to the words while you are at it. Nobody makes you do that, and it is the half of the backup people lose.

BastiatF

> From my understanding, if we use raw dice values without applying a SHA-256 hash function, converting them into binary causes a bias unless there is a perfect 1:1 mapping. There is no bias as long as each word as the same probability as any other (uniform distribution gives maximum entropy). Invalid combinations just require rerolls. The only drawback is that you are wasting entropy (i.e. you are generating more than 256 bits of entropy but keeping only 256 bits).

HedgehogGlad9505

It is probably fine to use the raw dice values, because BIP39 will apply SHA256 anyway?

Mammoth-Ad-168

From my understanding, if we use raw dice values without applying a SHA-256 hash function, converting them into binary causes a bias unless there is a perfect 1:1 mapping. In other words, if you use a SHA-256 function, rolling a D6 (6-sided die) 99 times allows you to obtain close to 256 bits of entropy. However, if you try a direct 1:1 mapping without a hash function, the mapping space doesn't perfectly align. Because calculating SHA-256 by hand is virtually impossible, generating a seed manually with just dice and no electronic devices requires alternative methods. You either have to roll 11 D6 dice at once using an even/odd rule to extract 11 bits and map them to the 2,048-word list, or roll two D16s and one D8 simultaneously and use a conversion table (like the one provided by Blockstream, the makers of the Jade wallet) to match the 2,048 words. Personally, I'm not a fan of D16 dice, so I created my own conversion table that allows me to throw four D8 dice at once and read them as an 8x8x8x4 combination. A few days ago, I used an offline scientific calculator (with no network capabilities) to build a mnemonic generator utilizing D6 dice and the SHA-256 hash function. The output results exactly matched the second method you mentioned earlier. Other D6-based mnemonic generators, like SeedSigner, also align with this method

Red_Wolf_2

Yep, I was thinking more about the simple reusable types of ICs like logic gates, regulators, timers/oscillators etc... Not ASICs as such because they're hardly application specific. In the context of my original comment, I was referring specifically to FPGA and ASIC driven mining hardware. Lots of effort went into trying to get the whole double SHA256 hashing thing onto dedicated hardware at a density and stability that would obsolete FPGA and GPU driven mining and it didn't all scale as well as many had hoped. I've still got my old BFL gear hiding away in a cupboard somewhere... Then there was all the chatter on IRC, the scams, the arguing between who was making better mining gear, the hodlers vs those who panic sold, mtgox falling apart... I even remember one of the old shock site operators showing up offering to sell one of the bigger domains for bitcoin back in the day (I don't remember if it was goatse, a party involving a certain citrus fruit, rapidly rotating structured protein, or maybe something involving a drinking vessel and two individuals, but whichever one it was they verified with a post to their rather well known site). It was a pretty wild time...

ackyou

Yes, the network would be easier to attack with kess hash power. Not only that, but as mining becomes less profitable a lot of miners would probably have to sell of their ASICS at a discount allowing someone to buy up a lot of that power. At this point I think we will never see GPU mining again. What that means, though, is if you attack the network you could be making that same equipment less valuable. I don't think there is any other good use case for a Bitcoin miner except mining SHA 256 blockchains. If you attacked a blockchain with a CPU or GPU optimized hash algorithm you could then turn your equipment to run AI or something. I think falling mining profits will actually be good for decentralizing miners because you will end up with many more small private miners that are either using excess energy or reusing the heat to eek out margins.

account009988

What a moron. This guy is claiming AI can crack SHA256. If it could do that the whole internet would be completely fucked including every bank. Utter moronic statement

BTC_MYTH44

SHA-256 bitcoin is a CBDC now IYKYK…

unforseen0_o

I want to talk about why the Coldcard incident from a couple weeks ago is scarier than most hardware wallet stories, and why ERA's response is a genuinely good case study in designing around the failure instead of just certifying against it. Quick recap for anyone who missed it. Starting July 30th, attackers began pulling roughly 1,367 BTC, about $89 million, out of thousands of Coldcard wallets. The cause traced back to a firmware bug from 2021. Under certain conditions, some devices silently fell back to a weak software random number generator during seed creation instead of using the hardware one they were supposed to rely on. The resulting seed phrases looked completely normal. There was no error, no warning, nothing that would tip off a user that anything was wrong. The keys were just reconstructible offline, and stayed that way for years until someone finally did the reconstructing. What makes this genuinely unsettling isn't the dollar amount, it's that Coldcard's RNG was a certified, respected component from a respected wallet. Certification tells you the chip behaves correctly in a lab. It says nothing about whether the firmware around it will actually route your entropy through that chip every time, under every condition, forever. That gap between "the chip is certified" and "the wallet used the chip correctly" is exactly where Coldcard users got hurt. ERA's blog post lays out how they're designing against that exact gap rather than just pointing at a certificate and calling it a day. Their seed generation pulls from up to five independent sources instead of one: Always active, two separate hardware random number generators from two different manufacturers. An STM32 microcontroller whose entropy is validated against NIST's statistical test suites, and an ATECC608C secure element whose entropy source is formally certified under NIST SP 800-90B. Different silicon, different vendor, different failure modes, so one bad batch or one bad firmware assumption doesn't take down the whole system. Optional, if you choose their expert flow, three more sources that come from you specifically. You draw on the screen, you shake the device, and you sweep the camera across whatever room you happen to be sitting in. None of that can be predicted by a factory or a supply chain attack, because it didn't exist until you made it exist in that exact moment. Every one of those user driven sources has to pass an on device randomness test before it counts. Leave the camera face down or barely tap the screen and the device just rejects it and makes you try again. If you skip the expert flow entirely, the slots that would have come from you get backfilled with fresh hardware entropy instead, so your seed is never weaker than the two chip baseline, only ever equal to it or stronger. All five sources then get combined through SHA-512/256, a one way hash function where partial knowledge is worthless. Knowing four of the five inputs perfectly still leaves an attacker with nothing they can use, because the function doesn't degrade gracefully. One honest source is enough to keep the output unpredictable. Where I'd push them further: everything above comes from ERA's own team, and while that's not a red flag by itself, "trust us, we tested it" is the same energy that let Coldcard's certified chip fail quietly for five years. To ERA's credit, they've already followed up with a technical report running their actual chips through NIST SP 800-90B, SP 800-22, AIS-31, and PractRand test suites, along with cold boot forensics, which is a real step toward "don't trust, verify" rather than just saying it. The next thing I'd want to see is an independent third party audit of the actual mixing implementation itself, not just the individual chips, since that's the layer where Coldcard's bug actually lived. If you're into wallet security or you're the kind of person who reads audit reports for fun, worth the full read: https://blog.era-wallet.com/randomness-you-dont-have-to-trust-how-era-generates-your-seed-phrase/

sunsetreunion

I like the included link to SHA-256 by hand. https://armantheparman.com/sha256/ Anyone have any idea how long that would take to calculate a single SHA256 by hand?

word-dragon

This is a riot! I’ve written software all my life and always thought in terms of explaining to the computer what process it has to go through to accomplish its task. Occasionally you have to run through it yourself to verify it’s gonna do what you want. The software is me. I don’t plan on using anyone’s computer hardware or someone’s software I’d have to verify. In the case you are asking: There are 2048 words often listed as 1 to 2048, but actually representing the bit patterns from 00000000000 to 11111111111 (000 to 7ff, in hex). So you take your first 11 bits that you generated using your manual process, and write down the corresponding word. Then you take the next eleven bits…and so on. Since 11 bits times 24 words is 264 bits, you’ll run out of bits in the last word. The last 8 bits are the first 8 bits of the SHA-256 hash of the key. How you get that manually is left as an exercise for the reader, lol!

sylsau

BIP-110 tried to prove that users could force miners to follow. It mined **two blocks**. Then the rebellion stalled. Now some supporters want to change Bitcoin’s proof-of-work and “fire the miners.” But here’s the uncomfortable part: If you replace SHA-256, abandon Bitcoin’s mining infrastructure, and create incompatible consensus rules… **Are you still changing Bitcoin—or have you simply created another coin?** Bitcoin gives everyone the freedom to fork. What it does **not** give you is the right to take Bitcoin’s identity with you. That verdict belongs to users, miners, markets, wallets, exchanges—and ultimately economic reality. **BIP-110 Failed. Now Bitcoin’s Rebels Want to Change Proof-of-Work.** The real question is no longer about spam. It’s about something much bigger: **When does forking Bitcoin become leaving Bitcoin?**

sylsau

BIP-110 tried to prove that users could force miners to follow. It mined **two blocks**. Then the rebellion stalled. Now some supporters want to change Bitcoin’s proof-of-work and “fire the miners.” But here’s the uncomfortable part: If you replace SHA-256, abandon Bitcoin’s mining infrastructure, and create incompatible consensus rules… **Are you still changing Bitcoin—or have you simply created another coin?** Bitcoin gives everyone the freedom to fork. What it does **not** give you is the right to take Bitcoin’s identity with you. That verdict belongs to users, miners, markets, wallets, exchanges—and ultimately economic reality. **BIP-110 Failed. Now Bitcoin’s Rebels Want to Change Proof-of-Work.** The real question is no longer about spam. It’s about something much bigger: **When does forking Bitcoin become leaving Bitcoin?**

Rasputin6942O

false. SHA256 Bitcoin changed in a way which 1) vastly increases the attack surface and 2) requires a consensus change to revert. you were airdropped a shipcoin by communists.

Mammoth-Ad-168

The mnemonic (BIP39) we use takes a random number as input and processes it through a one-way function, SHA256. Once it goes through this SHA256 conversion, reversing the process is incredibly difficult. However, as the name suggests, the SHA256 function will always output a 256-bit result regardless of what the input is. Even if you generated an input by rolling a die just once, it would still spit out a plausible-looking mnemonic. Therefore, for a crypto wallet to be secure, a sufficient amount of randomness is absolutely essential. That's why many companies implement TRNGs (True Random Number Generators) and mix in additional entropy—like noise or camera image data—to generate random numbers, which are then used to create the seed (mnemonic). As you mentioned, if the input data is identical, the subsequent steps follow a strict rule and will always generate the exact same seed. The problem is that once a mnemonic is generated, there is absolutely no way to verify whether it was created with sufficient entropy. Furthermore, since there is no way to individually check and verify the random number generation methods used by wallet manufacturers, people simply use a proven method like rolling physical dice to create 256 bits of entropy data themselves, and then manually convert that into a mnemonic. Wallets like Coldcard, SeedSigner, and Keystone Pro are equipped with a feature that allows users to generate random numbers and mnemonics using this actual dice-roll input method. I already own more than five hardware wallets from other manufacturers, but none of them have this feature. I debated whether I should buy another one, but I figured a calculator is also a sufficiently secure, air-gapped piece of hardware, so I programmed a seed generator on it myself. If you go to the website for the open-source wallet SeedSigner, their setup manual includes a publicly shared mnemonic generated from an arbitrary 99-character dice input. I tested this, and my calculator's seed generator produced the exact same value.

Routine-Surprise-601

One important detail: with a 24-word BIP-39 mnemonic, the last word isn’t purely a checksum. The first 23 words encode 253 entropy bits. The final word contains the remaining three entropy bits plus the eight-bit checksum. That means there are eight valid final words for any fixed set of 23 words. A device that always chooses one of those words deterministically is producing a valid mnemonic, but the first 23 words supplied only 253 bits of entropy. Selecting uniformly among all eight valid choices supplies the remaining three bits. Calculating the SHA-256 checksum entirely by hand is theoretically possible, but it’s difficult to audit and easy to get wrong. I wouldn’t rely on a new DIY workflow for live funds until its mathematics and implementation have been independently reviewed. Test it first with a disposable wallet, confirm recovery and the expected address, and never enter the resulting mnemonic into a website or connected computer. (Disclosure: I’m on the support team at Ballet.)

Legitimate_You_4730

I've been following the Coldcard situation pretty closely, and I also went through ERA Wallet's post about how they generate entropy. A few people were sharing it as the obvious answer to what happened, but I wanted to actually think through the argument instead of just nodding along. What bothers me most about the Coldcard incident isn't even the amount of money lost. It's how the failure happened. This wasn't phishing. It wasn't an exchange getting hacked. It wasn't someone storing their seed phrase in a Google Doc. The device did exactly what users expected it to do. It generated a seed, kept it on the device, never connected to the internet, and still produced a compromised wallet because of a firmware bug dating back to 2021 that caused it to fall back to a weaker software RNG instead of the hardware RNG. After three waves of drains, roughly 1,367 BTC are reportedly gone. That's the uncomfortable part for anyone who has ever felt completely safe because their funds were in cold storage. The whole promise of a hardware wallet is basically: your private key never leaves the device, so you're protected. But that only matters if the private key was generated properly in the first place. And that's an assumption most people never really question. A secure seed and a compromised seed can look exactly the same from the outside. Both can give you 24 perfectly normal-looking words. That's where I think ERA's approach gets interesting. Their basic argument is that you shouldn't put the entire security model behind one source of entropy. Instead, they combine two hardware RNGs from different manufacturers, using an STM32 chip alongside a NIST-certified secure element. Then there's the optional expert flow, which adds camera input, device movement and touchscreen input before everything is blended through SHA-512/256. The redundancy makes sense to me. If Coldcard taught us anything, it's that a silent failure in a single entropy source can become catastrophic. Having independently manufactured hardware generators means one failure doesn't automatically mean the entire entropy process is compromised. I also like the detail around user-generated entropy. ERA doesn't simply accept whatever input the user gives it. If someone barely shakes the device or leaves the camera pointed at a wall, the system can reject the input rather than pretending it added meaningful randomness. That's a small implementation detail, but it's the kind of thing I actually want to see. That said, I'm not ready to call the problem solved. ERA published this explanation immediately after a competitor suffered a major incident. That's exactly when I'd be paying more attention to the claims, not less. The chip-level claims can be checked independently. The implementation is harder. A well-designed entropy system on paper and a correctly implemented entropy system in production are two very different things. Coldcard is a pretty painful reminder of that. I'd also question how much value the "expert flow" really adds for the average user. Camera sweeps, shaking the device and scribbling on a touchscreen sound useful, but they're also more work. Most people will probably skip them. Which means the two-hardware-generator baseline has to be strong enough on its own. The extra entropy sources are only meaningful if people actually use them. So where do I land? I think the redundancy principle is absolutely the right lesson from the Coldcard incident. ERA's multi-source design is a legitimate response to the question of what happens when one entropy source silently fails. That's not just marketing fluff. It represents a different risk model from relying on a single source. But there's still a gap between "this architecture makes sense" and "this architecture has been independently proven to work." I'd want to see third-party audits, reproducible entropy testing, and eventually the NIST test-suite results ERA has teased. Until then, I'd call it promising rather than solved. Trust, but verify. And that standard should apply equally to every hardware wallet maker, including the ones currently benefiting from someone else's bad week.

sunsetreunion

Your point is very good, thanks for clarifying your position. Rolling the 11/23 words manually with dice, and then guess-and-checking the 12th/24th word with the hardware wallet (as you propose) does seem like it would be a more secure solution for generating a checksum word than the 2nd link solution I propose above. However, generating the receiving addresses using the hardware wallet from the seed phrase is another issue altogether. Using a hardware wallet, you are trusting that the custom and niche hardware/firmware/software layers have all been implemented correctly. Whereas if you use a permanently  air-gapped PC running audited JavaScript code in the browser, you need only trust that the general purpose computer and the browser running the code are behaving normally. While its true that a thief could compromise the cryptographic SHA-256 primitive in the Firefox browser to generate deterministic keys, the number of developers relying upon the cryptographic integrity of Firefox is massive compared to the relatively few developers who are looking at the code running on a hardware wallet. Case in point: the ColdCard fiasco. I know of no such similar attack on cryptographic primitives that has occurred on general purpose computers that has lost people bitcoin. Is it possible? Yes. But I believe the Cold Card attack shows that it's much easier to compromise these custom hardware devices than general purpose computers.  That being said, generating identical receiving addresses using identical derivation paths on two (or more) different devices would probably be pretty secure, but is arguably more difficult to accomplish than using a general purpose computer. Thanks for your thoughtful input.

Romanizer

The key mistake is treating electricity, generic computing power and Bitcoin hashrate as interchangeable. They aren’t. You cannot point a bunch of US data centers at Bitcoin and suddenly have 51%. Competitive SHA-256 hashing requires enormous quantities of dedicated ASICs. That hardware, its manufacturing capacity, deployment, power delivery and cooling are themselves major bottlenecks. And security does not have to scale linearly with Bitcoin’s market cap. A 51% attacker does not get to steal “a percentage of all Bitcoin.” They can censor/reorg blocks and attempt double-spends. The economically extractable prize is therefore nowhere near the total value stored on the network. PoS is certainly much more energy-efficient, but “same security for free” is not even Ethereum’s claim. It trades external ASIC/energy costs for stake, slashing, more protocol complexity, weak subjectivity and different concentration/attack risks (e.g. 33% attacks). The market doesn't seem to want this trade-off.

ghavhqydb

The codes are only 30 lines. Other than SHA256 hash algorithm, I think you can do rest of things all by hand. I'm just lazy to do manual 11 bits -> word translation.

RefrigeratorLow1259

Thanks for clarifying! Hashing the raw ASCII string of dice rolls directly is a very clean way to do it as letting SHA-256 handle the entropy extraction completely avoids modulo bias and base-conversion edge cases. How does micro python run time in Casio handle 32-bit unsigned bitwise rotations and additions in SHA-256 without hitting signed inteteger overflow/floating point truncation issues though? I'll have a look into it when I've got some time. Overall seems a pretty solid approach 😎 (though I'd love to see the code lol!)

12PALABRAS

One additional failure mode in the posted code: it validates that every character is 1–6, but never enforces a minimum number of rolls. A single 1 is accepted, hashed, and turned into a perfectly valid-looking 24-word mnemonic. The UI saying “99 rolls rec.” is not a safety check. Before anyone uses this with value, make the program reject fewer than 100 rolls, then verify the complete SHA-256 + checksum + word-index output against independent BIP39 test vectors. Matching another tool once is useful, but a deterministic implementation error will keep producing plausible words forever.

Mammoth-Ad-168

The dice results go into the SHA-256 function. If the dice are perfectly fair, the entropy of a single die is 2.585 bits, and repeating it 99 times gives 255.915 bits—falling short of the 256-bit target by 0.085 bits. Unless the dice have high precision, the value drops a bit, but in that case, you just need to roll them a bit more. 10 more times? ref. [https://hashexplained.com/entropy](https://hashexplained.com/entropy)

AnaMoneyro

You're right about BIP39 itself, the entropy goes into the words unhashed, and SHA-256 only produces the checksum bits. What the page shows is the dice workflow specifically. Coldcard and Krux take the dice digits as a string and SHA-256 that to produce the 128/256 bits that *become* the entropy, a separate step, before BIP39 starts. Then BIP39 runs as specified: checksum = first ENT/32 bits of SHA-256(entropy), appended, sliced into 11s. Two hashes doing different jobs. The page doesn't separate them clearly enough, I'll fix the wording. Good catch.

Mammoth-Ad-168

The physical dice rolls are what actually determine the randomness. The calculator just handles the SHA-256 hashing, checksum, padding, and slicing operations. I was half-doubting it while building it, but when I compared the output to other tools, the results match perfectly.

Mammoth-Ad-168

Just to clarify, I'm rolling actual physical dice 99+ times and inputting the results into the calculator, which then runs the SHA-256 hash and maps it to a seed according to the BIP39 rules. I'm not using any built-in dice software on the calculator.

lexicon_riot

What would it do to the viability of the HW wallet business if such a vulnerability is grounds for legally-enforced reimbursement? I mean I understand completely, I'm not going to defend NVK and co. I think the rules and precedent would need to be crystal clear though if any action is taken. Like, I don't think Trezor should be held responsible for lost funds if quantum computers break SHA-256 and a bunch of users fail to move over to whatever quantum safe solution we cook up. I don't think Ledger should be responsible if a bunch of users are targeted and tricked into entering their seed phrases online. Or even if people spend years combing through code without finding anything, but then Kimi K12 super mega AGI finds and exploits a horrible vulnerability after being available for a day, it's not like due diligence wasn't taken up until the release of what essentially amounts to a super weapon. Even if any ruling is very specific in it's application to Coinkite's situation (NVK ignoring concerns, implementing bad code knowingly to begin with, etc.) it's still going to be a massive regulatory and insurance headache for every other company doing things right.

ghavhqydb

yes, for the 24th word: use the last 3 bits generated from the dice roll; apply SHA256 hash on the entire length = 256 bits. Take the 1st 8 bits of the hashed result. The last 3 bit + 8 bits = 11 bits form the 24th word's index. Manually compute SH256 might be very hard and prone to error. I wrote a python script, and then ran it in an air-gaped machine.

ghavhqydb

Yes, you are right real entropy is only 256 bits. But I only meant the whole process on how to generate the 24 words: 256 bits randomly generated via dice rolling, then feed the 256 bits to SHA256 hash, take the first 8 bits of the hashed value to form the full 264 bits. Map each 11 bits to an integer, and then look up in 2048 word dictionary directly. (Index 0 means the 1st word to pick.) The 24th word's index is 3 bits (from the last 256 bits) + 8 bits (from hash value).

Zerogrinder

But this is all your own reasoning, internet stranger. No sources with wild assumptions (like odds improving by orders of magnitude daily etc.). Hashing is very effective against brute forcing with compute power, so when it comes to breaking SHA-256 even with quantum computing- it’s probably not going to happen in the near future out of the blue. And when it does, the traditional finance world and institutions themselves are just as vulnerable.

East-Day-7888

The source is just basic math. There’s no need to write a research paper to establish something anyone can calculate. SHA-256 has a defined computational complexity, which gives us fixed numerical variables to work with. we can estimate the amount of computational work required to break or undermine its security assumptions.(no research paper required) then compare that against the rate at which computing capabilities are advancing.(this is where research supplied come in) And to be upfront, saying, “We can break SHA-256 within a fixed amount of time with 100% certainty,” doesn’t account for outliers. The same reason reasoning is behind people running btc lottery miners: the expected time may be enormous, but that doesn’t make an earlier successful outcome mathematically impossible. I’m less concerned with the question, “When can we reliably break SHA-256 with 100% certainty?” and more concerned with, “At what point does successfully attacking it become mathematically plausible?” If the math say five years until a major degradation in effective security, then the risk doesn’t suddenly appear in year five. The probability increased along the way. At some point before that threshold, existing compute could theoretically have better odds of successfully attacking Bitcoin’s cryptographic security than a lottery miner has of successfully mining a single block. That probability is something I believe we have already crossed the threshold for. Granted the odds of solo mining a btc block are currently 400x worse than winning a multi million jackpot lottery. Its still mathematically possible which is why both sell, and those odds are only improving by orders if magnitude daily.

RefrigeratorLow1259

That's too error prone, I used: https://github.com/IanMcLo/bip-39-dice/tree/main The second method is significantly easier, faster, and much less error prone! Why? Well: Automatic Checksum: The biggest pain with pure paper lookup tables (taelfrinn) is the 12th/24th word checksum. Paper tables can't calculate SHA-256 hashes, so you're forced to do trial-and-error across a block of 16 candidate words in a wallet app until one works. The single-file HTML handles the SHA-256 calculation and outputs the exact correct final word instantly. Simpler Rolls: taelfrinn forces you to flip a coin and roll 4 dice for every word, plus re-roll whenever you hit out-of-bounds combinations (like Tails + >4362). The second approach just takes standard D6 rolls. Easy Air-Gapping: Because IanMcLo/bip-39-dice is plain, vanilla HTML/JS with zero NPM dependencies or external scripts, you can just save index.html to a thumb drive, drop it onto an air-gapped machine or Tails OS, and run it safely offline. TL;DR: Pure paper tables make getting a valid checksum word a hassle. Downloading the standalone offline HTML file gives you the same air-gapped security with none of the trial-and-error guesswork.

metalzip

> No it was not signed Well there is an "SHA256SUMS.asc" in his downloads for that program.

na3than

No. There's a reason ASICs - Application Specific Integrated Circuits - are called *Application Specific* Integrated Circuits. They're literally designed, from the ground up, for a specific application - in this case, lightning fast SHA256 hashes.

RefrigeratorLow1259

Bias makes little difference in the entropy calculation...check out Shannon entropy. For dice rolls entropy should be 2.585, but even if the 6 came up twice as often as the other numbers it only reduces entropy to 2.522. Also remember that running all the throws through a SHA-256 cryptograohic hashing function destroys any patterns.

GoldmezAddams

Yes, you can use a diceware sheet like the one from Bitbox02 to map it all out. That sheet comes with instructions, too. I'd like to see some evidence that sheet has been reviewed by a third party, but probably a good option. The option more like what Coldcard was doing, where you can add as many rolls as you want, involves recording the rolls like 1242651325614255 etc and then putting that string through SHA-256, and using the procedure outlined by BIP-39 to translate the resulting 256 bits into a seed phrase.

ghavhqydb

The 24th word is a checksum word, a random combo of 24 won't work. The Correct process: random pick 23 words, for the 24th. 1/256 chance among the 2048 words will be a correct one. And the 8 correct ones are distributed evenly, 1 legit word for every 256 ones in the list. You can just also randomly roll a 1-8 number, then brute force try all 256 choices in the range to get the correct one. Or I just choose to dice roll my own 256 bits, and then compute SHA256 to have a deterministic solution about which word is the 24th.

Strong-Al

Next version of this is quantum breaking SHA-256. Good luck Bitcoin Core devs!

Cryptotiptoe21

The Math **11 bits per word:** The BIP-39 list has 2,048 words (2\^{11} = 2,048). **23 full words:** 23 words x 11 bits = 256 bits **24th word breakdown:** The last word contains **3 bits** of user entropy + **8 bits** of SHA-256 checksum (253 + 3 = 256 bits total entropy The Catch with "Pulling from a Bag" If you pull 24 words completely at random out of a bag, **only 1 out of every 256 attempts will be a valid seed phrase** because the 24th word must mathematically match the checksum of the first 256 bits. To make a valid wallet phrase using physical randomness: 1. Draw **23 words** from your bag. 2. For the 24th word, you can only pick from a specific set of **8 valid words** (out of the 2,048) that satisfy the checksum generated by hashing the first 256 bits.

Cryptotiptoe21

With the official 2,048-word BIP-39 list, drawing 24 times with replacement works out to 256 bits of raw security entropy. ​The Math ​11 bits per word: The BIP-39 list has 2,048 words (2^{11} = 2,048). ​23 full words: 23 \text{ words} \times 11 \text{ bits} = 253 \text{ bits}. ​24th word breakdown: The last word contains 3 bits of user entropy + 8 bits of SHA-256 checksum (253 + 3 = \mathbf{256 \text{ bits}} total entropy). ​The Catch with "Pulling from a Bag" ​If you pull 24 words completely at random out of a bag, only 1 out of every 256 attempts will be a valid seed phrase because the 24th word must mathematically match the checksum of the first 256 bits. ​To make a valid wallet phrase using physical randomness: ​Draw 23 words from your bag. ​For the 24th word, you can only pick from a specific set of 8 valid words (out of the 2,048) that satisfy the checksum generated by hashing the first 256 bits.

ButchReemer

Theoretically. It would mean a hash collision for HMAC-SHA512, which so far has never happened and likely never will.

Downtown-Ice7534

You don’t need that. Just need a SHA256 hash implementation which you can either port in from bitcoin core codes or just use python default hashlib

opossum_cz

Yes, only the checksum. It is first 4 bits from SHA256, personally I find it bad design that checksum is unnecessarily complicated.

fllthdcrb

> trusting there isn't a bug that somehow reduces the randomness when inputing the dice rolls TBF, if you use the dice-only mode, where the seed is derived purely from dice rolls, it uses a documented algorithm for the derivation, which anyone can test. (It takes the values of the sequence of rolls, treats it as a string of ASCII digits 1–6, and runs that string through SHA-256.) I guess the mixed mode is also just as documented, but it's harder to check that one due to the source of entropy you can't control. Can there be a bug in that? Sure, but at the least, it seems like it would be easier to see such a bug than for the other methods. Just a guess, though.

Accomplished-Net1378

# Trezor Safe 3 — How the BIP-39 recovery words are generated After tracing the firmware and PC-side code, the recovery words appear to be generated from **two separate sources of entropy**: one from the Safe 3 itself and one from the PC/host software. The overall chain is: PC / HOST │ │ generateEntropy(32) ▼ PC CSPRNG │ │ 32 bytes host entropy ▼ EntropyAck.entropy │ │ USB / protocol ▼ TREZOR SAFE 3 │ ├─────────────────────────────────────┐ │ │ ▼ ▼ STM32 hardware RNG Host entropy │ │ │ 32 bytes │ 32 bytes ▼ │ int_entropy │ │ │ └──────────────┬──────────────────────┘ ▼ SHA-256(int_entropy || ext_entropy) │ ▼ 32-byte hash │ ▼ mnemonic_from_data() │ ▼ BIP-39 checksum + 11-bit word indexes │ ▼ BIP39 English wordlist │ ▼ 12 / 18 / 24 recovery words # 1. The PC generates 32 bytes of host entropy In the PC-side Trezor Connect code, `resetDevice (1).ts`, lines 61–65, the host calls: generateEntropy(32) and then sends the result as: EntropyAck { entropy } So the PC contributes **32 bytes of entropy** to the reset process. `generateEntropy()` is implemented in the PC-side entropy code, lines 9–24. It calls `randomBytes(len)` and requires a cryptographically secure random source. So: PC ↓ generateEntropy(32) ↓ randomBytes(32) ↓ 32 bytes host entropy ↓ EntropyAck.entropy The same `generateEntropy(32)` mechanism is used again during the entropy-check workflow (`resetDevice (1).ts`, lines 91–100 and 127–130). # 2. The host entropy travels to the Safe 3 The protocol contains two relevant messages: EntropyRequest ├── entropy_commitment └── prev_entropy EntropyAck └── entropy The important value for seed generation is `EntropyAck.entropy`. This becomes the firmware's `ext_entropy`. # 3. The Safe 3 generates its own entropy On the Safe 3, `reset.c` generates internal entropy with: random_buffer(int_entropy, sizeof(int_entropy)); The relevant code is around lines 288–304. `int_entropy` is **32 bytes**. The `random_buffer()` implementation for the STM32 build eventually calls the STM32 RNG peripheral. In the STM32 `rng.c`, the hardware RNG is read through: RNG->DR and `rng_get_u32()` / `rng_fill_buffer()` use those values to fill the requested buffer (STM32 `rng.c`, around lines 336–375). The generic `random_buffer()` wrapper is also shown in the STM32 RNG implementation around lines 66–85. So the device-side path is: STM32 hardware RNG ↓ RNG->DR ↓ rng_get_u32() ↓ rng_fill_buffer() ↓ random_buffer() ↓ 32-byte int_entropy # 4. The two entropy sources are combined This is the most important part. In `reset.c`, around lines 307–320, the firmware performs: SHA-256( int_entropy || ext_entropy ) In other words: 32 bytes from STM32 RNG + 32 bytes from PC CSPRNG ↓ SHA-256 ↓ final entropy The resulting SHA-256 output is stored as `secret`. So the final BIP-39 entropy is **not simply the raw STM32 RNG output** and it is **not simply the PC entropy**. It is the cryptographic combination of both. # 5. The SHA-256 result is passed to BIP-39 Immediately afterward, `reset.c`, around lines 314–321, does: mnemonic_from_data(secret, strength / 8) For the normal 256-bit case: STM32 entropy = 32 bytes PC entropy = 32 bytes ↓ SHA-256 ↓ 32-byte result ↓ BIP-39 entropy For the supported strengths: 128-bit → 16 bytes → 12 words 192-bit → 24 bytes → 18 words 256-bit → 32 bytes → 24 words # 6. BIP-39 converts the entropy into words Inside `bip39.c`, around lines 66–94, `mnemonic_from_data()`: 1. Takes the entropy. 2. Calculates SHA-256 of the entropy. 3. Takes the required checksum bits. 4. Appends the checksum to the entropy bits. 5. Splits the resulting bitstream into **11-bit groups**. 6. Each 11-bit value produces an index from `0` to `2047`. 7. That index selects a word from the 2048-word English BIP-39 word list. Conceptually: Final entropy ↓ SHA-256 ↓ checksum bits ↓ entropy + checksum ↓ 11-bit groups ↓ 0–2047 indexes ↓ BIP39_WORDLIST_ENGLISH ↓ recovery words For 256-bit entropy: 256 entropy bits + 8 checksum bits = 264 bits 264 / 11 = 24 words # Final conclusion Based on the source files traced above, the Safe 3 reset/new-wallet process uses **two entropy inputs**: 1. 32 bytes from the Safe 3's STM32 hardware RNG 2. 32 bytes from the PC-side cryptographically secure RNG (generateEntropy(32) → randomBytes(32)) Those are combined inside the Safe 3 firmware: SHA-256( STM32 hardware entropy || PC host entropy ) The resulting hash is then used as the BIP-39 entropy, which is converted into the 12/18/24 recovery words. So, in short: PC CSPRNG ───────────────┐ │ ▼ SHA-256 ▲ │ STM32 hardware RNG ──────┘ │ ▼ BIP-39 entropy │ ▼ BIP-39 encoding │ ▼ 12 / 18 / 24 words One important clarification: the **firmware hash is not the host entropy** in this chain. The host entropy is generated explicitly with `generateEntropy(32)` and sent as `EntropyAck.entropy`.

deadlock_jones

Why not just generate really hard and long password, turn it into SHA256, and use the resulting bits as private key?

TechnologyGrouchy679

You still need to hash the first 256 bits to get the final 8 checksum bits. Technically you could calculate SHA-256 by hand, it'll be very slow and must be error-free. just use an airgapped pi zero.

Fun-Analysis-182

You don't need the die to be perfectly fair. Each roll carries up to log2(6), about 2.585 bits, and the wallet runs all your rolls through SHA-256, so a slightly biased die just means each roll adds a little less than that rather than becoming predictable. It would have to be almost fully loaded, landing the same number nearly every time, to actually matter, and you'd catch that by eye. The security comes from stacking enough rolls (ColdCard asks ~99 for a 256-bit seed) and from the entropy being yours instead of the chip's, which is the whole point after this bug.

dj_destroyer

Saying "there is no relation between SHA256 and quantum computing" is simply incorrect. There are two main different reasons. Quantum comptuers can attack SHA256 using Grover's algorithm which provides a quadratic speedup for brute force search, reducing from 256 bits to 128. Sure, the biggest quantum threat to Bitcoin isn't SHA256 (its ECDSA \[secp256k1\]) because Shor's algorithm can attack elliptic curve cryptography much more efficiently than Grover attacks hash functions. But that doesn't negate quantum computing from SHA256. Saying quantum computing has no relation to SHA256 is like saying turbochargers have no relation to engines because they don't replace the engine.

opossum_cz

What? There is no relation between SHA256 and quantum computing.

Squeiner

Its not that its not safe, I don't think it would even be possible. Each word corresponds to a particular arrangement of 11 bits.  00000000000 (0) → abandon 00000000001 (1) → ability 00000000010 (2) → able etc. 23 words translates to 253 bits of information. But you need 256 bits of information to generate a checksum. So with only 23 words, you don't have the necessary requirements to generate a valid checksum. The checksum is the first 8 bits of the SHA256 hash output of a 256 bit string.  If you put a 253 bit string thru a SHA256 hash function,  you will not get a valid checksum. You need a full 256 bit string in order to do this.

Squeiner

The checksum is deterministic. You don't choose it. It is always the first 8 bits of the SHA256 hash of your original 256 bit string. Hardware wallets simply calculate it for you. Using a hardware wallet to calculate this checksum is perfectly safe. There is 0 entropy that goes into the checksum anyways. But also, im not sure you can generate it with just 23 words, because you're missing 3 bits that way. The checksum is only 8 bits, and each bip39 word corresponds to 11 bits. So you need the full 256 bit string, which gives you 23 groups of 11 bits each, plus 3 extra bits. Then you add the 8 bit checksum, and together with those 3 extra bits you get the last 11 bits, which correspond to the 24th word.

Squeiner

Great question. For this you need yo understand what a Hash function is, and then understand a bit about the specific SHA256 hash function. If you don’t, go do that first. Once you’ve flipped your coin and you have your 256 bit string, you turn it into a 64 digit hexadecimal string. Then you put this 64 digit hex thru a SHA256 tool (or multiple ones if you’re extra paranoid). It's crucial that this tool has Hexadecimal input, not text input. If you look at this tool here: [https://pi7.org/hash/sha256](https://pi7.org/hash/sha256) Below the input box, there’s a dropdown box where you can select "Text to SHA256" , or "Hex to SHA256" The type of input changes the output so it's important to use Hex to SHA256. Once you have your output, which will also be in hexadecimal, the first 2 digits of that output is your checksum. So you simply add those first 2 digits to the end of your original 64 digit hex string. And Voila, you now have a 66 digit Hex string which is a full and complete seed including the checksum. A bit context, the checksum is the first 8 bits of the SHA256 hash of your original 256 bit string. When represented in Hex, these first 8 bits are represented by the first 2 digits, each digit corresponding to 4 bits. The 256 bit string, the 64 digit hex, its all the same information, just represented in a different notation or language. You can imagine the concept of the number "1”. In English its “one”, in Spanish its “uno”, in French its “un”, in Hindu–Arabic numeral system, its “1”, in Roman numeral system its “I”, but all of them mean the same thing. It’s the same thing here. Binary is a language, hex is a different language, but you are saying the same thing in both languages, and you can go back and forth between the 2 languages and all the information will always be identical. So when you have your 66 digit hex string (which includes the checksum), you can turn the whole thing back to binary to get a 264 bit string. This string can be broken up into 24 groups of 11 bits each. And each word on the BIP39 list of seed words corresponds to a particular arrangement of 11 bits. 00000000000 (0) → abandon 00000000001 (1) → ability 00000000010 (2) → able etc. So you can then translate your 264 bit string into a seed phrase.

GoldmezAddams

Basically zero. There are roughly 2^256 possible wallets. That's 115,792,089,237,316,195,423,570,985,008,687,907,853,269,984,665,640,564,039,457,584,007,913,129,639,936 possibilities. The Coldcard search space is around 2^40 or 1,099,511,627,776 possibilities. Compared to 2^256, that number truly might as well be 1. Defining any narrow search space like that and exhaustively searching it is not an attack on 256 bit security. In 25 years, even with the BTC network currently calculating almost a sextillion hashes a second, not a *single* SHA-256 collision has *ever* been found. They could check 2^40 wallets *every second* until the sun goes out and it would be an absolute statistical *miracle* if they found even one active key. At that rate it would take on the order of 10^57 years to exhaust the search space. The age of the universe is on the order of 10^10. That assumes proper entropy, though.

atanasius

You can also append all results one after another and take a hash like SHA256. This will give a decent result as long as there is some randomness in each roll.

EriksonThorsen

The reason you got different results between the two options in Ian Coleman's tool comes down to how the dice rolls are processed into entropy: How the math works under the hood: When you select Dice \[1-6\] in Ian Coleman's tool, it treats your rolls as a base-6 number and directly uses the bits derived from that. Coldcard, on the other hand, takes the exact string of your dice rolls (e.g., "123456...") and runs it through a SHA-256 hash function, using the resulting 256-bit hash as your entropy. When you selected Hex \[0-9A-F\] in Ian Coleman's tool, you were likely entering the hashed output or a raw bit representation that lined up with Coldcard's calculation method. Number of rolls (125 vs 155+): Each roll of a standard 6-sided die yields about 2.58 bits of entropy (log2 (6) ≈ 2.58). To reach full 256-bit entropy mathematically, you need about 100 rolls (100 × 2.58 = 258 bits). Coldcard's recommendation of 100+ rolls is mathematically sound for 256 bits of security. The 155–160 roll recommendation is just extra buffer to ensure there's zero doubt about bias or short rolls, but 125 rolls is already well above the required 256 bits. You don't need to redo it or roll more.

GoldmezAddams

No. With proper entropy, the amount of possibilities is simply too big. The whole problem was that CC's lack of entropy created a very limited search space. The odds of a non-Coldcard producing anything within that search space are astronomically low simply because of the amount of possible options. With proper entropy, there are roughly 2^256 options. That's 115,792,089,237,316,195,423,570,985,008,687,907,853,269,984,665,640,564,039,457,584,007,913,129,639,936 options. The Coldcard Mk3 search space is around 2^40 or 1,099,511,627,776 options. Compared to 2^256, that number might as well be 1. For some context on 256 bit security, in 25 years, not a *single* SHA-256 collision has *ever* been found, even with the BTC network currently calculating around a sextillion hashes per second.

fllthdcrb

Yes, but it works just as well, and is simpler. It's just... more tedious. But the tricky part either way is computing the checksum. As the article you linked to says, SHA-256 can be calculated by hand, but it's *very* tedious and time-consuming. It really benefits from a computer, but you want to be very careful about the environment you do it in for this purpose. Incidentally, Coincard has a built-in facility that accepts dice rolls, though instead of mapping values directly to bits of the seed, it takes the sequence of rolls as a string of ASCII digits 1–6, and runs it through SHA-256 (or at least, this is what it does if you use the dice only mode). More computationally intensive, but also requiring fewer rolls.

GoldmezAddams

You can and should verify that the Coldcard produces the correct seed from dice. They have instructions in the manual, but basically, take your string of rolls, run it through SHA256, and then follow the procedure outline in BIP39 to turn it into a seedphrase. There are scripts and websites to do it for you. Then, obviously don't use whatever you punched into the script / website. Wipe the seed and do it for real. Or test it 1-5 more times to make sure they don't only make a fair seed the first time ;) I see why people would just never touch the device again. I also see why people would shelf the device until the dust settles and the code's gotten more scrutiny. In the end, it's probably still fine as a signing device as long as you never use the onboard entropy.

GoldmezAddams

People are bad at generating their own randomness. Just picking words is like the worst way to go. The proper way to make your own would be to flip a coin (0 = heads, 1 = tails, or vice versa), roll dice (1-6), or draw playing cards (rank \* 4 + suit, where Ace-King = 0-12 and suits are 0-3, returning the card and thoroughly shuffling every time). 256+ coin flips, 100+ dice rolls, or 45+ card draws. Take the resulting string (flips would look like 10010110101110..., dice would look like 312365413.., etc) and put the whole thing through SHA256 on an always offline computer, probably running something like Tails or another Linux live environment (or by hand if you were *really* motivated and paranoid). Then follow the procedure outlined by BIP39 to convert the resulting 256 bit number into a seed phrase. This is probably not the best way for the average Joe. It is so easy to shoot yourself in the foot. But it is doable for a motivated, slightly technical user. Ironically, Coldcard was one of the best hardware wallets precisely because it made producing a seed from dice rolls (and verifying that there was no funny business in that process) so easy. Coldcard is probably actually still a good option for that, but it is hard to actually recommend because trust is so completely gone. But anyone that set theirs up this way still have their funds. The average Joe that wants to self custody should honestly probably just move to something like Trezor and add a *strong* passphrase. Anyone who set up their Coldcard this way *also* have their funds (but are in a lot more danger than the guy that rolled dice). For advice on picking a strong passphrase, [https://xkcd.com/936/](https://xkcd.com/936/)

EriksonThorsen

For skipping tools entirely, yeah you can do the whole first 23 words with just dice and a lookup table, no computer involved at any point. A few ways people do this: * Use combos of dice that map directly to a number between 1 and 2048 (like one 20 sided die plus one 100 sided die, or a few smaller dice combined) and just look up that number on a printed, numbered BIP39 word list. No math, no conversion, just roll then look up the matching row. * There are pre-made printable dice tables (if I'm not wrong, Valerio Vaccaro has one floating around, also one from a guy going by [veebch on GitHub](https://github.com/veebch/Bip39-Dice)) that map specific roll sequences straight to a word, so you're not even doing lookup math, just matching symbols on paper to a table. * Some people use 5 rolls of a single 6 sided die per word and convert that to a number by hand using base 6 math, but honestly this is where mistakes creep in if you're not comfortable with the arithmetic, so the direct lookup table method is way less error prone for a non programmer. The one spot where pure pen and paper hits a wall is the 24th word, because that involves a SHA-256 hash, and there's no reasonable way to do that by hand, it's not like normal arithmetic, it's designed to be computationally annoying even for computers. The workaround most people use here doesn't require trusting a random tool though, it just uses the wallet itself. Devices like Coldcard, Trezor Safe 5 and SeedSigner let you punch in your dice rolls directly on the device screen during setup, no separate computer or software needed, and the device calculates and displays the resulting words. Since you're going to trust that wallet to hold your funds and derive your addresses anyway, this isn't really adding a new party into the mix, you already have to trust it at some point. If you want to avoid even that, another option is writing down your first 23 words, then during wallet restore just try entering candidate 24th words one at a time. The wallet will flat out reject the ones that don't pass the checksum, and only 8 out of 2048 will actually work, so you're not guessing forever, it narrows down fast. Roll a die to randomly decide which of those valid options you use if you want to keep it fully non deterministic. So overall your instinct that the initial shuffle is the actual risk factor is correct, that's really the crux of it. Fixing that means uniform slip size, aggressive random mixing, and drawing with replacement and remixing every single time rather than pulling from a static pile.

xiskghferx

You just calculate SHA256 by hand using calculator 😁

xiskghferx

You didn't read, what I wrote! Python script just takes inputs from my dice throws, transforms to bin, perform SHA256 and calculate checksum. You can follow all procedure but SHA256 and verify by hand if seed word are correct.

Classic_Storage8505

They use different approaches and will produce different seeds. **Coldcard/Seedsigner:** SHA256-hashes the exact roll string and uses the hash as entropy. **Ian Coleman:** Treats the rolls as a base-6 number and uses the resulting bits directly

xiskghferx

Also, you can throw your 128bit entropy with dice totally offline on paper, OK. But, then you NEED some device or sofware to calculate the checksum and define the last word! You cannot calculate SHA256 by hand and calculator. How you are supposed to do this? Yes, you can use Python on offline PC to do this, but it suddenly becomes much more complicated.

Wolffco

Coldcard uses SHA256 of all dice inputs combined, not per-roll entropy math. The display warning is conservative guidance, not the actual calculation method.

GodsMoney_Ape

You should test the seed generation on another device. It’s not magic. Input string of dice rolls, SHA 256 it, compute checksum, look words up in list. Compare to the hardware wallet output.

EyesFor1

100 rolls produce 256 bits of entropy which is what SHA-256 uses. Additional rolls don't add extra entropy because SHA-256 uses 258 bits of entropy. 2048 roll would add nothing extra

lifeanon269

Well now I know that's not the process you followed. I just reviewed the code to Ian's tooling and CoinKite's, and Ian's tooling doesn't follow the same program logic as ColdCard's. ColdCard's methodology runs the dice rolls as an ASCII string through SHA256 and uses that output as the entropy for generating the BIP-39 seed phrase. Ian Coleman's tool takes your dice rolls as input and uses them as base-6 digits into a raw binary input as entropy directly. So no SHA256 there. So you'd HAVE to use ColdCard's method as described on their website here to validate their hardware's output. You can't use Ian Coleman's BIP-39 tool for this. https://coldcard.com/docs/verifying-dice-roll-math/ So it seems like now you're just making stuff up. There is nothing wrong with running test inputs first, but there are absolutely pitfalls with that as well if you don't actually end up testing your actual results too. For example, you wouldn't know if ColdCard is truncating your input if you only test with say 20 dice rolls for your test, but perform 50-100 dice rolls for your actual seed. There are other pitfalls as well, which is why it is advised to validate your actual dice rolls if you don't any trust in your hardware.

pako-bitbox

Hi thanks for the tag! We reviewed the audit and the claim of 3 entropy sources seem to just be a mistake by the LLM. As you can see in section **2.5 Seed Generation** it shows a block of code, more specifically this our seed entropy generation code which you can find in our Github here: [keystore.rs # Line 557](https://github.com/BitBoxSwiss/bitbox02-firmware/blob/c838d7fd80190a02531ba30e4a904240e4485e1f/src/rust/bitbox02-rust/src/keystore.rs#L577) There are more entropy source than just this, one our engineers explains it: 1. This function queries the secure chip for entropy and calls another function: [ random.rs # Line 32 - Line 41](https://github.com/BitBoxSwiss/bitbox02-firmware/blob/master/src/rust/bitbox-core-utils/src/random.rs#L32-L41) (total entropy sources: 1) that other function queries the MCU trng for entropy, and mixes with the secure chip entropy and factory randomness: [random.rs # Line 9 - Line 30](https://github.com/BitBoxSwiss/bitbox02-firmware/blob/master/src/rust/bitbox-core-utils/src/random.rs#L9-L30) (total entropy sources: 3) and the above function is called here, where host entropy and user password are finally mixed in as well: [keystore.rs # Line 577 - Line 608](https://github.com/BitBoxSwiss/bitbox02-firmware/blob/c838d7fd80190a02531ba30e4a904240e4485e1f/src/rust/bitbox02-rust/src/keystore.rs#L577-L608) (total entropy sources: 5) So it's SHA-256( secure chip TRNG xor MCU TRNG xor factory entropy) xor host entropy xor user password entropy Hope this helped, we will be adding comments to the code to prevent this confusions in the future!

Charming-Designer944

The checksum is calculated using SHA256. While entirely possible to do offline, its beyond what you can do using a normal pocket calculator or pen and paper. You practically need some kind of offline computing device (computer, old phone, hard Bitcoin signing device with support for cehcksum generation). What you can do is to try the possible choices of the last wo words. In a 12 word seed the checksum is only 4 bits meaning you only have 16 possible words to test after filling the entropy bits, and this can be tested quickly using the recovery function of your wallet until you find the right word. In a 24 word seed the checksum is 8 bits which results in 256 differen possible last word to find the checksum. Not impossible, but also not something most people would accept doing.

InevitableSalty4366

Create your own paper wallet. Use coinflips, use dicerolls, count the number of different coloured cars. Be your own rng. https://www.bitaddress.org/bitaddress.org-v3.3.0-SHA256-dec17c07685e1870960903d8f58090475b25af946fe95a734f88408cef4aa194.html

brtastic

Also, not a widely known fact - BIP39 mnemonic-to-seed does not actually calculate the entropy back from your words. It performs PBKDF2-SHA512 on your words plus your passphrase to get the seed, which is then turned into a master key. Checking the checksum of the mnemonic is not critical here - there may be software that does not check it at all and simply turns your words into a seed. Mnemonic with a bad checksum will still produce a valid wallet unless the checksum is checked explicitly and the process is stopped. You may want to check if you can import a mnemonic with faulty checksum - if you can, you don't need to calculate 24th word, just randomize it same as the rest of the words.

InitiativeScared6583

using System; using System.Text; using System.Security.Cryptography; using NBitcoin; class Program { static void Main() { // 1. Define the source string you want to use to generate the wallet. string mySecretString = "This is my ultra secret string that no one can guess 2026!"; // 2. Hash the string using SHA-256 to get exactly 32 bytes (256-bit) of data. byte\[\] hash256; using (SHA256 sha256 = SHA256.Create()) { byte\[\] stringBytes = Encoding.UTF8.GetBytes(mySecretString); hash256 = sha256.ComputeHash(stringBytes); } // 3. Use the resulting 256-bit data to generate the Private Key. // (This process applies the secp256k1 Elliptic Curve equation.) Key privateKey = new Key(hash256); // 4. Derive the Public Key from the Private Key. PubKey publicKey = privateKey.PubKey; // 5. Convert to a Bitcoin Address (Native SegWit format). BitcoinAddress address = publicKey.GetAddress(ScriptPubKeyType.Segwit, Network.Main); // --- Display the results --- Console.WriteLine("Original String: " + mySecretString); // WIF (Wallet Import Format) is the Private Key encoded in Base58Check // so it can be easily imported into other wallet software. Console.WriteLine("Private Key (WIF): " + privateKey.GetWif(Network.Main)); // Hex format represents the raw Public Key in hexadecimal. Console.WriteLine("Public Key (Hex): " + publicKey.ToHex()); // The receiving Bitcoin address. Console.WriteLine("Bitcoin Address: " + address.ToString()); } }

NoKillNoSkill

2028 - i understand the weakness of SHA-256 leading to be cracked by first secret quantum processors which accumulated enough cracked private keys to execute a mass drain wave...

Laukess

Fair enough. No way in hell I would have a setup that was not tested, but I guess some people might want that. I also have no idea how you would generate an address from a private key without a computer, but it's probably possible. You have to work out the public key from the private key, and then hash it with SHA256? And then trust that you didn't make any mistakes and just send bitcoin to it? Haven't looked into this at all, might not be an issue. Don't really know the process.

na3than

do SHA256 <- do that safely, securely, privately, and with zero risk that malware has corrupted your tools or captured the output compute checksum <- do that safely, securely, privately, and with zero risk that malware has corrupted your tools or captured the output Easy peasy, right?

GodsMoney_Ape

Why not dice? Roll 100 D6, write the string down, do SHA256, compute checksum and append to hash, get 264 bits. Derive the 24 words by 11 bit-splits (264 / 11)

EyesFor1

You don't need to, you can if you want extra peace of mind. The firmware update is the same for every single coldcard updated. There are many many eyes on the firmware patch, more than ever. Following the vulnerability disclosure, security researchers (including teams like Wizardsardine, Core-Lightning contributors, and independent cryptography auditors) conducted line-by-line reviews of the patch commits across Coinkite's open-source posts. They have confirmed that the device directly calculates the SHA-256 hash of the user's physical dice input array without relying on or blending with internal device generators. You are safe with a dice roll of 50+ but do 100+. #

pantuso_eth

Quick question: Do you understand the Bitcoin protocol? Can you provide me a proof of work on your post using a double SHA256? Dude, I get it. People rush in without understanding everything, but at some point each person has to trust the parts they don't know and take a leap.

Youknowimtheman

It could probably do it if it was hot wallet somewhere, and the attacker knew where that somewhere was. Giving it a transaction is telling Anthropic to go break SHA-2.

RetiredAvocado

"Your own solution" is mentioned and discouraged for many good reasons. QC is more of an issue for ECDSA not SHA256.

opossum_cz

I know that. But it is infeasible. I wrote SHA 256 implementation myself several times, it is not even long, but probability you make an error by hand is extremely high.

Oxymorix

Using your hypothetical numbers, the rough brute-force work factors do multiply: (2\^{40}) possible mnemonics × (2\^{20}) possible passphrases = (2\^{60}) mnemonic/passphrase combinations. So, expressed logarithmically, you could describe the combined search as roughly 60 bits—provided the mnemonic and passphrase were independently and uniformly generated and the attacker must search both. However, the passphrase does not literally add entropy to the original 12-word mnemonic. BIP39 uses the mnemonic and passphrase together through PBKDF2-HMAC-SHA512 to create a completely different wallet. Every possible passphrase produces a valid wallet. The existing comment saying that security would rely “only on the password” is therefore too absolute. That becomes true only if the attacker has already identified the exact underlying mnemonic. If the attacker merely knows that the mnemonic lies somewhere within a (2\^{40}) vulnerable space, they generally still need to test the Cartesian product of mnemonic and passphrase candidates. There are two important qualifications: 1. Two randomly selected words from a 1,024-word list provide only 20 bits. That is a very weak passphrase if the mnemonic is ever identified. A million possibilities can be searched very quickly. 2. The current Coinkite estimate is not 40 bits for the Mk5. Coinkite presently estimates approximately 40 bits for affected Mk2/Mk3 seeds and approximately 72 bits for Mk4, Q and Mk5 under its current assumptions. Those estimates are preliminary and may change. Therefore, using Coinkite’s current Mk5 estimate and your hypothetical 20-bit diceware passphrase, the naïve combined ceiling would be approximately (72 + 20 = 92) bits—not 60 bits. But I would not recommend relying on only two diceware words, because any future discovery that narrows or reveals the mnemonic would leave only 20 bits protecting the wallet. So the basic “bits add” intuition is broadly correct for the combined independent search space, but it should not be interpreted as the passphrase strengthening the mnemonic itself, and the result is only as reliable as the assumptions behind both entropy estimates.

opossum_cz

For seed phrase? Flip a coin 128 times and write 0 and 1 for each flip. Split it into 16 groups of 8 bits (first bit is leftmost), each 8 bits is a byte, so you have 16 byte string. Do SHA256 on it and take first 4 bits. This is the hardest part, it is for checksum. There are most likely a simple programs that can be verified that would do this for you. Append those 4 bits to the original 128 bits, so you have 132 bits. Split 132 bits into groups of 11 and look up words: [https://bip39wordlist.net/](https://bip39wordlist.net/) BIP-39 has 2048 words, each represents 11 bits.

NamedBird

>Another alternative would be for the white-hat to sweep all the vulnerable funds first, but then how could they return them? Once the flaw is public, *a signature from the compromised key* ***no longer proves legitimate ownership***, since an attacker can derive the same key. Isn't it obvious? You do this ahead of time! Add the SHA256 of the following example file as a first transaction to the wallet: === Bitcoin wallet ownership claim === Wallet: 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa Real name: John Doe Birthdate: 1992-03-15 Nationality: United States, Texas Random: f6a11a3b9fda2c57a0ecb63b98b1501cd0c413bd04ac1932b64f41abb4e01687 Random: 45dac25943e4fdbd5c0b465da5448099e5b06e12db5d1e6ffeb1a6e00f3963fc Keep that file just as secret and hidden as your seed phrases. Due to the randoms (different sources, mash keyboard if necessary) nobody is going to crack it. If something ever happens to the wallet or coins, this file proves your original ownership. Pray that you'll never need it

TheQuantumPhysicist

Biased is a measurable factor, it's not binary (true/false). You measure it with probabilities. Biased will give you skewed results. I gave upper bounds for the skew in my calculations in the post. You can do everything by hand, but it's unreasonable and takes too much work. There's a guy who calculated a SHA-256 hash by hand. Took him a day of work, IIRC. What you need is an offline device to do tedious calculations for you, outside of generating entropy.

Swimming_Eye7220

On why an attacker would bother with the passphrase at all: the reason it's cheap for them is BIP-39 itself. Deriving a wallet from seed + passphrase runs PBKDF2-HMAC-SHA512 at only 2048 iterations, which is almost no key stretching. Once someone already has your seed, testing millions of candidate passphrases against it costs very little. An empty base wallet from a seed they already know is weak isn't a dead end for them, it's a hint that funds may be sitting behind a passphrase. Worth knowing the experts split on how much a passphrase buys you. Coinkite treats a strong unique one as protection for the funds behind it. Wizardsardine's independent write-up says treat it as insufficient, for exactly the reason above. Either way it doesn't repair the seed underneath, so migrating to a freshly generated seed is still the move. Disclosure: I run [bitcoinerreviews.com](http://bitcoinerreviews.com) and put together [https://bitcoinerreviews.com/coldcard](https://bitcoinerreviews.com/coldcard) with the per-model firmware breakdown and a checker that never asks for your seed. Mentioning it because fake checkers that do ask for seed words are circulating right now.

dj_destroyer

Quantum computing breaking SHA256 won't just affect Bitcoin obviously -- the whole world will experience the consequences. Bitcoin will likely be able to pivot (fork) faster than anything else.

Cheesegasm

It'll take millions and millions of years to hack BTC with traditional computers. You'll need a quantum computer to break SHA-256 cryptographic hash function and when that happens every password and bank account will be compromised as well.

jwhendy

What do the notes on the Seedsigner actually mean? I commented on X a day or two ago, but don't have much activity there and think my comments might not be showing up. I don't know if any of these are good or bad: - "no device SPRNG (grep-verified)." I think this is good/by design, you don't need an RNG since you supply the seed every time - "Camera: SHA-256 chain of s50 preview frames + final photo + serial/timestamp → 128/256 bits." Is this about using the photo-entropy approach? Or the QR codes? - "Dice: SHA-256 of 50/99-rol1 string, no mixing, no bias check (degenerate rolls accepted by design)." Is it good/bad to accept "degenerate rolls"? - "No automated camera check - check is user-visual (live preview + accept/reshoot)." What does that mean? Like if you thought you were taking a picture with sufficient detail, but someone hacked the camera to take a fully white picture, it's on you to compare what you think you photographed for entropy vs. what it shows?

rockorangebear

The whole security model of having a SHA256 key is that it's 256 bits of entropy... the Coldcard key was 32 bits, which is astronomically times less secure (2.69e+67 times: essentially a trillion times a trillion times a trillion times a trillion times a trillion). So it was your "key", but you really got a shitty knockoff/pretend key.

markasoftware

This image is for the "bcrypt" hash algorithm which is NOT what BIP39 wallets use. BIP39 hashes the seed together with the passphrase using PBKDF2-HMAC-SHA512, which I believe is about 100 times faster than bcrypt on an rtx 5090. So you need to divide all the times in the table above by 100 (ie, you need a longer passphrase than this image suggests).

markasoftware

the worse thing is that bip39 doesn't even use bcrypt, just PBKDF2-HMAC-SHA512 with 2048 rounds, which is about 2 orders of magnitudes faster than bcrypt.

brtastic

That's not connected to bitcoin at all. This is for bcrypt 10 (1024 rounds, rather low cost value), which requires different operations than cracking bitcoin wallet passwords. BIP39 passphrases requires multiple ECDSA operations, HMAC-SHA512, PBKDF2-SHA512 (2048 rounds), but most importantly a check against the blockchain to see whether the resulting wallet got any transaction history.

Rtxenjoyer

If you are determined to have the most secure hardware wallet setup, here is a surface level guide. For maximum security, I would recommend SeedSigner and assembling it yourself. Buy the parts, such as the Raspberry Pi board, camera, and display, from reputable vendors. If you are really paranoid, buy each part from a different vendor. Do not buy a prebuilt SeedSigner, as that defeats the purpose of building it yourself with off-the-shelf parts. Nobody will know that you are using the parts for a Bitcoin wallet. The best board is the Raspberry Pi Zero 1.3 because it has no built-in Bluetooth or Wi-Fi, but it is harder to find in stock. If you buy the Raspberry Pi Zero W, there is a guide on GitHub showing how to physically remove the Wi-Fi and Bluetooth capabilities. When it is time to flash the SeedSigner OS onto the SD card, make sure you download the latest release from GitHub, along with the SHA-256 files, so you can verify it. You can also verify the SeedSigner PGP fingerprint from different sources, such as Keybase, to confirm that you have the authentic SeedSigner OS. Before creating your seed using the dice method, which I recommend, you can verify that the dice inputs are correct using the iancoleman website. This allows you to confirm that SeedSigner outputs the correct seed from the numbers you enter. When you have fully built the SeedSigner and are ready to create your seed. Use casino dice, preferably, or multiple dice. Roll them 99 times and write down the order on a piece of paper. Then enter the dice rolls into SeedSigner multiple times to make sure you get the same seed every time. You can then store the numbered sequence on paper instead of storing your seed words. For a bad actor, it would be much harder to recognize that it represents a seed phrase containing your Bitcoin. For maximum security, also add a complicated passphrase and store it separately from the numbered sequence. For additional security, you could set up multisig using wallets from other vendors as well, but I will not go into that.