Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cracking a 512-bit DKIM key for less than $8 in the cloud

dmarcchecker.app

Post reply on HN
Print view View original

191–200 of 433 posts

Re: Cracking a 512-bit DKIM key for less than $8 in the cloud

#191

Post by littlestymaar »

DarkmSparks wrote: post #100
littlestymaar wrote: post #31

Earlier quoted context omitted.

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…

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.

Re: Cracking a 512-bit DKIM key for less than $8 in the cloud

#192

Post by zorgmonkey »

awulf wrote: post #160
andix wrote: post #148

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 ;)

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.

Re: Cracking a 512-bit DKIM key for less than $8 in the cloud

#193

Post by [deleted] »

Avamander wrote: post #109
1oooqooq wrote: post #102

Earlier quoted context omitted.

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.

[deleted]

Re: Cracking a 512-bit DKIM key for less than $8 in the cloud

#194

Post by [deleted] »

raverbashing wrote: post #38
jgrahamc wrote: post #21

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.

> "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

[deleted]

Re: Cracking a 512-bit DKIM key for less than $8 in the cloud

#196

Post by tptacek »

GTP wrote: post #47
matthewdgreen wrote: post #39

Earlier quoted context omitted.

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…

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.

Re: Cracking a 512-bit DKIM key for less than $8 in the cloud

#197

Post by tptacek »

GTP wrote: post #163
dfc wrote: post #59

Earlier quoted context omitted.

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 sp…

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.

Re: Cracking a 512-bit DKIM key for less than $8 in the cloud

#198

Post by tptacek »

lupusreal wrote: post #74
matthewdgreen wrote: post #39

Earlier quoted context omitted.

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…

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.

Re: Cracking a 512-bit DKIM key for less than $8 in the cloud

#199

Post by nyrikki »

mjl- wrote: post #178
zelphirkalt wrote: post #4

Some DNS providers suck and only let you set 1024 bit long keys. For example wordpress.com.

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 .

Re: Cracking a 512-bit DKIM key for less than $8 in the cloud

#200

Post by layer8 »

Havoc wrote: post #6

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 sid…

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.
Post reply on HN