I think op is saying, at the cost of an undetectable fraction of a second roundi...

kevin_thibedeau · on April 2, 2020

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.

ryanisnan · on April 3, 2020

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.

xref · on April 2, 2020

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

shandor · on April 2, 2020

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

tombrossman · on April 2, 2020

> 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 · on April 2, 2020

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