SHA

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.

FigAggressive237

Yes he could have, why are you assuming that? This hack in particular lowrs the seedphrase's entropy from 2\^128, to 2\^40 and 2\^72 depending on the firmware , but this is an upper bound I believe If its remotely close to 2\^72, its still safe-ish . I do think that each guess requires PBKDF2-HMAC-SHA512 (2048 rounds) plus elliptic-curve point derivation to check if it produces the target address. Check how much power you need to derive such seephrase .

FigAggressive237

Yes he could have, why are you assuming that? This hack in particular lowrs the seedphrase's entropy from 2\^128, to 2\^40 and 2\^72 depending on the firmware , but this is an upper bound I believe If its remotely close to 2\^72, its still safe-ish . I do think that each guess requires PBKDF2-HMAC-SHA512 (2048 rounds) plus elliptic-curve point derivation to check if it produces the target address. Check how much power you need to derive such seephrase .

Lefties_TheWorst7331

Quantum computing is right around the corner? 😅 You need to do some more research.. Quantum computing is like 0% towards cracking SHA256..

locustsandhoney

Most implementations of dice have you provide the dice roll results into the hardware or software wallet and it will simply use them as entropy factors. The dice rolls are not actually producing the seed, just providing entropy. It’s not realistically possible to produce all 12 / 24 words entirely with dice alone. I mean technically you can calculate SHA-256 by hand but no one is doing that.

riscten

Ultimately Bitcoin is about taking responsibility over your own money and asset. That's the entire point. That's what no other form of digital money affords you. Being your own bank means you have to do the legwork of understanding how the tech works. Here nobody is asking that you can derive your own SHA-256 by hand. Just the fundamentals of not blindly trusting anyone who claims that they can generate your keys for you. There is no place for trust in Bitcoin, and blaming companies like Coinkite serves no productive purpose. This is also why wallets with proprietary code such as Ledger are a no-go.

ToRedSRT

**The Ledger Standard: Ledger devices generate 256 bits of entropy directly from an AIS-31 certified True Random Number Generator (TRNG) inside their ST33 Secure Element chip.** **Mathematically, 256 bits of hardware TRNG entropy and 100 precision dice rolls hashed via SHA-256 offer identical cryptographic strength**

magma_lakes

Every Bitcoin address is generated from a private key, which is just a really large 256-bit number. This could be a private key, for example: \`d7cd482cb958ef235f5d26e852472ba1ee5309eab18e3c6712181a7bfae80000\` The address corresponding to the above private key is: \`bc1qhz95gehw8sj99cz9p5ya4ja2agk3unhskvl8lk\` Given that there are almost 2\^256 private keys, someone guessing your private key (if generated correctly) is the equivalent of someone picking correctly one particular atom out of the entire observable universe. However, if there is some flaw in the generation of the private key, then even though it might look "random", it doesn't mean it is. If it was generated from a poor source of entropy, then it is easier to brute force. For example, that private key I pasted above is literally the SHA-256d hash of the string "private key". Therefore, even though it "looks random", it isn't.

RetiredAvocado

Not that crazy. How old is your phone? When you see a device getting abandoned you upgrade from it. If you don't like how long it lasts buy a different brand. You're going to trust a security device for 23 years? Seriously? Let's look at what got basically obsoleted over that long. MD5, SHA1, RC4, 3DES, RSA with keys below 2048 bits, and even "post quantum" HAWK got hit this year. Yes bitcoin has its own specific algos but still. It's not set it and forget it. You have to keep up. And yes you have to buy better and newer hardware if that's what you want to entrust with your own money.

Lumpy-Doubt-4023

Example: Choose 3 secrets, with 3 hints. Example of (shitty) hints/secrets: "the song", "the person", "the move", corresponding to the secrets "billy jean", "michael jackson", "moonwalk". Of course, that needs to be seriously harder to guess than that. Choose a salt, like "johndoe42" Choose a large (but not too large) number, like 457 214 120. Choose a hash function, for instance PBKDF2-HMAC-SHA512 The seed for the private key is then PBKDF2-HMAC-SHA512( pass="billyjeanmichaeljacksonmoonwalk", salt="johndoe42", dklen=32, num\_iter=457214120 ). You can then write all the informations, except for the secret, in many places, as a public information. As long as your secrets are hard enough to discover from the hints you're good. Each attempt to generate a seed from guesses costs a fraction of a cent (that's why the number is in the hunudreds of millions), so as long as you don't store millions, no one will even attempt to break it. Or they'll be too dumb to try, or they'll be clever enough to understand there's not enough money in the wallet to justify spending hundreds of thousands worth of electricity breaking your encryption scheme. An AI can guide you though this. It also requires you to have an airgapped computer, basic software knowledge to run a script (the one that transforms your secrets into your seed and into your wif). It's not trivial, far from it, and should not be done if you don't understand the underlying principles because you'll probably overlook something. I can show you, publicly, the script I use that does the steps above (takes the secrets and outputs the wif), so you can give it to an AI for a more detailed explanation. But as said above, if you don't understand what each thing does you should not do it.

_Carth_Onasi

Waiting for an official response from them but from what I can tell they aren't effected. I generally hate ai but: Trezor’s entropy generation differs significantly from Coldcard’s in its multi-source design.How Trezor Generates EntropyTrezor deliberately avoids relying on a single source of randomness. When creating a new wallet:It requests entropy from the host computer or phone (via the operating system’s cryptographically secure random number generator, typically 256 bits). It combines this with entropy from the device’s own hardware True Random Number Generator (TRNG) in the main microcontroller (STM32). The two (or more) sources are mixed (usually via hashing such as SHA-256). Newer models add further independent sources:Trezor Safe 3 and Safe 5 — add entropy from the Optiga secure element (three sources total). Trezor Safe 7 — adds a fourth source from the TROPIC01 chip. Trezor Suite also includes an entropy check feature that generates, discards, and regenerates test wallets to verify the randomness process is working correctly.This design means that even if the device’s internal TRNG is broken or compromised, the host-provided entropy can still produce a strong seed (and vice versa).How This Differs from ColdcardColdcard’s normal approach is more device-centric and air-gapped focused:It primarily uses its own hardware TRNGs (microcontroller + secure elements), with the output whitened (e.g., via SHA-256). Users can optionally mix in or fully replace this with physical dice rolls (a strongly promoted feature). By design, it does not pull entropy from a connected host computer during seed generation. This aligns with its threat model that assumes the computer may already be compromised. The recent Coldcard Mk3 issue (firmware roughly 4.0.1–5.0.3) was a specific implementation bug: the hardware RNG was effectively bypassed due to a configuration/library error, falling back to a weak, predictable software PRNG seeded from non-secret data (chip UID, timers, etc.). This produced seeds with far lower effective entropy than intended. Later Coldcard models (Mk4, Q, Mk5) were reported as unaffected or far less impacted.Is Trezor Safer Than Coldcard?Regarding the specific entropy failure mode that hit Coldcard Mk3: Yes, Trezor’s multi-source design makes that particular class of bug much less dangerous. An attacker would need multiple independent sources to fail simultaneously for the seed to become weak

TheOnlyVibemaster

Hardware wallets are a very bad idea because you’re trusting that someone won’t mess up, which in crypto is a bad bet. This has existed since Bitcoin was made and can generate an address without an internet connection: https://www.bitaddress.org/bitaddress.org-v3.3.0-SHA256-dec17c07685e1870960903d8f58090475b25af946fe95a734f88408cef4aa194.html There is a such thing as a public address, which is what I meant to say. Burying was a figure of speech

genius_retard

I have been wondering if one of the new AIs might find an exploit in SHA256 or something and start emptying wallets.

ConcentrateJolly5461

You are completely misunderstanding the math of SHA-256. Even if computing power increases exponentially over the next 10 years, guessing a hidden private key behind a SHA-256 hash by making millions or trillions of attempts per second is mathematically impossible. To put it in perspective, if you turned every single atom on planet Earth into a supercomputer capable of making trillions of guesses per second, it would still take longer than the remaining lifespan of our universe to find a single correct hash. Quantum computers don't solve cryptography by just "guessing faster." They use Shor's algorithm to exploit the specific mathematical shortcuts in public key cryptography (like ECDSA/RSA). But against double-hashing (SHA-256 and RIPEMD-160), Shor's algorithm has no shortcut. Unexposed Bitcoin addresses are completely immune to quantum computers because "guessing" your way through a hash is a physical impossibility.

bitusher

CPUs < GPUs < FPGAs < ASICs SHA256 ASICs are special chips whose entire design is to mine Bitcoin as efficiently as possible. They can't do anything else but hash double rounds of SHA256 . This specialization makes them a single purpose tool that is incredibly efficient

TheGreatMuffin

> So it would be more feasible if you targeted a small alt coin? From what you are saying, you cannot ‘create’ money but you could deposit a large amount in your account, then double-spend? Yes, that's correct, it'd be possible in theory and easier to do with smaller altcoins that are not protected by a lot of hashpower or which have implemented some other mechanisms to protect themselves instead of SHA256 hashing.

theveganite

SHA256 will never be easily bruteforceable. SHA256 isn't the issue anyway. ECDSA is the issue. 

xcommon

Impending PoW change? From SHA-256? To what?

oak1337

The 4 Keys to Post-Quantum and Hedera's current state + Roadmap: **Hashes** - SHA384 (Post-Quantum). Most/all other chains use SHA256 (*probably* Post-Quantum) **Encryption** - AES256 (Post-Quantum) **Key Agreement** - Currently TLS (not Post-Quantum), will be upgrading to ML-KEM (waiting for libraries update) (Post-Quantum CRYSTALS-Kyber). **Digital Signatures** - Currently ECDSA and Ed25519 (not Post-Quantum), will be upgrading to Falcon Signatures (Post-Quantum)(when NIST approves).

oak1337

The 4 Keys to Post-Quantum and Hedera's current state + Roadmap: **Hashes** - SHA384 (Post-Quantum). Most/all other chains use SHA256 (*probably* Post-Quantum) **Encryption** - AES256 (Post-Quantum) **Key Agreement** - Currently TLS (not Post-Quantum), will be upgrading to ML-KEM (waiting for libraries update) (Post-Quantum CRYSTALS-Kyber). **Digital Signatures** - Currently ECDSA and Ed25519 (not Post-Quantum), will be upgrading to Falcon Signatures (Post-Quantum)(when NIST approves). Dr. Leemon Baird describes the whole process in this clip 👇 https://www.reddit.com/r/Hedera/s/dfc39cn6Mb

S1eeper

\> Hedera should be Post-Quantum with ML-KEM (waiting on libraries) and Falcon Signatures (waiting on NIST) by 2027. Add that Hedera is already SHA384 and AES256, both Post-Quantum. If it's already post-quantum with SHA384 and AES256, why does it need ML-KEM and Falcon?

AutoModerator

Post is by: oak1337 and the url/text [ ](https://goo.gl/GP6ppk)is: /r/CryptoMarkets/comments/1uxampy/in_the_end_all_roads_lead_to_hedera_hashgraph_hbar/ Hedera Hashgraph (HBAR). **Leaderless** architecture completely eliminates MEV, Frontrunning, Sandwich Attacks, etc. Any chain with a Block Leader has these problems and has some way of trying to "mitigate" it. **Don't mitigate, eliminate!** Block Leaders are also a security issue, since if you shut down the centralized single leader (DDOS), you shut down the network. **ABFT (Asynchronous Byzantine Fault Tolerance).** This was an unsolved math problem in computing since \\\~1982 (over 40 years). Dr. Leemon Baird solved it using \*\*Gossip about Gossip with ABFT Virtual Voting\*\*. It is the gold standard of consensus algorithms and will never be beaten. Perfect mathematics. \[https://hedera.com/blog/coq-proof-completed-by-carnegie-mellon-professor-confirms-hashgraph-consensus-algorithm-is-asynchronous-byzantine-fault-tolerant/\](https://hedera.com/blog/coq-proof-completed-by-carnegie-mellon-professor-confirms-hashgraph-consensus-algorithm-is-asynchronous-byzantine-fault-tolerant/) **Fees are fixed in USD, and paid in HBAR**. This makes it easy to forecast costs for users. \[https://docs.hedera.com/networks/fees\](https://docs.hedera.com/networks/fees) It has **Unlimited Scalability**. The current throttle is 10,000TPS, but that is a conservative throttle on a single shard. Add more nodes/shards to add more scale, as needed. Unlimited. **Modular Design for easy upgrades.** Hedera has the perfect mathematical foundation of Gossip about Gossip with ABFT Virtual Voting. Everything on top of that can be plug and play. This is why it will only take changing a couple lines of code to upgrade to Post-Quantum Security. **Hedera should be Post-Quantum with ML-KEM (waiting on libraries) and Falcon Signatures (waiting on NIST) by 2027.** Add that Hedera is already SHA384 and AES256, both Post-Quantum. \[https://hedera.com/blog/post-quantum-cryptography-and-blockchain/\](https://hedera.com/blog/post-quantum-cryptography-and-blockchain/) It is **Guaranteed Decentralization over time/scale**, meaning it's Nakamoto will only increase as it scales. All nodes are essentially equal (Gini and Theil Index), so adding more nodes/shards only increases Nakamoto. https://www.nodiens.com/market-research-reports# (Decentralization Comparative Model Across Blockchains) Full Hedera code base has been \*\*open sourced with Apache 2.0 and donated to Linux Foundation.\*\* \[https://www.lfdecentralizedtrust.org/projects/hiero\](https://www.lfdecentralizedtrust.org/projects/hiero) **Private HashSpheres, ZK Proofs, and encrypted messages to Mainnet,** means you can use your own private network that seamlessly connects to Mainnet, or keep your transactions private in many ways. https://hashgraph.com/blog/introducing-hashsphere-a-private-permissioned-network-powered-by-hedera/ **Cross-Ledger Protocol (CLPR)** enables cryptographically-secured communication and token transfers between independent blockchain networks–all without bridges, pooled liquidity or intermediary validator networks. Bridges are the most hacked/scammed part of crypto, so CLPR offers **bridgeless bridging.** https://hashgraph.com/clpr/ It's also **governed and being built on by a diverse set of Global Fortune 1000's and University's**. They have 3 year terms (max 2 consecutive terms, max 39 members), and all have 1 equal vote on governance issues. This means the Council rotates and power is never consolidated. https://hederacouncil.org/ **In short TLDR**: leaderless, best possible ABFT consensus, best possible SHA384 AES256 ML-KEM Falcon Signatures Post-Quantum Security, Unlimited Scalability, Guaranteed Decentralization over time/scale, fully open sourced with code donated to Linux, private HashSphere, connect to any network with CLPR, with a rotating expert governing council that is building enterprise grade solutions. Any questions? *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/CryptoMarkets) if you have any questions or concerns.*

oak1337

Hedera Hashgraph. **Leaderless** architecture completely eliminates MEV, Frontrunning, Sandwich Attacks, etc. Any chain with a Block Leader has these problems and has some way of trying to "mitigate" it. Don't mitigate, eliminate! Block Leaders are also a security issue, since if you shut down the centralized single leader (DDOS), you shut down the network. ABFT (Asynchronous Byzantine Fault Tolerance). This was an unsolved math problem in computing since \~1982 (over 40 years). Dr. Leemon Baird solved it using **Gossip about Gossip with ABFT Virtual Voting**. It is the gold standard of consensus algorithms and will never be beaten. Perfect mathematics. [https://hedera.com/blog/coq-proof-completed-by-carnegie-mellon-professor-confirms-hashgraph-consensus-algorithm-is-asynchronous-byzantine-fault-tolerant/](https://hedera.com/blog/coq-proof-completed-by-carnegie-mellon-professor-confirms-hashgraph-consensus-algorithm-is-asynchronous-byzantine-fault-tolerant/) **Fees are fixed in USD, and paid in HBAR**. This makes it easy to forecast costs for users. [https://docs.hedera.com/networks/fees](https://docs.hedera.com/networks/fees) It has **Unlimited Scalability**. The current throttle is 10,000TPS, but that is a conservative throttle on a single shard. Add more nodes/shards to add more scale, as needed. Unlimited. **Modular Design for easy upgrades.** Hedera has the perfect mathematical foundation of Gossip about Gossip with ABFT Virtual Voting. Everything on top of that can be plug and play. This is why it will only take changing a couple lines of code to upgrade to Post-Quantum Security. **Hedera should be Post-Quantum with ML-KEM (waiting on libraries) and Falcon Signatures (waiting on NIST) by 2027.** Add that Hedera is already SHA384 and AES256, both Post-Quantum. [https://hedera.com/blog/post-quantum-cryptography-and-blockchain/](https://hedera.com/blog/post-quantum-cryptography-and-blockchain/) It is **Guaranteed Decentralization over time/scale**, meaning it's Nakamoto will only increase as it scales. All nodes are essentially equal (Gini and Theil Index), so adding more nodes/shards only increases Nakamoto. Full Hedera code base has been **open sourced with Apache 2.0 and donated to Linux Foundation.** [https://www.lfdecentralizedtrust.org/projects/hiero](https://www.lfdecentralizedtrust.org/projects/hiero) In short: leaderless, best possible ABFT consensus, best possible SHA384 AES256 ML-KEM Falcon Signatures Post-Quantum Security, Unlimited Scalability, Guaranteed Decentralization over time/scale, fully open sourced with code donated to Linux. It's also governed and being built on by a diverse set of Global Fortune 1000's and University's. https://preview.redd.it/629pbn012fdh1.jpeg?width=918&format=pjpg&auto=webp&s=a2b1b470bb578aaecba269e450c153be5487ad15

dogehound

The stub never touches the network. Incoming blocks are verified in full-signature mode, which rejects any transaction whose signature is 64 bytes or shorter, so every transaction that enters the chain is checked against its complete 4,627 byte ML-DSA signature by every node before the block is accepted. The 64 byte stub only appears afterward, inside a node's own database, for transactions it has already verified. It is a receipt that a check happened, not a credential anyone will accept in place of one, and its stored hash is bound by SHA-256 to the exact signature that was verified. There is nothing there to forge and nothing to replay.

dj_destroyer

If quantum is close to breaking SHA256 -- the world has bigger problems than Bitcoin. That being said, I also think Bitcoin is particularly well-situated to adapt quicker than legacy systems. A Bitcoin fork could be completed in days, not weeks or months like a lot of other systems. You do raise a good point though about not being able to come to a singular conclusion but if we're truly on the verge of getting hacked, I bet you'll see the network come together and rally like never before. Quantum resistance is not the same type of issue as the block wars fundamentally.

brandonholm

Breaking SHA256 isn’t really a threat from quantum computers. Breaking elliptic curve cryptography is an issue though, and many devs are already planning on how to transition bitcoin to quantum secure signatures. Look at BIP-360 for example. You can also be relatively quantum secure by avoiding reusing addresses and not using taproot. This is because normal bitcoin addresses are a hash of the public key and the public key isn’t exposed until the address is spent from. So if you don’t re-use addresses, your key isn’t exposed until you spend it, at which point it’s already spent.

brandonholm

SHA256 is still considered quantum secure. Its elliptic curve cryptography that’s the issue.

Serenaded

\>Will quantum computing’s advancement make bitcoin obsolete? You can google this. The answer is yes. There is no fundamental way for something that lives on SHA256 to still be functional after quantum doomsday. And this is probably why ETH is breaking away from BTC, and elites are pivoting to ETH. Quantum doomsday is coming in the next 10 years, probably faster now that US gov is throwing trillions of dollars in funding into it.

maimutaAfricana

The main problem with cryptography is not the crypto use case. If SHA and other classical algos get(when) obliterated by qc then I'm pretty sure wise guys will develop or enhance existing qc resistant algos.

Appropriate-Talk-735

Here is some info from AI, perhaps you can try this? In the early days of Bitcoin (2011–2014), it was incredibly popular for people to create "Brainwallets." Instead of a wallet generating random words for you, a brainwallet allowed you to **type in any phrase, sentence, or random text you wanted** (like a poem, a quote, or a string of 20 complex words you picked out of a dictionary). The software would run that text through a SHA-256 hash function to generate the private key. * **The catch:** If it's a brainwallet, the exact case, spaces, and punctuation matter. * **How to recover it:** Old tools like [`brainwalletx.github.io`](http://brainwalletx.github.io) or specialized recovery scripts are used to turn custom text strings back into Bitcoin keys.

The_Bitcoin_Act

AI isn’t a magic codebreaker, Bitcoin’s security relies on SHA-256 and elliptic curve cryptography! The actual long-term threat is quantum computing, not AI.

Disastrous_Call_7120

The real damage wouldn't even be bitcoin itself, it's what comes after. If something can crack SHA-256 or break the elliptic curve cryptography, every bank, government system, military network goes down too. Bitcoin dying would be like the least of our problems at that point. People always think about the coin price but nobody considers that the same math protects their bank account and nuclear launch codes. Whole modern world runs on this stuff.

gmdavestevens

We should use an odd number SHA, so quantum computers can't halve them.

slavikthedancer

"A sufficiently large fault-tolerant quantum computer would roughly halve SHA-256's *bit-security* against brute-force preimage search (256-bit → \~128-bit equivalent), which is why NIST recommends SHA-384 or SHA-512 for long-term post-quantum resistance" (C) Claudia

Romanizer

That's not quite accurate. The tech and banking sectors haven't "switched" to post-quantum cryptography yet. They're in the middle of a migration that is expected to take many years (up to 10 years for banks). Bitcoin isn't stuck either. It can adopt new signature schemes through protocol upgrades which are already prepared, tested and deployable; the challenge is coordinating a decentralized network, not a lack of technical options but anyone can migrate when necessary. SHA256 is not assailable with quantum computers, so Bitcoin is always the safe haven when it comes to quantum resilience.

dj_destroyer

I would bet the Bitcoin network can fork to a new system faster than legacy bank systems. People act like BTC is the only network to use SHA256.

Educational_Cable405

Most of the panic conflates two different attacks. Mining is SHA-256 and Grover only buys a quadratic speedup, so you raise difficulty and it never actually breaks. The real one is Shor against secp256k1, and that only hits coins whose public key is already exposed, so P2PK outputs and any address you reused or already spent from. A fresh address nobody has spent from is just a hash on chain. For most people the fix is boring: stop reusing addresses. That's hygiene, not a White House emergency.

biggest_guru_in_town

The panic you are seeing online is a classic case of people confusing cryptocurrency with cryptography. ​On June 22, 2026, President Trump signed Executive Order 14409, titled "Securing the Nation Against Advanced Cryptographic Attacks." Despite the scary-sounding name, this directive has absolutely nothing to do with banning or dooming Bitcoin. ​Here is what is actually going on: Cryptography vs. Cryptocurrency ​What the bill is about: It is a national security directive focused on Post-Quantum Cryptography (PQC). It orders federal agencies to upgrade government cyber defenses and critical infrastructure by 2030/2031 so that future, powerful quantum computers won't be able to crack traditional government encryption (a risk often called "Q-Day"). ​What it means for Bitcoin: Nothing negative. In fact, the broader administration stance remains highly pro-crypto, following the establishment of the Strategic Bitcoin Reserve back in 2025. ​Are your 63k entries safe? ​The short answer is yes. Headlines shouting that this bill will "doom crypto" are just clickbait spinning the word "cryptographic" to trigger panic selling. ​If anything, the global push toward quantum-resistant security standards will eventually push the blockchain space to implement its own post-quantum signature schemes long before quantum computers pose a functional threat to SHA-256 or ECDSA (the cryptographic algorithms Bitcoin uses). ​Keep your head cool. Your DCA plan at 63k is facing standard market volatility, not a government shutdown. And stop being a FUD ass noob.

RetiredAvocado

Please use search function and return with at least some understanding. People already have described the issues in other posts. You can return and ask again, but armed with basic knowledge that doesn't have you write nonsense like "private key be unencrypted." First hint for you is there is no encryption in bitcoin, so if you are going to ask about QC, ask about proper things. Digital signatures are not encryption. You should also skim the wikipedia pages for SHA256 and ECDSA so that you know which of the two is threatened. Also don't mention politics or politicians to avoid your post getting instantly taken down into mod review queue. See ya in a few days.. Unless you can learn everything you need from existing posts.