Crypt::PGPSimple - keyring management

gary kuipers has asked for the wisdom of the Perl Monks concerning the following question:

This one is for Monks with experience in sockets and encryption:

I am using sockets (IO::Socket::INET) to communicate bi-directionally between several machines (n automatons and a server). I'd like to encrypt all messages using the PGPSimple module. My questions don't have to do directly with the encryption, but rather with the key management. This is an intranet application where automatons will connect to a port on the server.

1. When the automatons (which I have never seen or heard from before) log onto the server they will ask for the server's public key. Do I send and receive this as a string? (In other words $string = $objPGP->PublicKey("me\@myserver.com" and then send the $string via the socket).

2. Also, the automatons will send the server their public keys and identifications (automatonN@myweb.com), presumably in the same way the server sends its public key to them: as a sting into the socket. In order to use the automaton's public key I need to access it with the "PublicKey" method (which requires the identification. This menas that once I have the public key for automaton N I need to place it in the keyring (specified in PgpKeyPath). What method should I use to store the key?

Thanks All!
Gary

Comment on Crypt::PGPSimple - keyring management

Replies are listed 'Best First'.
Re: Crypt::PGPSimple - keyring management by thraxil (Prior) on Jun 28, 2002 at 12:21 UTC
if you're sending the public keys around like that, you'll be opening the system up to man-in-the-middle attacks. PKI is usually the hardest part of a system to get right. want you need is to either have the public keys distributed beforehand in a trusted manner (eg, you manually scp copies to each machine) or have them centrally distributed from a trusted source (maybe a webserver with SSL). in either of those cases, you wouldn't need to bother sending the public key itself, just the id of the key. another alternative would be to have a central signing authority that would sign all of the keys beforehand, then you could just require that anyone trying to connect have a public key signed by this authority. is there any reason you feel you have to use PGP and not something like SSL which is actually designed for encrypting socket connections like this (PGP is going to be slow in this applicationn) and that probably has a more convenient (and proven) PKI? if you stick with PGP, you definately should at least have each of the machines cache the public keys so they only need to be sent once. after the first time machines connect to each other and exchange keys, they would just identify themselves by name or id and not have to re-send keys all the time. this would be more efficient and even reduce the window of opportunity for a MIM attack to that first key exchange. anders pearson	[reply]

Replies are listed 'Best First'.

Re: Crypt::PGPSimple - keyring management
by thraxil (Prior) on Jun 28, 2002 at 12:21 UTC

if you're sending the public keys around like that, you'll be opening the system up to man-in-the-middle attacks.

PKI is usually the hardest part of a system to get right. want you need is to either have the public keys distributed beforehand in a trusted manner (eg, you manually scp copies to each machine) or have them centrally distributed from a trusted source (maybe a webserver with SSL). in either of those cases, you wouldn't need to bother sending the public key itself, just the id of the key. another alternative would be to have a central signing authority that would sign all of the keys beforehand, then you could just require that anyone trying to connect have a public key signed by this authority.

is there any reason you feel you have to use PGP and not something like SSL which is actually designed for encrypting socket connections like this (PGP is going to be slow in this applicationn) and that probably has a more convenient (and proven) PKI?

if you stick with PGP, you definately should at least have each of the machines cache the public keys so they only need to be sent once. after the first time machines connect to each other and exchange keys, they would just identify themselves by name or id and not have to re-send keys all the time. this would be more efficient and even reduce the window of opportunity for a MIM attack to that first key exchange.

anders pearson

[reply]