Live data from Hacker News

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

dmarcchecker.app

361–370 of 433 posts

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

#361

Earlier quoted context omitted.

Come on! Not only your math is ridiculous (you can't just square amounts of money, just consider how it would work if you changed currency: $8 is 1260¥, squares it makes it 1587000¥ which is $10k != $64) but believing that RSA-2048 is factorizable in $4k is hilarious. > none of it is "brute force" It's not exhaustive search like it would be for symmetric encryption, but it's still somewhat brute-force (especially sin…

I personally factored 512 bit numbers in 2007 for a lot less than $8, so tbh I'm going to say your overestimation of your knowledge of cryptology is far more hilarious than my paranoia about the potential truth of claims made by people claiming to be experts in cryoptology. Your claim that factoring a 256bit number would cost fractions of a cent rather than my claim of roughly $3 is also very easily verifiable. Furth…

I'm charitably sharing this to you: https://news.ycombinator.com/item?id=42645216 because someone actually interested in learning things asked the right question. May you sleep less ignorant tonight.

> Further I'll note you sound exactly like the kind of person insisting diffie hillman was a good key exchange mechanism prior to Snowdens disclosures. good luck with that.

Before or after Snowden, Diffie-Hellman (it's Martin Hellman with an “e”) is a good key exchange mechanism! When using it on Z/pZ as field it's not the most practical one nowadays because you need big keys to get the desired security level (exactly the same problem as RSA), but you if you use an elliptic curves instead you can use shorter keys again (and this is exactly what ECDH is doing: it litterally means Elliptic Curve Diffie Hellman! Diffie-Hellman went nowhere).

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

#362

Earlier quoted context omitted.

> (and to some extent NIST, because Ed25519 has not been approved by them). 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...

Oh, great to know. That gives me hope that we'll see Ed25519 certificates at some point then.

THE CABForum just updated its guidelines (in December) and elliptic curve wise only NIST P-256, NIST P-384 and NIST P-521 are accepted. (See https://cabforum.org/working-groups/server/baseline- requirements/requirements/#615-key-sizes)

So on the general web it seems remote at best.

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

#363

Earlier quoted context omitted.

https://www.keylength.com/en/4/ NIST says 2048 bit RSA is good until 2030. I'm not sure what that means, perhaps that it will be broken considering advances, perhaps just that someone (read governments) who cares to spend 5 years on the problem will break your key.

No, we are not in fact 5 years from breaking RSA-2048.

I have no idea what NIST means when they give 5 years for 2048 bit keys, but in generally I trust them more than some random poster on the internet.

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

#364

Earlier quoted context omitted.

TXT records are 255 bytes or 2040 bits. This is plenty of space to support RSA-1024 keys even with a small prefix and after base64 encoding them. However, it is obviously not enough to support RSA-2048 which is the minimum recommended size according to NIST right now. It's also not quite enough even for RSA-1536 (not widely used) due to base64 expanding the key by 33%. There actually is a standard for adding more tha…

> but it can be tricky to configure properly on a name server. I wouldn't say it is tricky with a good name server: for instance with bind just split the value into multiple quoted strings and it'll do the rest¹. Though while it is well known, it doesn't seem to be well documented away from many forum posts discussing the matter: after a little searching I can't find reference to the issue in bind documentation or re…

You're only halfway there. Also from RFC 1035:

  TXT-DATA        One or more s.
Looking up what a character-string is:

  ....  is a single
  length octet followed by that number of characters.  
  is treated as binary information, and can be up to 256 characters in
  length (including the length octet).
So the 255-byte limit for each string within the TXT record is a core part of DNS. But so is having more than one such string in the record data (which I thought was a later extension). I have no idea why this strange format was chosen when, as you noted already, the RDATA is already sized by the RDLENGTH, which is 16 bits. However, it is not a mere artifact of the zonefile format; indeed the format follows from the spec.

I'm not sure that all clients and servers out there handle more than one string in the record properly, though in my experience, most do. Still, having to split the values, and being able to split them before exactly 255 bytes, makes it trickier than it needed to be to administer and validate such configurations manually.

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

#365

Earlier quoted context omitted.

No, we are not in fact 5 years from breaking RSA-2048.

I have no idea what NIST means when they give 5 years for 2048 bit keys, but in generally I trust them more than some random poster on the internet.

Maybe check who you're responding to then ;).

He's not djb but definitely not a “random poster” either.

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

#366

Earlier quoted context omitted.

I imagine interviewing at McMaster-Carr to be a very different experience than Home Depot.

But also Apple, and Uber, etc. It was surprising.

(My joke was that McMaster's website is one of the fastest in the world, and Home Depot's is one of the slowest.)

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

#367

Earlier quoted context omitted.

As if courts care about any of that. They'll just ask the witness "did you send this email"

https://xkcd.com/538/

The same is true for breaking into a building. An expensive lock won't protect you against a determined attacker.

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

#368

Earlier quoted context omitted.

Yes, but then it also encroaches on ability to verify that you were the sender when receiving the original email. Basically, unless the recipient also checks whether the current DKIM key has been published, then they can't trust it because it may be published. If it's being published at random times and to a random URL, then it's nearly impossible to actually check. So I agree that it brings deniability, but I don't…

That’s all true, but I bet 99.99% of all email is delivered within a minute or so of being send. There are exceptions, of course, but in practice the whole thing is pretty fast. So there’s some threat modeling, too. Are you trying to email someone highly adversarial? Maybe you’re at a law office or such and that’s the case! This wouldn’t help a lot there. Not everyone is immediately forwarding all inbound mails to a…

> I bet 99.99% of all email is delivered within a minute or so of being send

No doubt that is true. However, given the total volume of email, even that tiny, tiny remaining fraction still represents actual mail with legitimate use-cases. So it's good to bear that fact in mind and not roughly implement 80-20 stuff that tramples on those.

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

#369

Breaking a 512-bit key for a good demonstration is very valuable security research, even if it's been done before. It's also legit to call out "Hey, here's a list of folks still using 512 bit, they should move off." ... but for me, actually cracking a real-world in-use key crosses an ethical line that makes me uncomfortable. IANAL but it might even be criminal. Just seems a bit unnecessary.

I don't think there's a way to make it criminal, any more than publishing a vulnerability that got you code execution on their servers could be. Actually exploiting it, of course, would be.

I think many in cryptography would see cracking a key as a precondition to "actually exploiting it" ... because you've only gotten a cryptographic secret, not "actual data".

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.

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

#370
post #355

Earlier quoted context omitted.

> (you can't just square amounts of money, just consider how it would work if you changed currency: $8 is 1260¥, squares it makes it 1587000¥ which is $10k != $64) What can you square then? For example, can you square lengths? E.g. 1km is 1000m, what is its square?

That is because "square length" is its own unit, which we call area. Square money is not meaningful as a unit, that is the problem. You can square anything you want but it turns it into a different unit, which the original commenter did not do (they presumed squaring dollars still gives you dollars back).

[deleted]
Post reply on HN