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

161–170 of 433 posts

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

#161

Post by daneel_w »

tptacek wrote: post #98
Avamander wrote: post #26

Earlier quoted context omitted.

Yikes. NIST wants to forbid even 2048-bit RSA by 2035, because it doesn't offer a good enough security level.

2048 achieves the same security level NIST requires from AEADs, doesn't it? What plausibly attacks it? Pushing people past 2048 seems counterproductive.

Counterproductive how and to what/whom? For the sake of keeping DNS TXT entries and e-mail headers compact? Would you stand by this statement also in the context of a certificate authority's root signing key, or an RSA host key for an ssh daemon?

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

#162

Post by Avamander »

colmmacc wrote: post #143
Avamander wrote: post #117

Earlier quoted context omitted.

They can pursue what they want, it doesn't mean it will go through. Looking at public data, using some other public knowledge to figure out something new does not make it inherently illegal. They didn't crack it on their systems, they didn't subvert it on their systems, they did not use it against their systems. I'd love to see some specific examples under what it could be prosecuted under specifically. Because "that…

It's more like the door has a weak lock that can be picked. Just like many real world doors do. Here's how it would go in court: "Are you aware that this key could be used to decrypt information and impersonate X?" "Are you aware that this key is commonly called a Private key?" "Are you aware that this key is commonly called a Secret key?" "Are you aware that it is common to treat these with high sensitivity? Protect…

If you want to continue with the analogies, looking at a lock and figuring out it's fake does not constitute a crime.

That key can not be used to decrypt anything. Maybe impersonate, but the researchers haven't done that. It's also difficult to claim something is very sensitive, private or secure if you're publicly broadcasting it, due to the fact that the operation to convert one to an another is so absolutely trivial.

And they did not make a copy of their private key, they did not access their system in a forbidden way. They calculated a new one from publicly accessible information, using publicly known math. It's like visually looking at something and then thinking about it hard.

I wouldn't want to explain these things either, but such a prosecution would be both bullshit and a landmark one at the same time.

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

#163

Post by GTP »

dfc wrote: post #59
GTP wrote: 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?

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.

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

#164

Post by deathanatos »

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

Fetch the TXT record; you should see something like,

  k=rsa; … p=
The base64 data is an RSA public key. You can print in textual form with something like,

  your-clipboard-paste-command | base64 -d | openssl rsa -pubin -noout -inform der -text
The first line of output will be something like,

  Public-Key: (2048 bit)
Which is the key length.

If you fetch with `dig`, note that sometimes dig will do this:

  example.com. 1800 IN TXT "k=rsa; t=s; p=blahblahblahblah" "blahblahblah"
I.e., it breaks it up with a `" "`; remove those, that's not part of the data. I.e., concat the strings dig returns, then parse out the p=, then base64 decode, then openssl.

(You can also do what the article does, but without Python, which is jam that base64 between some PEM header guards like the article does, and then feed it to openssl. Same command, but you don't need the -inform der b/c the "in[put] form[at]" is now pem, which is the default.)

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

#165

Post by tptacek »

daneel_w wrote: post #161
tptacek wrote: post #98

Earlier quoted context omitted.

2048 achieves the same security level NIST requires from AEADs, doesn't it? What plausibly attacks it? Pushing people past 2048 seems counterproductive.

Counterproductive how and to what/whom? For the sake of keeping DNS TXT entries and e-mail headers compact? Would you stand by this statement also in the context of a certificate authority's root signing key, or an RSA host key for an ssh daemon?

There is no plausible threat to 2048, but you'd still rather people switch off RSA, either to curves (because they're more resilient) or to lattices (for post-quantum). Pushing people to higher RSA key sizes is a waste of effort.

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

#166

Post by tonymet »

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…

Key rotation tooling has never been given adequate attention since you only do it every few years. Something ends up breaking, even if it’s just the name of the key .

keys are stateful content like DB schemas, but they don’t receive daily attention, so the tooling to maintain them is usually ad-hoc scripts and manual steps.

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

#167

Post by d1sxeyes »

meindnoch wrote: post #113
infogulch wrote: post #81

Earlier quoted context omitted.

It's more "I want you to be able to verify I sent an email to you, but I don't want you to be able to prove to a third party that I sent it." The fact that this is possible is some cryptography black magic.

I don't see how this could be possible. If I have some information which I can use to prove that you were the sender, then I can just share the same information with a third party, and they can verify just the same.

Simple, I tell you that in my message, if it’s genuine, I’ll use the word “apple” somewhere.

You tell me that you’ll use the word “banana”.

Provided no-one except you knows that my secret word is “apple”, you know the message came from me.

But it’s perfectly possible for you to fake a secret message and sign it “Love d1sxeyes, P.S. apples”, and so our approach only works between the two of us. A third party probably can’t even confirm that “apples” was the correct keyword, and even if they could, that can only prove that one of us wrote it, they can’t definitively say which one of us.

Now extrapolate this to using some more sensible mechanism than dictionary words.

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

#168

Post by singpolyma3 »

jabart wrote: post #129
linsomniac wrote: post #40

Earlier quoted context omitted.

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"

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

#169

Post by daneel_w »

littlestymaar wrote: post #31
zelphirkalt wrote: post #4

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

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

You and I aren't the ones in immediate danger. The service providers we rely on are. In discussions like these we have a "tragicomic" tendency to forget mankind's unstoppable progress. RSA-1024 offers 80 symmetric equivalent bits of security and we've been heading down this path for decades at an exponentially increasing pace.

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

#170

Post by upofadown »

throw0101c wrote: post #35
daneel_w wrote: post #17

Earlier quoted context omitted.

Probably because RSA 2048 is not yet broken, and once there we still have RSA 4096 to lean back on which is since quite some time the most common key size for most things using RSA (DKIM being one of the exceptions). In the context of DKIM we're waiting for Ed25519 to reach major adoption, which will solve a lot of annoyances for everyone.

> Probably because RSA 2048 is not yet broken […] 3072 has been recommended by various parties for a few years now: * https://www.keylength.com

But perhaps with not a very solid justification to do so:

* https://articles.59.ca/doku.php?id=em:20482030

Post reply on HN