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.
Yea, stuff with kids involved sometimes makes it SUPER unambiguous. Some people are very clearly willing to do anything to anyone, and are doing so as much as possible.
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.
Courts typically do not care as much about what an expert witness thinks, as rather why they think it - and whether their reasons hold up enough that the conclusions they support should be accepted.
That is not quite correct. A court is undoubtedly interested in what an expert witness has to say.
It is the lawyers appearing before the court that may attempt to play the person not the ball, by variously undermining or bolstering their standing as an expert at all.
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.
The same is true for breaking into a building. An expensive lock won't protect you against a determined attacker.
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. :-)
That was Matt Green, the person you replied to =)
There is a better than even chance that you are correct. :-)
I've been doing this since around 2018, and have seen a few others implement it.
/me skims, reaches footnotes
Sometimes you've just gotta love those auto-shortened URLs: security.googleblog.com/2013/12/internet-wide-efforts-to-fight-email.html
Hopefully one day we'll win the fight.
Google Wave, represent!
PS. Of course y'all young'uns won't remember ...
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.
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 :( ).
For 20 years Fastmail allowed any customer to spoof From: another
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.
Yes, it's a pretty good way of proving the server sent the email. That's all it proves. If the email came from gmail.com, it's up to Google to prove the person in the From: address composed the email. The signature can't prove that. Nonetheless almost everyone will accept that is what happened.
If Gmail received the email, it's likely they simply drop email with no or bad DKIM signatures. So if it's in your gmail inbox but a has signature that doesn't check out, to be categorically certain it was signed you would have to ask Google. But it's the same deal as the From: address - almost everyone is going to assume it was validly signed because that's gmail's policy.
TL/DR, I think your wrong. Rotating the key only weakens the proof slightly. The only thing that is destroyed is the cryptographic proof, but only in a fanatical cryptographers world is that the only form of acceptable proof. That fanatical cryptographer is wrong of course. Things outside of the mathematical certainty also matter. The rubber hose joke is funny, and the butt of that joke is fanatical cryptographers making that very assumption.
I really don't follow what you're trying to say here. The point is that the durable verifiable signature has no value to users, but lots of value to attackers; in other words: it only has value to attackers. People are confused because in a formal analysis, journalists getting stories from leaked mail spools are attackers; they are a thing secure messengers are designed to thwart.
> The point is that the durable verifiable signature has no value to users,
Apparently I'm the exception to that rule, because I have a DKIM extension installed on Thunderbird. I use it to do what you say isn't useful - as another way to check phishing messages long after they have been sent.
Until DKIM is universally enforced checking it after the fact will be useful. When DKIM is universally enforced rotating the keys won't matter to either the user or attacher, because both can be sure everything in the inbox (stolen or otherwise) was DKIM signed.
> I really don't follow what you're trying to say here.
It's simple. As things stand now much of the time you don't need a verifiable DKIM signature to know if the message had a valid DKIM signature when it was sent. Therefore it doesn't matter much to the user or attacker if keys were rotated - your "privacy violation" is still a thing whether the keys are rotated or not.
Unfortunately the "much" qualifier must be in there, and compounding that is the stuff that does skip through without being signed are almost always attacks on me - phishing or otherwise. Such messages are rarely sent from a bulk provider that insists on signing because it gets shut down promptly. The sender would probably prefer they were signed so the rejects weren't so frequent, but there are operating on low probability of people taking their message seriously so the even lower probability imposed by invalid DKIM signatures not a disaster.
Unfortunately for your argument legit email is now almost universally signed because the sender is relying on it getting through. If someone steals an inbox and an email that doesn't looked like spam was DKIM signed, then you can pretty safely assume it was validly signed when sent. Being able to validate the DKIM signature after the fact doesn't add much confidence.
It's not rocket science.
Correct me if I'm missing something, but isn't tptacek's point that if the DKIM's keys are public, I can now just make up any email I want with a "correct signature" and claim it was sent from X and I found it in Y's inbox (for any X, Y). And therefore even if you really found it there you can't prove it. At that point you'd just be trusting the reputation of the accuser (perhaps a respected journalist, perhaps a shady criminal).
I'm not clear how the universal DKIM argument comes into play. Even if we were sure Google only accepts valid DKIM, you still have to trust that the accuser did in fact find it in the alleged Google inbox.
Whereas with the non-rotated key, the accuser has cryptographic proof their alleged email is genuine, because they couldn't have created it without the key.
> you don't need a verifiable DKIM signature to know if the message had a valid DKIM signature when it was sent.
You seem to be trying to say that "the fact that it was delivered proves it had a valid signature when it was sent".
That presupposes that the headers indicating when it was delivered are correct, or that it was delivered at all in the first place.
I don't think you understand the attack.
I sent Thomas an email admitting to something scandalous.
A few months later, Mallory pops the server Thomas's email is stored on, and extracts his mail spool.
Mallory wants to prove to a third party that the email is authentic and not a fabrication.
I know it's real.
Thomas knows it's real.
Mallory is pretty sure it's real.
Alice, a reporter for the Daily Bugle cannot verify it is real, rather than Mallory's forgery.
I can claim it's a forgery, and point out that Mallory could have made it up and generated the signature with the published key.
Now, I may have a problem if it were a crime rather than something merely scandalous because then Bob, an FBI agent, decides to subpoena some logs and maybe prove when it was sent, but even so, logs typically don't have message content or even a hash of the message content.
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.
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.
This is always a possibility but I'm guessing the happy path is the more likely believable scenario and could be verified OOB.
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.
Thank you for clarifying where the vulnerability chain begins and ends.> 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.
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.
- [deleted]
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.
- [deleted]
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.
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.
[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.
Sounds nefarious. Why would a sender want the recipient to verify authenticity while being able to deny it to a 3rd party. Sending threats or blackmail come to mind as top uses. Breaking confidentiality agreements is another. What's a legit honest above board use?
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.
- [deleted]
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.)
> I bet 99.99% of all email is delivered within a minute or so of being send
No doubt that is true. However, given the total volume of email, even that tiny, tiny remaining fraction still represents actual mail with legitimate use-cases. So it's good to bear that fact in mind and not roughly implement 80-20 stuff that tramples on those.
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)
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.
- [deleted]
Both parties use the same key: https://en.m.wikipedia.org/wiki/Symmetric-key_algorithm
- [deleted]
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/
> "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
- [deleted]
86h, wasn't it? But regardless your point stands.
I'm pretty sure I can do it in two hours.
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-...
- [deleted]
First time a 512-bits RSA number (RSA-155) was factored was in 1999!
2010, Nostradamus :)
Depends if you're rounding up or down.