Live data from Hacker News

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

dmarcchecker.app

231–240 of 433 posts

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

#231
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…

"dramatically ramping up key sizes" is not done, because it's overly expensive, and not needed.

What people don't realize: key size recommendations are surprisingly stable over long timeframes, and have not changed for a very long time. In the early 2000s, some cryptographers started warning that 1024 bit RSA is no longer secure enough, and in the following years, recommendations have been updated to 2048 bit minimum. That's now been a stable recommendation for over 20 years, and there's not the slightest sign that 2048 bit can be broken any time soon.

The only real danger for RSA-2048 is quantum computers. But with quantum computers, increasing your RSA key sizes does not buy you much, you have to move to entirely different algorithms.

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

#232
I got an email from Bank of America yesterday about a problem setting up my account. I had set up a new account, and this email knew that, and knew the name of the company, etc. There were no links in the email, just a note to call the BofA business number. I verified the number on the BofA website -- it was the same number -- and I called them.

They couldn't tell me why I got the email, and what the problem was with my account. The representative couldn't see a record of this email set.

I'm 100% certain this email came from Bank Of America. There was nothing in the email that was phishing -- no links, no bad phone numbers.

The SPF, DKIM, and DMARC all passed googles's ARC-Authentication-Results. The DKIM key is 2048 bits long.

I asked Bank of America to investigate, and they said "it must have been a phishing message" and sent me a link on how to look out for phishing.

I'm pretty sure this was just a glitch; some system that does some consistancy check ran too early while the account was being set up and generated that email.

However, because they told me it was "phishing" I just sent a FedEx to the CTO with the complete paper trail advising them that EITHER their DKIM keys were compromised and they need to issue a public warning immediately OR their incompetent staff and IT system gave me the runaround and wasted an hour of my time. Either way, I want a complete investigation and resolution.

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

#233
This is the reason I had to stop using Hover for DNS management. They don't support TXT records longer than 255 characters, and I've not found any instance of someone getting split records to work with Hover. Ended up using Digital Ocean for it. I would love for elliptic curve crypto to become the status quo if this is going to continue to be an issue for yet another decade.

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

#234
post #47

Earlier quoted context omitted.

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

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

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

#235
post #129

Earlier quoted context omitted.

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.

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

#237

Earlier quoted context omitted.

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.

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

#238

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…

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.

I've been doing this since around 2018, and have seen a few others implement it.

https://rya.nc/dkim-privates.html

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

#239
post #234

Earlier quoted context omitted.

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

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

Repudiation is the goal.

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

#240
post #234

Earlier quoted context omitted.

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

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

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.

Post reply on HN