I know it will take time, but the Fediverse developers should strongly consider making the following opinionated technical decisions:

1. Use RFC 9421 instead of the earlier HTTP Signature spec.
2. Make Ed25519 the default algorithm, not 2048-bit RSA.

Ed25519 has a lot of advantages over RSA and ECDSA.

Over 2048-bit RSA:

1. Shorter signatures
2. Shorter keys (both secret and public), less storage/bandwidth overhead
3. More security (112-bit vs 126-bit)

Over ECDSA:

1. It's much faster than ECDSA
2. You don't have to worry about biased nonces leaking your secret key through lattice reduction
3. Tuned for security (no weird parameters)

Over both RSA and ECDSA:

1. EdDSA is constructed to provide Exclusive Ownership, which is a stronger notion of security
2. Easier to implement in constant-time

Bonus:

1. Ed25519 is approved for use in FedRAMP systems (FIPS 186-5), which Common Criteria sometimes cares about.

See more here: https://ianix.com/pub/ed25519-deployment.html and https://www.keylength.com/en/4/

Further reading:

• RSA: https://blog.trailofbits.com/2019/07/08/fuck-rsa/
• Elliptic curves for signing: https://soatok.blog/2022/05/19/guidance-for-choosing-an-elliptic-curve-signature-algorithm-in-2022/
• https://fullcirclesecurity.org/2024/11/26/nist-announces-the-end-of-rsa-and-ecdsa/

No, Ed25519 isn't post-quantum. (Neither is RSA or ECDSA.)

But signatures are less urgent to migrate before Q-Day (when a Cryptography Relevant Quantum Computer exists) than encryption is:

There is no "store now, decrypt later" for signing, like there is with encryption.

Cryptography and security experts the world wide wish you would stop using outdated legacy cryptography when better tools are freely available in most programming language ecosystems.

As much job security as it makes for us to clean up the same mess for 30+ years, it isn't very fun.

@soatok At work I am currently dealing with the hassle caused by PKCS#1 1.5 key padding being disabled in one library breaking the way we interact with Let's Encrypt.

ECDSA has prevented most customers from being affected, yet the faster everything not associated with the US government starts using Ed25519, the better.

There is another benefit to this, but it involves nightmare magic math.

(If you follow me on Fedi, or caught my DEFCON Furs talk, you've heard about this before.)

There's this thing you can do called Threshold Cryptography. If you've ever heard of Shamir's Secret Sharing Scheme, you probably know enough to grok the math, but basically:

Instead of 1 public key mapping to 1 secret key, you map it to some set of N shards of a secret key, for which T of the N must cooperate to produce a signature. That signature is valid for the 1 public key.

This lets you do some cool stuff, like, not ever have your signing key in the same country where an authoritarian government might demand it.

EdDSA (which Ed25519 is an instance of) inherits from Schnorr, which has a nice linear structure and makes threshold signing easy. See: RFC 9591 (FROST).

ECDSA was designed to avoid the Schnorr patent, and it's a nightmare to get right.

I'm not aware of any secure open source Threshold ECDSA library. Not a single one.

There are applications for which Ed25519 is not appropriate. Cryptocurrency being the main example.

For those advanced use cases, I recommend Ristretto255 instead.

For all else, until quantum computers are on this side of the horizon, just use Ed25519.

@rootwyrm That's a moot point. Even if they can materialize in 50 years, we have ~45 years before we need to care much about it.

My point is not to discount Ed25519 because of some weird hang-up on imagined risks.

What if I care about quantum computers that much?

Look, I work in this field and I'm not sweating them. We can plan a migration to ML-DSA or whatever much later.

For my E2EE project (for which Key Transparency is an important first step), my plan was to use a X-Wing (a hybrid of X25519 + ML-KEM) with MLS (RFC 9420), with public keys from the key transparency service.

I think that's approximately where @evan is landing with https://github.com/swicg/activitypub-e2ee too?

For confidentiality considerations, early adoption of PQ makes sense for encryption. Using a hybrid KEM with a currently accepted forward-secure key exchange algorithm is fine.

But for signatures, unless you have a time machine, a quantum computer doesn't do you any good until it's built. And we have no realistic timelines for that today.

@soatok I really need to get my head back into some modern threshold cryptography stuff. I fondly remember building a toy scheme out of Lagrange polynomials many years ago.

@gsuberland FROST uses Lagrange interpolation to compute the per-signer lambda values that are incorporated into each signer's signature share :3

• https://www.rfc-editor.org/rfc/rfc9591.html#name-polynomials
• https://www.rfc-editor.org/rfc/rfc9591.html#name-list-operations
• https://www.rfc-editor.org/rfc/rfc9591.html#name-signature-share-aggregation

(Which shouldn't be too surprising)

The main reason people still use RSA today is because of legacy decisions.

But Mastodon is getting RFC 9421 support soon. And maybe Ed25519 after that. And then, it might take some time, maybe we can move the default?

But the Fediverse is larger than just Mastodon! Thus, this thread.

@soatok neat! :D

@gsuberland I always get Lagrange and Legendre mixed up in my head, so when I read one, sometimes i think of the other haha

@soatok though also, we really, REALLY need a solution for email. One that addresses Google and Microsoft's MITM decryption. Especially when the hand-off can't be avoided at large scales. You can only rely on people to not read easily intercepted messages.

@rootwyrm If we can convince OpenAI that quantum is essential to "AGI" they'll probably shovel billions into that burning pit too

Finally, some words of caution around RFC 9421 from an applied cryptography perspective.

The same API allows each of the following algorithms:

• RSA
• ECDSA
• HMAC????
• EdDSA
• JSON Web Signatures??????

https://www.rfc-editor.org/rfc/rfc9421.html#name-signature-algorithms

Don't fucking support HMAC or JWS, please.

Why not HMAC?

Because HMAC is a symmetric-key algoritthm.

That means the ability to verify a signature also implies the ability to sign messages.

Why not JWS?

The Internet doesn't need more algorithm confusion vulnerabilities. https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/

In fact, you should write unit tests that are expected to fail when either algorithm is selected to ensure you don't accidentally enable support from a dependency upgrade.

@soatok

Why is Ed25519 not appropriate for cryptocurrencies, and are there other applications for which the same is also true? And is this true only for Ed25519 specifically, or also for other EdDSA variants, for example Ed448?

@srslypascal
https://ristretto.group/why_ristretto.html#pitfalls-of-a-cofactor

@soatok it is fucking wild to me that the brain trust behind JWTs ever decided alg: none was something that should exist for any reason

@mathias If I wanted alg=none I would simply json encode the data and maybe base64url it after

@soatok yeah the life span of these signed messages is like about a week at most (due to retries)

@mathias @soatok none algorithm left token

@mathias @soatok Presumably following the lead of the extremely popular "SSL NULL Cipher".

@soatok what the hell did COSSE use? Did I spell that right? I think you old me about that? Damn, I should go to bed. :P

@gothpanda COSE separated MACs from signatures by design https://www.rfc-editor.org/rfc/rfc8152.html#section-8

It's like someone sane got ahold of JOSE

@soatok

@soatok Also was default for SSH keygen for longer than it should of as well on various Linux distros even though Ed25519 was available.

@mathias @soatok I’m doing my best to reverse that. 19 months in – getting anything through the IETF is exhausting. Maybe in a year or so it’ll make it to last call…

https://www.ietf.org/archive/id/draft-ietf-jose-deprecate-none-rsa15-03.html

@neilmadden @mathias Thank you for putting in the effort.

Finally, I have some fur in the game on this one: I'm offering to implement this in Mastodon if they're willing to accept a patch.

https://github.com/mastodon/mastodon/issues/21429#issuecomment-3468933355

@soatok there's been ~some~ movement in AP about this, but they've been hesitant to document the existing (mastodon) system (because it sucks), and waiting for the RFC to be finished (which finally happened last year). i can't find any recent posts about it but i know there's been a lot of hand-wringing.

separately there's a fep for object identity proofs (https://codeberg.org/fediverse/fep/src/branch/main/fep/8b32/fep-8b32.md) which is slowly getting traction

(sorry if someone already mentioned these -- didn't see them in the replies!)

@soatok universities and agencies perpetuating NIST 800 have taken note of your handle

@StaticRocket Which one in the 800 series lol

@soatok oh god, whichever one was still pushing rsa for ssh 3 years ago. Have had the pleasure of not looking at em since.

@StaticRocket Hah

@soatok also, damn, just putting together that you are the same soatok who's blogs I've read on a handful of lemmy communities. Didn't know you were here. Huge fan of your stuff

@StaticRocket Aww thanks <3