Live data from Hacker News

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

dmarcchecker.app

181–190 of 433 posts

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

#181

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.

Both parties use the same key: https://en.m.wikipedia.org/wiki/Symmetric-key_algorithm

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

#183

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.

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.

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

#184

In case anybody is wondering about whether the 512bit number is big or small it depends on whether it is symmetric or asymmetric encryption technique. Always presume asymmetric encryption is 8x weaker than symmetric encryption. 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 S…

> Always presume asymmetric encryption is 8x weaker than symmetric encryption.

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.

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

#185
post #5
post #2

Technically, this is very nice work. 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

> But as a security generality - email is vastly less secure than human nature wants to assume that it is. 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 b…

Email is one of a great number of internet communication systems. It happens to be one that was created before security was much of a concern (and before it was a problem we could solve), and also one that is highly asynchronous. Newer systems have their own different sets of tradeoffs. None of them happen to be email plus security. But that makes sense: now that everyone is online most of the time, why would you design a highly asynchronous store-and-forward-ish system? Of course you want a recipient to receive a message as soon as you sent it and the sender to confirm the recipient received the message. Designing a new system any other way would be leaving value* on the table. (*actual value not economics value)

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.

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

#187

Earlier quoted context omitted.

Meanwhile in the real world, screenshots of emails without any cryptographic authentication at all are good enough to send people to prison.

I absolutely believe you - lawyers, judges, and juries alike tend to be technologically illiterate, but do you have any references/links to this happening?

In particular where the defendant denies the veracity of the screenshot.

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

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

> why we're not dramatically ramping up key sizes across the board on all encryption? 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.

Well, even MD4 hasn't been cracked yet.

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

#189

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

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.

Those service providers have had plenty of time to migrate to 2048 and most of them have already.

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

Post reply on HN