Hi Sid,
The 100x refers specifically to the implementations of secp192k1 and
secp256k1 that you'll get from CustomNamedCurves lookup (vs
SECNamedCurves in 1.7). There are, so far, also custom implementations
for secp192r1/P-192 (~95x), secp256r1/P-256 (~95x), secp521r1/P-521
(~75x). I'm intending to round out the list to include at least P-224
and P-384 before 1.8 is released.
What I mean by custom curves is that we've written classes tailored to
each curve's parameters, over mutable fixed-size buffers (instead of
BigInteger), using fast reduction (and sqrt) algorithms particular to
each curve's prime field. We've managed to make it all fit behind the
existing API too. Take a look in Math.EC.Custom.Sec if you are
interested in the details.
To be sure, the normal generic curve implementations (i.e. FpCurve and
F2mCurve) are much faster than 1.7 in any case. For Fp curves and
non-Koblitz binary, around ~10x. For the Koblitz binary curves, around
~5x (they were faster already).
The link you gave describes the optimization for binary Koblitz curves
(the sec_t_***k? series), which should not be confused with these
prime-field "koblitz" curves, which perhaps should better have been
called GLV curves. BC has had that "Tau" optimization for binary curves
for some long time already. I've implemented the GLV optimization
locally, but have yet to integrate it into BC.
The numbers given earlier are for random-point multiplication; we've
added a basic fixed-point multiplication that is used by e.g. ECDSA
signing, giving roughly a further 2x improvement to the higher-level ops
that use it, and for e.g. ECDSA verification
ECAlgorithms.SumOfTwoMultiplies is somewhat faster these days too (1.5x?).
You can use Math.EC.Tests.ECPointPerformanceTest to see some raw timing
data, comparing different coordinate systems and generic/custom curve
implementations.
Regards,
Pete Dettman
On 18/02/2014 11:51 PM, Sid Shetye wrote:
Hi Pete,
Unless I'm missing something, it sounds like the ~100x performance is
on secp***k1 (Koblitz curves) right ? Likely due to this (Link to
Google Books
<http://books.google.com/books?id=w6b0yhURTkQC&pg=PA355&lpg=PA355&dq=GLV+koblitz&source=bl&ots=0UIsfzcTFU&sig=YnBnJYvM8SKWTA8WWTSTHx11hXM&hl=en&sa=X&ei=lI4DU53aJsG62gXZ7oDwBA&ved=0CEoQ6AEwAw#v=onepage&q=GLV%20koblitz&f=false>)?
Or were the improvements generic enough to have that 100x improvement
on secp***r1 (Suite B) curves too? Would be helpful to know for those
on suite b ciphers.
Thanks
Sid
*From:*Peter Dettman [mailto:peter.dett...@bouncycastle.org]
*Sent:* Tuesday, February 18, 2014 4:44 AM
*To:* Bouncy Castle Developer List
*Subject:* Re: [dev-crypto-csharp] Latest Git build, issues with
isismtt\x509\AdmissionSyntax.cs
Hi Chris,
If you want the full performance improvements for secp192k1 or
secp256k1, from latest code (i.e. beta.1), please use
Crypto.EC.CustomNamedCurves.GetByName("secp***k1")
to get your curve/parameters (secp160k1 and secp224k1 may be
implemented in due course - presently there's also P-192/P-256/P-521
and their secp***r1 equivalents).
It is little exaggeration, if any, to say that these "custom" curves
are 2 orders of magnitude (100x) faster than what was in 1.7.
Regards,
Pete Dettman
On 14/02/2014 12:20 AM, Mankowski, Chris wrote:
Also, thank you for working on the scep***k1 curve improvements.
I can't wait to try them out!
------------------------------------------------------------------------
