PHP CookBook

Recipe 14.12 Encrypting Email with GPG

14.12.1 Problem

You want to send encrypted email messages. For example, you take orders on your web site and need to send an email to your factory with order details for processing. By encrypting the email message, you prevent sensitive data such as credit card numbers from passing over the network in the clear.

14.12.2 Solution

Encrypt the body of the email message with GNU Privacy Guard (GPG) before sending it:

$message_body = escapeshellarg($message_body);
$gpg_path     = '/usr/local/bin/gpg';
$sender       = 'web@example.com';
$recipient    = 'ordertaker@example.com';
$home_dir     = '/home/web';
$user_env     = 'web';

$cmd = "echo $msg | HOME=$home_dir USER=$user_env $gpg_path " .
       '--quiet --no-secmem-warning --encrypt --sign --armor ' .
       "--recipient $recipient --local-user $sender";

$message_body = `$cmd`;

mail($recipient,'Web Site Order',$message_body);

The email message can be decrypted by GPG, Pretty Good Privacy (PGP) or an email client plug-in that supports either program.

14.12.3 Discussion

PGP is a popular public key encryption program; GPG is an open-source program based on PGP. Because PGP in encumbered by a variety of patent and control issues, it's often easier to use GPG.

The code in the Solution invokes /usr/local/bin/gpg to encrypt the message in $message_body. It uses the private key belonging to $sender and the public key belonging to $recipient. This means that only $recipient can decrypt the email message and when she does, she knows the message came from $sender.

Setting the HOME and USER environment variables tells GPG where to look for its keyring: $HOME/.gnupg/secring.gpg. The --quiet and --no-secmem-warning options suppress warnings GPG would otherwise generate. The --encrypt and --sign options tell GPG to both encrypt and sign the message. Encrypting the message obscures it to anyone other than the recipient. Signing it adds information so that the recipient knows who generated the message and when it was generated. The --armor option produces plaintext output instead of binary, so the encrypted message is suitable for emailing.

Normally, private keys are protected with a passphrase. If a private key protected by a passphrase is copied by an attacker, the attacker can't encrypt messages with the private key unless he also knows the passphrase. GPG prompts for the passphrase when encrypting a message. In this recipe, however, we don't want the private key of $sender to have a passphrase. If it did, the web site couldn't send new-order email messages without a human typing in the passphrase each time. Storing the passphrase in a file and providing it to GPG each time you encrypt offers no additional security over not having a passphrase in the first place.

The downside of using a key without a passphrase for encryption is that an attacker who obtains the secret key can send fake order emails to your order processor. This is a manageable risk. Since orders can be submitted via a web site in the first place, there is already a place where false information can be injected into the order process. Any procedures for catching bad orders can also be triggered by these potential fake emails. Also, once the key theft is discovered, and the problem that enabled the theft is fixed, the attacker is easily disabled by switching to a new private key.

14.12.4 See Also

The GNU Privacy Guard home page at http://www.gnupg.org/ and the MIT PGP distribution site at http://web.mit.edu/network/pgp.html.