Hacker News Reader

Hacker News

Comment by ryanisnan | Hacker News Reader

Parent Full thread

ryanisnan

> using 4096 bit keys are just being paranoid with no gain

But at virtually no additional cost. I don't see your argument?

View on HN

> But at virtually no additional cost.

Bigger RSA keys are expensive to compute:

  $: openssl speed rsa
  
                     sign    verify    sign/s verify/s
  rsa  512  bits 0.000075s 0.000006s  13249.7 179054.0
  rsa 1024  bits 0.000136s 0.000011s   7363.7  90816.2
  rsa 2048  bits 0.000920s 0.000028s   1086.8  35897.8
  rsa 3072  bits 0.002575s 0.000053s    388.4  18845.6
  rsa 4096  bits 0.005716s 0.000093s    174.9  10777.2
  rsa 7680  bits 0.054218s 0.000304s     18.4   3287.0
  rsa 15360 bits 0.283036s 0.001182s      3.5    846.2

I think op is saying, at the cost of an undetectable fraction of a second rounding error when you SSH somewhere, so what?

It isn't practical on low end IoT devices which are now more than ever having to move toward encrypted communications. I work on a ~160Mhz product that typically takes 5+ minutes to generate a 2048-bit RSA key but can craft a 256-bit ECC key in 1 sec. There are no hardware resources that can speed this up. Stronger RSA is a dead end. It also chews up a non-trivial fraction of available RAM.

That’s for generation, not validation. And nobody is saying you have to use RSA.

If I may ask, what SSH implementation are you using? One of the libssh's? It's always a pain when one has to forego OpenSSH because it just won't run on the low-end devices...

I totally buy that for some applications, the cost of generating a 4096bit key is prohibitively expensive.

But that argument shouldn't be applied for all use cases, such as personal key management, or keys that are used for days/weeks/months at a time.

> I think op is saying, at the cost of an undetectable fraction of a second rounding error when you SSH somewhere, so what?

I tried switching from a 2048-bit to a 4096-bit key to control a modestly sized VPS (~4GB RAM, 2CPU) and scp file transfer speeds plummeted.

I have a symmetric 1GB FTTH connection and I'm used to everything being pretty quick. Using a longer key was like a return to dial-up speed. If you don't plan to transfer large files or directories you can safely ignore it, but I bet your patience will run out pretty quickly if you do.

The public key operations are only at the start of a SSH session, there isn't any effect on the transfer speed aside from the initial setup time.

(Unless you are saying you somehow convinced SSH to use a symmetric cipher with a 2-4k key size...?)

Slow within reason is a feature when it comes to decryption, so that difference is just fine.

Reply on news.ycombinator.com