Re: pgp library

[nobody@jpunix.com (Anonymous)]

-----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-----