Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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

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

* https://www.keylength.com



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


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.


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


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.


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.


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.


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.


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


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


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.


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.


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

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


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: