Hastur CT status

[A Loose Affiliation of Millionaires and Billionaires and Babies <cactus@hks.net>]

(Sorry if the signature gets anybody's noses out joint.  I'm in a goofy
 mood.)

-----ORTVA CTC FVTARQ ZRFFNTR-----

It's another Hastur Crypto Toolkit progress report.  Why?  Because many
people expressed an interest in it, because I want to continue to get
comments on what I'm doing, because I want people who might be inclined
to do something similar to know about what I'm doing, and because
cypherpunk projects tend to be assumed to be dead if nothing is heard.

The general IO section skeleton is finished, and all file I/O and memory
I/O types are supported.  Encoding rules now fully coded in are rot13 (for
simple testing), uuencode, and radix64.  There are also unfilled stubs
for DER/BER at the moment.  

I'm about to start in on the framework for crypto code and key management:
Any ideas on handling a generalized concept of keys will be greatly
appreciated!  For instance, I've asserted several times here that
X.509 keys can be fully modelled as special cases of PGP web-of-trust
keys with one additional field, the expiration time.  Nobody has flamed me, but
nobody has agreed with me... since I've only read the X.509 spec and never
actually used them, I'd like some assurance that I'm not missing some
subtleties in this approach.

The general I/O is fairly slow, since items are fetched in blocks
appropriate for the encoding (IE, radix 64 maps 4 bytes r64 to 3 bytes
binary);  I might put the effort into optimizing it later, but my gut
feeling is that the crypto is going to be at least an order of magnitude
slower.

Now, the general outline of what I'm building.  This is pretty much the
same as what I've posted before.  I do want to note that all I/O is
locking, using a library of locking versions of I/O fns I sent to some
folks here a while ago.

- ---
Hastur Crypto Toolkit.

In essence, what I'm building is a crypto library that takes a very general
approach with a few parameters controlling its behavior.  The idea is
to have something that anybody can drop into their mail agent and have
an easy way of using crypto and interface with existing systems such as
PGP.  A major design goal is to be backwards compatable with PGP, but
paramount is having a plug-and-play library that will be flexible enough
to meet future crypto needs.  RIPEM compatability is also desirable.

One of the biggest problems today is that crypto libraries are chiselled out
to deal with very specific cases -- the most general I know of if is RSAREF,
which deals with only with crypto functions that RSADSI happens to find
useful.

The things that I've parametrized in the design are:

	- Type of I/O.  Right now, files (and fds) and a couple of memory
	 configurations	are supported.  I've made it trivial to add new
	 types of I/O as well, and there are flags to support to
	 immediate zeroing of data once it is read into the internal
	 structures.

	- Encoding of data.  There are multiple ways to encode a bytestream
	 and these methods can be nested.  In this library, you can specify
	 the type.  I also want to eventually put logic in (where possible)
	 to determine the type and will also use this to support various
	 compression schemes.  Currently supported are rot13, radix64, and
	 uuencode.

	- Ciphers (this is the big one).  Right now, as I've mentioned,
	 things are very haphazard.  What I want is a way to change one
	 parameter from, for example, CRTYPE_IDEA to CRTYPE_DES and
	 thus change the encryption scheme.

	- Key management.  I know of two major ways of doing things
	 right now, X.509/PEM certificates as pushed by RSADSI, and
	 PGP web-of-trust.  As far as I can tell, PEM-style certificates
	 are just a degenerate case of PGP web-of-trust.

	- Random sources.  People should be offered a pretty good source
	 of random numbers, but should also be allowed to drop in their
	 own sources.  This is going to be relatively tough on platforms
	 I don't know much about, IE Mac and PC, but I'm hoping for some
	 help on this.  I can also salvage some code from RIPEM for those.

	- Autoconfiguration to incoming messages.  People should be
	 able to open a file and have it work, even with schema added
	 to the library after the original adaption to Hastur (assuming
	 an upgrade of the library, of course).

There's some other stuff that I'm probably forgetting here, but that's
the gist of it.  The cipher code is going to be pretty simple: I'm
getting a lot of code from various places on the net;  the code exists,
it just isn't put into a form that is easy to use.  The most difficult is
going to be a generalized scheme for key management: first off, I'm probably
going to simply use PGP's web-of-trust as my model, assuming the X.509/PEM
style certificates can be treated as degenerate cases of web of trust.

I also intend to offer a GSSAPI interface to all of this in release
1.1 or so.

This is so far all in C: I'm not a C++ convert yet and C is still the
most portable of the languages about.  Later, perhaps class libraries
can be designed around the same code.

Comments are actively solicited.

-----ORTVA CTC FVTANGHER-----
Irefvba: 2.6.2

vDPINjHOYmxxvuAutbieCO7qNDSfStDNyU0k5/4/10EHEJGY72kwhzoGEAZMe0z7
oQf4Y+QbtweC9vauOYo8SAXFrI4td2coJ3xbtsojYTuhHamWcX2AxIlLedSWFuuJ
e6mIEDbk6xIpoyLvIsfSLUqKkO6qe4hWXZxORSF6vN6cqvmNaNAuG17nE8IqfiAh
ZeydKo0cNf8=
=oOZD
-----RAQ CTC FVTANGHER-----