Hacker News Reader

Comment by xref | Hacker News Reader

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

View on HN

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

Reply on news.ycombinator.com