[Opendnssec-develop] (GOST support) Fwd: [Botan-devel] State of 1.9

[Rickard Bellgrim]

FYI


Vidarebefordrat brev:

Från: Jack Lloyd <<mailto:lloyd at randombit.net><mailto:lloyd at randombit.net>lloyd at randombit.net<mailto:lloyd at randombit.net>>
Datum: 1 mars 2010 18.27.35 CET
Till: botan dev list <<mailto:botan-devel at randombit.net><mailto:botan-devel at randombit.net>botan-devel at randombit.net<mailto:botan-devel at randombit.net>>
Ämne: [Botan-devel] State of 1.9
Svara till: Botan development list <<mailto:botan-devel at randombit.net><mailto:botan-devel at randombit.net>botan-devel at randombit.net<mailto:botan-devel at randombit.net>>


A quick update on the status of the 1.9 tree. I've merged Ajisai's
SSL/TLS implementation into mainline. Currently it relies on a Socket
wrapper class (an implementation exists for BSD sockets), which the
SSL code interacts with in a blocking manner. In the long view (before
1.10.0), this will change to be event-driven so there are no socket
dependencies in the library proper, and so applications can use
whatever interprocess method they prefer (BSD sockets, asio, Winsock,
libevent, etc). The code is very alpha still, and I know there is a
least one bug that causes crashes in the server-side handshake in the
current code. I would encourage anyone who is interested to consider
hacking on this stuff, there are a number of useful features
(including TLS 1.1 and 1.2, TLS extensions, reading SSLv2 client
hellos, etc, etc) that could be very nice to have.

I've added the GOST 34.10-2001 signature scheme at the request of the
OpenDNSSEC/SoftHSM developers, because GOST is in the process of being
added to DNSSEC and apparently will be required for use by the Russian
security agencies.

SIMD optimizations continue with implementations of IDEA (SSE2 only)
and Noekeon (SSE2 or Altivec), and now XTS mode and CBC (decryption
only; CBC encryption of a single stream requires iterative operation)
will process data using SIMD where possible. So using a SIMD-enabled
cipher with these modes offers substantial performance improvements.
This will also be useful with AES for those with processors that
included AES-NI since the AES-NI code in botan does 4 blocks in
parallel to hide instruction latencies as recommended by Intel.

The ECC code has been substantially modified, in particular removing
the use of shared_ptr, because it was causing strange crashes with
certain GCC versions on certain processors (for instance on x86-32 but
not x86-64 with the primary GCC version I use on my machine) that I
was unable to diagnose or understand, even with valgrind's help. On
the plus side this change means ECDSA will be available for Windows
developers as well. Part of this refactoring included removing many of
the Montgomery optimizations that had been included, so currently ECC
is substantially slower than it is in 1.8 (and it is not particularly
fast there either). My goal with ECC is for ECDSA to be at least 1/2
the speed of OpenSSL's ECDSA by 1.10.0 - since it currently is between
20 and 100 times slower, there is some rather major room for
improvement there.

A block cipher cascade is now available - for instance
"Cascade(Serpent,CAST-128)" is a 128-bit block cipher that encrypts
first with Serpent and then with CAST-128 (since CAST-128 is a 64-bit
cipher the two halves of the Serpent output are encrypted
seperately). Probably more useful is something like
"Cascade(Serpent,AES-256)" or (for the uber-paranoid who don't much
care about performance) "Cascade(Serpent,Twofish,MARS,RC6,AES-256)".
I should add an alias for that last one so it can be called as
"AES_Quinfecta".

A password hashing scheme (for user authentication, ala crypt(3) or
bcrypt) is available. It is a custom scheme based on PBKDF2 called
passhash9. I plan on documenting this scheme and providing
implementations in C, Python, etc once I have the time (interoperating
C and Python implementations are written already but writeup is not).

The S2K interface has changed. Instead of the current API where the
salt, iteration counts, etc are set with individual calls, followed by
derive_key() taking just the passphrase, all arguments are passed to
derive_key. This is simpler and easier to deal with in 99% of the use
cases I've encountered.

Passing --gen-amalgamation to configure.py will create two files,
botan_all.cpp and botan_all.h, which can be included in third party
projects that don't want to depend on an external library. Just
compile the .cpp file into your app and use botan_all.h wherever you
included any botan header. The assembly code and a few of the SIMD
modules are not available in the amalgamation, but everything else is.
The amalgamation only includes configured options so you can create
a minimal amalgamation using
 --no-autoload --enable-modules=<specific things you need>

Things currently holding up the release:

- You still can't create static libraries on VC++. --disable-shared
  is ignored. Lots of requests for this.
- Fixing the SSL handshake crash. Be kind of embarassing to announce
  adding SSL to the release when servers don't work at all.

Things that would be nice to have before 1.9.4:

- Adding Montgomery optimizations back to ECC. Clearly using Barrett
  reduction for this is not going to cut it, performance-wise.
- Adding ECDH/ECDSA ciphersuites to the SSL implementation. Maybe
  even the NSA Suite B CBC suites? (RFC 5430).

-Jack
_______________________________________________
botan-devel mailing list
<mailto:botan-devel at randombit.net><mailto:botan-devel at randombit.net>botan-devel at randombit.net<mailto:botan-devel at randombit.net>
<http://lists.randombit.net/mailman/listinfo/botan-devel><http://lists.randombit.net/mailman/listinfo/botan-devel>http://lists.randombit.net/mailman/listinfo/botan-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20100301/ab023b8e/attachment.htm>