Re: [Ace] Asymmetric signature performance

[Mohit Sethi <[e-mail]>]

Hi Mike

Reply inline.


On 02/08/2017 07:10 PM, Michael StJohns wrote:
> 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?
It isn't the case of a wrong abbreviation. It actually took that long to 
do the exponentiation operation. We don't implement our own crypto and 
use existing libraries. In this case, we use the following library: 
http://emsign.nl/. The author of the library himself runs some initial 
measurements to find that 512-bit RSA exponentiation can take roughly 26 
seconds.
>
> (And by the way - using "3" as the RSA exponent is just wrong).
Agree. The point here was to see if we need to invest more time to get a 
secure and efficient RSA implementation working? What we concluded was 
that the performance of ECC is significantly better, at least for our 
platform with the libraries available.
>
> 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.
We do write in the text that the numbers reflect the signing operation 
only. The time does not include the summary function.
>
> 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.
>
>
The best time with 163-bit koblitz curve was ~300 ms (for signing). I 
don't think it meets the requirements, but I definitely agree that we 
are getting quite better all the time. And bear in mind we use a 8-bit 
platform that not many deployments have. I think 32-bit is more common 
and cheaper because of economies of scale.
>
>>
>> Also, a lot of research in the crypto community is now on faster and 
>> more efficient elliptic curves. For example, the Crypto Forum 
>> Research group at the IRTF is currently working on Edwards curve:
>> https://tools.ietf.org/html/draft-irtf-cfrg-eddsa-08
>
> Aware of this along with Curve25519 and its ilk.  Most important thing 
> would be to get the numbers for an ARM M0 or other tiny processor for 
> these.
In the draft, we also cite an implementation where the authors were able 
to do Ed25519 signing on the same 8-bit platform in ~1,5 seconds.

Thanks
Mohit
>
>
>>
>> Hope this helps the discussion.
>>
>> Thanks
>> Mohit
>>
>> On 02/08/2017 04:55 AM, Michael StJohns wrote:
>>> Hi -
>>>
>>> This is sort of non-obvious, but one or two articles I read suggest 
>>> that RSA 1024 performance may be better than the ECDSA equivalent.
>>>
>>> The tradeoff here is obviously the size of the signature and the 
>>> transmission thereof, but...
>>>
>>> While 1024 bits isn't an ideal security strength for RSA, using any 
>>> asymmetric key system for source authentication in group systems is 
>>> going to be much better than trying to pretend that symmetric group 
>>> key systems have any authentication properties at all.
>>>
>>> I saw a PPT presentation by Hannes that  didn't include any RSA 
>>> performance numbers for the ARM processors even though the key sizes 
>>> were compared. My guess is that someone has numbers for 1024 RSA 
>>> signatures on the tiny ARM processors that might be useful to throw 
>>> into the mix.
>>>
>>> https://www.cryptopp.com/benchmarks.html has comparison values for a 
>>> specific library.
>>>
>>> What I'm suggesting is that we figure out how to meet the "can't 
>>> cost anything" requirement with weaker asymmetric keys rather than 
>>> accepting a low end fantasy of symmetric key multicast authentication.
>>>
>>> Mike
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Ace mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ace
>>
>