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
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
