3 ms·

Probably a good idea to see if the performance issues are real, though. Modular arithmetic is really expensive; to do the two exponentiations used in (non ellip

by CHY872 11y ago

Probably a good idea to see if the performance issues are real, though. Modular arithmetic is really expensive; to do the two exponentiations used in (non elliptic) 2048 bit DH, you'll be needing 6 million cycles on an Intel chip at an absolute minimum. That's 5 milliseconds in wall time (at a mobile standard 1.2GHz)). Imagine that you've got to load code from 8 different domains for a website. Then your CPU is working flat out for 40ms. Probably more like 50ms on ARM. That's a lot of time. Don't try to discredit those with perf concerns when the operation they're complaining about is incredibly expensive; they have genuine concerns.

pdkl95 11y ago
I'm not trying to imply that all of these concerns are fake, just that performance is one of the easier places to hide bullrun-style sabotage. All claims should be checked, of course. The link in my earlier post to djb's talk also discusses this issue, if youre' interested. As someone who has written an embedded webserver... including the underlying TCP/IP layer and the driver for the "supposedly NE2000 compatible" Realtek chip... on a Z80 clone using only about 4k of flash and ~1.5k-2k of RAM, I sympathetic to real performance limitations. (that device only handled once minimum-size packet only one socket at a time) That said, if you have a 1.2GHz chip, you have enough CPU for crypto. 40ms is a trivial cost for crypto, especially as you only use DH and pubkey to negotiate a symmetric key that isn't going to cause the same kind of CPU load. There isn't anywhere close to a real performance limitation on that kind of platform, and I would regard any complaint about the performance on a >1GHz CPU as highly suspicious. When you have 1/100 or even 1/1000 the CPU cycles, that something else entirely.
netheril96 11y ago
Let's presume that 5ms is a lot. Does fixing the bit size cut this down significantly? If not, then better just handle all parameter size with a single codebase.

by CHY872 11y ago

pdkl95 11y ago

I'm not trying to imply that all of these concerns are fake, just that performance is one of the easier places to hide bullrun-style sabotage. All claims should be checked, of course. The link in my earlier post to djb's talk also discusses this issue, if youre' interested. As someone who has written an embedded webserver... including the underlying TCP/IP layer and the driver for the "supposedly NE2000 compatible" Realtek chip... on a Z80 clone using only about 4k of flash and ~1.5k-2k of RAM, I sympathetic to real performance limitations. (that device only handled once minimum-size packet only one socket at a time) That said, if you have a 1.2GHz chip, you have enough CPU for crypto. 40ms is a trivial cost for crypto, especially as you only use DH and pubkey to negotiate a symmetric key that isn't going to cause the same kind of CPU load. There isn't anywhere close to a real performance limitation on that kind of platform, and I would regard any complaint about the performance on a >1GHz CPU as highly suspicious. When you have 1/100 or even 1/1000 the CPU cycles, that something else entirely.

netheril96 11y ago

Let's presume that 5ms is a lot. Does fixing the bit size cut this down significantly? If not, then better just handle all parameter size with a single codebase.