Cracking a 512-bit DKIM key for less than $8 in the cloud
dmarcchecker.app
dmarcchecker.app
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...
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.
PS. Of course y'all young'uns won't remember ...
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 :( ).
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.
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.
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 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.
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.
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.
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.
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.
Lying isn't a stronger defense to perform abuse than weak keys are for stopping abuse.
You don't need a conversation to cause havoc.
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.
> 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 fact that this is possible is some cryptography black magic.
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.
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.
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)
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.
https://www.wired.com/2012/10/dkim-vulnerability-widespread/
So we went to a few weeks to 8h in 14 years give or take
> 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 stand corrected
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.
Verifiers MUST be able to validate signatures with
keys ranging from 512 bits to 2048 bits, and they MAY be able to
validate signatures with larger keys.
Verifiers MUST be able to validate signatures with keys ranging from 1024 bits to 4096* bits
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.
most countries registrar's won't support DNS hacks requied for larger dkim.
we still use the minimum key size in most countries.
In the context of DKIM we're waiting for Ed25519 to reach major adoption, which will solve a lot of annoyances for everyone.
3072 has been recommended by various parties for a few years now:
Operations per second?
* https://wiki.strongswan.org/projects/strongswan/wiki/PublicK...
Running MacPorts-installed `openssl speed rsa` on an Apple M4 (non-Pro):
version: 3.4.0
built on: Tue Dec 3 14:33:57 2024 UTC
options: bn(64,64)
compiler: /usr/bin/clang -fPIC -arch arm64 -pipe -Os -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk -arch arm64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk -DL_ENDIAN -DOPENSSL_PIC -D_REENTRANT -DOPENSSL_BUILDING_OPENSSL -DZLIB -DNDEBUG -I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk
CPUINFO: OPENSSL_armcap=0x87d
sign verify encrypt decrypt sign/s verify/s encr./s decr./s
rsa 512 bits 0.000012s 0.000001s 0.000001s 0.000016s 80317.8 973378.4 842915.2 64470.9
rsa 1024 bits 0.000056s 0.000003s 0.000003s 0.000060s 17752.4 381404.1 352224.8 16594.4
rsa 2048 bits 0.000334s 0.000008s 0.000009s 0.000343s 2994.9 117811.8 113258.1 2915.6
rsa 3072 bits 0.000982s 0.000018s 0.000019s 0.000989s 1018.4 54451.6 53334.8 1011.3
rsa 4096 bits 0.002122s 0.000031s 0.000032s 0.002129s 471.3 31800.6 31598.7 469.8
rsa 7680 bits 0.016932s 0.000104s 0.000107s 0.017048s 59.1 9585.7 9368.4 58.7
rsa 15360 bits 0.089821s 0.000424s 0.000425s 0.090631s 11.1 2357.4 2355.5 11.0
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).
(This isn’t intended as a leading question.)
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.
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...
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.
Mail server administrators.
You're essentially asking "why aren't we doing what we're doing"
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.
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.
What size do you suggest?
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.
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.
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.
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.
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).
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.
It will likely work for a while, but it’s a fundamentally wrong approach and you’re going to be exposed into recording & decryption attacks, instead of breaking your encryption today, I just store all your communications and wait for the next qc to be online, then fish for stuff that is still useful.
It’s a silly approach if the timeframe is 50 years because most secret information goes stale quicker, but if you’re just waiting for say a year…
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.
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.
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!
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.
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)
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.
You aren't in danger.
[1]: https://sympa.inria.fr/sympa/arc/cado-nfs/2020-02/msg00001.h...
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.
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?
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.
Reference? Why has no one demonstrated this?
> 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.
Not NSA-proof, but should be more than enough to keep spammers out, especially considering that DKIM is just one layer of protection.
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.
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.
"first 255 bytes" "second 255 bytes" "etc"
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.
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.
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 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.
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.
As I said in my post, no company will listen to your hypothetical exploit. Show them youve hacked their system and they listen.
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.
Also, I don't think DKIM is used for encryption, just signatures.
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.
"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.
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.
Pointing out that someone is doing something stupid is also not illegal, though they make try to make your life painful for doing so.
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.
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).
Matthias, co-founder of Tuta Mail
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.
But I think many others, and many in law enforcement, will see cracking a key as "actually exploiting it". You've exploited the cracking vulnerability to target a particular key, is how they'll see it. Law enforcement also have a natural incentive to want possession of harm-adjacent paraphernalia to carry substantial liability.
I think they have a point; that key is private data, and there's a reason people lock keys up in KMSs and HSMs; they can have a large blast radius, and be hard for companies to revoke and rotate. Importantly, a compromise of a key will often trigger notification requirements and so now it is a breach or an incident, in a way that a good faith security vulnerability report is not.
To make an extreme example; if you were to crack an important key for a government agency, good luck with that is all I'll say. I sure wouldn't.
The CFAA has a clause about "trafficing in passwords or similar information" (18 USC 1030(a)(6)), but the mental state requirements are very high: that trafficking has to be knowing and with intent to defraud (that intent will be something prosecutors will have to prove at trial).
There might be some state law somewhere that makes this risky, but virtually every hacking prosecution in the US anyone has heard of happens under CFAA. I'm not a lawyer, but I've spent a lot of time with CFAA, and I think cracking DKIM keys is pretty safe.
My understanding, and IANAL, is that decrypting things that aren't yours is a bad idea and is covered mainly by electronic communications and wire acts, e.g. U.S. Code § 2511 and others.
Worth remembering: when CFAA was originally passed, an objection to it was "we already have laws that proscribe hacking computers"; the fraud statutes encompass most of this activity. CFAA's original motivation was literally WarGames: attacks with no financial motivation, just to mess things up. So even without statutory issues, breaking an encryption key and using it to steal stuff (or to gain information and ferry it to others who will use it for crimes) is still illegal.
Your guess is as good as mine about whether ECPA covers wifi sniffing. But: presuming you obtain an encryption key through lawful means, ECPA can't (by any obvious reading) make cracking that key unlawful; it's what you'd do with the key afterwards that would be problematic.
Did google really FAIL because of DKIM signature being insecure or because SPF failed?
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.
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.
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.
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.
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.
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.
Now, factoring large numbers is a separate thing. You don't brute force all the possible factors, that would be a really bad approach. Modern algorithms are called "sieves," this is a gross oversimplification but essentially they keep picking random numbers and computing relations between them until they come up with enough that have a certain property that you can combine them together to find one of the factors. It doesn't have anything to do with shortcuts or patterns or tricks, it is just a fundamental number theory algorithm.
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.
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.
Most of Asia (and probably Africa) uses phone #.
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.
Of course, if you can modify the SPF records, you can make the DMARC record say whatever you want.
I'm pretty sure mine are 2048-bit, though I'd have to check as they were last set a fair while ago.
> 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
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.
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.
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.
Please adhere to honesty and good faith arguments.
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
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.
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.
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.
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.
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.
k=rsa; … p=<a bunch of base64 data>
your-clipboard-paste-command | base64 -d | openssl rsa -pubin -noout -inform der -text
Public-Key: (2048 bit)
If you fetch with `dig`, note that sometimes dig will do this:
example.com. 1800 IN TXT "k=rsa; t=s; p=blahblahblahblah" "blahblahblah"
(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.)
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.
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]
We detached this subthread from https://news.ycombinator.com/item?id=42633787.