[Botan-devel] GOST-34.10 is broken in 1.9.4, ECC improvements, new crypto list
lloyd at randombit.net
Mon Mar 15 09:32:16 EDT 2010
On Sun, Mar 14, 2010 at 08:27:17AM +0000, James Mansion wrote:
> Is it feasible to delegate some implementations at runtime so that the
> fastest ones can be used? Presumably if there were faster code in crypto++
> it could be borrowed, even if the OpenSSL or GNUTLS one could not?
Yes, there is already support for calling GNU MP and OpenSSL's BN for
RSA, DH, and DSA - can't incorporate code from either due to
licensing, but there is no reason the library can't call out to them
in cases where it is availble. (This was originally written to support
hardware, but calling to other software interfaces actually seems more
useful most of the time).
GNU MP seems to be a consistent win on my machine for all of them,
OpenSSL varies depending on algorithm and key size. I looked at adding
an extra ECDSA implementation via OpenSSL but didn't have time to
puzzle out the EC key interfaces.
I'd also definitely like to optimize the 'native' routines as much as
possible, especially since OpenSSL and GNU MP often aren't available
on Windows. The big performance gap suggests there are lots of easy
wins yet to be had. Currently point multiplication uses a 2-bit
window; adding that showed an immediate large improvement, and I see
OpenSSL uses a significantly larger one, as large as 6 bits depending
on the scalar size. The NIST curves also have a special form that
offers very simple modular reduction; I'm not sure if OpenSSL makes
use of that or not.
> (Just trying to find time to try the Ajisai bits - any idea when the
> passive version that is transport agnostic will be ready? That's a
> big win for me with asio)
Yeah being able to use it with asio or other event-driven libraries seems
the biggest win for this change. No ETA, though. When it's ready. Sooner,
if you help. :)
More information about the botan-devel