-----BEGIN PGP SIGNED MESSAGE----- I'm just about done with the first part of my crypto library, the internal generalized I/O, and largely done with the framework for the encoding rules. Since I haven't fully outlined what I'm doing here, I thought I'd mention the outline in the hopes of getting some real feedback and perhaps some random snipets of code. 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. 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 AFAIK only supports BER/DER for encoding and RSA and DES/CBC for encryption. I'll grow more clueful on that, and other crypto and key management issues, as I get to actually working on them. 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. For example, PGP, MIME, and uuencode use their own formats. 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. - 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 GUCAPI. 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, as seems appropriate when I get to it. 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. Thoughts? Am I wasting my time, or is this a worthwhile pursuit? And should I find a better name than GUCAPI? -- Todd - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBLx7wfCoZzwIn1bdtAQGIWAF9GgY29Qop9p1TEryO3oe/cFUyyBAJQtp7 yPGjEDyCvk/vtLHTAxhQoMTE98MMkPP1 =EoBl -----END PGP SIGNATURE-----