7 ms·
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 m
by daneel_w 2y ago
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.
- throw0101c 2y ago> Probably because RSA 2048 is not yet broken […] 3072 has been recommended by various parties for a few years now: * https://www.keylength.com https://www.keylength.com
- bluGill 2y agoRSA 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.
- tptacek 2y agoWhat expert considers it a matter of time before 2048 is broken? 2048 is 112-bit-equivalent security.
- coppsilgold 2y agoRSA2048 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).
- bluGill 2y agohttps://www.keylength.com/en/4/ 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.
- tptacek 2y agoNo, we are not in fact 5 years from breaking RSA-2048.
- bluGill 2y agoI 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.
- littlestymaar 2y agoMaybe check who you're responding to then ;). He's not djb but definitely not a “random poster” either.
- kbolino 2y agoMy 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.
- lostmsu 2y agoAFAIK even RSA 1024 isn't broken yet.
- daneel_w 2y agoRSA-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.
- jandrese 2y agoIs 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.
- daneel_w 2y agoThere's no good reason at all, which is why RSA-3072 is the rarely seen "oddball".
- throw0101c 2y ago> There's no good reason at all Operations per second? * https://wiki.strongswan.org/projects/strongswan/wiki/PublicKeySpeed 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.)
- jandrese 2y agoIt'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.
- upofadown 2y agoBut perhaps with not a very solid justification to do so: * https://articles.59.ca/doku.php?id=em:20482030 https://articles.59.ca/doku.php?id=em:20482030
- daneel_w 2y agoNobody 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.
- woodruffw 2y agoEd25519 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.)
- daneel_w 2y agoEveryone 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.
- bluGill 2y agoIf 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.
- deleted 2y ago[deleted]
- paulnpace 2y ago> What’s blocking it for DKIM uniquely? Mail server administrators.
- Avamander 2y agoX25519 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.