Cracking a 512-bit DKIM key for less than $8 in the cloud • Hacker News Board

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

#421

Post by maxed » Sat, Jan 11, 2025, 1:19 PM UTC

dusted wrote: post #269

If you want to try something fun: Provision a 4096-bit DKIM key. Every online DKIM/SPF checker will say all is good when looking at your DNS. They will also fail any test email you send, with more or less excellent descriptions such as: STATUS: Fail DKIM: Pass SPF: Pass There's this fun thing that, apparently: It's permitted and valid to use keys larger than 2048 bits in your DKIM entry. It is not, however, required…

The latest RFC does require it though (RFC8301):

  Verifiers MUST be able to validate signatures with
  keys ranging from 512 bits to 2048 bits, and they MAY be able to
  validate signatures with larger keys.

I did my master thesis on this topic one year ago and found that all popular mail providers nowadays support 4096 bits, and some even up to 16384 bits.

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

#422

Post by maxed » Sat, Jan 11, 2025, 1:29 PM UTC

fernvenue wrote: post #337

Don't know how Apple's iCloud Email will handle it, after all, Apple has always prided itself on being extremely attentive to user privacy and data security.

I tested this last year, they properly reject mails signed with DKIM keys from <1024 bits

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

#423

Post by Twirrim » Sat, Jan 11, 2025, 3:22 PM UTC

maxed wrote: post #421

dusted wrote: post #269

If you want to try something fun: Provision a 4096-bit DKIM key. Every online DKIM/SPF checker will say all is good when looking at your DNS. They will also fail any test email you send, with more or less excellent descriptions such as: STATUS: Fail DKIM: Pass SPF: Pass There's this fun thing that, apparently: It's permitted and valid to use keys larger than 2048 bits in your DKIM entry. It is not, however, required…

The latest RFC does require it though (RFC8301): Verifiers MUST be able to validate signatures with keys ranging from 512 bits to 2048 bits, and they MAY be able to validate signatures with larger keys. I did my master thesis on this topic one year ago and found that all popular mail providers nowadays support 4096 bits, and some even up to 16384 bits.

Unfortunately MAY is not MUST. When it comes to RFCs, it's all too common that people won't implement MAYs, and you should operate expecting that. I wouldn't trust any key over 2048 bits to work.

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

#424

Post by kbolino » Sat, Jan 11, 2025, 4:19 PM UTC

1oooqooq wrote: post #420

kbolino wrote: post #364

Earlier quoted context omitted.

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

yeah my point is that most dns servers used outside the major markets do not support any of this double key stuff. if you want TLD not available at your us registrar, you're stuck with low dkim keys. period. doesn't matter what specs says. dunno if that's just a consequence of the monopoly design of the dns business, or more nefarious reasons, but that's the situation on most TLD not easily registered such as .br

Ok, using your registrar to serve your DNS records for you is a choice on your part, and if so, then yes you would be subject to their limitations. But the vast majority of registrars, and this includes registro.br as far as I can tell according to a machine translation from Portuguese to English [1], allow you to delegate a domain to your own nameservers, and this is the standard way to use a registrar. You pay a registrar to lease a domain, not to host it. Once they have delegated to your nameservers via NS records, you can serve whatever other records you want (subject to the registrar's legal policies). Now, maybe a lot of client software commonly used in Brazil does not support multi-string TXT records, and that would still be an issue, but it's not on the server side.

[1]: In the 5th bullet under section 1.2 of https://registro.br/ajuda/tutoriais-administrativos/ it says (roughly) "In DNS (OPTIONAL), you can inform the DNS servers previously configured for your domain. If you do not have this information, ignore this field. Our system will automatically use the DNS servers made available free of charge by Registro.br."

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

#425

Post by rstuart4133 » Sat, Jan 11, 2025, 10:58 PM UTC

ryan-c wrote: post #403

rstuart4133 wrote: post #394

Earlier quoted context omitted.

> The point is that the durable verifiable signature has no value to users, Apparently I'm the exception to that rule, because I have a DKIM extension installed on Thunderbird. I use it to do what you say isn't useful - as another way to check phishing messages long after they have been sent. Until DKIM is universally enforced checking it after the fact will be useful. When DKIM is universally enforced rotating the k…

> you don't need a verifiable DKIM signature to know if the message had a valid DKIM signature when it was sent. You seem to be trying to say that "the fact that it was delivered proves it had a valid signature when it was sent". That presupposes that the headers indicating when it was delivered are correct, or that it was delivered at all in the first place. I don't think you understand the attack. I sent Thomas an…

I understand the attack.

Consider this wrinkle: Thmoas's email provider is @gmail.com. Assume it is pretty well known the Gmail will only put email in his inbox if it is DKIM signed. (I run my own email home server. I can assure you this is true now unless you are someone like @debian.org. Unsigned email is simply dropped by most of the major players.)

You send the incriminating email. It's accepted by Gmail as it's DKIM signed. You rotate your DKIM keys. Mallory now steals in the @gmail inbox.

I can think of only two defences for you now. One is Google accepted the email without a valid DKIM signature - which you say is your main defence. The other is someone else sent the email by getting control of your email account / server / DKIM. I personally would find it much easier to believe you lost control of your email account than Google accepted a badly DKIM signed email from some random.

I still think this is a classic example of the XKCD rubber hose comic. The cryptographers are suffering from tunnel vision. They focus on exclusively on the well known properties of their beloved cryptography. It's odd they keep doing that. Modern cryptography is mature, well understood, and for the most part unbreakable. The weakest link is invariably elsewhere.

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

#426

Post by DarkmSparks » Sun, Jan 12, 2025, 12:10 PM UTC

cryptizard wrote: post #360

bmacho wrote: 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).

its a cost function, In that case:

cost = 2.828^(2*(bits/512))

It didn't "square the cost", it doubled the number of bits to find the cost, I just skipped a load of the math.

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

#427

Post by xondono » Sun, Jan 12, 2025, 12:19 PM UTC

daneel_w wrote: post #32

xondono wrote: post #18

Earlier quoted context omitted.

We are doing that, just not everyone is as concerned by safety and make different tradeoffs against things like ease of use or accessibility. Different applications have different tolerances and that’s fine. If and when anything quantum is able to yield results (I wouldn’t worry much about this), increasing key size is pretty much meaningless, you need to move to other encryption schemes (there’s lots of options alre…

In the case of RSA it's not meaningless to increase key size to fend off quantum computers. Quantum computing vs RSA is a case of being the largest contender, because quantum computing in itself doesn't definitively unravel the integer factorization problem.

I meant “meaningless” in the sense that your encryption is then on heavy diminishing returns territory when it comes to defending against a qc.

It will likely work for a while, but it’s a fundamentally wrong approach and you’re going to be exposed into recording & decryption attacks, instead of breaking your encryption today, I just store all your communications and wait for the next qc to be online, then fish for stuff that is still useful.

It’s a silly approach if the timeframe is 50 years because most secret information goes stale quicker, but if you’re just waiting for say a year…

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

#428

Post by maxed » Sun, Jan 12, 2025, 12:35 PM UTC

Twirrim wrote: post #423

maxed wrote: post #421

Earlier quoted context omitted.

The latest RFC does require it though (RFC8301): Verifiers MUST be able to validate signatures with keys ranging from 512 bits to 2048 bits, and they MAY be able to validate signatures with larger keys. I did my master thesis on this topic one year ago and found that all popular mail providers nowadays support 4096 bits, and some even up to 16384 bits.

Unfortunately MAY is not MUST. When it comes to RFCs, it's all too common that people won't implement MAYs, and you should operate expecting that. I wouldn't trust any key over 2048 bits to work.

Sorry, I somehow made a typo in the quoted text, the RFC says

  Verifiers MUST be able to validate signatures with keys ranging from 1024 bits to 4096* bits

So mail providers MUST support up to 4096 bits if they follow the latest RFC.

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

#429

Post by andriesm » Mon, Jan 13, 2025, 2:03 PM UTC

withinboredom wrote: post #291

speerer wrote: post #257

Earlier quoted context omitted.

It'd be funny if we were working together and just telling the same story behind our aliases.

My case was a family court dispute where one parent forged an email from the other parent about the child's care. It was a pretty wild case. After that, I was pretty convinced some people are just evil.

Most people are not aware of what it means to be sociopath/psychopath/Anti-social personality disorder... Or how common it is in the population (a few percentage points seems reasonably accepted) - Why is this information not made general knowledge?

I would argue it should be taught in schools.

It's a basic life skill, to be aware of what it means and how common it is. How do you function in society being oblivious of these facts? Basically by perennially becoming a victim to these, or by becoming bitter.

Just knowing about it is half the battle.

I would also add other dark personality types with potential to cause you real harm to the list - BPD and NPD.

School yourself, save yourself a whole lot of bad surprises. Over a lifetime being aware of the existence of these means you are on the lookout for warning signs, and you learn to get better at picking up on warning signs faster.

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

#430

Post by littlestymaar » Mon, Jan 13, 2025, 7:33 PM UTC

DarkmSparks wrote: post #414

jedwards1211 wrote: post #413

Earlier quoted context omitted.

function ops(n) { return Math.exp (((64/9) * (1/3) + 1) * (Math.log(n) * (1/3)) * (Math.log(Math.log(n)) * (2/3))) } > ops(2*16) 121106.42245436447 > ops(2*32) 38178499.24944067 > ops(2*32) / ops(2*16) 315.24751929508244 So if ops(2*16) costs $8, then ops(2*32) costs $8 * ops(2*32) / ops(2*16) = $2521.98. Far more than $8^2. The cost reaches the millions for 64 bits, and ~$165 trillion for 128 bits: > 8 * ops(2*64) /…

->The cost reaches the millions for 64 bits, and ~$165 trillion for 128 bits: meanwhile 512 bits costs $8 But you just keep believing 128 bits costs $165 trillion ROFL. >> ops(2 * 16) >121106.42245436447 >> ops(2 * 32) >38178499.24944067 >> ops(2 * 32) / ops(2 * 16) >315.24751929508244 So if ops(2 16) costs $8, then ops(2 32) costs $8 * ops(2 32) / ops(2 16) = $2521.98. Far more than $8^2. And I said $256, because as…

Their answer:

> So if ops(2*16) costs $8, then ops(232) costs $8 ops(232) / ops(216) = $2521.98. Far more than $8^2. > The cost reaches the millions for 64 bits, and ~$165 trillion for 128 bits:

Your answer

> meanwhile 512 bits costs $8 > But you just keep believing 128 bits costs $165 trillion ROFL.

At this point the only conclusion that doesn't involve questioning your sanity is just to conclude that you don't know anything about math and you struggle even reading mathematical notation (“if then ” being the most basic construct one can learn about math, and you still struggle with it!).