Crypto-API

[Werner Koch]

 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 guug.de           www.gnupg.org           keyid 621CC013