Re: pgp library

-----BEGIN PGP SIGNED MESSAGE-----

Jim McCoy responds:
>  In addition to this, the code really sucks as far as modularity
>  goes.  The next big version of PGP, which is supposed to include
>  library hooks, etc., will probably not be out for five or six
>  months.  I do know of some people who are interested in working on
>  a PGP compatible library of crypto code, but I am not quite sure
>  what the status of that project is at this time...

This is really a shame, because at the current time one of the most
lacking aspects of most crypto software is the key management
interface.  Encrypting and decrypting pgp format messages is easily
accomplished in an acceptable manner using the actual pgp binary.
However, writing a decent key-management interface is practically
impossible when your only interaction with the PGP key-management code
is via the system() function call.

Of course, shelling out to the PGP binary isn't the only solution.
It's not impossible to create a simple library for encrypting and
decrypting pgp format messages (there's PGPTools, and you can roll
your own).  But you are doubly screwed because the PGP development
team has made it clear that the keyring file format will change in
3.0.

Who wants to spend time writing a key management API (which, I admit,
is NOT trivial...) which is guaranteed not to work in the next version
of PGP?  Why spend the effort to write a decent PGP front-end, which
would necessarily include a key-management interface, when 1) Any
effort expended in writing your own library or sprucing up PGPTools is
supposedly being duplicated by the PGP team as we speak, and 2) your
code is going to break anyway... ?

PGP front-ends aren't the only application type whose progress is
being slowed by this situation.  IMHO, any app that uses PK-crypto
should support PGPformat keys, even if it's output isn't designed to
be fed into PGP.

Don't get me wrong.  I understand how difficult it is to do this and I
am not ragging on the PGP developers for being slow or lazy or
anything like that (I know they are underpaid).  BUT, somebody must
write a PGP library if we are to see major advancement in the
penetration of crypto software into the mainstream.  The question is,
who is writing it?  It almost seems as if PGP development is now
happening in secret, and nobody really knows what the statusis on pgp
3.0 and the rumored library.  There are people on this list who know,
but nobody is telling.  If the PGP people really are making progress
on a PGP library, we need to know.  We can probably help.  If not, we
also need to know so we can write one.


  Phase
  (yes you too can have a pseudonym)

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBLu9kW5Ot8/1bCL+9AQGHaQP/dEaZ+3h/o8AB/gu0VLOjs14F8cgUwkm2
zpqgqFmh6Bna3GzANxSqf7R6Idmwp+y6hzk9YbDiItCE+r0inv9tp0pAE7JlPLg1
bWxM2Nd8r+ZpKhLExepNftJ9iiBewCtWNg9ylxs78VR3QjeKLBWlpcPODeIa2C0S
kZlqVBwUBKY=
=s1Nh
-----END PGP SIGNATURE-----

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2

mQCNAy7vWyUAAAEEALwtONPeyYZ6jAYbFWgq8zTqttIclI/1wTjuFC3EkDzsjJM2
kkojkebMTwcJwLUgAL2+2EouAuM+MpyqAs+8/uMW42eP8kCS5XbLzSk5pisZpH/B
kflaSeQ6lS6fr66nDHpR33wxQ+0lJWf94rJbaSWZGP2iN1W1jJOt8/1bCL+9AAUR
tDlQaGFzZSBKaXR0ZXIgPGFsdC5zZWN1cml0eS5wZ3A+IG9yIDxjeXBoZXJwdW5r
c0B0b2FkLmNvbT6JAJUDBRAu71tLk63z/VsIv70BAQkbA/9UUtJpfeTzi+OcNxQn
QQEsP+xeusQWaJnS91sEYmjtzDJTqHOZ02Lh2tya0YZVl7ra8WJ6fbTzLR96s+vQ
q+qYOwUUq+1OB6L4gdssK5ofRD/4M4dkWJlilY3eHI7Kch8KL/b2L1RG+r0rnEnG
6mH5XaHu7Lebf8wjtexJmKoWXQ==
=mpBD
-----END PGP PUBLIC KEY BLOCK-----

nobody@jpunix.com (Anonymous) writes:
> Jim McCoy responds:
> >  [...]  I do know of some people who are interested in working on
> >  a PGP compatible library of crypto code, but I am not quite sure
> >  what the status of that project is at this time...
> 
> This is really a shame, because at the current time one of the most
> lacking aspects of most crypto software is the key management
> interface.

A key-management module is planned for this library.  Something that takes
the key management stuff out of the various places in the code it is
scattered and into it's own is one of the goals of the project.

> [...]  But you are doubly screwed because the PGP development
> team has made it clear that the keyring file format will change in
> 3.0.
[...]
> Who wants to spend time writing a key management API (which, I admit,
> is NOT trivial...) which is guaranteed not to work in the next version
> of PGP?

It is not necessarily guaranteed to not work.  We have been in contact with
members of the PGP development team, and may be able to emulate much of
thier API as things develop.  Either way, this is not just a project to
develop an updated PGPTools; we hope to have a general purpose crypto
library including better math routines, generalized key management, support
for multiple public-key and symmetrical ciphers, and hooks for various APIs
at different levels.  

> PGP front-ends aren't the only application type whose progress is
> being slowed by this situation.  IMHO, any app that uses PK-crypto
> should support PGPformat keys, even if it's output isn't designed to
> be fed into PGP.

Either that, or PGP should learn to use a key standard that might not
necessarly be it's own.  Key management issues are one of the primary goals
for Eclipse and hopefully some of the IETF work in this arena in recent
months will help us in determining a direction to work in.  Either way,
while we want to support as much PGP functionality as possible I doubt we
will shackle ourselves with the liabilities of blindly following only the
PGP developers when deciding what to do.

jim