Hacker News Reader

Comment by daneel_w | Hacker News Reader

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.

View on HN

> Probably because RSA 2048 is not yet broken […]

3072 has been recommended by various parties for a few years now:

* https://www.keylength.com

RSA 2048 isn't broken, but experts consider it a matter of time. How long I don't know, but since the attacks are known (prime numbers) someone (read not me) can make an estimate with error bars that are concerning enough to consider it as good as broken.

What expert considers it a matter of time before 2048 is broken? 2048 is 112-bit-equivalent security.

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.

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

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

My inclination would be that it has less to do with the keys getting broken in that timeframe and more to do with moving to larger key sizes as soon as possible. As pointed out by others, RSA depends on the asymmetric difficulty of multiplication vs factorization of integers, but the degree of that asymmetry has no hard bounds. Advances in mathematics could reduce it, and NSA may already know of or at least suspect the existence of techniques which are not public. Larger key sizes mitigate against these developments, and pushing the software and hardware stacks to their limits sooner rather than later allows both the vendors and standards bodies to adapt before cryptographic breaks actually occur.

RSA2048 is 112-bit-equivalent symmetric security under currently known methods. Number theory advances may change that. It is hard to imagine any significant advances in the breaking of symmetric cryptography (mathematically-unstructured permutations).

Cryptographically-relevant quantum computers (CRQC's) will also break smaller RSA keys long before (years?) the bigger ones. CRQC's can theoretically halve symmetric cryptography keys for brute force complexity (256-bit key becomes 128-bit for a CRQC cracker).

AFAIK even RSA 1024 isn't broken yet.

RSA-1024 is "only" 80 symmetric equivalent bits. It's a space requiring a tremendous amount of energy to explore, though I personally consider it very likely that the NSA and/or the MSS et al. have poured immense funds into accelerators specifically targeting RSA, and for them there'd be no obstacles at all to be granted an allocation for such energy consumption.

Is there a compelling reason to use 3072 instead of 4096? If you're going to kick the can down the road you might as well put some effort into it. The difference in memory use/compute time has to be marginal at this point. It's not like the old days when jumping from 512 to 4096 made the encryption unusably slow.

There's no good reason at all, which is why RSA-3072 is the rarely seen "oddball".

> There's no good reason at all

Operations per second?

* https://wiki.strongswan.org/projects/strongswan/wiki/PublicK...

Running MacPorts-installed `openssl speed rsa` on an Apple M4 (non-Pro):

    version: 3.4.0
    built on: Tue Dec  3 14:33:57 2024 UTC
    options: bn(64,64)
    compiler: /usr/bin/clang -fPIC -arch arm64 -pipe -Os -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk -arch arm64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk -DL_ENDIAN -DOPENSSL_PIC -D_REENTRANT -DOPENSSL_BUILDING_OPENSSL -DZLIB -DNDEBUG -I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk
    CPUINFO: OPENSSL_armcap=0x87d
                       sign    verify    encrypt   decrypt   sign/s verify/s  encr./s  decr./s
    rsa   512 bits 0.000012s 0.000001s 0.000001s 0.000016s  80317.8 973378.4 842915.2  64470.9
    rsa  1024 bits 0.000056s 0.000003s 0.000003s 0.000060s  17752.4 381404.1 352224.8  16594.4
    rsa  2048 bits 0.000334s 0.000008s 0.000009s 0.000343s   2994.9 117811.8 113258.1   2915.6
    rsa  3072 bits 0.000982s 0.000018s 0.000019s 0.000989s   1018.4  54451.6  53334.8   1011.3
    rsa  4096 bits 0.002122s 0.000031s 0.000032s 0.002129s    471.3  31800.6  31598.7    469.8
    rsa  7680 bits 0.016932s 0.000104s 0.000107s 0.017048s     59.1   9585.7   9368.4     58.7
    rsa 15360 bits 0.089821s 0.000424s 0.000425s 0.090631s     11.1   2357.4   2355.5     11.0

(Assuming you have to stick with RSA and not go over to EC.)

It's roughly half as fast as 4096, which sounds bad until you realize that 3072 is already 20% as fast as 2048, 3% as fast as 1024, and 1% as fast as 512. In terms of performance tradeoff it's downright mild compared to the other steps up.

If I could waive a magic wand and get a 40-100% performance boost on a service by changing 3-4 characters (s/4096/3072/) why wouldn't I take it? (Assuming I need security go to beyond RSA 2028.)

Well, in typical use cases RSA usage is very limited (eg some operations during TLS handshake), so the 40-100% boost wouldn’t be across the board, but likely shave some milliseconds per connection.

Its not a 40-100% performance boost overall, its just during one specific step that is a very small part of the entire overall system.

These are contrived benchmarks at the extreme end of things. In real world usage the difference is drowned-out by the delays of so many other things happening in order to complete a handshake and key exchange. The mildly higher performance of RSA 3072 versus RSA 4096 wasn't even a big bonus during the CPU performances we had 15 years ago.

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

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

Nobody is recommending RSA-3072 per se. The recommendation if wanting to stick with RSA is to move beyond RSA-2048, and the world at large jumped all the way to RSA-4096 long ago.

Ed25519 has seen broad adoption in TLS and other stacks that are used pervasively where DKIM is also used. What’s blocking it for DKIM uniquely?

(This isn’t intended as a leading question.)

Everyone has to be onboard before the switch can be made, and not everyone is happy about the somewhat messy solution of running dual-stack RSA+Ed25519 setups in the interim - it's a bit different than e.g. supporting multiple methods for key exchange or multiple ciphers for symmetric crypto. It's just one of those things that take time to happen.

If the big players (gmail, outlook) jump onto it the rest will be forced to follow. Outlook would probably jump in with a checkbox, and perhaps gmail will make at an option for the paid tier while everyone on the free tier gets no choice - but that is still enough. SmallCompany.com cannot do it alone, probably not even a fortune100.com (if any of them even care - their sales staff probably will overrule the few who do), but there are enough players if they all agree on something.

Getting the big players to agree and execute though is a lot like herding cats. I'm sure some in the big players are trying.

> What’s blocking it for DKIM uniquely?

Mail server administrators.

X25519 has seen broad adoption (in the key exchange). Ed25519 has not, you can't actually use an Ed25519 certificate on the web. It's in a deadlock between CAs, browsers and TPM manufacturers (and to some extent NIST, because Ed25519 has not been approved by them).

It's not being blocked per se, you can use it mostly (98%) without any issues. Though things like Amazon SES incorrectly reject letters with multiple signatures. Google and Microsoft can't validate them when receiving. It's more that a few common implementations lack the support for them so you can't use _just_ Ed25519.

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

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

NIST P-curve certs were acceptable per the Base Requirements all the way back in 2012

* https://cabforum.org/uploads/Baseline_Requirements_V1_1.pdf

See "Appendix A - Cryptographic Algorithm and Key Requirements (Normative)", (3) Subscriber Certificates.

I'm well aware I should have added a "still" in the sentence somewhere. All efforts to have Ed25519 on the general web seem to run out of steam, we can find https://www.ietf.org/archive/id/draft-moskowitz-eddsa-pki-06... IETF side, https://lists.cabforum.org/pipermail/servercert-wg/2024-June... is the last discussion CABforum side.

Ed25519 certs do work with TLS (OpenSSL support at least), but without browser adoption it's machine to machine with private CA only .

Reply on news.ycombinator.com