w3c
Update: COSE elliptic curve signatures 'in the wild' from small RustyKey® alpha-test user base
@antonymott Thanks for reporting back! That's very encouraging to see how commonly Ed25519 is being supported! Have you tried to understand how many of those are security keys vs platform authenticators? If I had to guess all the
-8are security keys 🤔
Originally posted by @MasterKale in #1757
2025 WebAuthn COSE Algorithm Usage Update + Post-Quantum Initiative
@MasterKale - One year later (Oct 2025), our RustyKey® alpha-sites (statistically noisy/unreliable user base), shows:
- 95%
-7(EcDSA) - 4.2%
-8(EdDSA) - <1%
-257(RS256)
Yes, you are correct: even one year on, -8 (Edwards curve) appears to be only from physical security keys, not platform authenticators. Is this not surprising, given Apple specs allow for -8 algorithm choice and our implementation allows both -8 and -7? The Edwards curve greatly lowers the risk of side-channel attacks as it uses deterministic signing, rather than relying on the generation of cryptographically secure random numbers every signature. Why would Apple and it seems most platform vendors continue to support the more vulnerable Weierstrasse curve? I wonder if our dataset is too small to make these conclusions statistically meaningful.
🔐 Post-Quantum Gap in COSE Registry
TL;DR: COSE registry lacks post-quantum algorithms. We're building an open-source Web-assembly (WASM) ML-KEM support - interested in FidoAlliance collaboration?
What we've done:
- 🚀 Published a DRAFT/WIP open-source
quantum-resistant-rustykey- fast WASM implementation of NIST ML-KEM - 🔎 tested for standards compliance (will perform 3rd party audit, but need more resources)
- 📝 Started IETF Internet-Draft RFC for COSE registry inclusion
- 🎓 University of Quantum Science, a Seattle based Private Foundation which supports open-source projects and that I'm associated with, provided partial funding but not enough to move fast with this if others expect to install and consume the implementation as a robust, tested, audited reliable open-source project
What we need:
- FidoAlliance interest/support assessment
- RFC collaboration partners
- Dev time funding for WIP open-source npm package improvements
Install & contribute: pnpm i quantum-resistant-rustykey
Worth pursuing or too early? LMK if this deserves its own issue. 🤔
The COSE registry temporarily includes the dilithium-based implementations as per below.
ML-DSA-87 -50 ML-DSA-65 -49 ML-DSA-44 -48
Kyber is an interesting one since it's currently patented. Would it even be used in the WebAuthn context since WebAuthn mostly is a challenge / signed response flow?
Hi @james-d-elliott, that's an interesting observation about Kyber and the French CNRS patent...I think fortunately NIST made all entrants grant the public full use and implementation rights to remove any practical encumbrance from patents, and generally encourage wide public adoption.
Great job on Authelia, Go WebAuthn and stamp of approval from OpenID. You wouldn't happen to be here at the Authenticate2025 conference in Carlsbad, CA by any chance?
Current WebAuthn Vulnerability to Post-Quantum-Cryptography
Yes, WebAuthn is mostly challenge / signed response...for the moment. At RustyKey® talking with potential users they assume or expect WebAuthn's reach is broader than the relying party challenge, that WebAuthn (of the future) includes improved TLS as well. On the one hand FidoAlliance may not want a technical challenge of that scope...but what about a hybrid approach (TLS wrapper)?
All browser-based authentication flows, including WebAuthn, use classical cryptography throughout:
- Challenge/response signing: EcDSA, EdDSA, RS256 (all quantum-vulnerable)
- TLS channel: ECDH / RSA key exchange (quantum-vulnerable)
- Certificate chains: ECDSA / RSA signatures (quantum-vulnerable)
Post-Quantum Enhancement Strategy
ML-DSA (Dilithium) - Core Authentication
graph LR
A[RP Challenge] --> B[Authenticator]
B --> C[Sign with ML-DSA]
C --> D[Quantum-resistant signature]
D --> E[RP Verification]
- Where: Replace ES256/EdDSA in
navigator.credentials.create/get - Benefit: Quantum-resistant user authentication signatures
ML-KEM (Kyber) - Secure Transport
graph LR
F[Browser] --> G[ML-KEM Key Exchange]
G --> H[Quantum-safe TLS]
H --> I[Protected WebAuthn Flow]
- Where: Hybrid TLS 1.3 key exchange for the entire HTTPS session
- Benefit: Quantum-resistant channel protecting credential exchange
Combined Strength
| Component | Current Risk | Post-Quantum Solution |
|---|---|---|
| Signature | Shor's Algorithm breaks ECDSA | ML-DSA resists quantum attacks |
| Transport | Quantum computer breaks ECDH | ML-KEM protects the channel |
| Result | Complete quantum vulnerability | End-to-end quantum resistance |
@antonymott it is unclear to me what changes you are requesting to the WebAuthn specification. Can you please clarify?
Great job on Authelia, Go WebAuthn and stamp of approval from OpenID.
Thanks, I love these projects. I don't plan to stop certification and accreditation there, I'm heavily invested in provable security and compliance. Some industries will flat out not accept a product with lack of certain credentials. It'd be nice to one day retire with a steady income from paid support for Authelia (or an equivalent project I deeply love) while keeping it entirely FOSS.
You wouldn't happen to be here at the Authenticate2025 conference in Carlsbad, CA by any chance?
No I'm not, I'm in Australia though have been known to travel the globe.
Hybrid TLS 1.3 key exchange for the entire HTTPS session
I was curious about the way it would be applied too since I was under the impression Kyber was a transport technology (KEX similar).
Since COSE registers signing algorithms wouldn't this effectively be out of scope for the IANA COSE registry since Kyber wouldn't be used for signatures? Also isn't transport largely out of scope of WebAuthn except for the fact that it must be transported over TLS in most instances? Maybe I'm misunderstanding your application though.
Would have thought the exchange of the Dilithium public key could effectively be exchanged in the clear since like traditional keys it's asymmetric, the critical factor is the challenge / response.
Yes, no that I think more about it, you're spot on, and the idea is completely out of scope of WebAuthn.
I asked the question in a session at this conference where there was a FidoAlliance panel and they said pretty much the gist of what you said...that it was trying to push a square peg into a round hole. More accurately, not a good idea to expand WebAuthn to do something it was never intended to do.
They were encouraging, in that are different working groups of the FIdoAlliance not related to WebAuthn that would be more interested.
Good to chat, and thanks for helping me look at it in a balanced way...hope one day to be down under (used to live in Sydney!), or see you on your global travels!