[Help-gnutls] PGP api

[Brad Hards]

On Tuesday 27 November 2007 01:41:53 am Angus wrote:
> 	I'm not trying to authenticate, but section 3.1 doesn't specify or
> generalize what I'm trying to do either. I'm sorry, I don't have much
> experience with public key encryption. I just had the idea that the
> contents of e-mails could be encrypted with PGP, and the more popular mail
> clients had the facilities to decrypt such e-mails.
This looks reasonable, but GnuTLS (or OpenCDK) probably is not the tool to do 
it. So this is probably off-topic.

> > > 	I'm looking at GPGME, and it looks a little too DIY. From what I can
> > > tell, all it does is open a socket to an algorithmic backend, and pipes
> > > data to and from it--no place to insert things like public and private
> > > keys and whatever else PGP needs.
> >
> > GPGME is designed to support mail user agents handled PGP encryped/signed
> > messages. Use of it for something wildly different is going to be messy.
>
> 	That does like what I'm trying to do. I have my own mail-sending daemon,
> you see. It can do things like attach files, include special X- headers,
> and now I want to encrypt the contents of these e-mails.
OK. I still suggest gpgme. It does have reasonable key handling - read the 
info pages a few times. Note that it isn't just a PGP library - it also does 
X.509 based certificate operations. That makes some of the function names a 
bit abstract, and not all functions are OpenPGP related.

Also, what you are trying to do is not trivial, and doing any crypto work 
without really solid understanding of the technology and the tools is at 
least a bit dangerous.

> > I can't help you with a better suggestion unless you can explain what you
> > are trying to do. Are you trying to generate the keys yourself, or do you
> > already have them? How are you planning on transferring the private key?
>
> 	I don't understand. From what I thought I knew about PGP, the private key
> shouldn't enter into the encryption of anything. I imagined the encryption
> algorithm would just take the content to encrypt, the public key, and let
> the recipient worry about the private key.
Sorry, from the context, I thought you were going to do a file transfer. 
You're obviously going to need the public key to encrypt, and the private key 
to decrypt. You still need to figure out the key management concept though 
(like how to reliably transfer the public key from the intended recipient, 
and manage the association of key to recipient).

Good luck.