Creating PGP-Encrypted E-Mails Using ASP

Understanding PGP Fundamentals

Pretty Good Privacy, or PGP, is a public‑key cryptosystem that couples encryption and digital signatures. When you want to send a secure e‑mail, both the sender and the recipient need a pair of keys: a public key that anyone can use to encrypt a message or verify a signature, and a private key that stays in the owner’s possession and is required to decrypt or sign. The beauty of this design is that the public keys can be freely shared while the private keys remain secret.

In practice, the workflow looks like this: before you start exchanging sensitive data, you exchange public keys. Each side imports the other’s public key into its own keyring. Once that is done, you can sign messages to prove they came from you. Signing involves using your private key to generate a mathematical hash of the message. The recipient can verify the hash against your public key, ensuring authenticity and integrity. Signing does not hide the content, so it is usually combined with encryption.

Encryption, on the other hand, transforms readable data into an unreadable form that only the intended recipient can revert. When you encrypt a message, you take the recipient’s public key and mix it with the message data. The result is a scrambled output that can be sent over an insecure channel. Only the recipient, who holds the matching private key, can decrypt it back to the original text.

PGP’s strength stems from using asymmetric cryptography for key exchange and symmetric cryptography for the bulk data. The symmetric part is fast, while the asymmetric part guarantees that only the intended parties can participate. The two layers work together seamlessly, so a single PGP command can sign, encrypt, and produce an ASCII‑armored file that can be attached to an e‑mail.

When you’re planning to automate this in a web environment, it’s crucial to understand that PGP itself is not a web protocol; it’s a command‑line tool that accepts file paths, key identifiers, and passphrases. ASP will act as the orchestrator: it will create temporary files, call the PGP executable, and then use a mail component to send the resulting .asc file. Knowing the difference between signing, encryption, and the steps required to set up the keyring will save time when you start coding.

Beyond the basic workflow, PGP offers additional features like key trust levels, revocation certificates, and key expiration dates. When you generate a key pair, you set a validity period; after that period the key is considered expired and cannot be used for new signatures. Revocation certificates allow you to invalidate a key if you suspect it has been compromised. For most developers, understanding these optional features is useful, but the core signing and encryption process remains the same.

By the end of this section you should grasp the following: public keys are shared, private keys are protected; signing proves origin, encryption protects confidentiality; and PGP’s command‑line interface will be the bridge between your ASP application and the cryptographic engine.

Installing and Configuring the PGP Command Line

The first practical step is to get the PGP software onto the server that will run your ASP pages. The Massachusetts Institute of Technology offers a free version of PGP for personal, noncommercial use. You can download it from http://web.mit.edu/network/pgp.html. If you need a commercial license, the PGP E‑Business server is available from PGP Security, a subsidiary of Network Associates Technology, Inc.; more information is at http://www.pgp.com/products/whatsnew/pgp-ebusiness-server-71.asp.

After downloading the installer, run it and follow the on‑screen prompts. Choose a location that is accessible to the IIS worker process. On Windows, the default location is often C:\Program Files\PGP\pgp.exe. If you are using a 64‑bit server, make sure you install the 64‑bit version to avoid compatibility issues with the ASP runtime.

Once installation is complete, open a command prompt and type pgp -h. This will display the help screen and confirm that the executable is on the PATH or that you can run it from its installation directory. If the command does not run, add the installation folder to the system PATH variable or use the full path when invoking PGP from ASP.

Before you can encrypt or sign any data, the PGP environment must contain a keyring with at least one key pair. PGP uses a configuration file, usually named pgp.cfg, located in the same directory as the executable. In the free MIT distribution, this file is automatically created with default settings. If you need to customize key generation parameters or set a global trust database, you can edit this file manually.

PGP also requires a directory for storing keyrings and temporary files. By default, it uses %APPDATA%\PGP on Windows. Ensure that the IIS user (often IIS_IUSRS or a custom account) has read/write permission to this directory. Without proper permissions, PGP will throw errors when trying to read or write keys.

Now that the software is installed and configured, you can start creating keys. The next section walks you through generating a key pair, extracting the public key for distribution, and adding a recipient’s key to your local keyring. These steps set the stage for the encryption commands that will later be called from ASP.

Generating and Managing Key Pairs

With PGP installed, the first cryptographic operation you’ll perform is key generation. From the command line, run pgp -kv. The -k flag tells PGP to create a key, while the v flag enables verbose output so you can see each prompt.

During the interactive session, PGP asks several questions that shape the security of your key. First, choose the key type: for most users, the default “Standard Key” is fine. Next, select an algorithm. The Digital Signature Standard (DSS) with Diffie‑Hellman provides strong authentication, but RSA is still widely supported and remains the default in older PGP versions. The key size is the next choice; 2048 bits is a common starting point, offering a good balance between security and performance. If you anticipate extremely sensitive data, consider 4096 bits, but be aware that larger keys will take longer to generate and use.

After the algorithm and size, you’ll provide a user ID in the form of an email address or a descriptive string. This ID will appear in the key header and is used when importing or searching for keys. Then, set a validity period for the key. You can enter a specific number of days or choose “forever.” Keep in mind that expired keys cannot be used for new signatures, so plan accordingly.

The final prompt is for a passphrase. This passphrase protects the private key on disk; if someone gains access to your keyfile, the passphrase prevents them from using it. Choose a strong, memorable passphrase and store it securely. Once the process finishes, PGP creates a private key file named keyring.pgp and a public key file that you can export.

Exporting the public key is straightforward. Run pgp -kx userid keyfile.asc, replacing userid with the user ID you entered and keyfile.asc with the desired output file name. The resulting ASCII file contains all the information necessary for others to encrypt messages to you or verify your signatures.

Now suppose you need to send a message to someone else who already has a PGP key. Before you can encrypt anything, you must import their public key into your keyring. Use pgp -ka keyfile.asc, where keyfile.asc is the file you received from the partner. After import, PGP will ask you to trust the key. Assign a trust level: “ultimate” if you fully trust the owner, “full” if you are reasonably sure, or “partial” if you are uncertain. Trust levels control whether PGP will allow you to encrypt to that key by default.

To sign a key and remove trust prompts during encryption, run pgp -ks userid. This marks the key as signed and establishes that you accept it as genuine. Signed keys are treated with higher confidence, so subsequent encryption operations will not issue warnings about untrusted keys.

Throughout this process, you’ll find that the keyring grows in complexity. You may have several keys from different partners or from earlier versions of PGP. Keep your keyring tidy by removing keys that are no longer in use: pgp -k -d userid deletes a key pair. Always back up your keyring before making major changes; a simple copy of keyring.pgp to a secure location protects you from accidental loss.

After mastering key generation and management, you’re ready to perform actual encryption and signing. The next section explains how to automate this workflow from an ASP application using an ActiveX wrapper around the PGP executable.

Encrypting Messages and Sending Them From ASP

Having the PGP executable on your server and a populated keyring, the final step is to bring everything together inside an ASP page. The typical workflow is: write the plain text message to a temporary file, invoke PGP to sign and encrypt that file, then send the resulting .asc file as an attachment. Because ASP runs under a web server, you’ll need a wrapper component that can launch external processes securely. An ActiveX control called XCrypt provides precisely that functionality and is available for download from http://www.appserp.com/xcrypt.

The XCrypt control exposes a simple method: encrypt. You pass the path to the PGP executable, the input file, the sender’s email, the recipient’s email, and the signing passphrase. The control then constructs the command line string and uses the Windows Shell function to execute it. If you prefer, you can write your own wrapper in VBScript, but using XCrypt keeps the code tidy and eliminates the need to manually parse command output.

Below is a minimal ASP snippet that demonstrates how to call the control. The example writes a short message to c:\temp\message.txt, encrypts it, and logs the command used. In a production scenario you would replace the hard‑coded paths and credentials with dynamic values from the web form or database.

The ActiveX code that implements encrypt is more involved. It verifies that the PGP executable exists, checks that the input file is present, constructs the command string with the appropriate flags (-seat for sign, encrypt, and ASCII armor), and ensures that any previous output file is removed before re‑executing. The code also logs each step when boolLogStatus is enabled, which is invaluable for troubleshooting.

Once the .asc file is produced, you can attach it to an e‑mail using any standard ASP mail component, such as CDO or Microsoft’s MAPI. Set the Body to a short notice that the attachment is encrypted, and use AttachFile to include the .asc. The recipient will open the file, use their private key to decrypt, and then verify the signature if you signed the message.

Security considerations are important. Keep the PGP executable and keyring in a directory that only the web server user can read. Store the signing passphrase in a secure location; in the sample code it appears in plain text, but in a real deployment you might retrieve it from a protected database or environment variable. Finally, always validate the input file paths to prevent directory traversal attacks.

With these pieces in place - PGP installed, keys generated, and an ASP wrapper that calls the command line - you can deliver encrypted, signed e‑mails from your web application. The process is straightforward once you understand the underlying steps, and it brings the same level of cryptographic assurance that PGP provides in a programmatic context.