3 ms·

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

by xref 7y ago

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

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

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