![](\"/user_uploads/2/62/rhrQb80u8jv3xyb-438gX-Fm/image.png\")
batteries not included
", "time": "2026-07-20T12:06:39.000Z"}, {"author": "Rich Salz", "text": "The \"extra\" chair on the stage is leftover from the previous session to accomodate a presenter who had physical issues. It could be removed and the mic stand put back into the common position.
", "time": "2026-07-20T12:08:53.000Z"}, {"author": "Bas Westerbaan", "text": "ACME today? Isn't that Thursday?
", "time": "2026-07-20T12:11:52.000Z"}, {"author": "Daniel Gillmor", "text": "yes, it's thursday.
", "time": "2026-07-20T12:12:12.000Z"}, {"author": "Mike Ounsworth", "text": "\"Log number encoded in serial
\n\u25cf 16-bit log number, 48-bit entry index\"
Didn't PKI move to randomized serial numbers as the obvious point to inject entropy into the TBSCertificate?
\nIs this design point addressed in the draft?
That's the randomizer.
", "time": "2026-07-20T12:12:43.000Z"}, {"author": "Bas Westerbaan", "text": "Only relevant if the hash is weak (which it isn't), or if you want to eek out more than 128-bit security from a 256-bit hash. https://mailarchive.ietf.org/arch/msg/plants/FN8L2-C2AjN7QxpX6RC7b3tnxi8/
", "time": "2026-07-20T12:13:44.000Z"}, {"author": "Mike Ounsworth", "text": "draft-ietf-plants-merkle-tree-certs-05 has 0 CTRL+F hits for \"randomizer\". Is that an addition that's not in the draft yet?
\nWhat I'm looking for is the details: is randomizer an X.509v3 extn in the TBSCert of the leaf entry?
", "time": "2026-07-20T12:14:48.000Z"}, {"author": "Brendan McMillion", "text": "Randomizer isn't built-in. It's a to-be-written extension
", "time": "2026-07-20T12:15:19.000Z"}, {"author": "Daniel Gillmor", "text": "relative OID would be my preference as well, fwiw.
", "time": "2026-07-20T12:15:22.000Z"}, {"author": "Yoav Nir", "text": "The bikeshed question is not about the color. It's about whether we make the bike shed of galvanized iron or aluminum. (actually aluminium because the book is British)
", "time": "2026-07-20T12:16:48.000Z"}, {"author": "Aaron Gable", "text": "Do we have any upki representatives to speak to their implementation plan / timeline?
", "time": "2026-07-20T12:19:48.000Z"}, {"author": "Viktor Dukhovni", "text": "@bob-beck signal chat me...
", "time": "2026-07-20T12:20:19.000Z"}, {"author": "Deb Cooley", "text": "@aarongable - mic?
", "time": "2026-07-20T12:20:54.000Z"}, {"author": "David Benjamin", "text": "Re randomizer, yeah, the mailing list discussion was inconclusive, so extensions are a way to strategically kick the can down the road. :-)
", "time": "2026-07-20T12:21:08.000Z"}, {"author": "Mike Ounsworth", "text": "David Benjamin said:
\n\n\nRe randomizer, yeah, the mailing list discussion was inconclusive, so extensions are a way to strategically kick the can down the road. :-)
\n
I'm asking to see the details so I can noodle on whether that's security-equivalent to randomized Serial.
", "time": "2026-07-20T12:21:57.000Z"}, {"author": "Bas Westerbaan", "text": "Did you read the thread, Mike? :)
", "time": "2026-07-20T12:22:25.000Z"}, {"author": "David Benjamin", "text": "Details would just be to allocate extension zero to have contents \"16 random bytes\" and you put that in every entry.
", "time": "2026-07-20T12:22:35.000Z"}, {"author": "Mike Ounsworth", "text": "Bas Westerbaan said:
\n\n\nDid you read the thread, Mike? :)
\n
Yes, I see that it has more replies than I can read while I'm setting here.
\nAm asking whether there is a section in the draft with the current proposal. Yes, or no?
instructions unclear, put \"16 random bytes\" into the extension
No, not in the current proposal.
", "time": "2026-07-20T12:24:42.000Z"}, {"author": "Bas Westerbaan", "text": "Happy to walk you through the details later.
", "time": "2026-07-20T12:25:00.000Z"}, {"author": "Bas Westerbaan", "text": "And of course we can add text to the security considerations if you feel it's not obvious
", "time": "2026-07-20T12:26:15.000Z"}, {"author": "David Benjamin", "text": "Re putting it in the serial, previously, we put randomizers in the serial number just because:
\nBut for MTC, we're defining a new structure that is being hashed so we can just define it to do whatever we want. So we're not forced to jam it into the serial.
", "time": "2026-07-20T12:26:53.000Z"}, {"author": "Mike Ounsworth", "text": "(I have now skimmed the email thread. I didn't see an obvious block of ASN.1 defn's + MUST's / SHOULD's. Is that in the email thread and I just missed it?)
", "time": "2026-07-20T12:27:08.000Z"}, {"author": "Dennis Jackson", "text": "Appeal to git is a novel strategy for pitching simplicity
", "time": "2026-07-20T12:29:52.000Z"}, {"author": "Sean Turner", "text": ":100:
", "time": "2026-07-20T12:30:15.000Z"}, {"author": "Daniel Gillmor", "text": "plus, git rebase is an incredible opportunity for concealing shennanigans in dev history
", "time": "2026-07-20T12:30:30.000Z"}, {"author": "Stefan Santesson", "text": "What prevents the act of reconciling a log from creating new forks that needs to be reconciled?
", "time": "2026-07-20T12:32:45.000Z"}, {"author": "Dennis Jackson", "text": "If mirrors get stuck, it may become an emergency due to paused issuance. If monitors get stuck, its a temporary loss of observability which is resolved when the monitor is fixed.
", "time": "2026-07-20T12:33:36.000Z"}, {"author": "Yoav Nir", "text": "I've spent way too long resolving conflicts from git rebase.
", "time": "2026-07-20T12:33:52.000Z"}, {"author": "Dennis Jackson", "text": "That suggests to me that keeping the mirrors simpler might be the way to go.
", "time": "2026-07-20T12:33:55.000Z"}, {"author": "Stephen Farrell", "text": "anyone planning any formal methods work on plants related things? eg. this stuff
", "time": "2026-07-20T12:34:04.000Z"}, {"author": "Devon O'Brien", "text": "I'm honestly a lot more interested in building ecosystem capability and agility to respond to a hosed log instead of introducing a complex graph-theoretic class of failure modes to an already error-prone ecosystem.
", "time": "2026-07-20T12:34:24.000Z"}, {"author": "David Benjamin", "text": "Fortunately, if we're wrong and this does turn out to be super easy (I'm dubious), we can set maxSerial to only allow one log and now log generations are a no-op.
", "time": "2026-07-20T12:35:51.000Z"}, {"author": "Bob Beck", "text": "presumably of course the CA won't be a jerk.
", "time": "2026-07-20T12:36:10.000Z"}, {"author": "Daniel Gillmor", "text": "plus, there are (at least) two different ways to do any reconciliation. are we going to fork based on which reconciliation choice was made?
", "time": "2026-07-20T12:36:42.000Z"}, {"author": "Mike Ounsworth", "text": "Stephen Farrell said:
\n\n\nanyone planning any formal methods work on plants related things? eg. this stuff
\n
Yeah. How do we convince ourselves that we've sufficiently considered all the edge-cases that need to be considered? Are we there already? How do we know?
", "time": "2026-07-20T12:37:02.000Z"}, {"author": "Robert Moskowitz", "text": "@MikeO: Is that by its nature, open ended?
", "time": "2026-07-20T12:37:54.000Z"}, {"author": "Robert Moskowitz", "text": "Is it really deterministic? Or non-deterministic.
", "time": "2026-07-20T12:38:43.000Z"}, {"author": "Bob Beck", "text": "Ooops we had a bug in our CA was auto forking the tree, but reconcillation made it invisible..
\nuntil the log fell over.
@BobMoskowitz -- Yes, but for example TLS 1.3 design + formal methods goes a long way to at least attempting to reach \"completeness\". I'm just musing out loud about what the equivalent bar is for the MTC design.
", "time": "2026-07-20T12:39:29.000Z"}, {"author": "Dennis Jackson", "text": "I do think we need the arch draft pronto. If only to concisely set out what the system is intended to achieve (when deployed 'correctly'). That will give the formal methods folks something to shoot at.
", "time": "2026-07-20T12:39:38.000Z"}, {"author": "Bas Westerbaan", "text": "Yeah, some manual friction in generations is actually a feature not a bug.
", "time": "2026-07-20T12:40:07.000Z"}, {"author": "Russ Housley", "text": "With major decisions behind us, an arch doc now seems do-able
", "time": "2026-07-20T12:40:31.000Z"}, {"author": "Stefan Santesson", "text": "What happens if a certificate gets stuck in a fork that eventually is abandoned, does that not just cause the certificate to fail validation. Does this needs to be fixed?
", "time": "2026-07-20T12:40:32.000Z"}, {"author": "Thom Wiggers", "text": "it should still be auditable that this stuck certificate ever existed
", "time": "2026-07-20T12:41:03.000Z"}, {"author": "Stephen Farrell", "text": "The timelines I recall for the TLSv1.3 analyses might impact on plants milestones. More importantly might conflict with announcements related to plants and timelines.
", "time": "2026-07-20T12:41:27.000Z"}, {"author": "Peter van Dijk", "text": "Total backseat driver here. How about something closer to git merge than git rebase? That gives us something visible
", "time": "2026-07-20T12:41:27.000Z"}, {"author": "Daniel Gillmor", "text": "i like Aaron's \"merge log entry\" more than the rebase.
", "time": "2026-07-20T12:41:36.000Z"}, {"author": "Stefan Santesson", "text": "And why ia that a problem. Not saying that it isn't
", "time": "2026-07-20T12:41:37.000Z"}, {"author": "Thom Wiggers", "text": "@Stefan: the first goal here transparency, to ensure CAs behave and don't create certificates for people they shouldn't be signing for
", "time": "2026-07-20T12:42:16.000Z"}, {"author": "Stefan Santesson", "text": "OK. Thanks.
", "time": "2026-07-20T12:42:34.000Z"}, {"author": "David Benjamin", "text": "ISTM that pairwise could still flipflop because rebase(A, B) != rebase(B, A).
", "time": "2026-07-20T12:43:35.000Z"}, {"author": "Dennis Jackson", "text": "image.png
\nShameless self citation for what transparency means
davidben realising some issue at the mic => maybe that formal analysis stuff's needed before deployment?
", "time": "2026-07-20T12:45:46.000Z"}, {"author": "Mike Ounsworth", "text": "\"What if the same serial number exists on two forks?\"
\n--> This is a problem introduced by removing strong random serial numbers, right? :thinking:
\nI would very much like to see the full proposal for non-random serials written out because I think the details matter!
So the \"invisible same serial number\" problem doesn't exist right now. The log generations strategy (intentionally!) makes it very visible.
", "time": "2026-07-20T12:47:39.000Z"}, {"author": "Felix Linker", "text": "Stephen Farrell said:
\n\n\ndavidben realising some issue at the mic => maybe that formal analysis stuff's needed before deployment?
\n
I would not advise to add a dependency on formal analysis :innocent: Though, formal analysis is definitely desirable
", "time": "2026-07-20T12:48:10.000Z"}, {"author": "Thom Wiggers", "text": "does a new generation point to \"this old generation was retired at point X\"?
", "time": "2026-07-20T12:48:27.000Z"}, {"author": "Bas Westerbaan", "text": "\n\nI would very much like to see the full proposal for non-random serials written out because I think the details matter!
\n
I haven't heard anyone propose before to reintroduce random serial numbers. Random serial numbers were a hack. We shouldn't bring them back as-is.
", "time": "2026-07-20T12:48:38.000Z"}, {"author": "Stephen Farrell", "text": "@felix: yeah it's tricky given the announced timelines. OTOH, discovering badness later could make us quite sad
", "time": "2026-07-20T12:49:00.000Z"}, {"author": "Aaron Gable", "text": "@Thom Wiggers No, but it could with a new log entry type. And that might help resolve the \"what if a CA tries to continue appending to a previous log generation\" concern.
", "time": "2026-07-20T12:49:48.000Z"}, {"author": "Mike Ounsworth", "text": "Bas Westerbaan said:
\n\n\nI haven't heard anyone propose before to reintroduce random serial numbers. Random serial numbers were a hack. We shouldn't bring them back as-is.
\n
Sure, and I'm not proposing to bring them back. I'm proposing that doing a differential security analysis relative to the properties of the X.509 that we've studied to death requires having the precise details of the new thing written down.
", "time": "2026-07-20T12:50:04.000Z"}, {"author": "Rich Salz", "text": "I'd be interested in (helping) with the arch document if everyone else is busy
", "time": "2026-07-20T12:51:09.000Z"}, {"author": "Bas Westerbaan", "text": "Perhaps a different proposal to consider: have an optional entry type to be added on a new log generation that contains the hash (or hashes) of the previous generation (forks.)
", "time": "2026-07-20T12:54:25.000Z"}, {"author": "Rich Salz", "text": "I do kinda like the reconciliation thing if it means we get log entry types '<<<<<<' etc
", "time": "2026-07-20T12:54:30.000Z"}, {"author": "Daniel Gillmor", "text": "Rich :joy:
", "time": "2026-07-20T12:54:52.000Z"}, {"author": "Bob Beck", "text": "pki rebase --hard
", "time": "2026-07-20T12:55:46.000Z"}, {"author": "Bob Beck", "text": "I was worried we would not get any bad plant puns
\nthank god someone remembered to keep their presentation up to standards.
I feel very silly now for forgetting haha.
", "time": "2026-07-20T12:57:27.000Z"}, {"author": "Aaron Gable", "text": "Is the idea here that the LDP is baked into the cert via extension, like the CRLDP today?
", "time": "2026-07-20T12:57:38.000Z"}, {"author": "Rich Salz", "text": "puns:PLANTS :: dadjokes:dads ?
", "time": "2026-07-20T12:57:43.000Z"}, {"author": "Bas Westerbaan", "text": "For those speaking at SAAG later: SAAG is Hindi for \"leafy greens\".
", "time": "2026-07-20T12:58:03.000Z"}, {"author": "Deb Cooley", "text": "is plants overgrown into saag?
", "time": "2026-07-20T12:58:33.000Z"}, {"author": "Bob Beck", "text": "and some people were annoyed at me for naming a draft leafy greens....
", "time": "2026-07-20T12:58:37.000Z"}, {"author": "Daniel Gillmor", "text": "certificate hierarchies and network availability: CHANA SAAG
", "time": "2026-07-20T13:00:14.000Z"}, {"author": "Aritra Banerjee", "text": "Now that's creative!
", "time": "2026-07-20T13:01:08.000Z"}, {"author": "Bas Westerbaan", "text": "John might kill Russ with those puns
", "time": "2026-07-20T13:02:04.000Z"}, {"author": "Bob Beck", "text": "+11 for puns.
", "time": "2026-07-20T13:02:35.000Z"}, {"author": "Jonathan Hammell", "text": "Will those draft branches be rebased in the future?
", "time": "2026-07-20T13:03:55.000Z"}, {"author": "Bob Beck", "text": "you mean pruned and grafted...
", "time": "2026-07-20T13:04:42.000Z"}, {"author": "Bas Westerbaan", "text": "I can answer how it's useful for downgrade detection. It's important to distinguish two kind of classical certs: the one to show a legacy client and the one to provision at a legacy server (that can't sign with PQ). It's only the latter case that causes a downgrade, but also you only need to issue that one if you have a legacy server. That does require a misissuance, but that can be detected with transparency.
", "time": "2026-07-20T13:05:32.000Z"}, {"author": "Bas Westerbaan", "text": "@Aaron Gable You can do even better compression with non-random serial numbers in MTC: https://github.com/bwesterb/go-ncrlite
", "time": "2026-07-20T13:06:18.000Z"}, {"author": "David Benjamin", "text": "saag will also talk a bit about this. https://www.chromium.org/Home/chromium-security/post-quantum-auth-roadmap/ has a write-up, but saag will have even more fun pictures. :-)
", "time": "2026-07-20T13:07:38.000Z"}, {"author": "David Benjamin", "text": "Bas Westerbaan said:
\n\n\nAaron Gable You can do even better compression with non-random serial numbers in MTC: https://github.com/bwesterb/go-ncrlite
\n
Yeah, it really feels like we could do nicer things with revocation now that our serials dense and ordered. Maybe size savings, maybe more natural sharding for CAs that want to keep their CDN pushes small, maybe something else.
", "time": "2026-07-20T13:11:03.000Z"}, {"author": "David Benjamin", "text": "(Isn't a plain counter how serials originally worked? I thought making them random was a later development.)
", "time": "2026-07-20T13:11:49.000Z"}, {"author": "Deb Cooley", "text": "This is true.
", "time": "2026-07-20T13:12:07.000Z"}, {"author": "Deb Cooley", "text": "It was added as a result of a hash that was less secure than we liked.
", "time": "2026-07-20T13:12:34.000Z"}, {"author": "Yoav Nir", "text": "That was the RapidSSL MD5 thing, right?
", "time": "2026-07-20T13:13:43.000Z"}, {"author": "Russ Housley", "text": "The random was added to the serial because of the Bleichenbacher Attack
", "time": "2026-07-20T13:14:05.000Z"}, {"author": "Deb Cooley", "text": "To make the 'next certificate' issued be less predictable.
", "time": "2026-07-20T13:14:55.000Z"}, {"author": "Russ Housley", "text": "Yep
", "time": "2026-07-20T13:15:32.000Z"}, {"author": "Aaron Gable", "text": "In summary: x509v3 still doesn't require serial randomness; the CA/BF Baseline Requirements require it. It was introduced in 2016 (Ballot 164) as a result of chosen-prefix attacks against MD5.
\nhttps://cabforum.org/2016/03/31/ballot-164-certificate-serial-number-entropy/
Yeah, because RapidSSL used a serial serial number, so the attackers could predict (and manipulate by requesting certificates) the serial number of the rogue certificate.
", "time": "2026-07-20T13:16:07.000Z"}, {"author": "Bas Westerbaan", "text": "Those numbers are actually quite a bit better than I expected.
", "time": "2026-07-20T13:16:22.000Z"}, {"author": "Devon O'Brien", "text": "It was also sheer luck that serial number was in the right place in the certificate (i.e. before the key) and had the right format/shape/purpose to store some entropy
", "time": "2026-07-20T13:16:40.000Z"}, {"author": "Bas Westerbaan", "text": "Bas Westerbaan said:
\n\n\nThose numbers are actually quite a bit better than I expected.
\n
Still a terrifying long way to go.
", "time": "2026-07-20T13:16:51.000Z"}, {"author": "Devon O'Brien", "text": "This was not a principled decision by any means
", "time": "2026-07-20T13:16:53.000Z"}, {"author": "Deb Cooley", "text": "right. The other option was to add random to the fast moving parts of the 'not before' and 'not after'.
", "time": "2026-07-20T13:17:17.000Z"}, {"author": "Deb Cooley", "text": "(was my pref)
", "time": "2026-07-20T13:17:37.000Z"}, {"author": "Josh G", "text": "hard to know if what's been migrated is what's easiest to migrate, or the most important
", "time": "2026-07-20T13:18:06.000Z"}, {"author": "Aaron Gable", "text": "Heh, sorry, Let's Encrypt is \"doing this four certificate business\" right now. It's necessary for any CA which is trying to support both old (trusted by out-of-date clients only) and new (trusted by up-to-date clients only) roots simultaneously.
", "time": "2026-07-20T13:20:51.000Z"}, {"author": "Bob Beck", "text": "in private pki (speaking from a consultant role in past lives) four and more is usually some form of encoding your org chart into your certificate chain.
", "time": "2026-07-20T13:21:40.000Z"}, {"author": "David Benjamin", "text": "How to deal with old vs new clients, the perennial PKI problem. :-)
", "time": "2026-07-20T13:22:18.000Z"}, {"author": "Daniel Gillmor", "text": "perennial IETF problem
", "time": "2026-07-20T13:22:28.000Z"}, {"author": "Daniel Gillmor", "text": "\"the curse of the deployed base\"
", "time": "2026-07-20T13:22:53.000Z"}, {"author": "Dennis Jackson", "text": "\"What are these people doing in my tent? How do I get them to leave? What will happen to them if they are chucked out?\"
", "time": "2026-07-20T13:23:25.000Z"}, {"author": "Dennis Jackson", "text": "(overheard at the IETF)
", "time": "2026-07-20T13:23:52.000Z"}, {"author": "Daniel Gillmor", "text": "it's usually more like \"what will happen to my tent if they are chucked out?\"
", "time": "2026-07-20T13:24:50.000Z"}, {"author": "Mike Ounsworth", "text": "Deb Cooley said:
\n\n\nTo make the 'next certificate' issued be less predictable.
\n
I'm curious to think through the implications of being able to predict a future not-yet-issued leaf of the Merkle tree -- ie what is the bad thing that happens if you don't have randomness in the MTC leaf? My intuition is that the bad thing here is quite a bit different from the bad thing in traditional X.509 (which largely boils down to RSA / ECDSA hash collisions).
", "time": "2026-07-20T13:27:26.000Z"}, {"author": "David Benjamin", "text": "It's ultimately the same thing: how strong do you believe your hash is. If your hash is collision-resistant, it's fine.
", "time": "2026-07-20T13:28:31.000Z"}, {"author": "David Benjamin", "text": "One hopes we're no longer playing with MD5 anymore. For SHA-256... if a 256-bit hash does not give you enough bits of collision resistance for you, then maybe you want the randomizer.
", "time": "2026-07-20T13:29:07.000Z"}, {"author": "Daniel Gillmor", "text": "agreed, the only problem motivating randomized IDs was MD5's collision-resistance failure
", "time": "2026-07-20T13:29:16.000Z"}, {"author": "Aaron Gable", "text": "Also, you'd have to predict the entire checkpoint subtree, not just a single entry.
", "time": "2026-07-20T13:29:45.000Z"}, {"author": "Mike Ounsworth", "text": "David Benjamin said:
\n\n\nIt's ultimately the same thing: how strong do you believe your hash is. If your hash is collision-resistant, it's fine.
\n
I don't follow this. If I know the exact value of a future MTC leaf, then I run the hash _forward_ to build an inclusion proof for this not-yet-issued leaf, which is a thing that my intuition tells me shouldn't be good. Since this is not a collision attack, I'm not following how using a collision-resistant hash protects you?
", "time": "2026-07-20T13:29:57.000Z"}, {"author": "David Benjamin", "text": "(Re number of bits, personally, I don't really believe in counting to 2^128. I have a low attention span and will get bored before then. But opinions vary.)
", "time": "2026-07-20T13:30:19.000Z"}, {"author": "Andrew Dolan", "text": "Along with the idea of a deployment guidance, and perhaps to be paired with the use cases draft, I'd like to see a good side by side breakdown of MTC sizes, particularly between where you do and don't have landmark relative certs. IIRC the MTC draft has some of this started already (estimates)
", "time": "2026-07-20T13:32:49.000Z"}, {"author": "David Benjamin", "text": "Mike Ounsworth said:
\n\n\nDavid Benjamin said:
\n\n\nIt's ultimately the same thing: how strong do you believe your hash is. If your hash is collision-resistant, it's fine.
\nI don't follow this. If I know the exact value of a future MTC leaf, then I run the hash _forward_ to build an inclusion proof for this not-yet-issued leaf, which is a thing that my intuition tells me shouldn't be good. And I don't think that requires collision-resistance of the hash?
\n
If you could collide the hash and control attacker.example, you can find a colliding pair A and B, where A has SANs attacker.example and B has SANs target.example. You present the first one to the CA, get them to sign it, but actually that certificate also certifies B. And now you've caused the CA to certify an unauthorized cert for target.example.
Sure. Collision attacks against MTC are clearly bad in exactly the same way as for traditional X.509.
\nWhat I'm questioning is your assertion that collision attacks are the only class of attacks that the randomness is protecting against.
\nMy intuition is telling me that there are some Merle tree specific attacks that the randomness is also helping with (ie randomness helps with attacks that don't have regular-X.509 analogs).
Oh I see. Not sure I'm following your attack, but maybe I'm not reading it right. You could certainly compute what the inclusion proof would have been if the next entry is xyz. But that inclusion proof will lead to a root hash that presumably wasn't signed by the CA.
", "time": "2026-07-20T13:35:47.000Z"}, {"author": "Daniel Gillmor", "text": "what's the other attack, Mike?
", "time": "2026-07-20T13:35:52.000Z"}, {"author": "David Benjamin", "text": "(Or a subtree. But one way or another, we only accept the tree hashes that are somehow authenticated by the CA.)
", "time": "2026-07-20T13:36:38.000Z"}, {"author": "Bas Westerbaan", "text": "@Mike Ounsworth To be very clear, the randomizer is not necessary for MTC as-is at 128-bit security level, because SHA2 is a good hash.
", "time": "2026-07-20T13:37:33.000Z"}, {"author": "Mike Ounsworth", "text": "Daniel Gillmor said:
\n\n\nwhat's the other attack, Mike?
\n
I don't know. Maybe (hopefully) there isn't one.
\nMy ENTIRE point here is that since the details of the randomness scheme (including the security model of the attacks it's intending to protect against) doesn't seem to have been written down yet, it's a bit difficult to construct an attack against it, or state that there isn't one. :yum:
The randomizer lives in a weird place. The kinds of people that have weird excessive requirements are going to want a different hash anyway (IMO)
", "time": "2026-07-20T13:38:45.000Z"}, {"author": "Bas Westerbaan", "text": "By the way, Andy H\u00fclsing who replied in the thread, is the world expert on this kind of stuff.
", "time": "2026-07-20T13:39:08.000Z"}]