Moi Mohit, One note on the timing constraints, if you use, for example, the Schnorr signature system you can precompute the group operation and do only one hash and one field operation with the fresh data. Similar optimization could be done for DSA, but it is more commonly mentioned in the Schnorr case. RSA does not allow this, as far as I know.
So if the sleep cycle is longer than the pre-computation time the latency would not be an issue. Mostly the power budget issues remain. Performance figures (on x86 and P-256) would show something in the ballpark of 35µsec for things you can precompute, and 5 µsec for things you cannot. This of course prevents using deterministic DSA variants (derive k like in eddsa). Also, there are more confidential bytes in memory on average. BR, Joona Kannisto > Mohit Sethi <mohit.m.se...@ericsson.com> kirjoitti 10.2.2017 kello 10.38: > > 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 _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
