There is some interesting discussion from Filippo on why you might not want to use ML-DSA in things like sigstore.
----
> We designed protocols for 30 years on the assumption that signatures and public keys are marginally ~free. Suddenly replacing them with multi-KB blobs is sub-optimal, but we have the time to do better, especially in the context of synchronous protocols like TLS! (Stuff like firmware signing with timelines in the decades is different, granted, but this CA/BF ballot is about server authentication, proving that the moment we implement this it will be used for TLS.)
----
> Sigstore is a great example, actually. Right now Sigstore works like this:
> Generate a short-lived private key.
Log in to Sigstore with OIDC to obtain a certificate for the key that includes the OIDC metadata.
Use the private key to sign an attestation.
Send the signed artifact and certificate back to Sigstore to get a signed inclusion proof in the transparency log.
Every transparency log entry contains at least one public key and two signatures (one on the cert, one on the artifact). That was fine when they were free, but they are not with ML-DSA!
> Instead, here's a small change to Sigstore that leads to a much better post-quantum system:
> Log in to Sigstore with OIDC and provide the artifact, get back a signed inclusion proof in the transparency log.
>This is completely equivalent in security, but removes both public key and signatures from transparency log leaves. You can then move to ML-DSA for signing the transparency log tree heads (a smaller transition, because it doesn't affect as many parts of the stack).
>ML-DSA support in Go is not the blocker for the bulk of this work.
A set of numbers with addition and multiplication is a _ring_ and is a _field_ only if every nonzero number has a multiplicative inverse.
Integers mod N for composite N (like in RSA) form a ring, not a field - if N = p*q then there is is no well-defined division by `p` or `q` (for example, there is no element corresponding to `2/p`).
When p is prime, every nonzero integer `x` has a multiplicative inverse `1/x` mod p. That's why the integers mod `p` form a field (denoted F_p).
In fact there is another kind of finite field that has `p^n` elements where `p` is any prime and `n` is any positive integer. These fields are not composed of the integers mod p^n, but are made of polynomials of degree `n` with coefficients in F_p.
----
> We designed protocols for 30 years on the assumption that signatures and public keys are marginally ~free. Suddenly replacing them with multi-KB blobs is sub-optimal, but we have the time to do better, especially in the context of synchronous protocols like TLS! (Stuff like firmware signing with timelines in the decades is different, granted, but this CA/BF ballot is about server authentication, proving that the moment we implement this it will be used for TLS.)
----
> Sigstore is a great example, actually. Right now Sigstore works like this:
> Generate a short-lived private key. Log in to Sigstore with OIDC to obtain a certificate for the key that includes the OIDC metadata. Use the private key to sign an attestation. Send the signed artifact and certificate back to Sigstore to get a signed inclusion proof in the transparency log. Every transparency log entry contains at least one public key and two signatures (one on the cert, one on the artifact). That was fine when they were free, but they are not with ML-DSA!
> Instead, here's a small change to Sigstore that leads to a much better post-quantum system:
> Log in to Sigstore with OIDC and provide the artifact, get back a signed inclusion proof in the transparency log.
>This is completely equivalent in security, but removes both public key and signatures from transparency log leaves. You can then move to ML-DSA for signing the transparency log tree heads (a smaller transition, because it doesn't affect as many parts of the stack).
>ML-DSA support in Go is not the blocker for the bulk of this work.
https://github.com/golang/go/issues/64537#issuecomment-34516...