Re: Call for Co-Editors: Post-Quantum Migration Pattern for Verifiable Credentials (Ed25519 + ML-DSA Dual-Signature Model)

Thanks Stephen and Sylvain for sharing these numbers and perspectives.

I think these kinds of implementation experiments are incredibly valuable
because they give us something concrete to reason about instead of relying
on assumptions. They expose the engineering constraints that eventually
shape good cryptographic systems.

Sylvain also makes an important point—the observed overhead is a property
of one PQC candidate, not necessarily PQC itself. That is exactly why
benchmarking different approaches matters.

One thing I've always found interesting is that constraints usually lead to
innovation and optimization. Instead of searching for a single perfect
algorithm, perhaps the better objective is to design migration patterns
that are inherently crypto-agile and allow communities to mix and match
primitives while understanding the tradeoffs. Signature size, verification
performance, storage growth, implementation complexity, interoperability,
deployment costs—all of these become part of the design space.

For me, ML-DSA here is simply one data point. The more interesting question
is how we design migration patterns that remain flexible enough to
accommodate today's choices and tomorrow's improvements without forcing
disruptive ecosystem changes.

I'm curious how others are approaching this. If you were designing a
long-lived cryptographic system today, what operational constraints would
you optimize for first? Signature size? Verification throughput? Storage
growth? Implementation simplicity? Algorithm agility? Or is there another
metric that deserves more attention than we typically give it?

I suspect collecting experiences from different protocols and deployments
could help us identify common patterns and perhaps arrive at migration
strategies that serve the broader cryptographic community rather than any
particular algorithm.

--Amir Hameed Mir

On Sun, 14 Jun 2026 at 11:53, sylvain cormier <sylvain@paraxiom.org> wrote:

> Good data point, Stephen — One thing worth flagging so the 10x doesn't get
> read as "the PQC cost" in general: that size/perf hit is largely an
> ML-DSA-44 characteristic. Among the NIST signatures, ML-DSA-44 is on the
> heavy end for size — Falcon-512 signatures are roughly 3.6x smaller (~666
> vs ~2420 bytes), which for a log-based method like did:webvh would
> meaningfully cut the per-entry and resolution overhead you measured. It's a
> genuine tradeoff, not a free win — Falcon has trickier (floating-point,
> constant-time) signing and some weaker BUFF properties (exclusive ownership
> / non-resignability) that matter in a long-lived log context. But for
> size-sensitive logs it's probably worth benchmarking alongside ML-DSA-44
> before the spec settles on the PQC profile. Happy to share Falcon-512
> numbers if useful.
>
> — Sylvain Cormier, Paraxiom Technologies Inc.
>
> On Sun, Jun 14, 2026 at 2:41 PM Stephen Curran <swcurran@cloudcompass.ca>
> wrote:
>
>> As Jori mentioned, Log based verification methods provide a nice way to
>> evolve to PQC.  We've been experimenting with the did:webvh DID Method
>> (did:web + verifiable history -- https://didwebvh.info) to include PQC
>> to secure a did:webvh Log and have found some interesting performance
>> numbers (below).
>>
>> For background, did:webvh uses a combination of mechanisms for the needed
>> crypto-agility in securing the DID Log:
>>
>>    - multikey to make sure that the verifier can determine the type of
>>    key used (and multihash for hash)
>>    - identification in the log of the version of the did:webvh spec in
>>    use, including the ability to increase the spec version in any log entry
>>    - dictating in each spec version the permitted hashing algorithms and
>>    Data Integrity cryptosuites so the verifier knows exactly what algorithms
>>    must be used to secure the DID Log.
>>       - Note -- this only constrains the algorithms/key types used to *secure
>>       the did:webvh DID Log itself *- not the verification methods
>>       included in the secured DIDDoc. The DID Controller is free to use ANY
>>       cryptographic key types in the DIDDoc itself. did:webvh does not put any
>>       constraints on the DIDDoc contents.
>>       - Currently (spec version 1.0) permits only eddsa-jcs-2022. The
>>       next version of the spec will most likely add the stabilized ML-DSA-44
>>       cryptosuite. Per NIST -- ML-DSA-44 is the logical PQC successor to EDDSA.
>>    - the 1.0 spec also allows for the use of "pre-rotation" for the
>>    securing key -- committing to the hash of the public key to be used to sign
>>    the next log entry. When pre-rotation is in use, key rotation is required
>>    for every entry, meaning the public key is only published on use, and never
>>    reused -- a PQ protection in and of itself. We expect that pre-rotation
>>    will be required in the next version of the did:webvh spec. Inspired by
>>    KERI's pre-rotation approach.
>>
>> Given that, the only (experimental) change we had to make was to pretend
>> that the v1.0 spec included ML-DSA-44, and add ML-DSA-44  cryptosuite
>> (mldsa44-jcs-2024) support for creating and resolving the DID.  We then
>> used the benchmark of the generation of a "10 year" DID, one that is
>> rotated monthly (120 rotations -- no witnesses).  In comparing the EDDSA
>> and ML-DSA performance, we have found on the same machine about 10x slower
>> in adding a log entry (56ms to 510ms), 10x slower in resolution of the last
>> entry (460ms to 4677ms), and had a 10x (~ increase in log file size (117kb
>> to 1.07MB).  Those numbers were for the Rust implementation, but the
>> TypeScript implementation performance ratios were about the same.
>>
>> Note that this was a quick experiment, but even that has led to
>> interesting discussions/approach changes on how to evolve the
>> specification. +1 to using these types of experiments to understand and
>> account for the practical impacts of the transition -- and to use them to
>> guide updates to specifications.
>>
>> The basing of did:webvh for securing the DID Log on Data Integrity
>> cryptosuites made the necessary changes very easy -- basically, changing
>> only the signature generation and verification. Everything else (JCS
>> processing, proof preparation, etc.) stayed the same. OK, we also had to
>> ease the restrictions on the permitted cryptosuites... :-)
>>
>> --
>>
>> Stephen Curran
>> Principal, Cloud Compass Computing, Inc.
>>
>
>
> --
>                           Sylvain Cormier - Founder
> Paraxiom Technologies inc.
> https://paraxiom.org
> 514 804 8434
>
>
>