Hot take: DKIM signatures with ed25519 are largely useless🔥🔑
-
Hot take: DKIM signatures with ed25519 are largely useless
I know what you're thinking. RSA is bad. You read that blogpost with the "f" word. (It's not good.) This isn't about ed25519 vs. RSA, but about how DKIM works
Here's the problem: if you introduce a new crypto algorithm into a protocol, you need to know if the other side" supports it. But in DKIM, you don't. You're sending e-mails to arbitrary receivers. DKIM has no mechanism to tell you if that receiver supports any algorithm.
🧵 -
Hot take: DKIM signatures with ed25519 are largely useless
I know what you're thinking. RSA is bad. You read that blogpost with the "f" word. (It's not good.) This isn't about ed25519 vs. RSA, but about how DKIM works
Here's the problem: if you introduce a new crypto algorithm into a protocol, you need to know if the other side" supports it. But in DKIM, you don't. You're sending e-mails to arbitrary receivers. DKIM has no mechanism to tell you if that receiver supports any algorithm.
🧵So you have a new algorithm, but you don't know if the receiver supports it. What do you do? You can add two signatures. If you're lucky and the receiver implements DKIM correctly (not a bet I'd take), that should work, as it'd ignore signatures with keys it doesn't support.
However... what did you win? You added complexity by now creating two signatures.
Now, you might say: doesn't RSA have so many security issues. Well, it's complicated, and... you're not protected anyway.
-
So you have a new algorithm, but you don't know if the receiver supports it. What do you do? You can add two signatures. If you're lucky and the receiver implements DKIM correctly (not a bet I'd take), that should work, as it'd ignore signatures with keys it doesn't support.
However... what did you win? You added complexity by now creating two signatures.
Now, you might say: doesn't RSA have so many security issues. Well, it's complicated, and... you're not protected anyway.
The vast majority of RSA security issues are implementation issues with RSA encryption. We're talking about signatures here. Anything RSA encryption-related is irrelevant. (I have some authority to speak about that, I wrote an impactful paper on it.)
The relevant implementation flaws in RSA signatures can entirely be avoided if you follow what everyone's been recommending for ages: use a standardized e value of 65537 (and not e=3).
But... it's all irrelevant anyway.
-
The vast majority of RSA security issues are implementation issues with RSA encryption. We're talking about signatures here. Anything RSA encryption-related is irrelevant. (I have some authority to speak about that, I wrote an impactful paper on it.)
The relevant implementation flaws in RSA signatures can entirely be avoided if you follow what everyone's been recommending for ages: use a standardized e value of 65537 (and not e=3).
But... it's all irrelevant anyway.
Given that you cannot practically have ed25519-only signatures for DKIM, as you always need the RSA signature for the receivers that don't support it, in case of an RSA vulnerability, you are still affected.
The attacker can just ignore your ed25519 key and attack RSA.
The main advantage of elliptic curve crypto is key+signature size and speed. But given that you are replacing RSA with RSA+ed25519, it should be obvious that speed+size aren't improved either.
-
So you have a new algorithm, but you don't know if the receiver supports it. What do you do? You can add two signatures. If you're lucky and the receiver implements DKIM correctly (not a bet I'd take), that should work, as it'd ignore signatures with keys it doesn't support.
However... what did you win? You added complexity by now creating two signatures.
Now, you might say: doesn't RSA have so many security issues. Well, it's complicated, and... you're not protected anyway.
@hanno you could also say: whoever does not support ed25519 in the year 2026 just should not be worthy getting an email from me. Not a call you can make everywhere but if you're in the position to not have to care (which is only small private self-managed mailservers and gmail) then you're fine i think
🥸 -
Given that you cannot practically have ed25519-only signatures for DKIM, as you always need the RSA signature for the receivers that don't support it, in case of an RSA vulnerability, you are still affected.
The attacker can just ignore your ed25519 key and attack RSA.
The main advantage of elliptic curve crypto is key+signature size and speed. But given that you are replacing RSA with RSA+ed25519, it should be obvious that speed+size aren't improved either.
So: given the lack of a negotiation mechanism, ed25519 signatures in DKIM have no advantage for security, speed, or size. They add complexity, and the risk of receivers not properly ignoring them if their implementation is not following the standard properly.
(This came up on the mailop list where someone appeared to have issues with ed25519 signatures.)
-
@hanno you could also say: whoever does not support ed25519 in the year 2026 just should not be worthy getting an email from me. Not a call you can make everywhere but if you're in the position to not have to care (which is only small private self-managed mailservers and gmail) then you're fine i think
🥸@bws That includes >90% of the e-mail market.
But also: why? why would you demand that people support an added algorithm that has no advantage in this setting? Just because it's more "modern"?
-
Hot take: DKIM signatures with ed25519 are largely useless
I know what you're thinking. RSA is bad. You read that blogpost with the "f" word. (It's not good.) This isn't about ed25519 vs. RSA, but about how DKIM works
Here's the problem: if you introduce a new crypto algorithm into a protocol, you need to know if the other side" supports it. But in DKIM, you don't. You're sending e-mails to arbitrary receivers. DKIM has no mechanism to tell you if that receiver supports any algorithm.
🧵@hanno Which blog post? Are there issues with RSA in DKIM that are not largely resolved by rotating keys regularly and monitoring lookups?
-
R relay@relay.infosec.exchange shared this topic
