Werner Koch
Fri, 10 Dec 1999 13:00:20 +0100

 On Fri, Dec 10, 1999 at 11:59:51AM +0100
 Warich, Eyck wrote:

> as i'm quite new to this list (as it seems that the list itself is
> quite new :)) i want to ask about the current status of the gcrypt
> development. A browsed the archive and found pluto mentioned, i want
I am only working partly on it becuase there are some other things to do at the same time ;-). As of yesterday (see GnuPG CVS HEAD) the library does compile but GnuPG, which uses it, does not. Configuration and autoconf macros are already there so the only tasks left to do before a first release is to implement the public key API for encryption - the one for signing does already work. One thing with the current code is that it only implements data formats which are needed by GnuPG (this is to migrate GnuPG to libcrypt). However this is not issue of the API as I believe that it is very flexible. I have still to to some benchmarking to prove that the concept is okay. The API is not build upon PKCS, but on an own API which I think is much more modern than the one of PKCS11 and much more flexible. It uses S-Expressions (like spki) for many of it's data structures and is therefore quite easy to extend.
> My idea behind that is the integration of more specific crypto
> devices as smartcards. I would suggest the usage of PKCS#11, as an
> GPLed implementation of this one exists (gpkcs11) and it allows
I had a look at Gpkcs11 but noticed that it is based on OpenSSL which is not a GPLed implementation. However it should be possible to use libgcrypt as a backend for gpkcs. Frankly said, PKCS11 reminds me of APIs as used with host software and I don't understand why the use fixed length data structures and thinks like strings padded with blanks (whatever a blank means, on a hoist it is 0x40). The use of restrictions like "convention on packing is that structures should be 1-byte aligned" does not sound very portable for me. Last not least, libgcrypt is not intended to be a "high"-level library but merely a low-level crypto library. Okay, this might change in the future but I think it is better to put high/level abstractions on top of libgcrypt. -- Werner Koch at keyid 621CC013