aboutsummaryrefslogtreecommitdiffstats
path: root/doc/todo.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/todo.txt')
-rw-r--r--doc/todo.txt208
1 files changed, 151 insertions, 57 deletions
diff --git a/doc/todo.txt b/doc/todo.txt
index 7d9060fe6..15b08fed2 100644
--- a/doc/todo.txt
+++ b/doc/todo.txt
@@ -1,57 +1,151 @@
-Here are some notes about various things I should/could/might do. If you're
-interested in working on something here (or something else!), drop me an email
-and we can coordinate efforts.
-
-* Algorithms / Related
- - ECDSA
- - ECDH
-
-* X.509 / PKCS / ASN.1
- - X.509 code is in need of a major cleanup, both API and internal
- - OCSP (RFC 2560)
- - Attribute Certificates (RFC 3281)
- - Support for Unicode (BMP STRING/UNIVERSAL STRING) strings in ASN1_String
- - Support for Unicode/UTF-8 strings everywhere they may show up (certs, etc)
-
-* New Interfaces / Protocols
- - SSL/TLS: Alpha release is available (http://ajisai.randombit.net)
- - OpenPGP
- - CMS: incomplete sources in misc/cms
- - NIST's PKAPI: needs CMS
-
-* Modules
- - EntropySources
- z/OS, OS/400, VMS
- - Compression: Zip, Gzip
- - Dynamic Algorithm Loader
- - Maybe, (maybe, maybe) integrate it with the stuff in algolist.cpp
- so it can do automatic lookup. I'm rather skeptical of this approach
- but it is a possibility.
- - mp_asm64: z/Series
- - HTTP certificate store access
- - Engines
- - VIA PadLock
- - Broadcom BCM582x: Free Linux drivers are available, but I need a card
- to test against.
- - CryptoSwift: Rainbow blew me off when I contacted them. I have a card,
- I just need drivers and API docs.
- - Hifn: Sokretis sells them cheap, but drivers may be an issue.
- - IBM 4758 / CCA
- - HP / Atalla
- - Intel Performance Primitives library
- - PKCS #11
- - Other suggestions welcome
-
-* Configure / Build System
- - The build system doesn't handle GCC on Windows well
- - Support for new OSes:
- - z/OS
- - OS/400
- - VMS
- - Hurd
- - Plan 9
- - Support more packaging systems
- - Debian
- - Solaris
- - MacOS X [Fink?]
- - Windows binary installer
+
+There are many areas where Botan is deficient. This file documents
+some of the more interesting ones. If you're thinking about working on
+something within Botan, one of these areas might be a good place to
+start. Questions or comments can go to the development mailing list.
+
+Build System / Porting
+--------------------
+
+The new configure script is fairly flexible in terms of build systems
+(though there do remain a few pieces of code tied to the idea of
+make-style syntax). No doubt many users would appreciate having Botan
+well-integrated into their build environment, so patches to
+configure.pl (and new template files for misc/config/makefile/) to add
+support for other build systems. The most requested by far is Visual
+Studio project files; others that might be of interest would be
+autotools, Scons, CMake, and jam/bjam.
+
+Testing the configure/build/install steps on as many platforms and
+compilers as possible is a huge win for us. Builds on some platforms,
+like the Motorola 680x0 and Hitachi SH machines, IBM's AIX on any CPU
+type, and the Haiku operating system (a BeOS R5 clone) - have *never*
+been attempted; the support is based entirely on documentation and
+conjecture, and is very unlikely to work. Support for several
+operating systems is completely nonexistent - this class includes VMS,
+vxWorks, eCos, MINIX, GNU/Hurd, L4, and Coyotos. Others, like IRIX,
+HP-UX, QNX, and Tru64, are tested only a few times a year. Similarly,
+many commercial compilers are only tested occasionally.
+
+Setting up a buildbot system would be ideal, if access to enough
+machines can be arranged (for the x86 and amd64 operating systems, a
+single machine running Xen or VMware could suffice). Even one-shot
+tests with the latest sources on a variety of machines would be
+incredibly useful.
+
+A nice but not essential feature for configure.pl would be adding the
+ability to generate any needed or requested package-building scripts,
+with support for systems like rpm, portage, dpkg, commercial Unix
+package systems, and Windows installer systems.
+
+Modules to allow use of platform-specific features within Botan can
+make life significantly better for users on that platform. Generic
+Unix/POSIX support is more or less complete, but there are countless
+vendor extensions that might be used in Botan in interesting and
+useful ways. Windows has the basics (two entropy source modules, and
+modules giving access to mutexes and high resolution timers), but
+there are probably a number of interesting extensions one could write,
+like making Botan's objects callable by DCOM. Other systems probably
+have all kinds of interesting system and library calls we can use.
+
+Self-test / Benchmark System
+--------------------
+
+The code is not terrible, but it is significantly sloppier than the
+library code it is testing. Reporting should be generalized and
+encapsulated, so it can easily be extended to produce tests results as
+text to the terminal, or HTML with full details, or as an email, or
+any of a number of useful formats (which would provide a varying
+amount of information about what was tested and what went wrong).
+Bonus points for writing a general system that takes in an arbitrary
+'template' file and outputs the filled out report.
+
+Much of the code operates at a very low level of abstraction; this has
+caused it to be difficult to add tests that vary much from the simple
+known answer tests used for the ciphers and hashes.
+
+There are significant codepaths that have no tests written for them,
+particularly in the X.509 certificate processing code.
+
+The benchmark code should also have its output formats generalized; it
+would be pretty great to have a benchmark run produce a detailed
+report as HTML and some gnuplot datasets to generate the images
+included from the HTML file.
+
+Documentation
+--------------------
+
+This could occupy someone for months. Perhaps even a majority of the
+API is undocumented, and while these are the less important pieces (or
+at least pieces meant mostly for internal library use), it would be
+great to have at least a brief description of each of them, along with
+a pointer to the appropriate headers. Text written in either a
+tutorial style or as a straight API breakdown could easily be
+integrated.
+
+There are many obvious example programs which have yet to be written,
+including encrypting a file with a shared passphrase, and securely
+salting and hashing a password for storage. Check the mailing list
+archives for ideas.
+
+ECC
+--------------------
+
+For a long time, interest in ECC has been minimal, but there are
+rumblings indicating user desire for this is starting to become really
+active. We don't need anything obscure - ECDSA and ECDH using NIST's
+approved GF(p) curves gets us 90% of what users are wanting right now.
+
+Public Key Engines
+--------------------
+
+In addition to the fairly low level BigInt optimizations that remain
+to be done, Botan provides a plugin system that allows different
+implementations of entire algorithms (RSA, DSA, etc) to be included,
+which can then be used in a completely transparent manner by
+application code. As of this writing one hardware public key
+accelerator (AEP's SureWare Runner cards) and two software backends
+(GNU MP and OpenSSL's BN library) are supported. There are many others
+out there, including Apple's vBigNum AltiVec library, Intel's
+Performance Primitives library, OpenBSD's /dev/crypto, and hardware
+units like the Broadcom BCM582x and Hi/fn 6500.
+
+BigInt
+--------------------
+
+The portable BigInt routines are fairly good, and as of 1.6 we're
+using reasonably good algorithms. But well written assembly can often
+speed up public key operations by 50% or more. There currently exists
+some limited x86 and x86-64 assembly, but implementations for other
+architectures (such as Cell's SPU units, PowerPC, SPARCv9, MIPS, and
+ARM) could really help, as could further work on the x86 code
+(including making use of SSE instructions and VIA's Montgomery
+multiplication instruction). The key routines for good performance are
+bigint_monty_redc and bigint_mul_add_words; together they make up
+30-60% of the runtime of most public key algorithms.
+
+It is very likely that many of the core algorithms (in src/mp_*) could
+be optimized at the C level by anyone has some knowledge or interest
+in algorithms.
+
+Compression Modules
+--------------------
+
+Botan currently supports the bzip2 and zlib compression
+formats. Support for gzip and (less importantly) zip would likely be
+appreciated by many users. There are also other interesting algorithms
+such as LZO (supposedly very fast, which might make it useful in
+custom network protocols), and LZW (a compression algorithm patented
+by nCipher; they sell hardware implementations).
+
+X.509 Attribute Certificates
+--------------------
+
+Most of the low-level processing code needed, like support for the
+ASN.1 SIGNED macro and the DER/BER codec, have already been written
+and used sufficiently to be well tested and relatively easy to work
+with. However it involves a lot of careful coding and design work to
+deal with the semantic issues and provide a good interface to the
+user; at this point I don't have the slightest idea what a useful API
+for attribute certificates would be like. RFC 3281 and its references
+have most of the information you'll need.