r/Bitcoin: correction disputing a claim that the MCU UID is part of the seed
reddit-mcu-uid-seed-correction
https://www.reddit.com/r/Bitcoin/comments/1vg0nop/coldcard_mcu_uid_is_not_part_of_the_seed_stop/
Latest reviewed change
source content difference between and
Reddit served 1 additional comment record(s); the diff preserves their text and any edits to existing records.
It would be prudent to remind people here that there are still a lot of vulnerable funds that could be saved and that it would be anti-social to explain how to reduce the search space of coldcard devices just to brag about how smart you are, or show that some rando was wrong on the internet.
Plenty of other people could be posting about the *exact* search space needed to enumerate vulnerable seeds and are kindly refraining from doing so. Just because you could figure out that doesn't mean that every would be coin-thief is going to figure it out before the owners sweep their coins.
+
+comment: p20heev
+parent: t1_p1y70jo
+author: opossum_cz
+created_utc: 1785999781
First lines only. The complete diff is in the timeline below.
- Organisation
- Evidence role
- Community discussion
- Published
- not established
- Source changes
- 1
- Detected differences
- 1
- Unreviewed
- 0
- Copies held
- 2
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 .
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.
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
-
Reddit served 1 additional comment record(s); the diff preserves their text and any edits to existing records.
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
It would be prudent to remind people here that there are still a lot of vulnerable funds that could be saved and that it would be anti-social to explain how to reduce the search space of coldcard devices just to brag about how smart you are, or show that some rando was wrong on the internet. Plenty of other people could be posting about the *exact* search space needed to enumerate vulnerable seeds and are kindly refraining from doing so. Just because you could figure out that doesn't mean that every would be coin-thief is going to figure it out before the owners sweep their coins. + +comment: p20heev +parent: t1_p1y70jo +author: opossum_cz +created_utc: 1785999781 +edited: false +body: +Sounds plausible.Extracted text as captured
post: 1vg0nop author: opossum_cz created_utc: 1785915824 title: ColdCard MCU UID is not part of the seed - stop repeating that nonsense body: It is one of the values that is used to generate the seed, but it is xored with timer value, RTC time, registers etc. It is used to get some entropy. If MCU UID is a part of the seed in any shape or form to tie generated seed to the device. It would be massive vulnerability, as everybody who gets ahold of your device (and especially the company itself which knows all MCU UIDs) would be able to lower the entropy of every seed key generated there by 32 bits immediately. comment: p1tbkht parent: t3_1vg0nop author: Javanaut018 created_utc: 1785917094 edited: false body: Doesn't matter if the UID (only the first 32 bit of it was used tho) is part of the generated key or used for the seed of the RNG. As the RNG is fully known, it really only depends on the set of input parameters that flowed into the private key making process. You just need to test all possible or at least all probable input arguments to the generation chain and ka-chinnng! there it comes. This is the big difference to TRNG units. They draw randomness from non-deterministic processes like noising amplifiers or chirping ring-oscillators, things that are physically governed by the butterfly effect. Such unit run for a couple of milliseconds and then start to throw out randomized numbers with 100% maxed out entropy. Impossible to guess on that. Also ppl tend to underestimate how vast key spaces are and have to be. The collapsed key space of the weak RNG chain in the device compared to the full 256-bit space is more or less like 1 atom in the whole milky way. Thats why such attack was feasible in the first place. Sad double so that such perfectly working TRNG is on all affected devices. It was only forgotten to plug it in ... comment: p1u2pvr parent: t3_1vg0nop author: frugaleringenieur created_utc: 1785929305 edited: false body: As long as you can fix all the other constants (which could be possible in the 40 bits hack) and the MCU UID is XORED against it, you could reliably identify a physical accessed Coldcard Mk3 as a victim. This is of importance for recovery of funds - if ever. comment: p1u7dra parent: t1_p1u2pvr author: opossum_cz created_utc: 1785931011 edited: falseExcerpt 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: 1vg0nop author: opossum_cz created_utc: 1785915824 title: ColdCard MCU UID is not part of the seed - stop repeating that nonsense body: It is one of the values that is used to generate the seed, but it is xored with timer value, RTC time, registers etc. It is used to get some entropy. If MCU UID is a part of the seed in any shape or form to tie generated seed to the device. It would be massive vulnerability, as everybody who gets ahold of your device (and especially the company itself which knows all MCU UIDs) would be able to lower the entropy of every seed key generated there by 32 bits immediately. comment: p1tbkht parent: t3_1vg0nop author: Javanaut018 created_utc: 1785917094 edited: false body: Doesn't matter if the UID (only the first 32 bit of it was used tho) is part of the generated key or used for the seed of the RNG. As the RNG is fully known, it really only depends on the set of input parameters that flowed into the private key making process. You just need to test all possible or at least all probable input arguments to the generation chain and ka-chinnng! there it comes. This is the big difference to TRNG units. They draw randomness from non-deterministic processes like noising amplifiers or chirping ring-oscillators, things that are physically governed by the butterfly effect. Such unit run for a couple of milliseconds and then start to throw out randomized numbers with 100% maxed out entropy. Impossible to guess on that. Also ppl tend to underestimate how vast key spaces are and have to be. The collapsed key space of the weak RNG chain in the device compared to the full 256-bit space is more or less like 1 atom in the whole milky way. Thats why such attack was feasible in the first place. Sad double so that such perfectly working TRNG is on all affected devices. It was only forgotten to plug it in ... comment: p1u2pvr parent: t3_1vg0nop author: frugaleringenieur created_utc: 1785929305 edited: false body: As long as you can fix all the other constants (which could be possible in the 40 bits hack) and the MCU UID is XORED against it, you could reliably identify a physical accessed Coldcard Mk3 as a victim. This is of importance for recovery of funds - if ever. comment: p1u7dra parent: t1_p1u2pvr author: opossum_cz created_utc: 1785931011 edited: falseExcerpt 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.
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.
Compare the screenshot or a quotation against the original while it is available.