Mailing List Archive

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

Hi Werner!

> 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.
>
[ew] Ok, i'll have to take a look at it :).

> > 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.
>
[ew] Its not that bad. We have an pkcs#11 implementation which is quite
portable, but it is somewhat clumsy, nevertheless :(.

> 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.
>
[ew] My intension was focused on integration of crypto hardware like
smartcards (what about that idea?), with the possibility for third parties
to develop their own crypto stuff to be used in gpgp or place it under GPL.

I'll take a look at your cryptolib, if i get some time and examine what
about integration of such stuff.

Eyck