For a number of years it was (non-officially) thought to be a feature to use weak DKIM keys. Some folks argued that short keys allowed you to preserve deniability, since DKIM signatures would only be short-lived and nobody would be able to use DKIM signatures to prove that any email was authentic. (I’m not saying that this is why most companies used short keys, just that there was a general view that short keys were not all bad.)
DKIM deniability is a particular hobbyhorse of mine [1]. These short keys are obviously not the way to achieve it, but I view this kind of thing as a result of the muddled thinking that’s been associated with DKIM and the community’s lack of desire to commit to the implications of an all-email signing mechanism.
I forget where but someone proposed regularly rotating your DKIM key and publishing old keys for deniability. So you can still use strong keys and provide a level of deniability.
Doing this only provides deniability in public. If this was brought to a court there are enough server logs to build out if that DKIM record was valid along with a number of DNS history providers.
My case was a family court dispute where one parent forged an email from the other parent about the child's care. It was a pretty wild case. After that, I was pretty convinced some people are just evil.
This isn't about evidence. In a court case, discovery and court orders can authenticate email messages even if providers publish their keys; the provider will have a record of having verified the email when it was received. But ATO attackers will not have access to those records.
I don't think this rationale is correct. DKIM doesn't authenticate a user, since the user doesn't the private key - DKIM authenticates that the MTA knows the private key on behalf of the domain owner, which isn't necessarily the users using that domain to send email.
What's more dangerous is that a jury wouldn't know the difference.
If there is some mail from my addr, with a valid DKIM signature, it proves nothing:
- perhaps the mail was sent by somebody else on the same plateform, but in my name (identity usurpation of the user part of the mail)
- perhaps somebody got illegal access to my email account, without me knowing
- .. ?
In no case it proves that I, as a human, sent this email.
But of course, justice is a fiction that cannot exist: there is no justice, only probabilities (and feelings :( ).
Isn't deniability at odds with DKIM's goal? What would be the point of setting DKIM then? Sure, it helps with spam scores. But most companies rely on a major email provider to send emails, so maybe they wouldn't have deliverability issues anyway?
No. DKIM is meant to apply to emails in transit; it is part of the transaction of exchanging emails. But DKIM signatures are verifiable long after that transaction has completed. That was not an intended feature of DKIM, and it's a grave privacy violation.
To satisfy DKIM's design goal, you only need a "current" DKIM key that is secure for a window of time. When that window of time passes, you rotate the secret and publish your own key, repairing (hopefully) much of the privacy injury.
I'm missing something here. DKIM mostly proves an email from person@from.me was sent by a server @from.me controls. There is also a bloody great audit trail inside of the email with together with SPF can do a pretty good job of proving the same thing.
I'm struggling to see how an email sent to me, that presumably was always intended to be readable by me could suddenly become a privacy violation because it's signed. That is doubly so if I won't receive it if it isn't validly signed when it is received, which is often the case.
I'm not sure privacy violation is necessarily the right term to help people understand why long-term non repudiation is an undesirable property for some people.
It comes down to if a third party gets access to your emails (e.g. through a server compromise), should they be able to prove to a fourth party that the emails are legitimately yours, vs completely faked? Non repudiation through strong DKIM keys enables this.
Example: Third party is a ransomware gang who releases your emails because you didn't pay a ransom after your email server was compromised. Fourth party is a journalist who doesn't trust the ransomware gang, but also wants to publish juicy stories about your company if there is one, but doesn't want to risk their reputation / a defamation case if the ransomware gang just invented the emails.
Non-repudiation is virtually always undesirable in general-purpose messaging systems. Revealing to a stranger whether a message is valid is a concession to that stranger, not a benefit to the email's owner. This property is called "deniability" and most secure messaging systems go way out of their way to have it.
It's nobody else's business whether the emails in your inbox are valid or not, and that's basically all non-deniable DKIM signatures do: durable secure verifiable DKIM signatures are "security feature" with real-world value exclusively for attackers.
If you’re under Rule 26 discovery or disclosure requirements, it absolutely might be my business whether emails in your client are valid, but I suppose you could classify opposing counsel as an “attacker,” so you’re not wrong.
I get the verification the email actually came from the domain (i.e., someone, who has the credentials of an insider) vs. an email that was totally spoofed, from the outside, without any creds of the purported sender org. (Right?)
Hands on keyboard? You're right, absolutely not. But I can learn something useful via DKIM nevertheless.
> To satisfy DKIM's design goal, you only need a "current" DKIM key that is secure for a window of time. When that window of time passes, you rotate the secret and publish your own key, repairing (hopefully) much of the privacy injury.
If this occurs, is DKIM privacy safe? To make sure I understand, by publishing the private key after a period, that allows for repudiation, since any real email at that point could have been faked using the published private key?
The point of DKIM is to provide DURING TRANSIT that a server is the server is allowed to send emails from that domain. Once the transaction is completed, it doesn't matter if the key even continues to exist: it was verified during transit.
The fact that people do not rotate keys or use secure keys means that you can use it for other things as well, like detecting forgeries. It wasn't meant for humans, but for machines.
Repudiation doesn't work if the receive discards the email if it isn't signed, or marks it as DKIM validated when it is received. Many receivers using independent email providers like gmail, so the sender has no control over whether it happens or not. Both practices are common today, so it likely it does happen.
Rotating the key does make the claim "I have proof he sent it" a litter weaker, as it's no longer as easy to prove. But only a little as "your honour, it is marked as DKIM verified by the independent email provider he uses" is pretty solid.
Rotating the key and publishing the private key destroys the ability of an after-the-fact attacker (someone who pilfers older mails out of your inbox) to prove they obtained a real email. It's not an "only a little" thing; it's categorical.
When using deniable authentication (e.g. Diffie-Hellman plus a MAC), the recipient can verify that the email came from the sender. But they can't prove to a third party that the email came from the sender, and wasn't forged by the recipient.
No, no, in these systems Alice and Bob both know a secret. Mallory doesn't know the secret, so, Mallory can't forge such a message.
However, Bob can't prove to the world "Alice sent me this message saying she hates cats!" because everybody knows Bob knows the same secret as Alice, so, that message could just as easily be made by Bob. Bob knows he didn't make it, and he knows the only other person who could was Alice, so he knows he's right - but Alice's cat hatred cannot be proved to others who don't just believe what Bob tells them about Alice.
Now it makes sense why Alice was sending me that kitten in a mixer video.
But seriously, in a case before a court or jury, wouldn't there be much more evidence? Down to your own lawyer sending a complete dump of your phone with all those Sandy-Hooks-conspiracies and hate messages to the opposing side?
Sometimes instead of a complete dump, you might mutually agree on a third party forensic lab to analyze your phone and only provide relevant details to the opposing side. Usually there's a few rounds of review where you can remove some details/records that are not relevant before the distilled records are sent to the opposing counsel.
Deniability is just that, the opportunity to deny. Will denying change what people believe? Well, maybe or maybe not. I'm sure you can think of your own examples without me annoying the moderators.
The idea is to use a MAC instead of a signature. As long as Alice isn't compromised and sharing her key with Mallory (which she could do even in the signature case), when Bob receives a message with a valid MAC on it, he knows that Alice authorized the message.
Do take a look at the blog post I cited above, where I go into this in loads of detail. The TL;DR is that DKIM only needs to ensure origin authenticity for the time it takes to deliver an email, which is usually a few hours or a day at most.
The unintentional problem DKIM is causing is that it actually provides non-repudiation for many years. Those signed emails can sit in someone's mailbox for years, then get stolen by a hacker. The hacker can then blackmail the owner by threatening to dump the email trove, or for newsworthy targets they can just do it. Reasonable people (e.g., high-integrity newspapers, courts of law) will say "how can we trust that these stolen emails are authentic given that there's no chain of custody?" DKIM signatures nearly answer that question, which makes stolen emails much more valuable than they would be otherwise.
> Reasonable people (e.g., high-integrity newspapers, courts of law) will say "how can we trust that these stolen emails are authentic given that there's no chain of custody?" DKIM signatures nearly answer that question, which makes stolen emails much more valuable than they would be otherwise.
Thank you for clarifying where the vulnerability chain begins and ends.
DKIM's goal is that the receiving system can trust that the message presented to it has come from a host that knows the key, and so could sign it. At the time that message is received, you should be able to assume that only people authorised to send from that domain are able to do so.
By publishing older keys, you gain deniability back, because anybody could have forged the message and signed it. Even if you have timestamps that show when you received the message, the onus is one you to prove that those timestamps are not fabricated. This is a much harder problem because secrets can be revealed later but not forgotten.
To be able to prove that you did it fact receive the message on that date, you'd probably have to record e.g. the message ID, signature and timestamp (perhaps all encrypted with a key that you can reveal later) on a blockchain, which would then serve as proof of when the message was received. Even then, you'd still have to prove that the key hadn't been disclosed before that time.
Deniability and perfect forward secrecy are at odds with how people use email anyway. But that doesn't stop people from demanding both very loudly, and some people from promising them.
I don't know what you're saying. Most email isn't encrypted so PFS wouldn't apply to the content of email messages. When you mention PFS are you talking about email encrypted with something like GPG/PGP? Or are you talking about PFS in the context of the TLS connections used to protect SMTP? I'm not sure what "deniability" refers to in your post and how you think people use email in ways that would contraindicate it. Once I understand what you're saying, I guess we could move on to who the demanders and promisers are and what you think they're doing.
Yes, I've now read it and it answered those questions. But it also stumbled upon an easier possible solution without realizing it: if you wish to pretend you didn't send some emails, you can still claim that someone stole your password. Whether this claim will be believed or not, is independent of DKIM.
Spoofing is a better excuse than a stolen password only in the case of a single email. If there's a conversation spanning multiple messages, a spoofer wouldn't be able to properly answer the messages of the other party, as he doesn't receive them.
If someone lies that their password was stolen to hide them being the originator of a single email, who are they telling the lie? Is it a court? In many cases the person would be caught through behavioral analysis. They didn't change their password, so it wasn't really stolen. No other emails were improperly authored, so it wasn't really stolen. They never reported it to the email server owner, so it wasn't really stolen.
Lying isn't a stronger defense to perform abuse than weak keys are for stopping abuse.
> They didn't change their password, so it wasn't really stolen
You change your password only after you realize it got stolen. If you didn't realize it, then it makes sense you didn't change it. And, depending on the specific case, you could find plausible explanations also for the other points.
I used to spoof emails to my teachers in high school asking them to come to the principle's office asap, and email the principle from another random teacher at the same time for him to come to the class room, and that random teacher to expect the principal at a certain time. We'd be teacher free for quite awhile because the principal wasn't there, and our teacher was.
Sure, but my point was different: let's say one of your teacher answered the spoofed email from the principal, you wouldn't be able to (properly) answer that email since you wouldn't receive it. So, in the case of an email exchange between two people, one can't claim his/her emails were spoofed, as the spoofer wouldn't be able to answer the other party's emails in a precise and on topic way. This is without even considering that, bh default, most email clients include the previous messages inside a reply. Meaning that the spoofer would somehow be able to know the other party's reply exactly word by word.
If you publish DKIM keys, you don't have to convince anybody that you were targeted by someone who stole your password, because your stolen email spool no longer reveals to attackers the authenticity of your emails, which is what you as a user want.
No you don't. You just say "that email is fake and you can't prove otherwise", and you're right. What's almost more important is: there is no reason not to give users that affordance. They literally do not benefit from the non-repudiability of their email archive. The OTR paper got this right 20 years ago, and in the process basically created the entire field of secure messaging.
It is wild to see people argue against it! They're basically pleading with email providers to collude with attackers to violate their privacy.
I think here is where the problem isn't purely a technical one anymore. You're right that, from a legal perspective, there is a difference as the burden of proof would now be on someone else. But, if this actually matters or not, depends entirely on the situation. If you're a criminal trying to get away with something then the change in the burden of proof is all you need. If instead you're a politician trying to avoid some imbarassment, the situation isn't any different: you're claiming in both cases that someone is trying to frame you for something you didn't say. In one case, this person stole your password, in the other he/she used an old and by now publicly available DKIM key. But if people believe you or not (and this would be everything a politician would care about) depends on factors outside the scope of cryptography. Regarding OTR: IIRC it is based on a shared secret. This can work for IM, but it wouldn't scale for emails as it would pose the key distribution issues that made us discover public key cryptography.
If you are a politician trying to get away with something, the public might have an interest in your secure messaging system being bad, but you yourself do not. Secure messaging systems generally take the side of their users, not the public.
Sorry, I'm missing what you're trying to say here, maybe that a politician would be more careful about which message system he's using? I don't think that's necessarily the case.
Anyway, to further add to my point, depending on the context you don't even need to claim that someone stole your password. In the company where I am now , it is custom that, if someone finds out someone else didn't lock their computer, that someone sends an email (from the victim's account) to the whole office saying that the victim is going to bring cake to the office. DKIM is meant to prove that a message comes from an authorized server, but to prove the identity of the sender as well you need something more.
Edit: to be fair, I do get that with DKIM deniability gets harder. But I think that, for the average person, you would gain more in terms of spam and phising protection than what you loose. High profile targets have to take different security measures than the masses anyway.
What I'm saying is that the "crooked politician" use case you're talking about for DKIM is a way in which you're pleased that a messaging system is insecure, because that insecurity works in your favor (because you're not the user; you just want to violate that user's privacy). But no rational user would want that property for themself; they can only lose from it.
Thank you, I get it now. The reason why I focused on that specific example, is because it is used in the blog post as proof that DKIM is being actively used to prove that someone actually sent an email.
> The fix would cost you basically nothing, and would remove a powerful tool from hands of thieves.
Maybe that was true a while ago, but it becoming much less true now. Most people and organisations outsource the email handling to the likes of Google and Microsoft. They tend to reject email that isn't DKIM signed, and add a "DKIM validated" header to those that are. "Tend" is probably too weak a word now - email that isn't signed isn't likely to be delivered.
So the mostly likely scenario now is "someone steaks email that can no longer be DKIM validated, but it is possible prove it was DKIM validated when it was received". If that's true rotating keys doesn't help.
The idea isn't to stop Google from signing and validating DKIM. It's that the major players who do DKIM should rotate and publish their keys, so that at any given instant their current DKIM key is only valid for N hours, and after that it's public, so anyone can forge backdated messages.
The issue here isn't rules of evidence, it's user privacy. In the real world, DKIM has repeatedly been used to violate privacy. More importantly: latent verifiable secure DKIM signatures on archived emails offer no value to users; they literally only have real-world value to attackers.
> More importantly: latent verifiable secure DKIM signatures on archived emails offer no value to users; they literally only have real-world value to attackers.
I don't think this is quite true. First of all, this is not only valuable to attackers, it's also valuable in a court of law to establish the truth of what happened. Secondly, it can be valuable to me to be able to prove that you sent me an email, even if you wished to deny it, also mostly in legal contexts.
Those are cases where DKIM is working against the user! I get that we can come up with cases where we're glad some hapless user is undone by DKIM, but when we're discussing messaging security, we generally take the side of the hapless user, not the courts and tort lawyers!
An email exchange has two users: one is the sender, the other the receiver. As the receiver, having proof that I received an email from you is potentially a feature, not a problem.
More generally, authenticated communication has a long history of being considered a useful thing for society. Physical mail includes delivery confirmations where the receiver must sign for the receipt, proving to anyone that they did receive the letter. People would often add hard-to-forge personal seals to letters in even older days, that could prove to anyone that they were the ones who sent that document. And even common letters were usually signed rather, even when typewritten, again making it hard to later repudiate.
While I absolutely see the value in making it possible to securely send repudiatable email in some specific circumstances, I think having non-repudiatable email as the default is a net benefit to society, and has been the de facto standard for at least a few hundred years before email ever came along.
This is the classic argument in favor of verifiable DKIM signatures: because it benefits the consumers of hacked mail spools. Consider that as a security engineering decision, enabling that use case is a bad thing.
That creates other problems. Content analysis is a large part of anti-spam. Which is a much more important problem than (non-)repudiation and all that.
Only if the defendant doesn't challenge the evidence. If I'm the defendant and I know I sent those emails, I'm not going to challenge the screenshot. If I know I did not send those emails, then I'll do my best to pay for forensic analysts to generate evidence to exonerate me.
I absolutely believe you - lawyers, judges, and juries alike tend to be technologically illiterate, but do you have any references/links to this happening?
They were asking for evidence that people have been convicted based on screenshots of emails, almost the opposite of using DKIM to authenticate emails.
What's the problem with verifiable email? You can just delete old emails (if gmail or whoever archives them that's another problem). Most people probably operate under the assumption that email is verifiable in some way anyway. If you receive malicious email, isn't it a good thing to be able to verify where it came from? Doesn't that benefit senders and receivers alike? Or is this a case of "I want to verify you, but I don't want you to verify me"?
I don't see how this could be possible. If I have some information which I can use to prove that you were the sender, then I can just share the same information with a third party, and they can verify just the same.
Simple, I tell you that in my message, if it’s genuine, I’ll use the word “apple” somewhere.
You tell me that you’ll use the word “banana”.
Provided no-one except you knows that my secret word is “apple”, you know the message came from me.
But it’s perfectly possible for you to fake a secret message and sign it “Love d1sxeyes, P.S. apples”, and so our approach only works between the two of us. A third party probably can’t even confirm that “apples” was the correct keyword, and even if they could, that can only prove that one of us wrote it, they can’t definitively say which one of us.
Now extrapolate this to using some more sensible mechanism than dictionary words.
Yes it seems crazy, but besides the obvious "leak your own key" as other comments mentioned, this is actually possible. This is one of the biggest discoveries in cryptography in the last decades and its implications are still being researched. I dug around and found this article which seems to do a pretty good job describing the cryptographic concepts of "non-transferability" / "deniability" / "deniable authentication" for a lay audience: https://dinhtta.github.io/zkp/ Also: https://en.wikipedia.org/wiki/Deniable_authentication
I.e. a symmetric key is shared between you and me. If I receive a message with that key, I know it's from you because the key is only known by you and me, and I know I wasn't the sender, so it must be you. But any third party can only say that the message was by one of us.
The idea is that for spam filtering purposes, you can prove this morning that the email I sent you this morning came from me, because I’m the only person who had the signing key on it. Anyone else could validate that too.
But let’s say I publish that signing key tomorrow. Once I do that, you can’t prove I sent today’s mail because anyone could’ve used that published key tomorrow forget the signature.
Ok, so there's a time window where it's possible to prove that you were the sender. And if I use a qualified timestamp service to sign all messages arriving in my inbox, then I can prove that you were the sender indefinitely.
Something like that, as long as you can also prove I hadn’t published the key prior to that. If I publish at random times and to random URL, that may be challenging.
Yes, but then it also encroaches on ability to verify that you were the sender when receiving the original email. Basically, unless the recipient also checks whether the current DKIM key has been published, then they can't trust it because it may be published. If it's being published at random times and to a random URL, then it's nearly impossible to actually check.
So I agree that it brings deniability, but I don't agree that it still meets the original purpose of verifying the sender.
That’s all true, but I bet 99.99% of all email is delivered within a minute or so of being send. There are exceptions, of course, but in practice the whole thing is pretty fast.
So there’s some threat modeling, too. Are you trying to email someone highly adversarial? Maybe you’re at a law office or such and that’s the case! This wouldn’t help a lot there. Not everyone is immediately forwarding all inbound mails to a timestamping service though.
(I don’t have skin in this game, so I’ll probably duck out after this. I don’t have opinions on whether publishing old DKIM keys is good or bad.)
If Alice and Bob each have a public/private key pair, they can do a diffie-hellman key exchange to form a common secret. If they use that secret to authenticate a message, then it can be shown that only Alice or Bob sent the message. If you're Alice or Bob, this is what you want to know --- either you or your corespondent sent it, and if you didn't send it, your correspondent did.
But if Alice or Bob asks Carol to validate it, Carol can only determine that Alice or Bob sent it, and perhaps not even that. Anyone in possession of the secret used to authenticate the message can also make a message that would be deemed authentic. If you have participation of Alice or Bob, you can show that the secret was derived from DHE with Alice and Bob's key pairs, but that's all.
This is nifty and useful, but it's more appropriate for end to end communication, which is not the domain of DKIM. Email is a multi point store and forward system, where each point would like to know if a message is authentic; deniability like this would probably mean either
a) only the final destination could determine authenticity and therefore intermediates would not be able to use authenticity as a signal to reject mail
b) only the first intermediate could determine authenticity; it could be used to reject mail, but the end user would have to trust the intermediate
Both of these are workable systems, but DKIM provides that all intermediates and the end user can know the mail was authorized (to some degree) by the origin system.
Imagine that yesterday, I had only one house key, and I left a copy of it in your mailbox so you could come into my house to borrow a cup of sugar while I was out. You can be sure I allowed it, because you know I had only one key.
Today, I made 3 copies of my housekey and gave them to friends. You still know that I was the one that allowed you entry into my house, but you can not prove to anyone else that I was the one that made the copy, because there are now 3 other people that could do that.
(For this example, imagine I made the key copies at home and didn't go to a locksmith who could verify when they were made, since we don't need a locksmith to do software crypto)
> "Keys of 512 bits have been shown to be practically breakable in 1999 when RSA-155 was factored by using several hundred computers and are now factored in a few weeks using common hardware."
So we went to a few weeks to 8h in 14 years give or take
I'm wondering if this process can be GPU optimized. It's possible to rent really beefy GPU cloud instances for a few bucks per hour. <1 hour seems to be in reach.
Addendum: You need to set a strict dmarc policy for the checks to fail.
Interestingly, the sites will tell you all three are correct and valid, but still fail the mail.. This is probably due to different pieces of software doing the dns record checking and the email validation.
Could someone help me understand why we're not dramatically ramping up key sizes across the board on all encryption? Not as a solution, but as a buy-some-time measure.
Compute is rapidly increasing, there is continuous chatter about quantum and yet everyone seems to be just staring at their belly buttons. Obviously bigger keys are more expensive in compute, but we've got more too...why only use it on the cracking side, but not on defense?
Even simple things like forcing TLS 1.3 instead of 1.2 from client side breaks things...including hn site.
These numbers have nothing to do with the technology of the devices; they are the maximums that thermodynamics will allow. And they strongly imply that brute-force attacks against 256-bit keys will be infeasible until computers are built from something other than matter and occupy something other than space.
Long story short, brute forcing AES256 or RSA4096 is physically impossible
That’s true for AES-256. But brute force attacks are not the most efficient way to attack RSA, so it’s not true in that case. (Eg quantum computers would break RSA-4096 but not AES-256).
We are. 1024-bit keys are being retired across cryptosystems everywhere, and have been for over a decade (don't get me started on the one laggard). Nothing threatens 2048 bit keys other than QC, which threatens RSA altogether. Progress isn't linear; it's not like 2048 falls mechanically some time after 1024 (which itself is not practical to attack today).
That would be true if RSA scaled proportionally with the number of bits, but the exponent involved is much lower than 1. 1024->2048 gives you around the same difficulty as adding 30 bits to a symmetric key.
It's also only true so long as we don't discover more efficient ways of factoring large numbers. We haven't come up with any dramatic improvements lately, but it's always possible that something will come up. Symmetric crypto systems like AES are on much firmer ground, as they don't depend as heavily on the difficulty of any single mathematical problem.
What? Just use normal name servers. The registrar doesn't matter one bit, they delegate the zone to whatever name servers you specify. Those can serve whatever records properly.
Probably because RSA 2048 is not yet broken, and once there we still have RSA 4096 to lean back on which is since quite some time the most common key size for most things using RSA (DKIM being one of the exceptions).
In the context of DKIM we're waiting for Ed25519 to reach major adoption, which will solve a lot of annoyances for everyone.
Is there a compelling reason to use 3072 instead of 4096? If you're going to kick the can down the road you might as well put some effort into it. The difference in memory use/compute time has to be marginal at this point. It's not like the old days when jumping from 512 to 4096 made the encryption unusably slow.
These are contrived benchmarks at the extreme end of things. In real world usage the difference is drowned-out by the delays of so many other things happening in order to complete a handshake and key exchange. The mildly higher performance of RSA 3072 versus RSA 4096 wasn't even a big bonus during the CPU performances we had 15 years ago.
It's roughly half as fast as 4096, which sounds bad until you realize that 3072 is already 20% as fast as 2048, 3% as fast as 1024, and 1% as fast as 512. In terms of performance tradeoff it's downright mild compared to the other steps up.
If I could waive a magic wand and get a 40-100% performance boost on a service by changing 3-4 characters (s/4096/3072/) why wouldn't I take it? (Assuming I need security go to beyond RSA 2028.)
Well, in typical use cases RSA usage is very limited (eg some operations during TLS handshake), so the 40-100% boost wouldn’t be across the board, but likely shave some milliseconds per connection.
RSA 2048 isn't broken, but experts consider it a matter of time. How long I don't know, but since the attacks are known (prime numbers) someone (read not me) can make an estimate with error bars that are concerning enough to consider it as good as broken.
RSA2048 is 112-bit-equivalent symmetric security under currently known methods. Number theory advances may change that. It is hard to imagine any significant advances in the breaking of symmetric cryptography (mathematically-unstructured permutations).
Cryptographically-relevant quantum computers (CRQC's) will also break smaller RSA keys long before (years?) the bigger ones. CRQC's can theoretically halve symmetric cryptography keys for brute force complexity (256-bit key becomes 128-bit for a CRQC cracker).
https://www.keylength.com/en/4/ NIST says 2048 bit RSA is good until 2030. I'm not sure what that means, perhaps that it will be broken considering advances, perhaps just that someone (read governments) who cares to spend 5 years on the problem will break your key.
RSA-1024 is "only" 80 symmetric equivalent bits. It's a space requiring a tremendous amount of energy to explore, though I personally consider it very likely that the NSA and/or the MSS et al. have poured immense funds into accelerators specifically targeting RSA, and for them there'd be no obstacles at all to be granted an allocation for such energy consumption.
Nobody is recommending RSA-3072 per se. The recommendation if wanting to stick with RSA is to move beyond RSA-2048, and the world at large jumped all the way to RSA-4096 long ago.
X25519 has seen broad adoption (in the key exchange). Ed25519 has not, you can't actually use an Ed25519 certificate on the web. It's in a deadlock between CAs, browsers and TPM manufacturers (and to some extent NIST, because Ed25519 has not been approved by them).
It's not being blocked per se, you can use it mostly (98%) without any issues. Though things like Amazon SES incorrectly reject letters with multiple signatures. Google and Microsoft can't validate them when receiving. It's more that a few common implementations lack the support for them so you can't use _just_ Ed25519.
Everyone has to be onboard before the switch can be made, and not everyone is happy about the somewhat messy solution of running dual-stack RSA+Ed25519 setups in the interim - it's a bit different than e.g. supporting multiple methods for key exchange or multiple ciphers for symmetric crypto. It's just one of those things that take time to happen.
If the big players (gmail, outlook) jump onto it the rest will be forced to follow. Outlook would probably jump in with a checkbox, and perhaps gmail will make at an option for the paid tier while everyone on the free tier gets no choice - but that is still enough. SmallCompany.com cannot do it alone, probably not even a fortune100.com (if any of them even care - their sales staff probably will overrule the few who do), but there are enough players if they all agree on something.
Getting the big players to agree and execute though is a lot like herding cats. I'm sure some in the big players are trying.
Because the only way to force their use is to break things, mostly this means transferring the pain directly to the user instead of the service operators in the hope that they will bitch loudly enough for the service operator to care, and this has a good chance of instead causing the user to move to your competitors instead, who will be more than willing to not let a little thing like security get between them and revenue.
"dramatically ramping up key sizes" is not done, because it's overly expensive, and not needed.
What people don't realize: key size recommendations are surprisingly stable over long timeframes, and have not changed for a very long time. In the early 2000s, some cryptographers started warning that 1024 bit RSA is no longer secure enough, and in the following years, recommendations have been updated to 2048 bit minimum. That's now been a stable recommendation for over 20 years, and there's not the slightest sign that 2048 bit can be broken any time soon.
The only real danger for RSA-2048 is quantum computers. But with quantum computers, increasing your RSA key sizes does not buy you much, you have to move to entirely different algorithms.
If I'm not mistaken, larger keys require more qbits in a machine to all be coherent together to be able to break it.
So it would be a slight increase in complexity, but if we are able to build a machine with enough qbits to crack 1024 keys, I don't think the engineering is all that far off from slightly scaling things up 2x-10x.
Yup. And I don't even think quantum resistance was the goal of some of the algos that, yet, happen to be believed to be quantum resistant. Take "Lamport signatures" for example: that's from the late seventies. Did anyone even talk about quantum computers back then? I just checked and the word "quantum" doesn't even appear in Lamport's paper.
> Did anyone even talk about quantum computers back then?
Not unless they have a time machine. Shor's algorithm was discovered in the 90s (sure the concept of a quantum computer predates that, but i don't think anyone really realized they had applications to cryptography)
> That’s the reason, it breaks things, and some of them are important and can’t simply be updated.
IMO this is not a valid excuse.
If it's exposed to the internet it needs to be able to be updated with relative ease to respond to a changing threat landscape. Especially if it's "important". If it cannot be then it is already broken and needs to be fixed. Whether that fix is doing a hard upgrade to get to the point that future upgrades can be easier, entirely replacing the component, or taking the thing offline to a private non-Internet network depends on the situation, but "we aren't going to change, the rest of the internet should conform to us" has never been a reasonable response.
This is particularly true in the contexts of public mail servers where DKIM matters and anything involving public use of TLS. The rest of the internet should not care if your company refuses to update their mail servers or replace their garbage TLS interception middleboxes. We should be happy to cause problems for such organizations.
We are doing that, just not everyone is as concerned by safety and make different tradeoffs against things like ease of use or accessibility. Different applications have different tolerances and that’s fine.
If and when anything quantum is able to yield results (I wouldn’t worry much about this), increasing key size is pretty much meaningless, you need to move to other encryption schemes (there’s lots of options already).
In the case of RSA it's not meaningless to increase key size to fend off quantum computers. Quantum computing vs RSA is a case of being the largest contender, because quantum computing in itself doesn't definitively unravel the integer factorization problem.
Getting a working qc to reasonable scale is the hard part. Once you have done that most of the hard engineering problems are solved. I doubt doubling its size at that point would be very much of a problem.
If we are making (uninformed) predictions, i bet we wont see QC solving 1024 bit RSA in the next 15 years (at least), but once it does it will only take a year or two more to solve 4096.
Linear bit size increases require exponential compute increases to break. RSA with 1024 bits is still beyond any practical capability to break. The current practical limit is considered to be around 800-something bits. Still the recommendation is to use at least 3000 bits nowadays, to defend against possible mathematical advances.
This is incorrect. Factoring algorithms like GNFS are super-polynomial but sub-exponential. RSA-1024 is likely breakable at practical-but-very-expensive costs.
> Could someone help me understand why we're not dramatically ramping up key sizes across the board on all encryption? Not as a solution, but as a buy-some-time measure.
I am acutely aware that there are SOME places where software only supports RSA and only supports up to 1024-bit or 2048-bit keys, and that is a legal requirement. Ramping up key sizes would be great but even 2048-bit keys aren't quite secure against certain kinds of actors (even disregarding hammer-to-head style of attacks)
> Even simple things like forcing TLS 1.3 instead of 1.2 from client side breaks things
... kind've a case in point about the pace of required improvements.
> Could someone help me understand why we're not dramatically ramping up key sizes across the board on all encryption? Not as a solution, but as a buy-some-time measure.
We've been doing it for decades now… (DES used 56bits back then, AES started at 128).
Also, keep in mind that increasing the key length by 1 means that you need twice as much compute to crack it through brute force (that is, unless cryptanalysis shows an attack that reduces the difficulty of the scheme, like for instance with the number field sieve on RSA) so you don't need to increase key size too often: following Moore's law, you need to increase it by on bit every two years, or 5 bits every decades. Additionally key size generally account for many years of compute progress and theoretical advance, so that you really don't need to worry about that over a short period (for the record higest RSA factorization to date is 829 bits, yet people started recommending migration away from 1024 bit RSA a decade ago or so, and the industry is in the process in deprecating it entirely even though it's probably going to take years before an attack on it becomes realistic.
> why we're not dramatically ramping up key sizes across the board on all encryption?
because no one thinks there is a reason to, no one has any fear that classical computers will catch up with RSA-2048/AES-128 before their grand children are dead.
post-quantum crypt stuff is happening and people are planning how to migrate to it.
Ok, preimage resistance is still pretty strong, but it has been reduced enough that I wouldn't trust it remaining above practical attacks beyond the next decade.
Key rotation tooling has never been given adequate attention since you only do it every few years. Something ends up breaking, even if it’s just the name of the key .
keys are stateful content like DB schemas, but they don’t receive daily attention, so the tooling to maintain them is usually ad-hoc scripts and manual steps.
because everyone recommending those things work on both sides.
they recommend 2048 and use 4096 themselves because if they need to ever break your 2048 it's less bad than if you were recommended to use 4069. wink wink
same with everyone recommending ed22519 when ed448 is as good and as fast to encode. but all the arguments point to encode speed from a Bernstein paper which used a pentium iii!
CADO-NFS makes this surprisingly easy to do. A few weeks back I factored a 512bit RSA DKIM key for work using my desktop computer in only 28 hours. Specifically, an AMD Zen 5 9900X.
Unfortunately 1024 bit keys are still out of reach of a hobbyist effort but could be pulled off by academics roughly of the same scale as the 2010 effort to factor a 768 bit key (https://eprint.iacr.org/2010/006.pdf)
2048 achieves the same security level NIST requires from AEADs, doesn't it? What plausibly attacks it? Pushing people past 2048 seems counterproductive.
It should achieve the same level, yes. It's not exactly described what could attack it. Right now it seems that 2048-bits would be the last allowed step and they're not going to push people past 2048, they want to phase out RSA in general.
Counterproductive how and to what/whom? For the sake of keeping DNS TXT entries and e-mail headers compact? Would you stand by this statement also in the context of a certificate authority's root signing key, or an RSA host key for an ssh daemon?
There is no plausible threat to 2048, but you'd still rather people switch off RSA, either to curves (because they're more resilient) or to lattices (for post-quantum). Pushing people to higher RSA key sizes is a waste of effort.
That's just the extra compute required. There is a large increase in required memory that needs to be quickly accessible in a particular way. One estimate I saw claimed that breaking 1024 bit RSA would take more than 2 billion dollars over a period of years.
Yep, the formula is a bit complicated, it comes from the general number field sieve (GNFS) algorithm, you can find some equivalences online between symmetric key algorithms and RSA and 23 bits seems about right. I have also seen lists where they give RSA-512 64 bits and RSA-1024 80 bits, just a 16 bit difference, but it looks a bit arbitrary to me. I think the NIST doesn't even look at RSA-512 anymore, as it is definitely broken, it only starts at 1024.
A RSA key is the product of two primes, not any number, so you need a lot more bits to get equivalent security to, say, AES. That's also a reason for elliptic-curve cryptography, which needs a lot less bits than RSA for the same level of security.
> A RSA key is the product of two primes, not any number, so you need a lot more bits to get equivalent security
This explanation doesn't seem right to me. For 1024 bit numbers, about 0.14% are prime. So that difference only loses a handful of bits. There are more than 2^2000 usable RSA-2048 keys, and simply guessing and dividing would require more than 2^1000 guesses. Those few bits lost to the prime number restriction aren't why the level of security is so low.
DKIM records are just DNS TXT records. Do they have a limit on the size of TXT records? Or are they going out of their way to try to parse the TXT records you're adding that look like DKIM records, failing on them, and then refusing to add them?
> DNS clients combine the 255-byte strings back into a single string.
No, DKIM clients and SPF clients do that. Generic DNS clients, however, are in theory free to ascribe any semantic meaning they like to the string separations.
1024 is still many orders of magnitude hard to crack than 512. For the record, the last RSA number having been broken was RSA-250 (829 bits) and it took 2700 core-years to crack back in 2020[1]. In comparison, RSA-155 (512 bits) was factorized as early as 1999!
There are several open source GNFS tools that can do 1024 very efficiently on GPUs, and even cheap consumer GPUs have 10s of thousands of cores now, even by your measure "2700 core-years" is only around a month or so on a single consumer grade GPU.
Not "free", but any malicious actor has access to a lot more than a single GPU.
The UK government also has several huge arm based solutions dedicated to cracking internet encryption, zero chance that isn't breaking mostly everything, for sure the Chinese and Russians have similar.
> The UK government also has several huge arm based solutions dedicated to cracking internet encryption, zero chance that isn't breaking mostly everything, for sure the Chinese and Russians have similar.
So you seriously think that almost all current RSA is being decrypted in real time by at least UK, China and Russia (and I would assume US)? Do you have any source or reference for this at all?
Yet nobody is collecting the RSA-numbers bounties?
RSA-270 (much, much easier than 1024 compute-wise) has a bounty of $75k, why would it be unclaimed then when you can spend three years worth of cloud rented H100 (I'm being conservative here and count $3/h which is far from the best deal you can get) and still make a profit?
Also a GPU core and CPU cores really aren't comparable individually, so your “consumer graphic card having thousands of core already” is comparing apples to oranges.
none of it is "brute force", GNFS is a process that rapidly excludes numbers from the search space that cannot be the answer, in principle similar to the way they broke enigma.
That's not correct. Consider, for example, a processor that can handle 2^31 computations per second. 2^32 operations can be computed in 2 time units, whereas 2^64 operations will take 2^33 time units.
search_space(n: number_of_bits) = 2^n * k
so search_space(1024)/search_space(512)=2^512, not 2^2.
Asymptotics in GNFS are better[0], but only on the order of e^(cbrt(512 * 64/9)) times more work, not 2^2.
This would give an approximation of math.exp(math.cbrt(512 * 64/9))*$8 = $40 million for 1024 bits.
Pretty sure the search cost of GNFS is (bits)^2, the search cost of brute force is 2^(bits), if it was 2^(bits) GNFS would be no better than brute force.
Come on! Not only your math is ridiculous (you can't just square amounts of money, just consider how it would work if you changed currency: $8 is 1260¥, squares it makes it 1587000¥ which is $10k != $64) but believing that RSA-2048 is factorizable in $4k is hilarious.
> none of it is "brute force"
It's not exhaustive search like it would be for symmetric encryption, but it's still somewhat brute-force (especially since RSA keys are inflated in size compared to symmetric encryption to accommodate for their vulnerabilities), put more clearly what I meant was “not without theoretical breakthrough unknown to the public”.
BTW, it's not a very good idea to lecture people with actual crypto knowledge (even though mine is quite rusty now for I have not done any serious stuff for 15 years) when your own comes from ill-understood YouTube vulgarization videos.
I personally factored 512 bit numbers in 2007 for a lot less than $8, so tbh I'm going to say your overestimation of your knowledge of cryptology is far more hilarious than my paranoia about the potential truth of claims made by people claiming to be experts in cryoptology.
Your claim that factoring a 256bit number would cost fractions of a cent rather than my claim of roughly $3 is also very easily verifiable.
Further I'll note you sound exactly like the kind of person insisting diffie hillman was a good key exchange mechanism prior to Snowdens disclosures. good luck with that.
You and I aren't the ones in immediate danger. The service providers we rely on are. In discussions like these we have a "tragicomic" tendency to forget mankind's unstoppable progress. RSA-1024 offers 80 symmetric equivalent bits of security and we've been heading down this path for decades at an exponentially increasing pace.
Those service providers have had plenty of time to migrate to 2048 and most of them have already.
> a "tragicomic" tendency to forget mankind's unstoppable progress
When it comes to compute, it's no faster than Moore's Law, which means roughly one bit of symmetric encryption every two years.
> and we've been heading down this path for decades at an exponentially increasing pace.
Given that the encryption security is itself exponential in bit length, we are in fact heading down this path linearly! (A doubling in compute power means the ability to crack twice as hard cryptosystems, which means ones that have 1 bit more of security).
Key must be extended over time, and they are, and have been for decades. A PoC of an attack of a security system broken since 1999 should be treated exactly like how we are amazed at little computing power was available to the Apollo program: this is a cool bit of trivia that shows the growth of available computing power, but not a display of any kind of security issue.
This is the reason I had to stop using Hover for DNS management. They don't support TXT records longer than 255 characters, and I've not found any instance of someone getting split records to work with Hover. Ended up using Digital Ocean for it. I would love for elliptic curve crypto to become the status quo if this is going to continue to be an issue for yet another decade.
> Although most providers correctly identified the 512-bit key as insecure and rejected our DKIM signature, three major providers — Yahoo Mail, Mailfence, and Tuta — reported a dkim=pass result.
Did google really FAIL because of DKIM signature being insecure or because SPF failed?
The DKIM verification failed with the result "dkim=policy (weak key)," as it should according to RFC 8301: "Verifiers MUST NOT consider signatures using RSA keys of less than 1024 bits as valid signatures."
This is a little bit of a layman's question but maybe someone is interested:
When people go searching for prime numbers / bitcoin with massive compute, I assume that there are huge libraries of "shortcuts" to reduce the searching space, like prime numbers only appear with certain patterns, or there are large "holes" in the number space that do not need to be searched, etc. (see videos e.g. about how prime numbers make spirals on the polar coord. system, etc). I.e. if you know these you can accelerate/reduce your search cost by orders of magnitude.
For whatever various encryption algorithm that people choose to test or attack (like this story), is there somewhere such libraries of "shortcuts" are kept and well known? To reduce the brute force search need?
And is the state of sharing these to the point that the encryption services are designed to avoid the shortcut vulnerabilities?
There exist certain classes of prime numbers that should not be used for some cryptographic operations because algorithms exist that reduce the computation required for factoring attacks. This more often applies to cases where smaller primes are applied. Sources for this king of knowledge are mathematics or cryptography textbooks.
For other cryptographic operations, almost any sufficiently large prime can be used. Even a 50% reduction on a computation that will take trillions of years, has no practical impact.
Don't know how Apple's iCloud Email will handle it, after all, Apple has always prided itself on being extremely attentive to user privacy and data security.
In case anybody is wondering about whether the 512bit number is big or small it depends on whether it is symmetric or asymmetric encryption technique. Always presume asymmetric encryption is 8x weaker than symmetric encryption.
DKIM is asymmetric. So a 512bit DKIM equivalent symmetric hash would be 64bits, which is long broken. Even 160bit SHA1 is considered broken. A DKIM of roughly equivalent strength to a 512bit SHA3 would be at least 4096bits and still does not include SHA3's techniques for mitigating replay attacks.
Wikipedia says it is a correlation check based upon a public key based signature. How is that not a form of encryption? Google says encryption is a process that scrambles data into a secret code that can only be decoded with a unique digital key, which is exactly what public keys are for.
Breaking a 512-bit key for a good demonstration is very valuable security research, even if it's been done before. It's also legit to call out "Hey, here's a list of folks still using 512 bit, they should move off." ... but for me, actually cracking a real-world in-use key crosses an ethical line that makes me uncomfortable. IANAL but it might even be criminal. Just seems a bit unnecessary.
> for me, actually cracking a real-world in-use key crosses an ethical line that makes me uncomfortable
They've contacted the company with the vulnerability and resolved it before publishing the article - search the original article for the substring "now no longer available".
Usually, you demonstrate that an online system is vulnerable by exploiting that vulnerability in good faith, documenting the research, and submitting it for review. It does not matter if you're cracking an encryption scheme, achieving custom code execution for a locked-down game console, proving that you can tamper with data in a voting machine, or proving that you can edit people's comments on a Google Meet Q&A session - the process is the same.
If you say something's vulnerable, people can shrug it off. If you say and prove something's vulnerable, the ability to shrug it off shrinks. If you say and prove something's vulnerable and that you'll publish the vulnerability - again, using the industry standard of disclosure deadlines and making the vulnerability public after 60-or-so days of attempting to contact the author - the ability to shrug it off effectively disappears.
I read the article, and I don't think it changes it. If you crack someone's key, they might be well within their rights to pursue a criminal prosecution. Of course it would also have a Streisand effect and there's reasons not to, but I personally wouldn't allow or recommend a security researcher to do it. It's needlessly risky.
In general, subverting security and privacy controls tends to be illegal in most jurisdictions. Best case is when you have clear permission or consent to do some testing. Absent that there's a general consensus that good faith searching for vulnerabilities is ok, as long as you report findings early and squarely. But if you go on to actually abuse the vulnerability to spy on users, look at data etc ... you've crossed a line. For me, cracking a key is much more like that second case. Now you have a secret that can be used for impersonation and decryption. That's not something I'd want to be in possession of without permission.
> If you crack someone's key, they might be well within their rights to pursue a criminal prosecution.
If that were true there would be no market for white hat hackers collecting bug bounties. You need to be able to demonstrate cracking the working system for that to be of any use at all. No company will listen to your theoretical bug exploit, but show them that you can actually break their system and they will pay you well for disclosure.
What is or isn't illegal depends on where you live. Where I live, using any kind of digital secret to do something you shouldn't be doing is technically illegal. Guessing admin/admin or guest/guest is illegal, even if they're public knowledge, as long as you could reasonably know you're not supposed to log in.
Generally, law enforcement and judges don't blame you as long as you use best practices, but you need to adhere to responsible disclosure very strictly in order for this not to be something the police might take an interest in.
Demonstrating the insecurity of a 512 bit key is easy to do without cracking a real life key someone else owns; just generate your own to show it can be done, then use that as proof when reporting these issues to other companies. The best legal method may be to only start cracking real keys if they ignore you or deny the vulnerability, or simply report on the fact you can do it and that the company/companies you've reached out to deny the security risk.
Companies that pay for disclosure won't get you into trouble either way, but companies that are run by incompetent people will panic and turn to law enforcement quickly. White-hat hackers get sued and arrested all the time. You may be able to prove you're right in the court room, but at that point you've already spent a ton of money on lawyers and court fees.
In this case, the risk is increased by not only cracking the key (which can be argued is enough proof already, just send them their own private key as proof), but also using it to impersonate them to several mail providers to check which ones accept the cracked key. That last step could've easily been done by using one's own domains, and with impersonation being a last resort to prove an issue is valid if the company you're reporting the issue to denies the risk.
> Demonstrating the insecurity of a 512 bit key is easy to do without cracking a real life key someone else owns; just generate your own to show it can be done
As I said in my post, no company will listen to your hypothetical exploit.
Show them youve hacked their system and they listen.
Bug bounties are a form of consent for testing and usually come with prescribed limits. Prescribed or not, actually getting user data tends to be a huge no go. Sometimes it can happen inadvertently, and when that happens it's best to have logs or evidence that can demonstrate you haven't looked at it or copied it beyond the inadvertent disclosure.
But to pursue data deliberately crosses a bright line, and is not necessary for security research. Secret keys are data that be used to impersonate or decrypt. I would be very very careful.
I see it the other way around. If some hacker contacted me and proved they had cracked my businesses encryption keys and was looking for a reward, I dont think I would be looking to prosecute them and antagonise them further.
They can pursue what they want, it doesn't mean it will go through.
Looking at public data, using some other public knowledge to figure out something new does not make it inherently illegal. They didn't crack it on their systems, they didn't subvert it on their systems, they did not use it against their systems. I'd love to see some specific examples under what it could be prosecuted under specifically. Because "that door doesn't actually have a lock" or "the king doesn't actually have clothes" is not practically prosecutable anywhere normal just like that.
Especially in the EU, making such cryptographic blunders might even fall foul of NIS2, should it apply to you.
It's more like the door has a weak lock that can be picked. Just like many real world doors do. Here's how it would go in court:
"Are you aware that this key could be used to decrypt information and impersonate X?"
"Are you aware that this key is commonly called a Private key?"
"Are you aware that this key is commonly called a Secret key?"
"Are you aware that it is common to treat these with high sensitivity? Protecting them from human eyes, using secure key management services and so on?"
"Was it even necessary to target someone else's secret private key to demonstrate that 512-bit keys can be cracked?"
"Knowing all of this, did you still willfully and intentionally use cracking to make a copy of this secret private key?"
I wouldn't want to be in the position of trying to explain to a prosecutor, judge, or jury why it's somehow ok and shouldn't count. The reason I'm posting at all here is because I don't think folks are thinking this risk through.
If you want to continue with the analogies, looking at a lock and figuring out it's fake does not constitute a crime.
That key can not be used to decrypt anything. Maybe impersonate, but the researchers haven't done that. It's also difficult to claim something is very sensitive, private or secure if you're publicly broadcasting it, due to the fact that the operation to convert one to an another is so absolutely trivial.
And they did not make a copy of their private key, they did not access their system in a forbidden way. They calculated a new one from publicly accessible information, using publicly known math. It's like visually looking at something and then thinking about it hard.
I wouldn't want to explain these things either, but such a prosecution would be both bullshit and a landmark one at the same time.
Breaking a key isn't criminal. It's just math. Sending emails that would constitute fraud or a violation of another jurisdictional law, relying on that math, is illegal. But again -- it's not the math, it's the action and intent.
Pointing out that someone is doing something stupid is also not illegal, though they make try to make your life painful for doing so.
Secrets themselves are often regarded as sensitive information, and often also categorized in the highest classifications for information protection. This stuff isn't just a game, and in my experience it's not how law enforcement authorities or courts see things.
Just as if you made a copy of the physical key for a business's real-world premises, you could well find yourself in trouble. Even if you never "use" it.
You can say this about a lot of security research, i.e "Showing a bug is exploitable is one thing, but writing a POC is crossing the line!" The problem is that most people won't listen to your security research unless you demonstrate that something is actually possible.
They only called out 1 out of the ~1.7k domains they found with keys shorter than 1024bits.
They _did_ call out the 3 of 10 tested major email providers that don't follow the DKIM RFC properly: Yahoo, Tuta, Mailfence (after having notified them).
I don't think there's a way to make it criminal, any more than publishing a vulnerability that got you code execution on their servers could be. Actually exploiting it, of course, would be.
I am also not a lawyer, but I would suspect it's not criminal to crack a real-world in-use key if you do so using only publicly available information and you don't actually do anything with the result.
Let's say you local coffee shop is featured in a local news piece and the blithe owner happened to get photographed holding the store key. That's now easy to clone from public information. Would you be comfortable actually doing it? Reporting the issue is fine - "Hey you should rekey your locks!".
Actually making a clone of the key, and then showing "hey it fits" will get you more traction more quickly ... but there's also plenty of Police Departments who might well arrest you for that.
That's exactly what I meant in terms of not actually doing anything with the result. That said, it's obviously somewhat different with a physical key than a cryptographic key.
As mentioned in the article, the key's no longer available and I presume the article has been released only after responsible disclosure was done and with the approval of the key owner (hope so). At this point, it's not more unethical than any other security research performed in the same conditions and with the same outcome.
I think the cynic in me says "so what" mostly because dkim as an ancient technology is hardly secure. I don't think we're any less prone to email fakery and spam. I'd be interested to see a possible new solution or a revamping of email as a protocol but that's unlikely. We're more likely to keep it like snail mail as we prioritise different forms of communication. Unfortunately nothing has beat the universal email address on the internet. Here's hoping we come up with a chat standard that sticks and people run a user@server.com chat server where you can communicate from anywhere. Sorry xmpp, you don't count.
Email-style user@host.domain addressing is also used in SIP.
At one point in time you could reach me on email, XMPP, and SIP all using the same identifier. We dropped XMPP about a decade ago when all the major service providers stopped federating with it, but if you know my work email address you can also call my desk phone using the same identifier.
You hit the nail on the head with the word 'Universal'.
Because email addresses have existed since the begining of the web, anyone who has ever been on the internet has one and uses it for identification purposes. This will not change without another universal standard which everybody automatically has.
Its like IPv4, we all have the ability to use IPv6 but do we? Hell no we just use NAT as its an easier quick fix.
Changing any addressing on the internet is tough because you always have to have backwards compatibilty, which kind of ruins the point of moving forward.
Thats because those are mostly developing countries which were late to the internet party, and are accessed mainly through mobile. Phone # could well be a replacement for email globally in the future, once all the younger generation grow up and rule the world.
Yep, but it will never replace email address as universal identifier until it is adopted by all.
In addition to that, reports show that the majority of Asian and African users access the internet via a shared device. Therefore phone number cannot be a universal identifier there as it generally identifies a group of people rather than in indivdual. This is why google and outlook accounts with SSO are still generally the most used identifying systems in the world.
Of course XMPP doesn't count... even though it's a standard, allows people to run their own server, have an email-like address of user@server, allows you to communicate from anywhere, and is how I, my family, and many many others chat online? :)
> In our study on the SPF, DKIM, and DMARC records of the top 1M websites, we were surprised to uncover more than 1,700 public DKIM keys that were shorter than 1,024 bits in length
I must do something about my short-term memory/attention. I must have read that and promptly blanked it during the scanning of the rest of the article.
I guess most of these keys are decades old and no longer in use. They're likely just sitting in the DNS because someone forgot to delete them. Now, no one's sure if they're still needed and is afraid to remove them in case it breaks something. Or maybe they're still used by a legacy system, and no one realizes the impact an old DKIM record could have.
txt records are 1024bits... add the prefix for the key and you get <1024.
to use a larger key you must combine many txt records in a never ending comical interoperability issues. the first one usually being that your regional monopoly scoundrel, a.k.a. registrar, run a server which doesn't even allow more than one entry.
TXT records are 255 bytes or 2040 bits. This is plenty of space to support RSA-1024 keys even with a small prefix and after base64 encoding them. However, it is obviously not enough to support RSA-2048 which is the minimum recommended size according to NIST right now. It's also not quite enough even for RSA-1536 (not widely used) due to base64 expanding the key by 33%.
There actually is a standard for adding more than 255 bytes to a TXT record and it's fairly widely supported, but it can be tricky to configure properly on a name server.
> but it can be tricky to configure properly on a name server.
I wouldn't say it is tricky with a good name server: for instance with bind just split the value into multiple quoted strings and it'll do the rest¹.
Though while it is well known, it doesn't seem to be well documented away from many forum posts discussing the matter: after a little searching I can't find reference to the issue in bind documentation or relevant RFCs. The RR format allows RDATA to be longer than 255 octets (RDLENGTH is an unsigned 16-bit value, not 8-bit) so presumably the limit is imposed by the zonefile format. The only reference to 255 octet limits in RFCs 1034 & 1035 is the length of a full name (with individual labels making up a name being limited to 63 octets).
Of course many UIs for editing zone files or other stored RR information, or other DNS management interfaces, might implement longer RDATA support in a worse way or not support longer RDATA values at all.
----
[1] I'm not sure what “the rest” is (I might look deeper later)
I agree, but to be precise, it was 1,726 out of 476,617 DKIM keys found across those 1M domains, or about 0.36%. Since it's impossible to determine all DKIM records a domain might have from the outside, I used a list of commonly used selectors (e.g., "default' or 'key1") for the search. It's likely there are additional short keys under selectors I didn't check.
Those 1,700 are easy to find though, just need to dig a bunch of domain names and you'll find plenty vulnerable ones that you can spoof.
Yahoo Mail has a market share on the order of 3%. So a black hat could then target a decent chunk of users with @yahoo addresses specifically.
Has anyone heard of this being exploited in the wild? Would be interesting to find out whether there are some reputable domains among the 1.7k vulnerable ones.
remember when yahoo mail was the first one to implement DKIM validation and then all mailing list owners added a footer telling their subscribers not to use yahoo mail because it was broken, instead of calling their mailing list providers to upload a key? yeah nobody remembers, but yahoo probably do. i doubt they will err on the side of security again.
The top million domains are more likely to be on top of their security than less prominent domains. 0.2% is therefore a fairly strict lower bound for the overall internet.
Not common. 1024-2048 bit RSA is the most common DKIM scheme. It's been 6 years since Ed25519 was labeled "required" in a drafted RFC, but adoption is as usual taking an unfortunately long time.
If you fetch with `dig`, note that sometimes dig will do this:
example.com. 1800 IN TXT "k=rsa; t=s; p=blahblahblahblah" "blahblahblah"
I.e., it breaks it up with a `" "`; remove those, that's not part of the data. I.e., concat the strings dig returns, then parse out the p=, then base64 decode, then openssl.
(You can also do what the article does, but without Python, which is jam that base64 between some PEM header guards like the article does, and then feed it to openssl. Same command, but you don't need the -inform der b/c the "in[put] form[at]" is now pem, which is the default.)
An easy way is to check the length of the p= value in the DKIM record. If it's around 216 characters, it's likely a 1024-bit key. A 2048-bit key usually has about 388 characters.
If you're going to do this you should also check for k=rsa since other key types will be different lengths. But I'd really recommend something like in the other comment where you base64 decode and parse it with something like openssl.
Considering that Yahoo doesn't really exist anymore, and that Yahoo Mail is just a relic of Yahoo's heyday that is somehow still hanging around, I assume nobody has bothered to actually maintain its handling of security protocols for about a decade.
"existing" is basically all it does. They make 8B a year and have the 12th most popular website globally.
The email product has gobbled up both AOL and Verizon and they also whitelabel to a bunch of other ISPs. Just because they are never in the news for anything cool and hackernews commenters dont use them doesnt mean they dont exist.
Yahoo mail still has plenty of users and yahoo still have many employees. It'd be borderline criminal to not have somebody at yahoo oversee their email security.
They are, but someone set this up in 2016 or so, and nobody has changed it :) Most likely the person got laid off, or went somewhere else, and nobody on the team has any idea about it.
"as RSA keys shorter than 1,024 bits are considered insecure, and their use in DKIM has been deprecated since the introduction of RFC 8301 in 2018."
LOL.
One of my favourite internet flame wars was circa 2007 (in and around discussing the incoming financial crises) and we got talking about encryption and how none of it actually "works".
Particularly vile troll, and iirc also owner of the site bet me $50,000 I couldn't reverse the 512 RSA key he posted (created by openssl).
He got the factorisation less than an hour after he made the post.
Strangely, the entire site disappeared pretty quickly after that (and it's not on wayback machine).
given where the math guys are now with GNFS I'm not sure I would trust 8192 bit RSA in 2024, 2018 for dropping 512 bit was already more than a decade late.
Do you have any proof/quote for that? Some pretty knowledgeable and well-known people in this thread 2048 bit RSA is quite safe with current capabilities[1]
Thanks for sharing this article, I think people have been doing this for some time!
I’ve gotten a lot of spear phishing attacks, as far back of 2018, with emails that passed many verification checks. Getting representation to this issue is notoriously difficult because people assume an undiscerning victim and end user. They also rely on the false idea that scammers can’t spell or don’t spell correctly, specifically to weed out discerning people. When there is a subset that makes everything as legit and impersonating as possible.
I got an email from Bank of America yesterday about a problem setting up my account. I had set up a new account, and this email knew that, and knew the name of the company, etc. There were no links in the email, just a note to call the BofA business number. I verified the number on the BofA website -- it was the same number -- and I called them.
They couldn't tell me why I got the email, and what the problem was with my account. The representative couldn't see a record of this email set.
I'm 100% certain this email came from Bank Of America. There was nothing in the email that was phishing -- no links, no bad phone numbers.
The SPF, DKIM, and DMARC all passed googles's ARC-Authentication-Results. The DKIM key is 2048 bits long.
I asked Bank of America to investigate, and they said "it must have been a phishing message" and sent me a link on how to look out for phishing.
I'm pretty sure this was just a glitch; some system that does some consistancy check ran too early while the account was being set up and generated that email.
However, because they told me it was "phishing" I just sent a FedEx to the CTO with the complete paper trail advising them that EITHER their DKIM keys were compromised and they need to issue a public warning immediately OR their incompetent staff and IT system gave me the runaround and wasted an hour of my time. Either way, I want a complete investigation and resolution.
As a small mail server admin I see this less about security of messages originating from me and more about the possibility of spammers sending DKIM-authenticated mail as coming from me (and resulting in shadow bans at gmail, etc. which is a huge pain to deal with)
>But as a security generality - email is vastly less secure than human nature wants to assume that it is.
I don't think this has to do with "human nature" anymore than http did. It's a very important, powerful form of communication without any secure replacement. Just as we switched to https, ideally an "xmail" or the like would get created as an open standard with open software that was email with better security by default. Sadly I'm not sure we collectively have the ability to do that kind of thing any longer, powerful entities have realized it's just too attractive to lock it up. But even many open source organizations don't seem to feel like bothering. Plenty of security experts even just prefer new shiny and will spout ridiculous "move to instant messaging". So status quo rules for the foreseeable future.
Email is one of a great number of internet communication systems. It happens to be one that was created before security was much of a concern (and before it was a problem we could solve), and also one that is highly asynchronous. Newer systems have their own different sets of tradeoffs. None of them happen to be email plus security. But that makes sense: now that everyone is online most of the time, why would you design a highly asynchronous store-and-forward-ish system? Of course you want a recipient to receive a message as soon as you sent it and the sender to confirm the recipient received the message. Designing a new system any other way would be leaving value* on the table. (*actual value not economics value)
We can extend email, though. Why isn't there an SMTP GETKEY command to return a PGP key corresponding to an email address? Sure, the sender might not support the same version of PGP, and sure, the connection might be intercepted (hopefully you'd not trust the output of this command except over TLS), but like most of the email system, it would be a big improvement and good enough most of the time.
I think your view of email is romanticized, or perhaps skewed because of your social circle. Email servers sometimes use TLS to talk with eachother, and emails are signed. But that's the extent of encryption when it comes to "real email". Email content is not encrypted in "almost all" of "real email" because almost nobody uses PGP.
I don't know what social circle I should be part of to consider email unsecure.
Even Russian spies use mail.ru and their emails are compromised not by SMTP MitM but by weak passwords, google for "moscow1 moscow2 password" to see what I am talking about )
Anyway. Back to the technical point. Email servers pretty much always use TLS to talk to each other. The connection may degrade to non-encrypted for backwards compatibility, unlike HTTPS. But it's vanishingly rare.
So, for all practical purposes that affect ordinary citizens: injection, scanning and sensitive information extraction, email in transit is quite secure.
If you're in IT at a carefully run org: You ditched 512-bit keys years ago. This article is nothing but a 20-second story, to help explain to PHB's and noobs why they got an error message, or what sorta important stuff you're always busy keeping your org safe from.
If you're in IT at a scraping-by org: Maybe today's a good day to ditch 512-bit keys. And if you get push-back...gosh, here's a how-to article, showing how a "forged corporate signature stamp" can be made for only $8.
If you're trying to teach senior citizen how to avoid being scammed on the internet: You've got zero visibility or control, so you're stuck with "sometimes these can be forged, depending on technical details" generalities.
"How we X'd a Y" is a linkbait trope. We edited that in accordance with the site guidelines: "Please use the original title, unless it is misleading or linkbait". https://news.ycombinator.com/newsguidelines.html
Thanks for clarifying. Interestingly, in the guidelines, there's an example of where you _add_ "How" instead of removing it: "E.g. translate '10 Ways To Do X' to 'How To Do X'". That tripped me.
Well, backend is our precious server resources and front end resources belong to the lowly user. It's a matter of scale though, frontend is optinized for one concurrent user. Plenty of small websites using slow and bloated frameworks on the backend because it's easy.
Me writing over 14 years ago: https://blog.jgc.org/2010/06/facebooks-dkim-rsa-key-should-b... This was doable 14 years ago for 512-bit keys.
For a number of years it was (non-officially) thought to be a feature to use weak DKIM keys. Some folks argued that short keys allowed you to preserve deniability, since DKIM signatures would only be short-lived and nobody would be able to use DKIM signatures to prove that any email was authentic. (I’m not saying that this is why most companies used short keys, just that there was a general view that short keys were not all bad.)
DKIM deniability is a particular hobbyhorse of mine [1]. These short keys are obviously not the way to achieve it, but I view this kind of thing as a result of the muddled thinking that’s been associated with DKIM and the community’s lack of desire to commit to the implications of an all-email signing mechanism.
[1] https://blog.cryptographyengineering.com/2020/11/16/ok-googl...
I forget where but someone proposed regularly rotating your DKIM key and publishing old keys for deniability. So you can still use strong keys and provide a level of deniability.
Doing this only provides deniability in public. If this was brought to a court there are enough server logs to build out if that DKIM record was valid along with a number of DNS history providers.
As if courts care about any of that. They'll just ask the witness "did you send this email"
Counter-example: I've used DKIM as evidence in court.
Counter-example example: I've been an expert witness in court to prove an email was a forgery; using DKIM.
It'd be funny if we were working together and just telling the same story behind our aliases.
My case was a family court dispute where one parent forged an email from the other parent about the child's care. It was a pretty wild case. After that, I was pretty convinced some people are just evil.
That would be a counter-counterexample, wouldn't it?
The stacking of either term is unnecessary, because all counter-examples are also examples, thus:
* an example supporting the counter-example is simply another counter-example, and
* an example contradicting the counter-example is, by definition, also another counter-example.
Corollary: all examples that can be opposed or contradicted by counter-examples are themselves also counter-examples.
Nah, it supports the counter-example, so it's a counter-example example.
I'd say it refutes the counter-example. The court doesn't care about DKIM, they care about witness testimony.
DKIM might have convinced the witness sometimes though.
https://xkcd.com/538/
Which is why you say "No". Then when they try to prove that you did in fact send it, this comes up.
Well, if you did send it then you just perjured yourself, so you better hope you don't get caught :)
You'd be lying to the court either way if you did send it and meant to conceal it.
Right. There’s generally going to be other evidence. Rotating the DKIM isn’t going to save anyone relying on the shaggy defense.
This isn't about evidence. In a court case, discovery and court orders can authenticate email messages even if providers publish their keys; the provider will have a record of having verified the email when it was received. But ATO attackers will not have access to those records.
In the link in the parent comment. :-)
I've been doing this since around 2018, and have seen a few others implement it.
https://rya.nc/dkim-privates.html
That was Matt Green, the person you replied to =)
I don't think this rationale is correct. DKIM doesn't authenticate a user, since the user doesn't the private key - DKIM authenticates that the MTA knows the private key on behalf of the domain owner, which isn't necessarily the users using that domain to send email.
What's more dangerous is that a jury wouldn't know the difference.
For 20 years Fastmail allowed any customer to spoof From: another
https://news.ycombinator.com/item?id=42536750#42539217
Ha, at least ! Thank you for the comment.
If there is some mail from my addr, with a valid DKIM signature, it proves nothing: - perhaps the mail was sent by somebody else on the same plateform, but in my name (identity usurpation of the user part of the mail) - perhaps somebody got illegal access to my email account, without me knowing - .. ?
In no case it proves that I, as a human, sent this email.
But of course, justice is a fiction that cannot exist: there is no justice, only probabilities (and feelings :( ).
Isn't deniability at odds with DKIM's goal? What would be the point of setting DKIM then? Sure, it helps with spam scores. But most companies rely on a major email provider to send emails, so maybe they wouldn't have deliverability issues anyway?
No. DKIM is meant to apply to emails in transit; it is part of the transaction of exchanging emails. But DKIM signatures are verifiable long after that transaction has completed. That was not an intended feature of DKIM, and it's a grave privacy violation.
To satisfy DKIM's design goal, you only need a "current" DKIM key that is secure for a window of time. When that window of time passes, you rotate the secret and publish your own key, repairing (hopefully) much of the privacy injury.
> it's a grave privacy violation.
I'm missing something here. DKIM mostly proves an email from person@from.me was sent by a server @from.me controls. There is also a bloody great audit trail inside of the email with together with SPF can do a pretty good job of proving the same thing.
I'm struggling to see how an email sent to me, that presumably was always intended to be readable by me could suddenly become a privacy violation because it's signed. That is doubly so if I won't receive it if it isn't validly signed when it is received, which is often the case.
I'm not sure privacy violation is necessarily the right term to help people understand why long-term non repudiation is an undesirable property for some people.
It comes down to if a third party gets access to your emails (e.g. through a server compromise), should they be able to prove to a fourth party that the emails are legitimately yours, vs completely faked? Non repudiation through strong DKIM keys enables this.
Example: Third party is a ransomware gang who releases your emails because you didn't pay a ransom after your email server was compromised. Fourth party is a journalist who doesn't trust the ransomware gang, but also wants to publish juicy stories about your company if there is one, but doesn't want to risk their reputation / a defamation case if the ransomware gang just invented the emails.
Non-repudiation is virtually always undesirable in general-purpose messaging systems. Revealing to a stranger whether a message is valid is a concession to that stranger, not a benefit to the email's owner. This property is called "deniability" and most secure messaging systems go way out of their way to have it.
It's nobody else's business whether the emails in your inbox are valid or not, and that's basically all non-deniable DKIM signatures do: durable secure verifiable DKIM signatures are "security feature" with real-world value exclusively for attackers.
If you’re under Rule 26 discovery or disclosure requirements, it absolutely might be my business whether emails in your client are valid, but I suppose you could classify opposing counsel as an “attacker,” so you’re not wrong.
Note, just to rub this in: you don't even get the verification you're looking for, because DKIM verifies domains and not users.
I get the verification the email actually came from the domain (i.e., someone, who has the credentials of an insider) vs. an email that was totally spoofed, from the outside, without any creds of the purported sender org. (Right?)
Hands on keyboard? You're right, absolutely not. But I can learn something useful via DKIM nevertheless.
> To satisfy DKIM's design goal, you only need a "current" DKIM key that is secure for a window of time. When that window of time passes, you rotate the secret and publish your own key, repairing (hopefully) much of the privacy injury.
If this occurs, is DKIM privacy safe? To make sure I understand, by publishing the private key after a period, that allows for repudiation, since any real email at that point could have been faked using the published private key?
The point of DKIM is to provide DURING TRANSIT that a server is the server is allowed to send emails from that domain. Once the transaction is completed, it doesn't matter if the key even continues to exist: it was verified during transit.
The fact that people do not rotate keys or use secure keys means that you can use it for other things as well, like detecting forgeries. It wasn't meant for humans, but for machines.
Repudiation is the goal.
Repudiation doesn't work if the receive discards the email if it isn't signed, or marks it as DKIM validated when it is received. Many receivers using independent email providers like gmail, so the sender has no control over whether it happens or not. Both practices are common today, so it likely it does happen.
Rotating the key does make the claim "I have proof he sent it" a litter weaker, as it's no longer as easy to prove. But only a little as "your honour, it is marked as DKIM verified by the independent email provider he uses" is pretty solid.
Rotating the key and publishing the private key destroys the ability of an after-the-fact attacker (someone who pilfers older mails out of your inbox) to prove they obtained a real email. It's not an "only a little" thing; it's categorical.
When using deniable authentication (e.g. Diffie-Hellman plus a MAC), the recipient can verify that the email came from the sender. But they can't prove to a third party that the email came from the sender, and wasn't forged by the recipient.
Mallory sends a message, forged as if from Alice, to Bob. How can Bob determine that it came from Alice and wasn’t forged by Mallory?
No, no, in these systems Alice and Bob both know a secret. Mallory doesn't know the secret, so, Mallory can't forge such a message.
However, Bob can't prove to the world "Alice sent me this message saying she hates cats!" because everybody knows Bob knows the same secret as Alice, so, that message could just as easily be made by Bob. Bob knows he didn't make it, and he knows the only other person who could was Alice, so he knows he's right - but Alice's cat hatred cannot be proved to others who don't just believe what Bob tells them about Alice.
Now it makes sense why Alice was sending me that kitten in a mixer video.
But seriously, in a case before a court or jury, wouldn't there be much more evidence? Down to your own lawyer sending a complete dump of your phone with all those Sandy-Hooks-conspiracies and hate messages to the opposing side?
Sometimes instead of a complete dump, you might mutually agree on a third party forensic lab to analyze your phone and only provide relevant details to the opposing side. Usually there's a few rounds of review where you can remove some details/records that are not relevant before the distilled records are sent to the opposing counsel.
Deniability is just that, the opportunity to deny. Will denying change what people believe? Well, maybe or maybe not. I'm sure you can think of your own examples without me annoying the moderators.
This is always a possibility but I'm guessing the happy path is the more likely believable scenario and could be verified OOB.
The idea is to use a MAC instead of a signature. As long as Alice isn't compromised and sharing her key with Mallory (which she could do even in the signature case), when Bob receives a message with a valid MAC on it, he knows that Alice authorized the message.
Do take a look at the blog post I cited above, where I go into this in loads of detail. The TL;DR is that DKIM only needs to ensure origin authenticity for the time it takes to deliver an email, which is usually a few hours or a day at most.
The unintentional problem DKIM is causing is that it actually provides non-repudiation for many years. Those signed emails can sit in someone's mailbox for years, then get stolen by a hacker. The hacker can then blackmail the owner by threatening to dump the email trove, or for newsworthy targets they can just do it. Reasonable people (e.g., high-integrity newspapers, courts of law) will say "how can we trust that these stolen emails are authentic given that there's no chain of custody?" DKIM signatures nearly answer that question, which makes stolen emails much more valuable than they would be otherwise.
That's not quite what he's saying.
DKIM's goal is that the receiving system can trust that the message presented to it has come from a host that knows the key, and so could sign it. At the time that message is received, you should be able to assume that only people authorised to send from that domain are able to do so.
By publishing older keys, you gain deniability back, because anybody could have forged the message and signed it. Even if you have timestamps that show when you received the message, the onus is one you to prove that those timestamps are not fabricated. This is a much harder problem because secrets can be revealed later but not forgotten.
To be able to prove that you did it fact receive the message on that date, you'd probably have to record e.g. the message ID, signature and timestamp (perhaps all encrypted with a key that you can reveal later) on a blockchain, which would then serve as proof of when the message was received. Even then, you'd still have to prove that the key hadn't been disclosed before that time.
Yes.
Deniability and perfect forward secrecy are at odds with how people use email anyway. But that doesn't stop people from demanding both very loudly, and some people from promising them.
I don't know what you're saying. Most email isn't encrypted so PFS wouldn't apply to the content of email messages. When you mention PFS are you talking about email encrypted with something like GPG/PGP? Or are you talking about PFS in the context of the TLS connections used to protect SMTP? I'm not sure what "deniability" refers to in your post and how you think people use email in ways that would contraindicate it. Once I understand what you're saying, I guess we could move on to who the demanders and promisers are and what you think they're doing.
You should read the blog post Prof. Green linked to. All of your questions are addressed there.
Yes, I've now read it and it answered those questions. But it also stumbled upon an easier possible solution without realizing it: if you wish to pretend you didn't send some emails, you can still claim that someone stole your password. Whether this claim will be believed or not, is independent of DKIM.
Spoofing is a better excuse than a stolen password only in the case of a single email. If there's a conversation spanning multiple messages, a spoofer wouldn't be able to properly answer the messages of the other party, as he doesn't receive them.
If someone lies that their password was stolen to hide them being the originator of a single email, who are they telling the lie? Is it a court? In many cases the person would be caught through behavioral analysis. They didn't change their password, so it wasn't really stolen. No other emails were improperly authored, so it wasn't really stolen. They never reported it to the email server owner, so it wasn't really stolen.
Lying isn't a stronger defense to perform abuse than weak keys are for stopping abuse.
> They didn't change their password, so it wasn't really stolen
You change your password only after you realize it got stolen. If you didn't realize it, then it makes sense you didn't change it. And, depending on the specific case, you could find plausible explanations also for the other points.
I used to spoof emails to my teachers in high school asking them to come to the principle's office asap, and email the principle from another random teacher at the same time for him to come to the class room, and that random teacher to expect the principal at a certain time. We'd be teacher free for quite awhile because the principal wasn't there, and our teacher was.
You don't need a conversation to cause havoc.
> You don't need a conversation to cause havoc.
Sure, but my point was different: let's say one of your teacher answered the spoofed email from the principal, you wouldn't be able to (properly) answer that email since you wouldn't receive it. So, in the case of an email exchange between two people, one can't claim his/her emails were spoofed, as the spoofer wouldn't be able to answer the other party's emails in a precise and on topic way. This is without even considering that, bh default, most email clients include the previous messages inside a reply. Meaning that the spoofer would somehow be able to know the other party's reply exactly word by word.
If you publish DKIM keys, you don't have to convince anybody that you were targeted by someone who stole your password, because your stolen email spool no longer reveals to attackers the authenticity of your emails, which is what you as a user want.
But you need to convince someone that someone targeted you and used the published key to forge an email. Where is the difference?
No you don't. You just say "that email is fake and you can't prove otherwise", and you're right. What's almost more important is: there is no reason not to give users that affordance. They literally do not benefit from the non-repudiability of their email archive. The OTR paper got this right 20 years ago, and in the process basically created the entire field of secure messaging.
It is wild to see people argue against it! They're basically pleading with email providers to collude with attackers to violate their privacy.
https://otr.cypherpunks.ca/otr-wpes.pdf
I think here is where the problem isn't purely a technical one anymore. You're right that, from a legal perspective, there is a difference as the burden of proof would now be on someone else. But, if this actually matters or not, depends entirely on the situation. If you're a criminal trying to get away with something then the change in the burden of proof is all you need. If instead you're a politician trying to avoid some imbarassment, the situation isn't any different: you're claiming in both cases that someone is trying to frame you for something you didn't say. In one case, this person stole your password, in the other he/she used an old and by now publicly available DKIM key. But if people believe you or not (and this would be everything a politician would care about) depends on factors outside the scope of cryptography. Regarding OTR: IIRC it is based on a shared secret. This can work for IM, but it wouldn't scale for emails as it would pose the key distribution issues that made us discover public key cryptography.
If you are a politician trying to get away with something, the public might have an interest in your secure messaging system being bad, but you yourself do not. Secure messaging systems generally take the side of their users, not the public.
Sorry, I'm missing what you're trying to say here, maybe that a politician would be more careful about which message system he's using? I don't think that's necessarily the case.
Anyway, to further add to my point, depending on the context you don't even need to claim that someone stole your password. In the company where I am now , it is custom that, if someone finds out someone else didn't lock their computer, that someone sends an email (from the victim's account) to the whole office saying that the victim is going to bring cake to the office. DKIM is meant to prove that a message comes from an authorized server, but to prove the identity of the sender as well you need something more.
Edit: to be fair, I do get that with DKIM deniability gets harder. But I think that, for the average person, you would gain more in terms of spam and phising protection than what you loose. High profile targets have to take different security measures than the masses anyway.
What I'm saying is that the "crooked politician" use case you're talking about for DKIM is a way in which you're pleased that a messaging system is insecure, because that insecurity works in your favor (because you're not the user; you just want to violate that user's privacy). But no rational user would want that property for themself; they can only lose from it.
Thank you, I get it now. The reason why I focused on that specific example, is because it is used in the blog post as proof that DKIM is being actively used to prove that someone actually sent an email.
From the blog:
> The fix would cost you basically nothing, and would remove a powerful tool from hands of thieves.
Maybe that was true a while ago, but it becoming much less true now. Most people and organisations outsource the email handling to the likes of Google and Microsoft. They tend to reject email that isn't DKIM signed, and add a "DKIM validated" header to those that are. "Tend" is probably too weak a word now - email that isn't signed isn't likely to be delivered.
So the mostly likely scenario now is "someone steaks email that can no longer be DKIM validated, but it is possible prove it was DKIM validated when it was received". If that's true rotating keys doesn't help.
The idea isn't to stop Google from signing and validating DKIM. It's that the major players who do DKIM should rotate and publish their keys, so that at any given instant their current DKIM key is only valid for N hours, and after that it's public, so anyone can forge backdated messages.
Meanwhile in the real world, screenshots of emails without any cryptographic authentication at all are good enough to send people to prison.
The issue here isn't rules of evidence, it's user privacy. In the real world, DKIM has repeatedly been used to violate privacy. More importantly: latent verifiable secure DKIM signatures on archived emails offer no value to users; they literally only have real-world value to attackers.
> More importantly: latent verifiable secure DKIM signatures on archived emails offer no value to users; they literally only have real-world value to attackers.
I don't think this is quite true. First of all, this is not only valuable to attackers, it's also valuable in a court of law to establish the truth of what happened. Secondly, it can be valuable to me to be able to prove that you sent me an email, even if you wished to deny it, also mostly in legal contexts.
Those are cases where DKIM is working against the user! I get that we can come up with cases where we're glad some hapless user is undone by DKIM, but when we're discussing messaging security, we generally take the side of the hapless user, not the courts and tort lawyers!
An email exchange has two users: one is the sender, the other the receiver. As the receiver, having proof that I received an email from you is potentially a feature, not a problem.
More generally, authenticated communication has a long history of being considered a useful thing for society. Physical mail includes delivery confirmations where the receiver must sign for the receipt, proving to anyone that they did receive the letter. People would often add hard-to-forge personal seals to letters in even older days, that could prove to anyone that they were the ones who sent that document. And even common letters were usually signed rather, even when typewritten, again making it hard to later repudiate.
While I absolutely see the value in making it possible to securely send repudiatable email in some specific circumstances, I think having non-repudiatable email as the default is a net benefit to society, and has been the de facto standard for at least a few hundred years before email ever came along.
This is the classic argument in favor of verifiable DKIM signatures: because it benefits the consumers of hacked mail spools. Consider that as a security engineering decision, enabling that use case is a bad thing.
It would then make sense to encrypt the email content.
Repudiation of clear text messages looks like the easier implementation.
That creates other problems. Content analysis is a large part of anti-spam. Which is a much more important problem than (non-)repudiation and all that.
Only if the defendant doesn't challenge the evidence. If I'm the defendant and I know I sent those emails, I'm not going to challenge the screenshot. If I know I did not send those emails, then I'll do my best to pay for forensic analysts to generate evidence to exonerate me.
Experts are expensive. Most defendants never get them.
I absolutely believe you - lawyers, judges, and juries alike tend to be technologically illiterate, but do you have any references/links to this happening?
If you read the blog post, you'll see that newspapers frequently verify DKIM signatures on stolen email corpora before they publish about them. Eg: https://www.propublica.org/nerds/authenticating-email-using-...
They were asking for evidence that people have been convicted based on screenshots of emails, almost the opposite of using DKIM to authenticate emails.
In particular where the defendant denies the veracity of the screenshot.
[flagged]
It's tiring that most things have to come back to politics nowadays.
What's the problem with verifiable email? You can just delete old emails (if gmail or whoever archives them that's another problem). Most people probably operate under the assumption that email is verifiable in some way anyway. If you receive malicious email, isn't it a good thing to be able to verify where it came from? Doesn't that benefit senders and receivers alike? Or is this a case of "I want to verify you, but I don't want you to verify me"?
It's more "I want you to be able to verify I sent an email to you, but I don't want you to be able to prove to a third party that I sent it."
The fact that this is possible is some cryptography black magic.
I don't see how this could be possible. If I have some information which I can use to prove that you were the sender, then I can just share the same information with a third party, and they can verify just the same.
Simple, I tell you that in my message, if it’s genuine, I’ll use the word “apple” somewhere.
You tell me that you’ll use the word “banana”.
Provided no-one except you knows that my secret word is “apple”, you know the message came from me.
But it’s perfectly possible for you to fake a secret message and sign it “Love d1sxeyes, P.S. apples”, and so our approach only works between the two of us. A third party probably can’t even confirm that “apples” was the correct keyword, and even if they could, that can only prove that one of us wrote it, they can’t definitively say which one of us.
Now extrapolate this to using some more sensible mechanism than dictionary words.
Yes it seems crazy, but besides the obvious "leak your own key" as other comments mentioned, this is actually possible. This is one of the biggest discoveries in cryptography in the last decades and its implications are still being researched. I dug around and found this article which seems to do a pretty good job describing the cryptographic concepts of "non-transferability" / "deniability" / "deniable authentication" for a lay audience: https://dinhtta.github.io/zkp/ Also: https://en.wikipedia.org/wiki/Deniable_authentication
Hmm. So basically any protocol with a shared key?
I.e. a symmetric key is shared between you and me. If I receive a message with that key, I know it's from you because the key is only known by you and me, and I know I wasn't the sender, so it must be you. But any third party can only say that the message was by one of us.
The idea is that for spam filtering purposes, you can prove this morning that the email I sent you this morning came from me, because I’m the only person who had the signing key on it. Anyone else could validate that too.
But let’s say I publish that signing key tomorrow. Once I do that, you can’t prove I sent today’s mail because anyone could’ve used that published key tomorrow forget the signature.
Ok, so there's a time window where it's possible to prove that you were the sender. And if I use a qualified timestamp service to sign all messages arriving in my inbox, then I can prove that you were the sender indefinitely.
Something like that, as long as you can also prove I hadn’t published the key prior to that. If I publish at random times and to random URL, that may be challenging.
Yes, but then it also encroaches on ability to verify that you were the sender when receiving the original email. Basically, unless the recipient also checks whether the current DKIM key has been published, then they can't trust it because it may be published. If it's being published at random times and to a random URL, then it's nearly impossible to actually check.
So I agree that it brings deniability, but I don't agree that it still meets the original purpose of verifying the sender.
That’s all true, but I bet 99.99% of all email is delivered within a minute or so of being send. There are exceptions, of course, but in practice the whole thing is pretty fast.
So there’s some threat modeling, too. Are you trying to email someone highly adversarial? Maybe you’re at a law office or such and that’s the case! This wouldn’t help a lot there. Not everyone is immediately forwarding all inbound mails to a timestamping service though.
(I don’t have skin in this game, so I’ll probably duck out after this. I don’t have opinions on whether publishing old DKIM keys is good or bad.)
It's pretty simple with a couple concepts.
If Alice and Bob each have a public/private key pair, they can do a diffie-hellman key exchange to form a common secret. If they use that secret to authenticate a message, then it can be shown that only Alice or Bob sent the message. If you're Alice or Bob, this is what you want to know --- either you or your corespondent sent it, and if you didn't send it, your correspondent did.
But if Alice or Bob asks Carol to validate it, Carol can only determine that Alice or Bob sent it, and perhaps not even that. Anyone in possession of the secret used to authenticate the message can also make a message that would be deemed authentic. If you have participation of Alice or Bob, you can show that the secret was derived from DHE with Alice and Bob's key pairs, but that's all.
This is nifty and useful, but it's more appropriate for end to end communication, which is not the domain of DKIM. Email is a multi point store and forward system, where each point would like to know if a message is authentic; deniability like this would probably mean either
a) only the final destination could determine authenticity and therefore intermediates would not be able to use authenticity as a signal to reject mail
b) only the first intermediate could determine authenticity; it could be used to reject mail, but the end user would have to trust the intermediate
Both of these are workable systems, but DKIM provides that all intermediates and the end user can know the mail was authorized (to some degree) by the origin system.
Both parties use the same key: https://en.m.wikipedia.org/wiki/Symmetric-key_algorithm
Imagine that yesterday, I had only one house key, and I left a copy of it in your mailbox so you could come into my house to borrow a cup of sugar while I was out. You can be sure I allowed it, because you know I had only one key.
Today, I made 3 copies of my housekey and gave them to friends. You still know that I was the one that allowed you entry into my house, but you can not prove to anyone else that I was the one that made the copy, because there are now 3 other people that could do that.
(For this example, imagine I made the key copies at home and didn't go to a locksmith who could verify when they were made, since we don't need a locksmith to do software crypto)
Reminds me of the story of a guy cracking one thinking it was a Google headhunting challenge.
https://www.wired.com/2012/10/dkim-vulnerability-widespread/
Just as an interesting FYI for those who care: the parent poster is the CTO of CloudFlare.
Your blog got a mention in the comments of http://www.wired.com/threatlevel/2012/10/dkim-vulnerability-...
> "Keys of 512 bits have been shown to be practically breakable in 1999 when RSA-155 was factored by using several hundred computers and are now factored in a few weeks using common hardware."
So we went to a few weeks to 8h in 14 years give or take
86 hours. 8 dollars. I wonder how scalable it is. They only used:
> We chose a server with 8 dedicated vCPUs (AMD EPYC 7003 series) and 32 GB of RAM from Hetzner
Not very beefy really. Beating this time is easily in range of, what, millions of people high end gaming machines?
I'm wondering if this process can be GPU optimized. It's possible to rent really beefy GPU cloud instances for a few bucks per hour. <1 hour seems to be in reach.
> 86 hours
I stand corrected
I'm pretty sure I can do it in two hours.
86h, wasn't it? But regardless your point stands.
First time a 512-bits RSA number (RSA-155) was factored was in 1999!
2010, Nostradamus :)
Depends if you're rounding up or down.
If you want to try something fun:
Provision a 4096-bit DKIM key.
Every online DKIM/SPF checker will say all is good when looking at your DNS.
They will also fail any test email you send, with more or less excellent descriptions such as:
STATUS: Fail
DKIM: Pass
SPF: Pass
There's this fun thing that, apparently:
It's permitted and valid to use keys larger than 2048 bits in your DKIM entry.
It is not, however, required to process keys larger than 2048 bits.
This cost me some hair to learn the hard way.
Addendum: You need to set a strict dmarc policy for the checks to fail. Interestingly, the sites will tell you all three are correct and valid, but still fail the mail.. This is probably due to different pieces of software doing the dns record checking and the email validation.
Could someone help me understand why we're not dramatically ramping up key sizes across the board on all encryption? Not as a solution, but as a buy-some-time measure.
Compute is rapidly increasing, there is continuous chatter about quantum and yet everyone seems to be just staring at their belly buttons. Obviously bigger keys are more expensive in compute, but we've got more too...why only use it on the cracking side, but not on defense?
Even simple things like forcing TLS 1.3 instead of 1.2 from client side breaks things...including hn site.
Old but still relevant: https://www.schneier.com/blog/archives/2009/09/the_doghouse_...
Long story short, brute forcing AES256 or RSA4096 is physically impossibleThat’s true for AES-256. But brute force attacks are not the most efficient way to attack RSA, so it’s not true in that case. (Eg quantum computers would break RSA-4096 but not AES-256).
We are. 1024-bit keys are being retired across cryptosystems everywhere, and have been for over a decade (don't get me started on the one laggard). Nothing threatens 2048 bit keys other than QC, which threatens RSA altogether. Progress isn't linear; it's not like 2048 falls mechanically some time after 1024 (which itself is not practical to attack today).
People might be assuming that 2048-bits is only twice as strong as 1024-bits, but it's in fact a billion times better. (corrected, thanks!)
That would be true if RSA scaled proportionally with the number of bits, but the exponent involved is much lower than 1. 1024->2048 gives you around the same difficulty as adding 30 bits to a symmetric key.
I stand corrected, thanks! 2^30 still means a billion times better.
It's also only true so long as we don't discover more efficient ways of factoring large numbers. We haven't come up with any dramatic improvements lately, but it's always possible that something will come up. Symmetric crypto systems like AES are on much firmer ground, as they don't depend as heavily on the difficulty of any single mathematical problem.
By "lately" you mean...
I'm hedging a little because I'm not an expert. :) As far as I'm aware, the last major algorithmic development was GNFS in 1993.
we are definitely not.
most countries registrar's won't support DNS hacks requied for larger dkim.
we still use the minimum key size in most countries.
What? Just use normal name servers. The registrar doesn't matter one bit, they delegate the zone to whatever name servers you specify. Those can serve whatever records properly.
Probably because RSA 2048 is not yet broken, and once there we still have RSA 4096 to lean back on which is since quite some time the most common key size for most things using RSA (DKIM being one of the exceptions).
In the context of DKIM we're waiting for Ed25519 to reach major adoption, which will solve a lot of annoyances for everyone.
> Probably because RSA 2048 is not yet broken […]
3072 has been recommended by various parties for a few years now:
* https://www.keylength.com
Is there a compelling reason to use 3072 instead of 4096? If you're going to kick the can down the road you might as well put some effort into it. The difference in memory use/compute time has to be marginal at this point. It's not like the old days when jumping from 512 to 4096 made the encryption unusably slow.
There's no good reason at all, which is why RSA-3072 is the rarely seen "oddball".
> There's no good reason at all
Operations per second?
* https://wiki.strongswan.org/projects/strongswan/wiki/PublicK...
Running MacPorts-installed `openssl speed rsa` on an Apple M4 (non-Pro):
(Assuming you have to stick with RSA and not go over to EC.)These are contrived benchmarks at the extreme end of things. In real world usage the difference is drowned-out by the delays of so many other things happening in order to complete a handshake and key exchange. The mildly higher performance of RSA 3072 versus RSA 4096 wasn't even a big bonus during the CPU performances we had 15 years ago.
It's roughly half as fast as 4096, which sounds bad until you realize that 3072 is already 20% as fast as 2048, 3% as fast as 1024, and 1% as fast as 512. In terms of performance tradeoff it's downright mild compared to the other steps up.
If I could waive a magic wand and get a 40-100% performance boost on a service by changing 3-4 characters (s/4096/3072/) why wouldn't I take it? (Assuming I need security go to beyond RSA 2028.)
Its not a 40-100% performance boost overall, its just during one specific step that is a very small part of the entire overall system.
Well, in typical use cases RSA usage is very limited (eg some operations during TLS handshake), so the 40-100% boost wouldn’t be across the board, but likely shave some milliseconds per connection.
RSA 2048 isn't broken, but experts consider it a matter of time. How long I don't know, but since the attacks are known (prime numbers) someone (read not me) can make an estimate with error bars that are concerning enough to consider it as good as broken.
What expert considers it a matter of time before 2048 is broken? 2048 is 112-bit-equivalent security.
RSA2048 is 112-bit-equivalent symmetric security under currently known methods. Number theory advances may change that. It is hard to imagine any significant advances in the breaking of symmetric cryptography (mathematically-unstructured permutations).
Cryptographically-relevant quantum computers (CRQC's) will also break smaller RSA keys long before (years?) the bigger ones. CRQC's can theoretically halve symmetric cryptography keys for brute force complexity (256-bit key becomes 128-bit for a CRQC cracker).
https://www.keylength.com/en/4/ NIST says 2048 bit RSA is good until 2030. I'm not sure what that means, perhaps that it will be broken considering advances, perhaps just that someone (read governments) who cares to spend 5 years on the problem will break your key.
No, we are not in fact 5 years from breaking RSA-2048.
AFAIK even RSA 1024 isn't broken yet.
RSA-1024 is "only" 80 symmetric equivalent bits. It's a space requiring a tremendous amount of energy to explore, though I personally consider it very likely that the NSA and/or the MSS et al. have poured immense funds into accelerators specifically targeting RSA, and for them there'd be no obstacles at all to be granted an allocation for such energy consumption.
Nobody is recommending RSA-3072 per se. The recommendation if wanting to stick with RSA is to move beyond RSA-2048, and the world at large jumped all the way to RSA-4096 long ago.
But perhaps with not a very solid justification to do so:
* https://articles.59.ca/doku.php?id=em:20482030
Ed25519 has seen broad adoption in TLS and other stacks that are used pervasively where DKIM is also used. What’s blocking it for DKIM uniquely?
(This isn’t intended as a leading question.)
X25519 has seen broad adoption (in the key exchange). Ed25519 has not, you can't actually use an Ed25519 certificate on the web. It's in a deadlock between CAs, browsers and TPM manufacturers (and to some extent NIST, because Ed25519 has not been approved by them).
It's not being blocked per se, you can use it mostly (98%) without any issues. Though things like Amazon SES incorrectly reject letters with multiple signatures. Google and Microsoft can't validate them when receiving. It's more that a few common implementations lack the support for them so you can't use _just_ Ed25519.
> (and to some extent NIST, because Ed25519 has not been approved by them).
Ed25519 (and Ed448) have been approved for use in FIPS 186-5 as of February 2023:
* https://en.wikipedia.org/wiki/EdDSA#Standardization_and_impl...
Oh, great to know. That gives me hope that we'll see Ed25519 certificates at some point then.
Everyone has to be onboard before the switch can be made, and not everyone is happy about the somewhat messy solution of running dual-stack RSA+Ed25519 setups in the interim - it's a bit different than e.g. supporting multiple methods for key exchange or multiple ciphers for symmetric crypto. It's just one of those things that take time to happen.
If the big players (gmail, outlook) jump onto it the rest will be forced to follow. Outlook would probably jump in with a checkbox, and perhaps gmail will make at an option for the paid tier while everyone on the free tier gets no choice - but that is still enough. SmallCompany.com cannot do it alone, probably not even a fortune100.com (if any of them even care - their sales staff probably will overrule the few who do), but there are enough players if they all agree on something.
Getting the big players to agree and execute though is a lot like herding cats. I'm sure some in the big players are trying.
> What’s blocking it for DKIM uniquely?
Mail server administrators.
Because the only way to force their use is to break things, mostly this means transferring the pain directly to the user instead of the service operators in the hope that they will bitch loudly enough for the service operator to care, and this has a good chance of instead causing the user to move to your competitors instead, who will be more than willing to not let a little thing like security get between them and revenue.
"dramatically ramping up key sizes" is not done, because it's overly expensive, and not needed.
What people don't realize: key size recommendations are surprisingly stable over long timeframes, and have not changed for a very long time. In the early 2000s, some cryptographers started warning that 1024 bit RSA is no longer secure enough, and in the following years, recommendations have been updated to 2048 bit minimum. That's now been a stable recommendation for over 20 years, and there's not the slightest sign that 2048 bit can be broken any time soon.
The only real danger for RSA-2048 is quantum computers. But with quantum computers, increasing your RSA key sizes does not buy you much, you have to move to entirely different algorithms.
> That's now been a stable recommendation for over 20 years, and there's not the slightest sign that 2048 bit can be broken any time soon.
Except that now the recommendation by NIST at least is to switch to 2048-bit by 2030 and then deprecate RSA altogether by 2035.
But yeah, not being on at least 1024-bit RSA is weird and careless.
512 DKIM was exceedingly rare even 8 years ago when I worked in email.
You're essentially asking "why aren't we doing what we're doing"
The key sizes we use today are expected to hold against a Dyson sphere focused on breaking them with the best exploit we know today.
What size do you suggest?
It's not quantum-safe though.
Larger keys won't make the algorithms quantum-safe either.
If I'm not mistaken, larger keys require more qbits in a machine to all be coherent together to be able to break it.
So it would be a slight increase in complexity, but if we are able to build a machine with enough qbits to crack 1024 keys, I don't think the engineering is all that far off from slightly scaling things up 2x-10x.
Which is why post-quantum algos were invented.
> Which is why post-quantum algos were invented.
Yup. And I don't even think quantum resistance was the goal of some of the algos that, yet, happen to be believed to be quantum resistant. Take "Lamport signatures" for example: that's from the late seventies. Did anyone even talk about quantum computers back then? I just checked and the word "quantum" doesn't even appear in Lamport's paper.
> Did anyone even talk about quantum computers back then?
Not unless they have a time machine. Shor's algorithm was discovered in the 90s (sure the concept of a quantum computer predates that, but i don't think anyone really realized they had applications to cryptography)
It's not quantum-broken though, it might just make it a bit faster. Just half a Dyson sphere.
> Even simple things like forcing TLS 1.3 instead of 1.2 from client side breaks things...including hn site.
That’s the reason, it breaks things, and some of them are important and can’t simply be updated.
> That’s the reason, it breaks things, and some of them are important and can’t simply be updated.
IMO this is not a valid excuse.
If it's exposed to the internet it needs to be able to be updated with relative ease to respond to a changing threat landscape. Especially if it's "important". If it cannot be then it is already broken and needs to be fixed. Whether that fix is doing a hard upgrade to get to the point that future upgrades can be easier, entirely replacing the component, or taking the thing offline to a private non-Internet network depends on the situation, but "we aren't going to change, the rest of the internet should conform to us" has never been a reasonable response.
This is particularly true in the contexts of public mail servers where DKIM matters and anything involving public use of TLS. The rest of the internet should not care if your company refuses to update their mail servers or replace their garbage TLS interception middleboxes. We should be happy to cause problems for such organizations.
> IMO this is not a valid excuse.
The world is full of things that aren't "valid excuses". Explaining why something is the way it is is not the same as justifying it.
We are doing that, just not everyone is as concerned by safety and make different tradeoffs against things like ease of use or accessibility. Different applications have different tolerances and that’s fine.
If and when anything quantum is able to yield results (I wouldn’t worry much about this), increasing key size is pretty much meaningless, you need to move to other encryption schemes (there’s lots of options already).
In the case of RSA it's not meaningless to increase key size to fend off quantum computers. Quantum computing vs RSA is a case of being the largest contender, because quantum computing in itself doesn't definitively unravel the integer factorization problem.
That seems suspect to me.
Getting a working qc to reasonable scale is the hard part. Once you have done that most of the hard engineering problems are solved. I doubt doubling its size at that point would be very much of a problem.
If we are making (uninformed) predictions, i bet we wont see QC solving 1024 bit RSA in the next 15 years (at least), but once it does it will only take a year or two more to solve 4096.
Linear bit size increases require exponential compute increases to break. RSA with 1024 bits is still beyond any practical capability to break. The current practical limit is considered to be around 800-something bits. Still the recommendation is to use at least 3000 bits nowadays, to defend against possible mathematical advances.
This is incorrect. Factoring algorithms like GNFS are super-polynomial but sub-exponential. RSA-1024 is likely breakable at practical-but-very-expensive costs.
In the case of DKIM, Ed25519.
Compare the time it takes to generate or decrypt/encrypt 4096 bit RSA versus 16384 bit RSA (it's not four times slower).
Indeed. There has got to be some middle ground there though that is both an incremental improvement and still within reason on cost
> Could someone help me understand why we're not dramatically ramping up key sizes across the board on all encryption? Not as a solution, but as a buy-some-time measure.
I am acutely aware that there are SOME places where software only supports RSA and only supports up to 1024-bit or 2048-bit keys, and that is a legal requirement. Ramping up key sizes would be great but even 2048-bit keys aren't quite secure against certain kinds of actors (even disregarding hammer-to-head style of attacks)
> Even simple things like forcing TLS 1.3 instead of 1.2 from client side breaks things
... kind've a case in point about the pace of required improvements.
> Could someone help me understand why we're not dramatically ramping up key sizes across the board on all encryption? Not as a solution, but as a buy-some-time measure.
We've been doing it for decades now… (DES used 56bits back then, AES started at 128).
Also, keep in mind that increasing the key length by 1 means that you need twice as much compute to crack it through brute force (that is, unless cryptanalysis shows an attack that reduces the difficulty of the scheme, like for instance with the number field sieve on RSA) so you don't need to increase key size too often: following Moore's law, you need to increase it by on bit every two years, or 5 bits every decades. Additionally key size generally account for many years of compute progress and theoretical advance, so that you really don't need to worry about that over a short period (for the record higest RSA factorization to date is 829 bits, yet people started recommending migration away from 1024 bit RSA a decade ago or so, and the industry is in the process in deprecating it entirely even though it's probably going to take years before an attack on it becomes realistic.
> why we're not dramatically ramping up key sizes across the board on all encryption?
because no one thinks there is a reason to, no one has any fear that classical computers will catch up with RSA-2048/AES-128 before their grand children are dead.
post-quantum crypt stuff is happening and people are planning how to migrate to it.
Well, even MD4 hasn't been cracked yet.
What is your definition of cracked? Collisions are easy to produce; there's one right on the Wikipedia page.
Collisions are not interesting. Millions of leaked passwords hashed with MD4/MD5 are of very practical interest.
Ok, preimage resistance is still pretty strong, but it has been reduced enough that I wouldn't trust it remaining above practical attacks beyond the next decade.
If you use the same password on different sites despite password managers and now passkeys you are asking for it.
Key rotation tooling has never been given adequate attention since you only do it every few years. Something ends up breaking, even if it’s just the name of the key .
keys are stateful content like DB schemas, but they don’t receive daily attention, so the tooling to maintain them is usually ad-hoc scripts and manual steps.
because everyone recommending those things work on both sides.
they recommend 2048 and use 4096 themselves because if they need to ever break your 2048 it's less bad than if you were recommended to use 4069. wink wink
same with everyone recommending ed22519 when ed448 is as good and as fast to encode. but all the arguments point to encode speed from a Bernstein paper which used a pentium iii!
https://cr.yp.to/ecdh/curve25519-20060209.pdf
CADO-NFS makes this surprisingly easy to do. A few weeks back I factored a 512bit RSA DKIM key for work using my desktop computer in only 28 hours. Specifically, an AMD Zen 5 9900X.
Unfortunately 1024 bit keys are still out of reach of a hobbyist effort but could be pulled off by academics roughly of the same scale as the 2010 effort to factor a 768 bit key (https://eprint.iacr.org/2010/006.pdf)
Some DNS providers suck and only let you set 1024 bit long keys. For example wordpress.com.
Yikes. NIST wants to forbid even 2048-bit RSA by 2035, because it doesn't offer a good enough security level.
2048 achieves the same security level NIST requires from AEADs, doesn't it? What plausibly attacks it? Pushing people past 2048 seems counterproductive.
It should achieve the same level, yes. It's not exactly described what could attack it. Right now it seems that 2048-bits would be the last allowed step and they're not going to push people past 2048, they want to phase out RSA in general.
Counterproductive how and to what/whom? For the sake of keeping DNS TXT entries and e-mail headers compact? Would you stand by this statement also in the context of a certificate authority's root signing key, or an RSA host key for an ssh daemon?
There is no plausible threat to 2048, but you'd still rather people switch off RSA, either to curves (because they're more resilient) or to lattices (for post-quantum). Pushing people to higher RSA key sizes is a waste of effort.
RSA-1024 seems to be about 8 million times better than RSA-512, so cracking that would be $64 million in compute.
Not NSA-proof, but should be more than enough to keep spammers out, especially considering that DKIM is just one layer of protection.
That's just the extra compute required. There is a large increase in required memory that needs to be quickly accessible in a particular way. One estimate I saw claimed that breaking 1024 bit RSA would take more than 2 billion dollars over a period of years.
512 extra bits of key only gets you 23 bits of entropy?
Yep, the formula is a bit complicated, it comes from the general number field sieve (GNFS) algorithm, you can find some equivalences online between symmetric key algorithms and RSA and 23 bits seems about right. I have also seen lists where they give RSA-512 64 bits and RSA-1024 80 bits, just a 16 bit difference, but it looks a bit arbitrary to me. I think the NIST doesn't even look at RSA-512 anymore, as it is definitely broken, it only starts at 1024.
A RSA key is the product of two primes, not any number, so you need a lot more bits to get equivalent security to, say, AES. That's also a reason for elliptic-curve cryptography, which needs a lot less bits than RSA for the same level of security.
> A RSA key is the product of two primes, not any number, so you need a lot more bits to get equivalent security
This explanation doesn't seem right to me. For 1024 bit numbers, about 0.14% are prime. So that difference only loses a handful of bits. There are more than 2^2000 usable RSA-2048 keys, and simply guessing and dividing would require more than 2^1000 guesses. Those few bits lost to the prime number restriction aren't why the level of security is so low.
DKIM records are just DNS TXT records. Do they have a limit on the size of TXT records? Or are they going out of their way to try to parse the TXT records you're adding that look like DKIM records, failing on them, and then refusing to add them?
RFC1035 imposes a 255 character limit per string on TXT records .
Yes, so you use multiple strings (in a single record) if you need longer values:
"first 255 bytes" "second 255 bytes" "etc"
DNS clients combine the 255-byte strings back into a single string.
> DNS clients combine the 255-byte strings back into a single string.
No, DKIM clients and SPF clients do that. Generic DNS clients, however, are in theory free to ascribe any semantic meaning they like to the string separations.
1024 is still many orders of magnitude hard to crack than 512. For the record, the last RSA number having been broken was RSA-250 (829 bits) and it took 2700 core-years to crack back in 2020[1]. In comparison, RSA-155 (512 bits) was factorized as early as 1999!
You aren't in danger.
[1]: https://sympa.inria.fr/sympa/arc/cado-nfs/2020-02/msg00001.h...
There are several open source GNFS tools that can do 1024 very efficiently on GPUs, and even cheap consumer GPUs have 10s of thousands of cores now, even by your measure "2700 core-years" is only around a month or so on a single consumer grade GPU.
Not "free", but any malicious actor has access to a lot more than a single GPU.
The UK government also has several huge arm based solutions dedicated to cracking internet encryption, zero chance that isn't breaking mostly everything, for sure the Chinese and Russians have similar.
> The UK government also has several huge arm based solutions dedicated to cracking internet encryption, zero chance that isn't breaking mostly everything, for sure the Chinese and Russians have similar.
So you seriously think that almost all current RSA is being decrypted in real time by at least UK, China and Russia (and I would assume US)? Do you have any source or reference for this at all?
>There are several open source GNFS tools that can do 1024 very efficiently on GPUs, ...
Reference? Why has no one demonstrated this?
Yet nobody is collecting the RSA-numbers bounties?
RSA-270 (much, much easier than 1024 compute-wise) has a bounty of $75k, why would it be unclaimed then when you can spend three years worth of cloud rented H100 (I'm being conservative here and count $3/h which is far from the best deal you can get) and still make a profit?
Also a GPU core and CPU cores really aren't comparable individually, so your “consumer graphic card having thousands of core already” is comparing apples to oranges.
had a bounty. the RSA challenge unexpectly finished in 2007, task is left to the reader to speculate what happened in 2007.
Oh, I wasn't aware of the end of the challenge. But 1024 was definitely not broken by then, at least not by brute force.
none of it is "brute force", GNFS is a process that rapidly excludes numbers from the search space that cannot be the answer, in principle similar to the way they broke enigma.
numberphile has a great video on that one https://www.youtube.com/watch?v=V4V2bpZlqx8
Also, taking the OP as a "worse case", afaik:
512bit = $8
so
1024 = 8^2 = $64
2048 = 8^2^2 = $4,096
4096 = 8^2^2 = $16,777,216
noting $8 for 512 seems very expensive to me.
That's not correct. Consider, for example, a processor that can handle 2^31 computations per second. 2^32 operations can be computed in 2 time units, whereas 2^64 operations will take 2^33 time units.
search_space(n: number_of_bits) = 2^n * k
so search_space(1024)/search_space(512)=2^512, not 2^2.
Asymptotics in GNFS are better[0], but only on the order of e^(cbrt(512 * 64/9)) times more work, not 2^2.
This would give an approximation of math.exp(math.cbrt(512 * 64/9))*$8 = $40 million for 1024 bits.
[0] https://en.wikipedia.org/wiki/General_number_field_sieve
Pretty sure the search cost of GNFS is (bits)^2, the search cost of brute force is 2^(bits), if it was 2^(bits) GNFS would be no better than brute force.
->but only on the order of e^(cbrt(512 * 64/9))
e^(log(n)) = n
[dead]
Come on! Not only your math is ridiculous (you can't just square amounts of money, just consider how it would work if you changed currency: $8 is 1260¥, squares it makes it 1587000¥ which is $10k != $64) but believing that RSA-2048 is factorizable in $4k is hilarious.
> none of it is "brute force"
It's not exhaustive search like it would be for symmetric encryption, but it's still somewhat brute-force (especially since RSA keys are inflated in size compared to symmetric encryption to accommodate for their vulnerabilities), put more clearly what I meant was “not without theoretical breakthrough unknown to the public”.
BTW, it's not a very good idea to lecture people with actual crypto knowledge (even though mine is quite rusty now for I have not done any serious stuff for 15 years) when your own comes from ill-understood YouTube vulgarization videos.
[delayed]
I personally factored 512 bit numbers in 2007 for a lot less than $8, so tbh I'm going to say your overestimation of your knowledge of cryptology is far more hilarious than my paranoia about the potential truth of claims made by people claiming to be experts in cryoptology.
Your claim that factoring a 256bit number would cost fractions of a cent rather than my claim of roughly $3 is also very easily verifiable.
Further I'll note you sound exactly like the kind of person insisting diffie hillman was a good key exchange mechanism prior to Snowdens disclosures. good luck with that.
You and I aren't the ones in immediate danger. The service providers we rely on are. In discussions like these we have a "tragicomic" tendency to forget mankind's unstoppable progress. RSA-1024 offers 80 symmetric equivalent bits of security and we've been heading down this path for decades at an exponentially increasing pace.
Those service providers have had plenty of time to migrate to 2048 and most of them have already.
> a "tragicomic" tendency to forget mankind's unstoppable progress
When it comes to compute, it's no faster than Moore's Law, which means roughly one bit of symmetric encryption every two years.
> and we've been heading down this path for decades at an exponentially increasing pace.
Given that the encryption security is itself exponential in bit length, we are in fact heading down this path linearly! (A doubling in compute power means the ability to crack twice as hard cryptosystems, which means ones that have 1 bit more of security).
Key must be extended over time, and they are, and have been for decades. A PoC of an attack of a security system broken since 1999 should be treated exactly like how we are amazed at little computing power was available to the Apollo program: this is a cool bit of trivia that shows the growth of available computing power, but not a display of any kind of security issue.
This is the reason I had to stop using Hover for DNS management. They don't support TXT records longer than 255 characters, and I've not found any instance of someone getting split records to work with Hover. Ended up using Digital Ocean for it. I would love for elliptic curve crypto to become the status quo if this is going to continue to be an issue for yet another decade.
> Although most providers correctly identified the 512-bit key as insecure and rejected our DKIM signature, three major providers — Yahoo Mail, Mailfence, and Tuta — reported a dkim=pass result.
Did google really FAIL because of DKIM signature being insecure or because SPF failed?
The DKIM verification failed with the result "dkim=policy (weak key)," as it should according to RFC 8301: "Verifiers MUST NOT consider signatures using RSA keys of less than 1024 bits as valid signatures."
This is a little bit of a layman's question but maybe someone is interested:
When people go searching for prime numbers / bitcoin with massive compute, I assume that there are huge libraries of "shortcuts" to reduce the searching space, like prime numbers only appear with certain patterns, or there are large "holes" in the number space that do not need to be searched, etc. (see videos e.g. about how prime numbers make spirals on the polar coord. system, etc). I.e. if you know these you can accelerate/reduce your search cost by orders of magnitude.
For whatever various encryption algorithm that people choose to test or attack (like this story), is there somewhere such libraries of "shortcuts" are kept and well known? To reduce the brute force search need?
And is the state of sharing these to the point that the encryption services are designed to avoid the shortcut vulnerabilities?
Was always wondering this.
There exist certain classes of prime numbers that should not be used for some cryptographic operations because algorithms exist that reduce the computation required for factoring attacks. This more often applies to cases where smaller primes are applied. Sources for this king of knowledge are mathematics or cryptography textbooks.
For other cryptographic operations, almost any sufficiently large prime can be used. Even a 50% reduction on a computation that will take trillions of years, has no practical impact.
Don't know how Apple's iCloud Email will handle it, after all, Apple has always prided itself on being extremely attentive to user privacy and data security.
In case anybody is wondering about whether the 512bit number is big or small it depends on whether it is symmetric or asymmetric encryption technique. Always presume asymmetric encryption is 8x weaker than symmetric encryption.
DKIM is asymmetric. So a 512bit DKIM equivalent symmetric hash would be 64bits, which is long broken. Even 160bit SHA1 is considered broken. A DKIM of roughly equivalent strength to a 512bit SHA3 would be at least 4096bits and still does not include SHA3's techniques for mitigating replay attacks.
DKIM is not an encryption algorithm. It is a standard for embedding and validating signatures in email headers.
Unfortunately DKIM only supports rsa-sha1 and rsa-sha256 signatures (https://datatracker.ietf.org/doc/html/rfc6376/#section-3.3). It'd be nice to see DKIM get revised to allow Ed25519 or similar signatures.
Ed25519-SHA256 support has existed for a while now.
https://datatracker.ietf.org/doc/html/rfc8463
Oh excellent. I didn't realize rfc6376 had been superseded.
Wikipedia says it is a correlation check based upon a public key based signature. How is that not a form of encryption? Google says encryption is a process that scrambles data into a secret code that can only be decoded with a unique digital key, which is exactly what public keys are for.
> Always presume asymmetric encryption is 8x weaker than symmetric encryption.
RSA encryption is 10x weaker than Elliptic curve (224 bits ECC ~= 2048 bits RSA). Both are asymmetric.
Alternatively, asymmetric Elliptic curve is as strong as AES symmetric encryption. But it's quantum vulnerable, of course.
Breaking a 512-bit key for a good demonstration is very valuable security research, even if it's been done before. It's also legit to call out "Hey, here's a list of folks still using 512 bit, they should move off." ... but for me, actually cracking a real-world in-use key crosses an ethical line that makes me uncomfortable. IANAL but it might even be criminal. Just seems a bit unnecessary.
> for me, actually cracking a real-world in-use key crosses an ethical line that makes me uncomfortable
They've contacted the company with the vulnerability and resolved it before publishing the article - search the original article for the substring "now no longer available".
Usually, you demonstrate that an online system is vulnerable by exploiting that vulnerability in good faith, documenting the research, and submitting it for review. It does not matter if you're cracking an encryption scheme, achieving custom code execution for a locked-down game console, proving that you can tamper with data in a voting machine, or proving that you can edit people's comments on a Google Meet Q&A session - the process is the same.
If you say something's vulnerable, people can shrug it off. If you say and prove something's vulnerable, the ability to shrug it off shrinks. If you say and prove something's vulnerable and that you'll publish the vulnerability - again, using the industry standard of disclosure deadlines and making the vulnerability public after 60-or-so days of attempting to contact the author - the ability to shrug it off effectively disappears.
I read the article, and I don't think it changes it. If you crack someone's key, they might be well within their rights to pursue a criminal prosecution. Of course it would also have a Streisand effect and there's reasons not to, but I personally wouldn't allow or recommend a security researcher to do it. It's needlessly risky.
In general, subverting security and privacy controls tends to be illegal in most jurisdictions. Best case is when you have clear permission or consent to do some testing. Absent that there's a general consensus that good faith searching for vulnerabilities is ok, as long as you report findings early and squarely. But if you go on to actually abuse the vulnerability to spy on users, look at data etc ... you've crossed a line. For me, cracking a key is much more like that second case. Now you have a secret that can be used for impersonation and decryption. That's not something I'd want to be in possession of without permission.
> If you crack someone's key, they might be well within their rights to pursue a criminal prosecution.
If that were true there would be no market for white hat hackers collecting bug bounties. You need to be able to demonstrate cracking the working system for that to be of any use at all. No company will listen to your theoretical bug exploit, but show them that you can actually break their system and they will pay you well for disclosure.
What is or isn't illegal depends on where you live. Where I live, using any kind of digital secret to do something you shouldn't be doing is technically illegal. Guessing admin/admin or guest/guest is illegal, even if they're public knowledge, as long as you could reasonably know you're not supposed to log in.
Generally, law enforcement and judges don't blame you as long as you use best practices, but you need to adhere to responsible disclosure very strictly in order for this not to be something the police might take an interest in.
Demonstrating the insecurity of a 512 bit key is easy to do without cracking a real life key someone else owns; just generate your own to show it can be done, then use that as proof when reporting these issues to other companies. The best legal method may be to only start cracking real keys if they ignore you or deny the vulnerability, or simply report on the fact you can do it and that the company/companies you've reached out to deny the security risk.
Companies that pay for disclosure won't get you into trouble either way, but companies that are run by incompetent people will panic and turn to law enforcement quickly. White-hat hackers get sued and arrested all the time. You may be able to prove you're right in the court room, but at that point you've already spent a ton of money on lawyers and court fees.
In this case, the risk is increased by not only cracking the key (which can be argued is enough proof already, just send them their own private key as proof), but also using it to impersonate them to several mail providers to check which ones accept the cracked key. That last step could've easily been done by using one's own domains, and with impersonation being a last resort to prove an issue is valid if the company you're reporting the issue to denies the risk.
> Demonstrating the insecurity of a 512 bit key is easy to do without cracking a real life key someone else owns; just generate your own to show it can be done
As I said in my post, no company will listen to your hypothetical exploit. Show them youve hacked their system and they listen.
Bug bounties are a form of consent for testing and usually come with prescribed limits. Prescribed or not, actually getting user data tends to be a huge no go. Sometimes it can happen inadvertently, and when that happens it's best to have logs or evidence that can demonstrate you haven't looked at it or copied it beyond the inadvertent disclosure.
But to pursue data deliberately crosses a bright line, and is not necessary for security research. Secret keys are data that be used to impersonate or decrypt. I would be very very careful.
> I would be very very careful.
I see it the other way around. If some hacker contacted me and proved they had cracked my businesses encryption keys and was looking for a reward, I dont think I would be looking to prosecute them and antagonise them further.
What if the private key were accidentally exposed via public API, behind ROT13?
Also, I don't think DKIM is used for encryption, just signatures.
They can pursue what they want, it doesn't mean it will go through.
Looking at public data, using some other public knowledge to figure out something new does not make it inherently illegal. They didn't crack it on their systems, they didn't subvert it on their systems, they did not use it against their systems. I'd love to see some specific examples under what it could be prosecuted under specifically. Because "that door doesn't actually have a lock" or "the king doesn't actually have clothes" is not practically prosecutable anywhere normal just like that.
Especially in the EU, making such cryptographic blunders might even fall foul of NIS2, should it apply to you.
In general this also quickly boils down to the topic of "illegal numbers" (https://en.wikipedia.org/wiki/Illegal_number) as well.
It's more like the door has a weak lock that can be picked. Just like many real world doors do. Here's how it would go in court:
"Are you aware that this key could be used to decrypt information and impersonate X?"
"Are you aware that this key is commonly called a Private key?"
"Are you aware that this key is commonly called a Secret key?"
"Are you aware that it is common to treat these with high sensitivity? Protecting them from human eyes, using secure key management services and so on?"
"Was it even necessary to target someone else's secret private key to demonstrate that 512-bit keys can be cracked?"
"Knowing all of this, did you still willfully and intentionally use cracking to make a copy of this secret private key?"
I wouldn't want to be in the position of trying to explain to a prosecutor, judge, or jury why it's somehow ok and shouldn't count. The reason I'm posting at all here is because I don't think folks are thinking this risk through.
If you want to continue with the analogies, looking at a lock and figuring out it's fake does not constitute a crime.
That key can not be used to decrypt anything. Maybe impersonate, but the researchers haven't done that. It's also difficult to claim something is very sensitive, private or secure if you're publicly broadcasting it, due to the fact that the operation to convert one to an another is so absolutely trivial.
And they did not make a copy of their private key, they did not access their system in a forbidden way. They calculated a new one from publicly accessible information, using publicly known math. It's like visually looking at something and then thinking about it hard.
I wouldn't want to explain these things either, but such a prosecution would be both bullshit and a landmark one at the same time.
Breaking a key isn't criminal. It's just math. Sending emails that would constitute fraud or a violation of another jurisdictional law, relying on that math, is illegal. But again -- it's not the math, it's the action and intent.
Pointing out that someone is doing something stupid is also not illegal, though they make try to make your life painful for doing so.
Secrets themselves are often regarded as sensitive information, and often also categorized in the highest classifications for information protection. This stuff isn't just a game, and in my experience it's not how law enforcement authorities or courts see things.
Just as if you made a copy of the physical key for a business's real-world premises, you could well find yourself in trouble. Even if you never "use" it.
You can say this about a lot of security research, i.e "Showing a bug is exploitable is one thing, but writing a POC is crossing the line!" The problem is that most people won't listen to your security research unless you demonstrate that something is actually possible.
They only called out 1 out of the ~1.7k domains they found with keys shorter than 1024bits.
They _did_ call out the 3 of 10 tested major email providers that don't follow the DKIM RFC properly: Yahoo, Tuta, Mailfence (after having notified them).
I don't think there's a way to make it criminal, any more than publishing a vulnerability that got you code execution on their servers could be. Actually exploiting it, of course, would be.
I am also not a lawyer, but I would suspect it's not criminal to crack a real-world in-use key if you do so using only publicly available information and you don't actually do anything with the result.
Let's say you local coffee shop is featured in a local news piece and the blithe owner happened to get photographed holding the store key. That's now easy to clone from public information. Would you be comfortable actually doing it? Reporting the issue is fine - "Hey you should rekey your locks!".
Actually making a clone of the key, and then showing "hey it fits" will get you more traction more quickly ... but there's also plenty of Police Departments who might well arrest you for that.
> showing "hey it fits"
That's exactly what I meant in terms of not actually doing anything with the result. That said, it's obviously somewhat different with a physical key than a cryptographic key.
As mentioned in the article, the key's no longer available and I presume the article has been released only after responsible disclosure was done and with the approval of the key owner (hope so). At this point, it's not more unethical than any other security research performed in the same conditions and with the same outcome.
Love the practicality demonstrated here. It is unclear how old this article is. Based on the poster's previous submissions, I assume today?
I published the article today, though it was written a few months ago (when the DKIM record was still online).
Was redfin aware you were trying to break their DKIM record?
It was already broken.
This comment also serves as a public notice that I'm going to factor all the 512-bit DKIM RSA keys out there from now on. Start migrating.
Reminds me of factoring 512-bit RSA signing keys used on Ti calculators in 2009: https://en.wikipedia.org/wiki/Texas_Instruments_signing_key_...
Anyone know or have experience how well supported ECDSA is for DKIM?
DKIM supports Ed25519-SHA256.
https://datatracker.ietf.org/doc/html/rfc8463
specs supports many things. I believe the question was more about the real world.
In the real world, DKIM specs only support Ed25519 and RSA.
I think the cynic in me says "so what" mostly because dkim as an ancient technology is hardly secure. I don't think we're any less prone to email fakery and spam. I'd be interested to see a possible new solution or a revamping of email as a protocol but that's unlikely. We're more likely to keep it like snail mail as we prioritise different forms of communication. Unfortunately nothing has beat the universal email address on the internet. Here's hoping we come up with a chat standard that sticks and people run a user@server.com chat server where you can communicate from anywhere. Sorry xmpp, you don't count.
Email-style user@host.domain addressing is also used in SIP.
At one point in time you could reach me on email, XMPP, and SIP all using the same identifier. We dropped XMPP about a decade ago when all the major service providers stopped federating with it, but if you know my work email address you can also call my desk phone using the same identifier.
You hit the nail on the head with the word 'Universal'.
Because email addresses have existed since the begining of the web, anyone who has ever been on the internet has one and uses it for identification purposes. This will not change without another universal standard which everybody automatically has.
Its like IPv4, we all have the ability to use IPv6 but do we? Hell no we just use NAT as its an easier quick fix.
Changing any addressing on the internet is tough because you always have to have backwards compatibilty, which kind of ruins the point of moving forward.
Haha, definitely not true outside of the US and Western Europe.
Most of Asia (and probably Africa) uses phone #.
Thats because those are mostly developing countries which were late to the internet party, and are accessed mainly through mobile. Phone # could well be a replacement for email globally in the future, once all the younger generation grow up and rule the world.
Users in those countries already vastly outnumber users in other countries. And are growing much, much faster too.
Yep, but it will never replace email address as universal identifier until it is adopted by all.
In addition to that, reports show that the majority of Asian and African users access the internet via a shared device. Therefore phone number cannot be a universal identifier there as it generally identifies a group of people rather than in indivdual. This is why google and outlook accounts with SSO are still generally the most used identifying systems in the world.
By what metric?
In India, it is exceptionally rare for any services (gov’t and commercial) to use email address. They use mobile.
One of many examples [https://web.umang.gov.in/landing/department/aadhaar.html]
That accounts for 1.3+ billion distinct accounts in 2023 right there.
[https://uidai.gov.in/en/about-uidai/unique-identification-au...]
Do you think those folks in Asia and Africa sharing mobile devices have email accounts they can use instead?
Of course XMPP doesn't count... even though it's a standard, allows people to run their own server, have an email-like address of user@server, allows you to communicate from anywhere, and is how I, my family, and many many others chat online? :)
How common are such small DKIM keys?
I'm pretty sure mine are 2048-bit, though I'd have to check as they were last set a fair while ago.
First sentence:
> In our study on the SPF, DKIM, and DMARC records of the top 1M websites, we were surprised to uncover more than 1,700 public DKIM keys that were shorter than 1,024 bits in length
I must do something about my short-term memory/attention. I must have read that and promptly blanked it during the scanning of the rest of the article.
The interesting question is: Did these sites forget that they have these records, or have they perhaps forgot how to rotate their keys.
I guess most of these keys are decades old and no longer in use. They're likely just sitting in the DNS because someone forgot to delete them. Now, no one's sure if they're still needed and is afraid to remove them in case it breaks something. Or maybe they're still used by a legacy system, and no one realizes the impact an old DKIM record could have.
dns server limitations.
txt records are 1024bits... add the prefix for the key and you get <1024.
to use a larger key you must combine many txt records in a never ending comical interoperability issues. the first one usually being that your regional monopoly scoundrel, a.k.a. registrar, run a server which doesn't even allow more than one entry.
TXT records are 255 bytes or 2040 bits. This is plenty of space to support RSA-1024 keys even with a small prefix and after base64 encoding them. However, it is obviously not enough to support RSA-2048 which is the minimum recommended size according to NIST right now. It's also not quite enough even for RSA-1536 (not widely used) due to base64 expanding the key by 33%.
There actually is a standard for adding more than 255 bytes to a TXT record and it's fairly widely supported, but it can be tricky to configure properly on a name server.
> but it can be tricky to configure properly on a name server.
I wouldn't say it is tricky with a good name server: for instance with bind just split the value into multiple quoted strings and it'll do the rest¹.
Though while it is well known, it doesn't seem to be well documented away from many forum posts discussing the matter: after a little searching I can't find reference to the issue in bind documentation or relevant RFCs. The RR format allows RDATA to be longer than 255 octets (RDLENGTH is an unsigned 16-bit value, not 8-bit) so presumably the limit is imposed by the zonefile format. The only reference to 255 octet limits in RFCs 1034 & 1035 is the length of a full name (with individual labels making up a name being limited to 63 octets).
Of course many UIs for editing zone files or other stored RR information, or other DNS management interfaces, might implement longer RDATA support in a worse way or not support longer RDATA values at all.
----
[1] I'm not sure what “the rest” is (I might look deeper later)
So 1,700 out of 1,000,000, i.e. around 0.2%. "Not common" is one way of putting it, I guess.
I agree, but to be precise, it was 1,726 out of 476,617 DKIM keys found across those 1M domains, or about 0.36%. Since it's impossible to determine all DKIM records a domain might have from the outside, I used a list of commonly used selectors (e.g., "default' or 'key1") for the search. It's likely there are additional short keys under selectors I didn't check.
Those 1,700 are easy to find though, just need to dig a bunch of domain names and you'll find plenty vulnerable ones that you can spoof.
Yahoo Mail has a market share on the order of 3%. So a black hat could then target a decent chunk of users with @yahoo addresses specifically.
Has anyone heard of this being exploited in the wild? Would be interesting to find out whether there are some reputable domains among the 1.7k vulnerable ones.
Your claim that yahoo uses a 512bit key are counterfactual.
Please adhere to honesty and good faith arguments.
I never suggested that Yahoo uses 512bit keys, that's a misunderstanding.
The article clearly states that Yahoo is one of the 3 clients that didn't reject 512bit keys the way they should per RFC.
Yahoo Mail inbox users are vulnerable _receivers_ of spoofed emails.
remember when yahoo mail was the first one to implement DKIM validation and then all mailing list owners added a footer telling their subscribers not to use yahoo mail because it was broken, instead of calling their mailing list providers to upload a key? yeah nobody remembers, but yahoo probably do. i doubt they will err on the side of security again.
The Yahoo that built Yahoo Mail no longer exists, so actually they probably don't remember.
The top million domains are more likely to be on top of their security than less prominent domains. 0.2% is therefore a fairly strict lower bound for the overall internet.
Not common. 1024-2048 bit RSA is the most common DKIM scheme. It's been 6 years since Ed25519 was labeled "required" in a drafted RFC, but adoption is as usual taking an unfortunately long time.
Any tips on how to easily fetch the key length of DKIM-Keys from DNS? Just by looking at the DNS entries I can't easily determine the key length ;)
Fetch the TXT record; you should see something like,
The base64 data is an RSA public key. You can print in textual form with something like, The first line of output will be something like, Which is the key length.If you fetch with `dig`, note that sometimes dig will do this:
I.e., it breaks it up with a `" "`; remove those, that's not part of the data. I.e., concat the strings dig returns, then parse out the p=, then base64 decode, then openssl.(You can also do what the article does, but without Python, which is jam that base64 between some PEM header guards like the article does, and then feed it to openssl. Same command, but you don't need the -inform der b/c the "in[put] form[at]" is now pem, which is the default.)
An easy way is to check the length of the p= value in the DKIM record. If it's around 216 characters, it's likely a 1024-bit key. A 2048-bit key usually has about 388 characters.
If you're going to do this you should also check for k=rsa since other key types will be different lengths. But I'd really recommend something like in the other comment where you base64 decode and parse it with something like openssl.
I don't understand why didn't Yahoo fail due to SPF check failure.
Considering that Yahoo doesn't really exist anymore, and that Yahoo Mail is just a relic of Yahoo's heyday that is somehow still hanging around, I assume nobody has bothered to actually maintain its handling of security protocols for about a decade.
"existing" is basically all it does. They make 8B a year and have the 12th most popular website globally.
The email product has gobbled up both AOL and Verizon and they also whitelabel to a bunch of other ISPs. Just because they are never in the news for anything cool and hackernews commenters dont use them doesnt mean they dont exist.
Yahoo mail still has plenty of users and yahoo still have many employees. It'd be borderline criminal to not have somebody at yahoo oversee their email security.
why aren't people just defaulting to 2048?
They are, but someone set this up in 2016 or so, and nobody has changed it :) Most likely the person got laid off, or went somewhere else, and nobody on the team has any idea about it.
They are defaulting to 1024-2048. Systems signing with 512 bit keys are an outlier.
"as RSA keys shorter than 1,024 bits are considered insecure, and their use in DKIM has been deprecated since the introduction of RFC 8301 in 2018."
LOL. One of my favourite internet flame wars was circa 2007 (in and around discussing the incoming financial crises) and we got talking about encryption and how none of it actually "works".
Particularly vile troll, and iirc also owner of the site bet me $50,000 I couldn't reverse the 512 RSA key he posted (created by openssl).
He got the factorisation less than an hour after he made the post.
Strangely, the entire site disappeared pretty quickly after that (and it's not on wayback machine).
given where the math guys are now with GNFS I'm not sure I would trust 8192 bit RSA in 2024, 2018 for dropping 512 bit was already more than a decade late.
> not sure I would trust 8192 bit RSA in 2024
Do you have any proof/quote for that? Some pretty knowledgeable and well-known people in this thread 2048 bit RSA is quite safe with current capabilities[1]
1: https://news.ycombinator.com/item?id=42635066
https://www.bbc.com/news/world-us-canada-23981291
Was it a key affected by CVE-2008-0166 ? :)
Thanks for this
Thanks for sharing this article, I think people have been doing this for some time!
I’ve gotten a lot of spear phishing attacks, as far back of 2018, with emails that passed many verification checks. Getting representation to this issue is notoriously difficult because people assume an undiscerning victim and end user. They also rely on the false idea that scammers can’t spell or don’t spell correctly, specifically to weed out discerning people. When there is a subset that makes everything as legit and impersonating as possible.
I got an email from Bank of America yesterday about a problem setting up my account. I had set up a new account, and this email knew that, and knew the name of the company, etc. There were no links in the email, just a note to call the BofA business number. I verified the number on the BofA website -- it was the same number -- and I called them.
They couldn't tell me why I got the email, and what the problem was with my account. The representative couldn't see a record of this email set.
I'm 100% certain this email came from Bank Of America. There was nothing in the email that was phishing -- no links, no bad phone numbers.
The SPF, DKIM, and DMARC all passed googles's ARC-Authentication-Results. The DKIM key is 2048 bits long.
I asked Bank of America to investigate, and they said "it must have been a phishing message" and sent me a link on how to look out for phishing.
I'm pretty sure this was just a glitch; some system that does some consistancy check ran too early while the account was being set up and generated that email.
However, because they told me it was "phishing" I just sent a FedEx to the CTO with the complete paper trail advising them that EITHER their DKIM keys were compromised and they need to issue a public warning immediately OR their incompetent staff and IT system gave me the runaround and wasted an hour of my time. Either way, I want a complete investigation and resolution.
That can be done locally on a laptop, no need for the cloud.
Technically, this is very nice work.
But as a security generality - email is vastly less secure* than human nature wants to assume that it is. Human nature usually wins.
*Outside of a carefully run org's own network, and a few other edge cases
As a small mail server admin I see this less about security of messages originating from me and more about the possibility of spammers sending DKIM-authenticated mail as coming from me (and resulting in shadow bans at gmail, etc. which is a huge pain to deal with)
>But as a security generality - email is vastly less secure than human nature wants to assume that it is.
I don't think this has to do with "human nature" anymore than http did. It's a very important, powerful form of communication without any secure replacement. Just as we switched to https, ideally an "xmail" or the like would get created as an open standard with open software that was email with better security by default. Sadly I'm not sure we collectively have the ability to do that kind of thing any longer, powerful entities have realized it's just too attractive to lock it up. But even many open source organizations don't seem to feel like bothering. Plenty of security experts even just prefer new shiny and will spout ridiculous "move to instant messaging". So status quo rules for the foreseeable future.
Email is one of a great number of internet communication systems. It happens to be one that was created before security was much of a concern (and before it was a problem we could solve), and also one that is highly asynchronous. Newer systems have their own different sets of tradeoffs. None of them happen to be email plus security. But that makes sense: now that everyone is online most of the time, why would you design a highly asynchronous store-and-forward-ish system? Of course you want a recipient to receive a message as soon as you sent it and the sender to confirm the recipient received the message. Designing a new system any other way would be leaving value* on the table. (*actual value not economics value)
We can extend email, though. Why isn't there an SMTP GETKEY command to return a PGP key corresponding to an email address? Sure, the sender might not support the same version of PGP, and sure, the connection might be intercepted (hopefully you'd not trust the output of this command except over TLS), but like most of the email system, it would be a big improvement and good enough most of the time.
Yeah, so I guess there's no point in picking any of the low hanging fruit to make it more secure.
Email is actually quite secure, just in a different way that web.
For instance, once you disregard so called transactional mail and spam, real email is almost all encrypted for all practical purposes.
DKIM and DMARC also work quite well for spoofing protection, aside from the corner cases like the above.
Average Software Engineers have an outdated idea of email, formed by 1990 era Internet.
I think your view of email is romanticized, or perhaps skewed because of your social circle. Email servers sometimes use TLS to talk with eachother, and emails are signed. But that's the extent of encryption when it comes to "real email". Email content is not encrypted in "almost all" of "real email" because almost nobody uses PGP.
I don't know what social circle I should be part of to consider email unsecure.
Even Russian spies use mail.ru and their emails are compromised not by SMTP MitM but by weak passwords, google for "moscow1 moscow2 password" to see what I am talking about )
Anyway. Back to the technical point. Email servers pretty much always use TLS to talk to each other. The connection may degrade to non-encrypted for backwards compatibility, unlike HTTPS. But it's vanishingly rare.
So, for all practical purposes that affect ordinary citizens: injection, scanning and sensitive information extraction, email in transit is quite secure.
Depends on context.
If you're in IT at a carefully run org: You ditched 512-bit keys years ago. This article is nothing but a 20-second story, to help explain to PHB's and noobs why they got an error message, or what sorta important stuff you're always busy keeping your org safe from.
If you're in IT at a scraping-by org: Maybe today's a good day to ditch 512-bit keys. And if you get push-back...gosh, here's a how-to article, showing how a "forged corporate signature stamp" can be made for only $8.
If you're trying to teach senior citizen how to avoid being scammed on the internet: You've got zero visibility or control, so you're stuck with "sometimes these can be forged, depending on technical details" generalities.
Slight change of title. The leading "How" was dropped. Original: "How We Cracked a 512-Bit DKIM Key for Less Than $8 in the Cloud"
"How we X'd a Y" is a linkbait trope. We edited that in accordance with the site guidelines: "Please use the original title, unless it is misleading or linkbait". https://news.ycombinator.com/newsguidelines.html
Thanks for clarifying. Interestingly, in the guidelines, there's an example of where you _add_ "How" instead of removing it: "E.g. translate '10 Ways To Do X' to 'How To Do X'". That tripped me.
Dropping the How is part of Hackernews guidelines
There’s no such guideline. It’s just part of the default title normalization. The submitter can adjust it afterwards.
Altering headlines automatically is really irresponsible.
It is if you only count the cases it gets wrong.
Is there any documentation on this? @dang?
Couldn't find it in the guidelines. Can you quote the relevant part?
Because we need that compute for our React frameworks.
"Eschew flamebait. Avoid generic tangents."
We detached this subthread from https://news.ycombinator.com/item?id=42633787.
Don't forget Electron as well.
My Chromebook all of the sudden needs compute to serve ads. RIP uBlock.
[flagged]
Well, backend is our precious server resources and front end resources belong to the lowly user. It's a matter of scale though, frontend is optinized for one concurrent user. Plenty of small websites using slow and bloated frameworks on the backend because it's easy.
Man, users are the worst. Sometimes I think that they only exist to stress out my precious beautiful servers.
I agree. Those stateful bastards. I suggest we wrap them all into Monads. That’ll teach them!
Simple economics; who pays for the servers and who pays for the front-end execution?
Front-ends are essentially free distributed computing resources while the backends need to be paid for.
I don't think that is true of "HN". This thread, about how wasteful frontend development is, is a pretty standard trope in the comments here.
Loads of developers everywhere, frontend and backend, go to lengths to optimise their programs. Loads of other developers also don't care.
I have stopped mentioning frontend performance being my speciality on interviews as it has elicited tepid responses from all but one.
I imagine interviewing at McMaster-Carr to be a very different experience than Home Depot.
But also Apple, and Uber, etc. It was surprising.
It's funny how some folks with no domain experience hn seem to be obsessed with html.
[dead]
[flagged]