[Deployment] ML-DSA-65 as the default signature for a federated identity and content-provenance protocol (TIP)
277 views
Skip to first unread message
Dinesh Mendhe
Jun 24, 2026, 6:38:36 PMJun 24
to pqc-forum
Hello wonderful pqc team,
Thank you,
I am the inventor of the Trust Identity Protocol (TIP), an open standard for verified-human identity and AI content provenance, published by The AI Lab Intelligence Unobscured, Inc. under CC BY 4.0.
The whitepaper (v5.0, 140 pages) is at Zenodo: https://doi.org/10.5281/zenodo.20722378
I am writing because TIP has adopted the FIPS 203 / 204 / 205 suite as its only signature and KEM primitives, and I would value feedback from this list before we commission a formal audit later this year.
Specifically:
Specifically:
- Default content and identity signatures: ML-DSA-65 (FIPS 204, Category 3). Chosen for the balance of signature size (3,309 bytes) against the 1024 / 1280 / 1952 byte trade-offs at Cat 1 / 5.
- Key encapsulation for verifier-to-issuer session keys: ML-KEM-768 (FIPS 203, Category 3).
- Hash-based fallback signatures for long-archive content (anything intended to verify past 50 years): SLH-DSA-SHA2-128s (FIPS 205), accepting the ~7,856 byte signature cost in exchange for hash-only security assumptions.
Three questions I would value the list's perspective on:
1. ML-DSA-65 at Category 3 vs ML-DSA-87 at Category 5 for content signatures: the protocol is designed for human-published content with a verification horizon of ~50 years. Category 3 reads as a reasonable trade against the 4,627 byte Cat 5 signature for the bandwidth and storage envelope we expect, but I would welcome pushback on that choice from anyone who has modelled the long-horizon risk differently.
2. SLH-DSA parameter selection for archive: SLH-DSA-SHA2-128s gives the smallest signatures in the FIPS 205 menu but the slowest signing. Our use case signs once and verifies many times over decades, so we picked -s. Anyone who has run the implementation cost analysis against -f and disagrees?
3. Public-key fingerprint scheme: we are using SHA3-256 truncated to 128 bits as the human-displayable fingerprint for TIP-ID public keys (4 groups of 4 hex chars).
Comments welcome on whether the 128-bit truncation is appropriate against second-preimage attacks in a registry-lookup threat model.
2. SLH-DSA parameter selection for archive: SLH-DSA-SHA2-128s gives the smallest signatures in the FIPS 205 menu but the slowest signing. Our use case signs once and verifies many times over decades, so we picked -s. Anyone who has run the implementation cost analysis against -f and disagrees?
3. Public-key fingerprint scheme: we are using SHA3-256 truncated to 128 bits as the human-displayable fingerprint for TIP-ID public keys (4 groups of 4 hex chars).
Comments welcome on whether the 128-bit truncation is appropriate against second-preimage attacks in a registry-lookup threat model.
I would rather hear the technical objection now than after publication. Replies on the list or off-list are both fine.
Thank you,
Dinesh Mendhe
Founder, theailab.org
The AI Lab Intelligence Unobscured, Inc.
Raymond Chang
Jun 24, 2026, 9:40:21 PMJun 24
to Dinesh Mendhe, pqc-forum
Subject: Re: [pqc-forum] [Deployment] ML-DSA-65 as the default signature for a federated identity and content-provenance protocol (TIP)
Dinesh,
Thanks for putting the parameters out for review before the audit. The sizes you cite for ML-DSA-65 (3309 B), ML-DSA-87 (4627 B), and SLH-DSA-SHA2-128s (7856 B) all check out, and wanting the objections now rather than after publication is the right call. A few comments, strongest first.
On the fingerprint (your Q3). Two things.
First, a units check: "128 bits" and "4 groups of 4 hex chars" don't match. Four groups of four hex characters is 16 hex digits, so 64 bits. Worth confirming which you actually mean, because it changes the security argument a lot.
Second, and this is the bigger one: I'd analyze this as a collision problem, not a second-preimage one. Second-preimage (finding a second key that matches one specific, already-registered fingerprint) sits at ~2^n and is fine at 128 bits. But in a registry where an attacker generates their own keypairs, the cheaper attack is a collision: grind your own keys until two share a fingerprint, then exploit the ambiguity. That's a birthday bound, ~2^(n/2). So 128 bits buys ~64-bit collision resistance, and 64 bits buys ~32-bit, which is grindable on a laptop. The short key-ID collisions in OpenPGP are the precedent to look at. Whether 64-bit collision resistance is good enough is a threat-model decision, but that's the number to size against, and it's half of what the second-preimage view suggests.
On the archive parameter (your Q2). The -s over -f reasoning is sound for sign-once / verify-many. What I'd flag is the category rather than the s/f choice. SLH-DSA-SHA2-128s is NIST Category 1, while your content layer (ML-DSA-65) is Category 3, so the layer you mean as the multi-decade anchor is sitting a category below your everyday content signatures. If the archive layer is supposed to be the conservative floor, SLH-DSA-SHA2-192s keeps the -s properties you want and lands at Category 3, matching the content layer. (Separately, ML-DSA only has Categories 2/3/5, so the "Cat 1" reference earlier looks like a slip worth fixing before the audit.)
On ML-DSA-65 vs ML-DSA-87 (your Q1). Cat 3 as the default is a defensible, common choice, and for the bandwidth envelope you describe I wouldn't argue with it. The part I'd question is the framing of the long-horizon worry. At a 50-year horizon, the gap between Cat 3 and Cat 5 isn't where the real risk lives; what could actually break this is cryptanalytic progress against the lattice assumptions themselves, and Cat 5 barely helps there. Your hedge against that is the hash-based fallback, which you already have. So I'd turn the question around: rather than "should content be Cat 5," ask whether anything with a genuine multi-decade verification horizon should be on the SLH-DSA path at all rather than ML-DSA, and where the line between your ~50-year content layer and your >50-year archive layer should actually fall. Right now that boundary reads as fairly arbitrary.
Happy to expand on any of these off-list.
Raymond Chang
Codebat (codebat.ai)
Dinesh,
Thanks for putting the parameters out for review before the audit. The sizes you cite for ML-DSA-65 (3309 B), ML-DSA-87 (4627 B), and SLH-DSA-SHA2-128s (7856 B) all check out, and wanting the objections now rather than after publication is the right call. A few comments, strongest first.
On the fingerprint (your Q3). Two things.
First, a units check: "128 bits" and "4 groups of 4 hex chars" don't match. Four groups of four hex characters is 16 hex digits, so 64 bits. Worth confirming which you actually mean, because it changes the security argument a lot.
Second, and this is the bigger one: I'd analyze this as a collision problem, not a second-preimage one. Second-preimage (finding a second key that matches one specific, already-registered fingerprint) sits at ~2^n and is fine at 128 bits. But in a registry where an attacker generates their own keypairs, the cheaper attack is a collision: grind your own keys until two share a fingerprint, then exploit the ambiguity. That's a birthday bound, ~2^(n/2). So 128 bits buys ~64-bit collision resistance, and 64 bits buys ~32-bit, which is grindable on a laptop. The short key-ID collisions in OpenPGP are the precedent to look at. Whether 64-bit collision resistance is good enough is a threat-model decision, but that's the number to size against, and it's half of what the second-preimage view suggests.
On the archive parameter (your Q2). The -s over -f reasoning is sound for sign-once / verify-many. What I'd flag is the category rather than the s/f choice. SLH-DSA-SHA2-128s is NIST Category 1, while your content layer (ML-DSA-65) is Category 3, so the layer you mean as the multi-decade anchor is sitting a category below your everyday content signatures. If the archive layer is supposed to be the conservative floor, SLH-DSA-SHA2-192s keeps the -s properties you want and lands at Category 3, matching the content layer. (Separately, ML-DSA only has Categories 2/3/5, so the "Cat 1" reference earlier looks like a slip worth fixing before the audit.)
On ML-DSA-65 vs ML-DSA-87 (your Q1). Cat 3 as the default is a defensible, common choice, and for the bandwidth envelope you describe I wouldn't argue with it. The part I'd question is the framing of the long-horizon worry. At a 50-year horizon, the gap between Cat 3 and Cat 5 isn't where the real risk lives; what could actually break this is cryptanalytic progress against the lattice assumptions themselves, and Cat 5 barely helps there. Your hedge against that is the hash-based fallback, which you already have. So I'd turn the question around: rather than "should content be Cat 5," ask whether anything with a genuine multi-decade verification horizon should be on the SLH-DSA path at all rather than ML-DSA, and where the line between your ~50-year content layer and your >50-year archive layer should actually fall. Right now that boundary reads as fairly arbitrary.
Happy to expand on any of these off-list.
Raymond Chang
Codebat (codebat.ai)
--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.
To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/3f127e21-3669-48cd-ad3f-4d72bd4ce302n%40list.nist.gov.
Dinesh Mendhe
Jun 24, 2026, 11:31:39 PMJun 24
to Raymond Chang, pqc-forum
Raymond, Thank you for the careful read.
All three points land, and in the order you ranked them.
On the fingerprint (Q3):
On the fingerprint (Q3):
You are right on both counts. The "128 bits" and the "4 groups of 4 hex chars" in my post contradicted each other; 4 x 4 hex digits is 64 bits, and 64 is what is actually in the spec text. The 128 was a transcription slip in the post. So the real number is worse than I described.
And you are right that the threat model is collision, not second-preimage. The registry is the lookup side: if an attacker can grind two keypairs whose fingerprints collide, they swap identity claims under registry ambiguity, and that is the cheaper attack.
At 64 bits the birthday bound is roughly 2^32, which is grindable on a laptop, exactly as you say. Evil32 and the older OpenPGP short-key-ID confusions are the right precedent. Fix path I am taking back to the working group. First, raise the on-the-wire fingerprint to 128 bits (32 hex digits), so the birthday bound on a registry-grinding adversary is roughly 2^64.
That is a defensible floor against commodity-hardware grinding over the registration window. TIP-ID also binds a Verification Provider attestation to the public key at issuance time, so a successful grind has to clear both the fingerprint match and the VP's identity proof; the fingerprint width is the cryptographic floor, not the entire defence.
Second, display the 128-bit fingerprint as two lines of 16 hex characters, not one compressed line. The original reason for going short was the human-display constraint, and two lines is still a single glance. Open question I would value pushback on: is 128 bits the right floor, or does the registry threat model justify 160 bits (Tor v3 onion-service territory, roughly 2^80 collision resistance, at the cost of a third line on display)?
I am inclined toward 128 as the default with a 160-bit option for institutional registrants, but I want to hear the argument against.
And you are right that the threat model is collision, not second-preimage. The registry is the lookup side: if an attacker can grind two keypairs whose fingerprints collide, they swap identity claims under registry ambiguity, and that is the cheaper attack.
At 64 bits the birthday bound is roughly 2^32, which is grindable on a laptop, exactly as you say. Evil32 and the older OpenPGP short-key-ID confusions are the right precedent. Fix path I am taking back to the working group. First, raise the on-the-wire fingerprint to 128 bits (32 hex digits), so the birthday bound on a registry-grinding adversary is roughly 2^64.
That is a defensible floor against commodity-hardware grinding over the registration window. TIP-ID also binds a Verification Provider attestation to the public key at issuance time, so a successful grind has to clear both the fingerprint match and the VP's identity proof; the fingerprint width is the cryptographic floor, not the entire defence.
Second, display the 128-bit fingerprint as two lines of 16 hex characters, not one compressed line. The original reason for going short was the human-display constraint, and two lines is still a single glance. Open question I would value pushback on: is 128 bits the right floor, or does the registry threat model justify 160 bits (Tor v3 onion-service territory, roughly 2^80 collision resistance, at the cost of a third line on display)?
I am inclined toward 128 as the default with a 160-bit option for institutional registrants, but I want to hear the argument against.
On the archive layer (Q2):
You are right about the category mismatch. SLH-DSA-SHA2-128s is Category 1; the everyday content signature (ML-DSA-65) is Category 3. The intent was for the archive layer to be the conservative floor, so sitting it a category below the content layer is exactly backwards.
The fix is SLH-DSA-SHA2-192s, which preserves the small (-s) sign-once verify-many trade-off and lands the archive layer at Category 3, matching the content layer. The signature size cost is roughly 16 KB instead of 8 KB, which is fine for the archive use case (we are signing the manifest of a publishable artefact, not the artefact itself, and we sign it once).
I will update the spec to SLH-DSA-SHA2-192s before audit.
The fix is SLH-DSA-SHA2-192s, which preserves the small (-s) sign-once verify-many trade-off and lands the archive layer at Category 3, matching the content layer. The signature size cost is roughly 16 KB instead of 8 KB, which is fine for the archive use case (we are signing the manifest of a publishable artefact, not the artefact itself, and we sign it once).
I will update the spec to SLH-DSA-SHA2-192s before audit.
On the ML-DSA category labels:
Caught. ML-DSA defines Categories 2, 3, and 5 (ML-DSA-44, -65, -87, respectively). The "Cat 1" reference in my post should have been Cat 2. The spec text has the labels right; the list post was the typo.
I will note the correction in the whitepaper changelog when the next revision lands so the public record reads cleanly.
Caught. ML-DSA defines Categories 2, 3, and 5 (ML-DSA-44, -65, -87, respectively). The "Cat 1" reference in my post should have been Cat 2. The spec text has the labels right; the list post was the typo.
I will note the correction in the whitepaper changelog when the next revision lands so the public record reads cleanly.
On Q1 framing:
This is the most important part of your reply for the design, and I want to think with you on it rather than respond fast. You are right that the gap between Cat 3 and Cat 5 is not where the real risk lives at a 50-year horizon. If the lattice assumption breaks, Cat 5 buys very little.
The honest hedge is the hash-based fallback, and the question I should be asking is where the boundary between the lattice layer and the hash layer falls. The current design treats the ML-DSA layer as the everyday content path (5 to 50 year verification horizon) and the SLH-DSA layer as the archive path (50 years and above, or sovereign claims: notary attestations, government documents, scientific record). Your framing makes me want to revisit two things before audit. The first is whether anything with a genuine multi-decade verification horizon should default to ML-DSA at all.
The current spec lets a publisher elect to dual-sign with SLH-DSA-192s as a belt-and-suspenders option, but does not require it. A stricter rule would be: any content tagged as part of the institutional or public-record corpus signs with both ML-DSA-65 (for everyday verification cost) and SLH-DSA-192s (for the long-horizon hedge), mandatory not optional.
The second is whether the boundary between the two layers should be content-type-driven (as it is now) or horizon-driven (the publisher declares an intended verification horizon at sign time, and the protocol chooses the primitive). Horizon-driven has the appeal of forcing publishers to think about what they are claiming. It has the cost of giving them a knob they may set wrongly. I would value your read on which boundary is the more defensible one before audit, on or off list.
The dual-sign-by-default rule for institutional content feels like the right floor to me, but I want to test that against your sign-once / verify-many framing more carefully. I will fold all four updates (fingerprint width, fingerprint threat model, SLH-DSA-192s for archive, ML-DSA category corrections) into the next whitepaper revision and post the diff back to the list when it is published.
The honest hedge is the hash-based fallback, and the question I should be asking is where the boundary between the lattice layer and the hash layer falls. The current design treats the ML-DSA layer as the everyday content path (5 to 50 year verification horizon) and the SLH-DSA layer as the archive path (50 years and above, or sovereign claims: notary attestations, government documents, scientific record). Your framing makes me want to revisit two things before audit. The first is whether anything with a genuine multi-decade verification horizon should default to ML-DSA at all.
The current spec lets a publisher elect to dual-sign with SLH-DSA-192s as a belt-and-suspenders option, but does not require it. A stricter rule would be: any content tagged as part of the institutional or public-record corpus signs with both ML-DSA-65 (for everyday verification cost) and SLH-DSA-192s (for the long-horizon hedge), mandatory not optional.
The second is whether the boundary between the two layers should be content-type-driven (as it is now) or horizon-driven (the publisher declares an intended verification horizon at sign time, and the protocol chooses the primitive). Horizon-driven has the appeal of forcing publishers to think about what they are claiming. It has the cost of giving them a knob they may set wrongly. I would value your read on which boundary is the more defensible one before audit, on or off list.
The dual-sign-by-default rule for institutional content feels like the right floor to me, but I want to test that against your sign-once / verify-many framing more carefully. I will fold all four updates (fingerprint width, fingerprint threat model, SLH-DSA-192s for archive, ML-DSA category corrections) into the next whitepaper revision and post the diff back to the list when it is published.
Thanks again for the time.
Raymond Chang
Jun 25, 2026, 1:12:34 AMJun 25
to Dinesh Mendhe, pqc-forum
Dinesh,
Glad it was useful. Quick takes on your two open questions, then I'll let you carry the diff back to the list.
Fingerprint width. I'd go 160. And I'd treat the VP-attestation binding as defence-in-depth, not as a reason to keep the fingerprint short. The width only becomes the binding parameter where the fingerprint stands alone as the identifier: someone reading it off a screen, comparing two by eye, pasting it without the attestation in the loop. Human-displayable identifiers get used that way regardless of what the protocol intends, which is exactly the Evil32 lesson. So size it for the standalone case, because that's the case you can't enforce away.
Two things push me past 128 specifically. First, this is a protocol built around multi-decade horizons, and a 2^64 collision floor only gets cheaper over the exact window you're designing for; grindable on a laptop cluster today is worse in twenty years. Second, fingerprint width is close to unchangeable once registries and displays are populated, so it's the wrong place to economise. 2^80 for one extra display line is cheap insurance on a parameter you're stuck with. If anything, your 128-default / 160-institutional split runs the wrong way: institutional registrants have the strongest VP binding, so they're the better-covered class, while the casual standalone uses are the exposed ones.
Boundary. Go content-type, and make the dual-sign rule mandatory for the institutional / public-record corpus rather than optional. A declared horizon puts the security-critical choice at sign time, when the publisher knows least about the future and is most tempted to pick the smaller signature. A content-type or corpus tag is observable and auditable after the fact; a declared horizon is just an assertion.
Your dual-sign instinct is right, and partly because it dissolves the boundary problem instead of solving it. Content that signs both ways never has to predict a horizon. Under sign-once / verify-many the cost lands where it's affordable: you pay the SLH-DSA-192s signing cost once at publication, carry one larger manifest signature, and everyday verification still runs on the cheap ML-DSA path, with the hash-based signature sitting there as the durable fallback. Keep a horizon field if you want one, but as advisory metadata, never as the switch that picks the primitive.
Content-type tags can still be gamed by mis-classifying to dodge the dual-sign cost. But that's an auditable failure, and the cost is low enough that the incentive is weak. A wrong horizon guess is invisible until the day it matters.
Look forward to the diff when it lands.
Raymond Chang
Codebat (codebat.ai)
Glad it was useful. Quick takes on your two open questions, then I'll let you carry the diff back to the list.
Fingerprint width. I'd go 160. And I'd treat the VP-attestation binding as defence-in-depth, not as a reason to keep the fingerprint short. The width only becomes the binding parameter where the fingerprint stands alone as the identifier: someone reading it off a screen, comparing two by eye, pasting it without the attestation in the loop. Human-displayable identifiers get used that way regardless of what the protocol intends, which is exactly the Evil32 lesson. So size it for the standalone case, because that's the case you can't enforce away.
Two things push me past 128 specifically. First, this is a protocol built around multi-decade horizons, and a 2^64 collision floor only gets cheaper over the exact window you're designing for; grindable on a laptop cluster today is worse in twenty years. Second, fingerprint width is close to unchangeable once registries and displays are populated, so it's the wrong place to economise. 2^80 for one extra display line is cheap insurance on a parameter you're stuck with. If anything, your 128-default / 160-institutional split runs the wrong way: institutional registrants have the strongest VP binding, so they're the better-covered class, while the casual standalone uses are the exposed ones.
Boundary. Go content-type, and make the dual-sign rule mandatory for the institutional / public-record corpus rather than optional. A declared horizon puts the security-critical choice at sign time, when the publisher knows least about the future and is most tempted to pick the smaller signature. A content-type or corpus tag is observable and auditable after the fact; a declared horizon is just an assertion.
Your dual-sign instinct is right, and partly because it dissolves the boundary problem instead of solving it. Content that signs both ways never has to predict a horizon. Under sign-once / verify-many the cost lands where it's affordable: you pay the SLH-DSA-192s signing cost once at publication, carry one larger manifest signature, and everyday verification still runs on the cheap ML-DSA path, with the hash-based signature sitting there as the durable fallback. Keep a horizon field if you want one, but as advisory metadata, never as the switch that picks the primitive.
Content-type tags can still be gamed by mis-classifying to dodge the dual-sign cost. But that's an auditable failure, and the cost is low enough that the incentive is weak. A wrong horizon guess is invisible until the day it matters.
Look forward to the diff when it lands.
Raymond Chang
Codebat (codebat.ai)
Demi Marie Obenour
Jul 25, 2026, 12:46:02 AM (3 days ago) Jul 25
to Raymond Chang, Dinesh Mendhe, pqc-forum
On 6/25/26 01:11, Raymond Chang wrote:
> Dinesh,
>
> Glad it was useful. Quick takes on your two open questions, then I'll let
> you carry the diff back to the list.
>
> Fingerprint width. I'd go 160. And I'd treat the VP-attestation binding as
> defence-in-depth, not as a reason to keep the fingerprint short. The width
> only becomes the binding parameter where the fingerprint stands alone as
> the identifier: someone reading it off a screen, comparing two by eye,
> pasting it without the attestation in the loop. Human-displayable
> identifiers get used that way regardless of what the protocol intends,
> which is exactly the Evil32 lesson. So size it for the standalone case,
> because that's the case you can't enforce away.
>
> Two things push me past 128 specifically. First, this is a protocol built
> around multi-decade horizons, and a 2^64 collision floor only gets cheaper
> over the exact window you're designing for; grindable on a laptop cluster
> today is worse in twenty years. Second, fingerprint width is close to
> unchangeable once registries and displays are populated, so it's the wrong
> place to economise. 2^80 for one extra display line is cheap insurance on a
> parameter you're stuck with. If anything, your 128-default /
> 160-institutional split runs the wrong way: institutional registrants have
> the strongest VP binding, so they're the better-covered class, while the
> casual standalone uses are the exposed ones.
160 bits isn't enough to prevent collisions. 2^80 is a lot of work,
> Dinesh,
>
> Glad it was useful. Quick takes on your two open questions, then I'll let
> you carry the diff back to the list.
>
> Fingerprint width. I'd go 160. And I'd treat the VP-attestation binding as
> defence-in-depth, not as a reason to keep the fingerprint short. The width
> only becomes the binding parameter where the fingerprint stands alone as
> the identifier: someone reading it off a screen, comparing two by eye,
> pasting it without the attestation in the loop. Human-displayable
> identifiers get used that way regardless of what the protocol intends,
> which is exactly the Evil32 lesson. So size it for the standalone case,
> because that's the case you can't enforce away.
>
> Two things push me past 128 specifically. First, this is a protocol built
> around multi-decade horizons, and a 2^64 collision floor only gets cheaper
> over the exact window you're designing for; grindable on a laptop cluster
> today is worse in twenty years. Second, fingerprint width is close to
> unchangeable once registries and displays are populated, so it's the wrong
> place to economise. 2^80 for one extra display line is cheap insurance on a
> parameter you're stuck with. If anything, your 128-default /
> 160-institutional split runs the wrong way: institutional registrants have
> the strongest VP binding, so they're the better-covered class, while the
> casual standalone uses are the exposed ones.
but the Bitcoin network's output is far higher. It's true that Bitcoin
ASICs can't be repurposed, but I think their output is enough to show
that 2^80 work is insufficient.
Furthermore, humans are inherently imprecise. A near-collision (where
all but a few bits of the output are the same) is likely enough to
fool many of them. Longer fingerprints make that much harder.
OpenPGP has switched to 256-bit fingerprints and I recommend doing
the same. 512-bit might be even better.
I also recommend having a mapping from fingerprints to both QR codes
and human-readable words. QR codes allow easy verification by a
device with a camera and QR reader software, and human-readable words
can be easily read and compared.
> Boundary. Go content-type, and make the dual-sign rule mandatory for the
> institutional / public-record corpus rather than optional. A declared
> horizon puts the security-critical choice at sign time, when the publisher
> knows least about the future and is most tempted to pick the smaller
> signature. A content-type or corpus tag is observable and auditable after
> the fact; a declared horizon is just an assertion.
>
> Your dual-sign instinct is right, and partly because it dissolves the
> boundary problem instead of solving it. Content that signs both ways never
> has to predict a horizon. Under sign-once / verify-many the cost lands
> where it's affordable: you pay the SLH-DSA-192s signing cost once at
> publication, carry one larger manifest signature, and everyday verification
> still runs on the cheap ML-DSA path, with the hash-based signature sitting
> there as the durable fallback. Keep a horizon field if you want one, but as
> advisory metadata, never as the switch that picks the primitive.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
Reply all
Reply to author
Forward
0 new messages