r/Bitcoin: claim that Mk3 PRNG seed entropy is nearer 23 bits than 32
reddit-mk3-seed-entropy-worse
https://www.reddit.com/r/Bitcoin/comments/1vh0lm7/coldcard_entropy_even_worse_than_feared/
Latest reviewed change
source content difference between and
A comment by 1n5aN1aC describing dice-roll verification with a simple Python script was removed from the thread.
Cool
-comment: p22uu6m
-parent: t1_p21yp2i
-author: 1n5aN1aC
-created_utc: 1786030521
-edited: false
First lines only. The complete diff is in the timeline below.
- Organisation
- Evidence role
- Community discussion
- Published
- 2026-08-06
- Source changes
- 9
- Detected differences
- 9
- Unreviewed
- 0
- Copies held
- 10
Every check is recorded, including checks that found no text change. A detected edit is therefore bounded between two checks. The publisher's exact save time is not observable from this record. Last checked .
Also held inside a captured conversation
This post is held twice: here, with this project's own note on why it matters, and again as part of the conversation captured at , which is polled for changes. Both copies are the same post; neither is a separate event.
Public privacy boundary
Snapshot and diff bodies for this chain monitor are held in the local evidence archive but withheld from the public site because they can contain the addresses of people who published nothing themselves. Capture times and reviewed change summaries remain available below.
Held captures
-
A comment by 1n5aN1aC describing dice-roll verification with a simple Python script was removed from the thread.
Recovered from the Internet Archive rather than captured by this project. The row records that third-party provenance separately from captures made by this project.
What changed from the previous capture 12 lines
Cool -comment: p22uu6m -parent: t1_p21yp2i -author: 1n5aN1aC -created_utc: 1786030521 -edited: false -body: -With Coldcard, you could use dicerolls, and a python script on a computer to verify the hash matches the generated. - -And since the python script is very very simple, it wouldn't be too hard to audit that, then generate 1-2 keys on your card, verifying it matches, then generate the real one, now confident the key is secure and not leaked. - -That does solve pretty much all possible vulnerabilities related to key generation, but it is harder for a non-technical user. - comment: p22v0fg parent: t1_p22mvk0 author: WhenIntegralsAttack2Extracted text as captured
post: 1vh0lm7 author: ineedanamegenerator created_utc: 1786012708 title: Coldcard entropy even worse than feared body: TL;DR: The random number generator is initialized with a 32 bit value (4B+ possibilities). But only less than 10M options are possible because of how they generate the value. The PRNG used in Coldcard MK3 is initialized with UID\[31:0\] XOR SysTick->VAL SysTick->VAL gives 80k possibilities \~16.3 bit, all located in the lowest 17 bits of the value. UID encodes the X and Y coordinates of wafer position of the STM32 in the 32 bits that are used by the code. ~~This is encoded in BCD, which means only 10 out of 16 possible values of each nibble are used. This means the 32 bit value at most encodes 100M options (26.6 bits), but there are nowhere near 100M chips in a wafer.~~ The BCD encoding seems to be an mistake in some STM32 manuals. The number is plain HEX encoded, but that doesn't matter here. There are never 2\^16 rows or columns in a wafer. I don't know how many there are in a wafer, but google gives an upper bound of 20k chips per wafer. The lower 16 bits overlap with Systick->VAL, so XORing the wafer location adds no entropy. The upper 16 bits can carry only about SQRT(20000) possibilities (probably less) \~ 7.2 bits. And they aren't even evenly distributed in a round wafer. So at most we're looking at \~23 bits of entropy. Not 32 bits. This isn't 100% exact because SQRT assumes a square while a wafer is round, but too lazy to work it out further. Point is: entropy is way worse than 32 bits. comment: p218c9t parent: t3_1vh0lm7 author: frugaleringenieur created_utc: 1786012836 edited: false body: Makes little sense, yet. comment: p2197hk parent: t3_1vh0lm7 author: Javanaut018 created_utc: 1786013204 edited: false body: That explains why attackers were able to even scan for multiple derivations and simple extra passphrases ...Excerpt only. The complete copy is held offline and backs quotations on this site. The original publication remains the canonical public source.
-
The thread gained a new comment by brando2131 stating that multisig equals multiple factors.
Recovered from the Internet Archive rather than captured by this project. The row records that third-party provenance separately from captures made by this project.
What changed from the previous capture 8 lines
body: mk3 +comment: p3ea484 +parent: t1_p21upfp +author: brando2131 +created_utc: 1786603901 +edited: false +body: +multisig = multiple factors... + more-stub: parent t1_p22wv5v count <live-count> more-stub: parent t1_p22ti4j count <live-count>Extracted text as captured
post: 1vh0lm7 author: ineedanamegenerator created_utc: 1786012708 title: Coldcard entropy even worse than feared body: TL;DR: The random number generator is initialized with a 32 bit value (4B+ possibilities). But only less than 10M options are possible because of how they generate the value. The PRNG used in Coldcard MK3 is initialized with UID\[31:0\] XOR SysTick->VAL SysTick->VAL gives 80k possibilities \~16.3 bit, all located in the lowest 17 bits of the value. UID encodes the X and Y coordinates of wafer position of the STM32 in the 32 bits that are used by the code. ~~This is encoded in BCD, which means only 10 out of 16 possible values of each nibble are used. This means the 32 bit value at most encodes 100M options (26.6 bits), but there are nowhere near 100M chips in a wafer.~~ The BCD encoding seems to be an mistake in some STM32 manuals. The number is plain HEX encoded, but that doesn't matter here. There are never 2\^16 rows or columns in a wafer. I don't know how many there are in a wafer, but google gives an upper bound of 20k chips per wafer. The lower 16 bits overlap with Systick->VAL, so XORing the wafer location adds no entropy. The upper 16 bits can carry only about SQRT(20000) possibilities (probably less) \~ 7.2 bits. And they aren't even evenly distributed in a round wafer. So at most we're looking at \~23 bits of entropy. Not 32 bits. This isn't 100% exact because SQRT assumes a square while a wafer is round, but too lazy to work it out further. Point is: entropy is way worse than 32 bits. comment: p218c9t parent: t3_1vh0lm7 author: frugaleringenieur created_utc: 1786012836 edited: false body: Makes little sense, yet. comment: p2197hk parent: t3_1vh0lm7 author: Javanaut018 created_utc: 1786013204 edited: false body: That explains why attackers were able to even scan for multiple derivations and simple extra passphrases ...Excerpt only. The complete copy is held offline and backs quotations on this site. The original publication remains the canonical public source.
-
Several comments were deleted or redacted as [deleted] and [removed], and a short reply reading 'mk3' was added.
Recovered from the Internet Archive rather than captured by this project. The row records that third-party provenance separately from captures made by this project.
What changed from the previous capture 40 lines
What? Of course it can. Why couldn't they? Pre-compute all possible wallets first and rank them. -comment: p22fhmu -parent: t3_1vh0lm7 -author: broskibrokovski21 -created_utc: 1786026553 -edited: false -body: -This story keeps getting crazier by the minute... - comment: p22fj2c parent: t1_p22eqfq author: ineedanamegenerator comment: p240ksc parent: t3_1vh0lm7 -author: serious_discussion5 +author: [deleted] created_utc: 1786040838 edited: false body: -This is an absolutely ridiculous bug , the fact it made it to production is stupid +[removed] comment: p241rce parent: t1_p23thyp comment: p2420ku parent: t1_p21upfp -author: Todo_es +author: [deleted] created_utc: 1786041201 edited: false body: -It has, look up "Passphrase". +[deleted] comment: p2421nk parent: t1_p21nnox comment: p244jxf parent: t1_p2447sm -author: serious_discussion5 +author: [deleted] created_utc: 1786041838 edited: false body: -And now my bitcoin is stuck on a time locked seed that'll probably get stolen and I can't do anything about it. +[removed] comment: p246gwx parent: t1_p243ftx comment: p248d39 parent: t1_p246o8q -author: serious_discussion5 +author: [deleted] created_utc: 1786042806 edited: false body: -I'm talking about mini script time locked vaults. I've got some bitcoin locked up long term there and I hate that it could be compromised right now. +[removed] comment: p248mvb parent: t3_1vh0lm7 But honestly, that would still be a much better situation than today. If they had added just one factory generated UUID in the mix they'd be protected against a hack like this. This is common design choice: if you get hacked or a flaw is exposed, try to make it impact only one device at a time. In this case all devices are exposed to the single flaw. - -comment: p24c7mr -parent: t1_p24aezd -author: serious_discussion5 -created_utc: 1786043794 -edited: false -body: -Exactly. I'll have to wait until the exact moment it's unlocked then try to choose a fee that's higher than what they'll choose and hope they can't RBF it. Luckily I have a while to plan for this event and hopefully the hackers won't scan for my type of wallet or will forget by then. comment: p24d62o parent: t1_p24abxx body: Mk3 or 4/5/q? +comment: p2tg535 +parent: t1_p2ppo8e +author: orbag +created_utc: 1786362294 +edited: false +body: +mk3 + more-stub: parent t1_p22wv5v count <live-count> more-stub: parent t1_p22ti4j count <live-count>Extracted text as captured
post: 1vh0lm7 author: ineedanamegenerator created_utc: 1786012708 title: Coldcard entropy even worse than feared body: TL;DR: The random number generator is initialized with a 32 bit value (4B+ possibilities). But only less than 10M options are possible because of how they generate the value. The PRNG used in Coldcard MK3 is initialized with UID\[31:0\] XOR SysTick->VAL SysTick->VAL gives 80k possibilities \~16.3 bit, all located in the lowest 17 bits of the value. UID encodes the X and Y coordinates of wafer position of the STM32 in the 32 bits that are used by the code. ~~This is encoded in BCD, which means only 10 out of 16 possible values of each nibble are used. This means the 32 bit value at most encodes 100M options (26.6 bits), but there are nowhere near 100M chips in a wafer.~~ The BCD encoding seems to be an mistake in some STM32 manuals. The number is plain HEX encoded, but that doesn't matter here. There are never 2\^16 rows or columns in a wafer. I don't know how many there are in a wafer, but google gives an upper bound of 20k chips per wafer. The lower 16 bits overlap with Systick->VAL, so XORing the wafer location adds no entropy. The upper 16 bits can carry only about SQRT(20000) possibilities (probably less) \~ 7.2 bits. And they aren't even evenly distributed in a round wafer. So at most we're looking at \~23 bits of entropy. Not 32 bits. This isn't 100% exact because SQRT assumes a square while a wafer is round, but too lazy to work it out further. Point is: entropy is way worse than 32 bits. comment: p218c9t parent: t3_1vh0lm7 author: frugaleringenieur created_utc: 1786012836 edited: false body: Makes little sense, yet. comment: p2197hk parent: t3_1vh0lm7 author: Javanaut018 created_utc: 1786013204 edited: false body: That explains why attackers were able to even scan for multiple derivations and simple extra passphrases ...Excerpt only. The complete copy is held offline and backs quotations on this site. The original publication remains the canonical public source.
-
The thread gained a reply asking whether the entropy estimate applies to Mk3 or to newer models.
Recovered from the Internet Archive rather than captured by this project. The row records that third-party provenance separately from captures made by this project.
What changed from the previous capture 8 lines
body: Fewer and fewer will understand... +comment: p2ppo8e +parent: t1_p21kt88 +author: flutecop +created_utc: 1786308736 +edited: false +body: +Mk3 or 4/5/q? + more-stub: parent t1_p22wv5v count <live-count> more-stub: parent t1_p22ti4j count <live-count>Extracted text as captured
post: 1vh0lm7 author: ineedanamegenerator created_utc: 1786012708 title: Coldcard entropy even worse than feared body: TL;DR: The random number generator is initialized with a 32 bit value (4B+ possibilities). But only less than 10M options are possible because of how they generate the value. The PRNG used in Coldcard MK3 is initialized with UID\[31:0\] XOR SysTick->VAL SysTick->VAL gives 80k possibilities \~16.3 bit, all located in the lowest 17 bits of the value. UID encodes the X and Y coordinates of wafer position of the STM32 in the 32 bits that are used by the code. ~~This is encoded in BCD, which means only 10 out of 16 possible values of each nibble are used. This means the 32 bit value at most encodes 100M options (26.6 bits), but there are nowhere near 100M chips in a wafer.~~ The BCD encoding seems to be an mistake in some STM32 manuals. The number is plain HEX encoded, but that doesn't matter here. There are never 2\^16 rows or columns in a wafer. I don't know how many there are in a wafer, but google gives an upper bound of 20k chips per wafer. The lower 16 bits overlap with Systick->VAL, so XORing the wafer location adds no entropy. The upper 16 bits can carry only about SQRT(20000) possibilities (probably less) \~ 7.2 bits. And they aren't even evenly distributed in a round wafer. So at most we're looking at \~23 bits of entropy. Not 32 bits. This isn't 100% exact because SQRT assumes a square while a wafer is round, but too lazy to work it out further. Point is: entropy is way worse than 32 bits. comment: p218c9t parent: t3_1vh0lm7 author: frugaleringenieur created_utc: 1786012836 edited: false body: Makes little sense, yet. comment: p2197hk parent: t3_1vh0lm7 author: Javanaut018 created_utc: 1786013204 edited: false body: That explains why attackers were able to even scan for multiple derivations and simple extra passphrases ...Excerpt only. The complete copy is held offline and backs quotations on this site. The original publication remains the canonical public source.
-
A comment about moderator removals was deleted and a new short comment was added stating that fewer people will understand the technical discussion.
Recovered from the Internet Archive rather than captured by this project. The row records that third-party provenance separately from captures made by this project.
What changed from the previous capture 16 lines
But that’s all unnecessary… if your key generation is good. -comment: p24ys9j -parent: t1_p220iyg -author: TheGamingGallifreyan -created_utc: 1786049669 -edited: false -body: -Pretty much every one of them was removed by the moderators lol - comment: p24zxdu parent: t1_p21mxwf author: LeatherMine body: Both things that were considered advanced schizo stuff at the time. Entering a passphrase on an MK3 would also be a royal pain in the ass. +comment: p2kcuhh +parent: t3_1vh0lm7 +author: Tahueisin +created_utc: 1786238191 +edited: false +body: +Fewer and fewer will understand... + more-stub: parent t1_p22wv5v count <live-count> more-stub: parent t1_p22ti4j count <live-count>Extracted text as captured
post: 1vh0lm7 author: ineedanamegenerator created_utc: 1786012708 title: Coldcard entropy even worse than feared body: TL;DR: The random number generator is initialized with a 32 bit value (4B+ possibilities). But only less than 10M options are possible because of how they generate the value. The PRNG used in Coldcard MK3 is initialized with UID\[31:0\] XOR SysTick->VAL SysTick->VAL gives 80k possibilities \~16.3 bit, all located in the lowest 17 bits of the value. UID encodes the X and Y coordinates of wafer position of the STM32 in the 32 bits that are used by the code. ~~This is encoded in BCD, which means only 10 out of 16 possible values of each nibble are used. This means the 32 bit value at most encodes 100M options (26.6 bits), but there are nowhere near 100M chips in a wafer.~~ The BCD encoding seems to be an mistake in some STM32 manuals. The number is plain HEX encoded, but that doesn't matter here. There are never 2\^16 rows or columns in a wafer. I don't know how many there are in a wafer, but google gives an upper bound of 20k chips per wafer. The lower 16 bits overlap with Systick->VAL, so XORing the wafer location adds no entropy. The upper 16 bits can carry only about SQRT(20000) possibilities (probably less) \~ 7.2 bits. And they aren't even evenly distributed in a round wafer. So at most we're looking at \~23 bits of entropy. Not 32 bits. This isn't 100% exact because SQRT assumes a square while a wafer is round, but too lazy to work it out further. Point is: entropy is way worse than 32 bits. comment: p218c9t parent: t3_1vh0lm7 author: frugaleringenieur created_utc: 1786012836 edited: false body: Makes little sense, yet. comment: p2197hk parent: t3_1vh0lm7 author: Javanaut018 created_utc: 1786013204 edited: false body: That explains why attackers were able to even scan for multiple derivations and simple extra passphrases ...Excerpt only. The complete copy is held offline and backs quotations on this site. The original publication remains the canonical public source.
-
A new reply was added noting that passphrases and dice entropy were once dismissed as paranoid, and that entering a passphrase on a Mk3 is cumbersome.
Recovered from the Internet Archive rather than captured by this project. The row records that third-party provenance separately from captures made by this project.
What changed from the previous capture 8 lines
body: Why do you need new wallets? New adress would be sufficient, no? +comment: p2fz73e +parent: t1_p21r3af +author: ItsMeMulbear +created_utc: 1786188909 +edited: false +body: +Both things that were considered advanced schizo stuff at the time. Entering a passphrase on an MK3 would also be a royal pain in the ass. + more-stub: parent t1_p22wv5v count <live-count> more-stub: parent t1_p22ti4j count <live-count>Extracted text as captured
post: 1vh0lm7 author: ineedanamegenerator created_utc: 1786012708 title: Coldcard entropy even worse than feared body: TL;DR: The random number generator is initialized with a 32 bit value (4B+ possibilities). But only less than 10M options are possible because of how they generate the value. The PRNG used in Coldcard MK3 is initialized with UID\[31:0\] XOR SysTick->VAL SysTick->VAL gives 80k possibilities \~16.3 bit, all located in the lowest 17 bits of the value. UID encodes the X and Y coordinates of wafer position of the STM32 in the 32 bits that are used by the code. ~~This is encoded in BCD, which means only 10 out of 16 possible values of each nibble are used. This means the 32 bit value at most encodes 100M options (26.6 bits), but there are nowhere near 100M chips in a wafer.~~ The BCD encoding seems to be an mistake in some STM32 manuals. The number is plain HEX encoded, but that doesn't matter here. There are never 2\^16 rows or columns in a wafer. I don't know how many there are in a wafer, but google gives an upper bound of 20k chips per wafer. The lower 16 bits overlap with Systick->VAL, so XORing the wafer location adds no entropy. The upper 16 bits can carry only about SQRT(20000) possibilities (probably less) \~ 7.2 bits. And they aren't even evenly distributed in a round wafer. So at most we're looking at \~23 bits of entropy. Not 32 bits. This isn't 100% exact because SQRT assumes a square while a wafer is round, but too lazy to work it out further. Point is: entropy is way worse than 32 bits. comment: p218c9t parent: t3_1vh0lm7 author: frugaleringenieur created_utc: 1786012836 edited: false body: Makes little sense, yet. comment: p2197hk parent: t3_1vh0lm7 author: Javanaut018 created_utc: 1786013204 edited: false body: That explains why attackers were able to even scan for multiple derivations and simple extra passphrases ...Excerpt only. The complete copy is held offline and backs quotations on this site. The original publication remains the canonical public source.
-
The Reddit thread gained a new participant comment asking whether a new address is sufficient rather than a new wallet.
Recovered from the Internet Archive rather than captured by this project. The row records that third-party provenance separately from captures made by this project.
What changed from the previous capture 8 lines
body: you wouldn't need to tho. +comment: p2ew12a +parent: t1_p21nfjo +author: LJass +created_utc: 1786169433 +edited: false +body: +Why do you need new wallets? New adress would be sufficient, no? + more-stub: parent t1_p22wv5v count <live-count> more-stub: parent t1_p22ti4j count <live-count>Extracted text as captured
post: 1vh0lm7 author: ineedanamegenerator created_utc: 1786012708 title: Coldcard entropy even worse than feared body: TL;DR: The random number generator is initialized with a 32 bit value (4B+ possibilities). But only less than 10M options are possible because of how they generate the value. The PRNG used in Coldcard MK3 is initialized with UID\[31:0\] XOR SysTick->VAL SysTick->VAL gives 80k possibilities \~16.3 bit, all located in the lowest 17 bits of the value. UID encodes the X and Y coordinates of wafer position of the STM32 in the 32 bits that are used by the code. ~~This is encoded in BCD, which means only 10 out of 16 possible values of each nibble are used. This means the 32 bit value at most encodes 100M options (26.6 bits), but there are nowhere near 100M chips in a wafer.~~ The BCD encoding seems to be an mistake in some STM32 manuals. The number is plain HEX encoded, but that doesn't matter here. There are never 2\^16 rows or columns in a wafer. I don't know how many there are in a wafer, but google gives an upper bound of 20k chips per wafer. The lower 16 bits overlap with Systick->VAL, so XORing the wafer location adds no entropy. The upper 16 bits can carry only about SQRT(20000) possibilities (probably less) \~ 7.2 bits. And they aren't even evenly distributed in a round wafer. So at most we're looking at \~23 bits of entropy. Not 32 bits. This isn't 100% exact because SQRT assumes a square while a wafer is round, but too lazy to work it out further. Point is: entropy is way worse than 32 bits. comment: p218c9t parent: t3_1vh0lm7 author: frugaleringenieur created_utc: 1786012836 edited: false body: Makes little sense, yet. comment: p2197hk parent: t3_1vh0lm7 author: Javanaut018 created_utc: 1786013204 edited: false body: That explains why attackers were able to even scan for multiple derivations and simple extra passphrases ...Excerpt only. The complete copy is held offline and backs quotations on this site. The original publication remains the canonical public source.
-
The Reddit thread gained a new participant reply.
Recovered from the Internet Archive rather than captured by this project. The row records that third-party provenance separately from captures made by this project.
What changed from the previous capture 8 lines
Don‘t say „by adding dice rolls you can optionally add your own entropy which is cool because you don‘t have to trust the device‘s“ say „by adding dice rolls you can never mess up the devices security you can not make anything worse. Even if you mess it up completely and make the rolls up yourself, only use one roll or post your rolls online: It doesn‘t decrease the safety of your coins. So roll the damn dice!“ +comment: p2ca3z4 +parent: t1_p279vs9 +author: tridentgum +created_utc: 1786136099 +edited: false +body: +you wouldn't need to tho. + more-stub: parent t1_p22wv5v count <live-count> more-stub: parent t1_p22ti4j count <live-count>Extracted text as captured
post: 1vh0lm7 author: ineedanamegenerator created_utc: 1786012708 title: Coldcard entropy even worse than feared body: TL;DR: The random number generator is initialized with a 32 bit value (4B+ possibilities). But only less than 10M options are possible because of how they generate the value. The PRNG used in Coldcard MK3 is initialized with UID\[31:0\] XOR SysTick->VAL SysTick->VAL gives 80k possibilities \~16.3 bit, all located in the lowest 17 bits of the value. UID encodes the X and Y coordinates of wafer position of the STM32 in the 32 bits that are used by the code. ~~This is encoded in BCD, which means only 10 out of 16 possible values of each nibble are used. This means the 32 bit value at most encodes 100M options (26.6 bits), but there are nowhere near 100M chips in a wafer.~~ The BCD encoding seems to be an mistake in some STM32 manuals. The number is plain HEX encoded, but that doesn't matter here. There are never 2\^16 rows or columns in a wafer. I don't know how many there are in a wafer, but google gives an upper bound of 20k chips per wafer. The lower 16 bits overlap with Systick->VAL, so XORing the wafer location adds no entropy. The upper 16 bits can carry only about SQRT(20000) possibilities (probably less) \~ 7.2 bits. And they aren't even evenly distributed in a round wafer. So at most we're looking at \~23 bits of entropy. Not 32 bits. This isn't 100% exact because SQRT assumes a square while a wafer is round, but too lazy to work it out further. Point is: entropy is way worse than 32 bits. comment: p218c9t parent: t3_1vh0lm7 author: frugaleringenieur created_utc: 1786012836 edited: false body: Makes little sense, yet. comment: p2197hk parent: t3_1vh0lm7 author: Javanaut018 created_utc: 1786013204 edited: false body: That explains why attackers were able to even scan for multiple derivations and simple extra passphrases ...Excerpt only. The complete copy is held offline and backs quotations on this site. The original publication remains the canonical public source.
-
One comment's author changed to [deleted] and a new reply explained that adding entropy sources can only increase or preserve entropy.
Recovered from the Internet Archive rather than captured by this project. The row records that third-party provenance separately from captures made by this project.
What changed from the previous capture 16 lines
comment: p21guy2 parent: t3_1vh0lm7 -author: kurtzsp +author: [deleted] created_utc: 1786016196 edited: false body: -This post explain well why it's not possible to reach mass adoption. You almost need a degree in physics to just be sure that your keys are safe... +[deleted] comment: p21hjd5 parent: t1_p21cu31 The CEO dismissed it. +comment: p29ax2e +parent: t1_p219g6c +author: Psychological_Mode98 +created_utc: 1786107689 +edited: false +body: +This is gold. Understanding that different entropy sources „added up“ can only increase the entropy or keep it equal to the best factor‘s entropy and can never result in worse. + +This knowledge would have been so easy to put in one sentence in all that cc setup edu that it could have saved so many more people because it would have reduced their fear of messing something up. + +Don‘t say „by adding dice rolls you can optionally add your own entropy which is cool because you don‘t have to trust the device‘s“ say „by adding dice rolls you can never mess up the devices security you can not make anything worse. Even if you mess it up completely and make the rolls up yourself, only use one roll or post your rolls online: It doesn‘t decrease the safety of your coins. So roll the damn dice!“ + more-stub: parent t1_p22wv5v count <live-count> more-stub: parent t1_p22ti4j count <live-count>Extracted text as captured
post: 1vh0lm7 author: ineedanamegenerator created_utc: 1786012708 title: Coldcard entropy even worse than feared body: TL;DR: The random number generator is initialized with a 32 bit value (4B+ possibilities). But only less than 10M options are possible because of how they generate the value. The PRNG used in Coldcard MK3 is initialized with UID\[31:0\] XOR SysTick->VAL SysTick->VAL gives 80k possibilities \~16.3 bit, all located in the lowest 17 bits of the value. UID encodes the X and Y coordinates of wafer position of the STM32 in the 32 bits that are used by the code. ~~This is encoded in BCD, which means only 10 out of 16 possible values of each nibble are used. This means the 32 bit value at most encodes 100M options (26.6 bits), but there are nowhere near 100M chips in a wafer.~~ The BCD encoding seems to be an mistake in some STM32 manuals. The number is plain HEX encoded, but that doesn't matter here. There are never 2\^16 rows or columns in a wafer. I don't know how many there are in a wafer, but google gives an upper bound of 20k chips per wafer. The lower 16 bits overlap with Systick->VAL, so XORing the wafer location adds no entropy. The upper 16 bits can carry only about SQRT(20000) possibilities (probably less) \~ 7.2 bits. And they aren't even evenly distributed in a round wafer. So at most we're looking at \~23 bits of entropy. Not 32 bits. This isn't 100% exact because SQRT assumes a square while a wafer is round, but too lazy to work it out further. Point is: entropy is way worse than 32 bits. comment: p218c9t parent: t3_1vh0lm7 author: frugaleringenieur created_utc: 1786012836 edited: false body: Makes little sense, yet. comment: p2197hk parent: t3_1vh0lm7 author: Javanaut018 created_utc: 1786013204 edited: false body: That explains why attackers were able to even scan for multiple derivations and simple extra passphrases ...Excerpt only. The complete copy is held offline and backs quotations on this site. The original publication remains the canonical public source.
-
Recovered from the Internet Archive rather than captured by this project. The row records that third-party provenance separately from captures made by this project.
What changed from the previous capture 0 lines
Extracted text as captured
post: 1vh0lm7 author: ineedanamegenerator created_utc: 1786012708 title: Coldcard entropy even worse than feared body: TL;DR: The random number generator is initialized with a 32 bit value (4B+ possibilities). But only less than 10M options are possible because of how they generate the value. The PRNG used in Coldcard MK3 is initialized with UID\[31:0\] XOR SysTick->VAL SysTick->VAL gives 80k possibilities \~16.3 bit, all located in the lowest 17 bits of the value. UID encodes the X and Y coordinates of wafer position of the STM32 in the 32 bits that are used by the code. ~~This is encoded in BCD, which means only 10 out of 16 possible values of each nibble are used. This means the 32 bit value at most encodes 100M options (26.6 bits), but there are nowhere near 100M chips in a wafer.~~ The BCD encoding seems to be an mistake in some STM32 manuals. The number is plain HEX encoded, but that doesn't matter here. There are never 2\^16 rows or columns in a wafer. I don't know how many there are in a wafer, but google gives an upper bound of 20k chips per wafer. The lower 16 bits overlap with Systick->VAL, so XORing the wafer location adds no entropy. The upper 16 bits can carry only about SQRT(20000) possibilities (probably less) \~ 7.2 bits. And they aren't even evenly distributed in a round wafer. So at most we're looking at \~23 bits of entropy. Not 32 bits. This isn't 100% exact because SQRT assumes a square while a wafer is round, but too lazy to work it out further. Point is: entropy is way worse than 32 bits. comment: p218c9t parent: t3_1vh0lm7 author: frugaleringenieur created_utc: 1786012836 edited: false body: Makes little sense, yet. comment: p2197hk parent: t3_1vh0lm7 author: Javanaut018 created_utc: 1786013204 edited: false body: That explains why attackers were able to even scan for multiple derivations and simple extra passphrases ...Excerpt only. The complete copy is held offline and backs quotations on this site. The original publication remains the canonical public source.
0 presentation-noise differences. Sidebar, ticker and other page chrome churn that our review classified as not being changes to what the source says.
How to check this yourself
The excerpts and plain unified diffs above show the text this project held and how it changed. To verify a quotation, compare it against the page itself or against the Internet Archive's copies, which are independent of this project.
Complete captures are held offline rather than mirrored here, so this page shows diffs and excerpts. If a quotation is ever disputed, the full copy can be produced. Ask.
How to check this yourself
Compare the screenshot or a quotation against the original while it is available.