3 ms·

> using 4096 bit keys are just being paranoid with no gain But at virtually no additional cost. I don't see your argument?

Ayesh 7y ago
> 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
- xref 7y ago
  I think op is saying, at the cost of an undetectable fraction of a second rounding error when you SSH somewhere, so what?
  - kevin_thibedeau 7y ago
    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.
    - xref 7y ago
      That’s for generation, not validation. And nobody is saying you have to use RSA.
    - shandor 7y ago
      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...
    - ryanisnan 7y ago
      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.
  - tombrossman 7y ago
    > 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.
    - fulafel 7y ago
      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...?)
- sgc 7y ago
  Slow within reason is a feature when it comes to decryption, so that difference is just fine.

Ayesh 7y ago

> 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

xref 7y ago
I think op is saying, at the cost of an undetectable fraction of a second rounding error when you SSH somewhere, so what?
- kevin_thibedeau 7y ago
  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.
  - xref 7y ago
    That’s for generation, not validation. And nobody is saying you have to use RSA.
  - shandor 7y ago
    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...
  - ryanisnan 7y ago
    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.
- tombrossman 7y ago
  > 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.
  - fulafel 7y ago
    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...?)
sgc 7y ago
Slow within reason is a feature when it comes to decryption, so that difference is just fine.