Hi Derek

A small comment on ECC performance inline.


On 02/09/2017 05:10 PM, Derek Atkins wrote:
Mike,

Michael StJohns <mstjo...@comcast.net> writes:

On 2/8/2017 8:19 AM, Mohit Sethi wrote:
Hi Mike

At least with our measurements on an 8-bit microprocessor platform,
1024-bit RSA exponentiation was extremely slow. Please have a look
at Table 1:

https://tools.ietf.org/html/draft-ietf-lwig-crypto-sensors-01
I look at Table 1 the first thing I see is that you're using the wrong
abbreviation for time - (ms is milli second), what you want is micro
seconds or (us).   Or are you actually trying to claim that a 1024 bit
operation takes 199 seconds?   Or all of 3+ minutes?     Or are you
using an abacus and a monkey to do the math?
 From my personal experience working with tiny microcontrollers I would
guess that there is NOT a typo in those numbers and it really does take
3 minutes to compute an RSA operation.  I've had similar (although
somewhat better) results with ECC on similar platforms (166-bit ECC was
taking around 30s).  Note that this is computation in software.  A
hardware implementation would certainly be faster, but then you actually
need to implement the hardware.
Regarding the performance of 160-bit ECDSA on our 8-bit platform. We experimented with a couple of different libraries and found that the signature operation took anywhere between 800 ms - 2000 ms. The exact numbers can be found in Tables 2,3,4,5 and 6 of the draft: https://tools.ietf.org/html/draft-ietf-lwig-crypto-sensors-01. Perhaps you could try some of those libraries on your platform and see if you get better performance results on your chosen platform.

Any other comments on the draft are also welcome.

Thanks
Mohit

(And by the way - using "3" as the RSA exponent is just wrong).
It's done frequently in "lopsided" constrained environments in order to
limit the computation required by the more-constrained device.

Table 1 doesn't actually indicate whether this is a signing operation
or a verification operation, or whether or not the summary function
(SHA1 or SHA256) is included.

If Table 2 and table 3 have the same mistakes in time abbreviation
(and I'm not sure why they wouldn't), you're saying that you can do an
ECDSA function in 2-6 milliseconds.   Which more than meets the
requirements.
I don't think it's a mistake.

_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
-derek


_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Reply via email to