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