What is PGP Encryption and How does it Work?

Peter Thiel of Palantir Technologies and PayPal once said that every time an email is written, it gets broadcasted into the public domain, which is not as secure as people (end-users) tend, or led to – believe. This land of endless possibilities (and probabilities) which is the public domain has taken the stand more than – sometimes lobbying out for creative commons and other times denouncing itself for being a pool of resources in which any ill-intended user can cast a fishing rod. Security and privacy are the pillars of any software development endeavor.

In extenso, these are also the vertebrae of the grand, worldwide web, a scaffolding around which we raise web pages and other types of resources. From ARPANET to the more modern, AI-curated Internet, the need for efficient communication has remained unwavering.

Everything boils down to communication, whether you’re the underdog looking to impress the top brass or a simple customer asking the teller to gift-wrap your products. Today’s article is dedicated to one of the most crucial aspects of OTA (over-the-air) communication: privacy. And with privacy being synonymous with encryption, I’ll be taking you through PGP encryption. We’ll talk about the history of PGP, legal conundrums, incidents, and more. Enjoy and stay safe!

What is PGP Encryption?

Back in 1991, computer wizard Phil Zimmerman comes up with a new encryption program for email communications. It was called PGP, which is short for Pretty Good Privacy. Zimmerman, who was also involved in the development of VoIP encryption protocols (e.g., Zfone and ZRTP), managed to piece together an encryption system that was based on a gold combo: public-key cryptography (i.e., private-public key) hashing, symmetric-key encryption, and data compression. I’ll discuss each component in the upcoming section dedicated to the more technical aspects of the PGP encryption.

Long before PGP became the standard for secure email communications, the plaintext content of your emails could have been ‘scanned’ by anyone who possessed the right resources (e.g., your Internet Service Provider, black-hat hackers, governmental entities, etc.). Of course, this aspect would have been unacceptable, even by 90s standards. Zimmerman’s longstanding passion for cryptography made PGP possible and, to some extent, very feasible. Although Pretty Good Privacy has turned 30 this year, it has yet to be ‘cracked’ by computational or cryptanalytical means, which makes it -probably- one of the most secure email communications protocols.

The very core of PGP encryption is associating pair credentials (i.e., username and email address) with a public key. As you know, in private-public key cryptography, you encrypt with your public key and decrypt with your private key. This public-private key generation system would have undoubtedly created an abundance of keys that require some sort of curation system. As a result, the web of trust was created. Eerily similar to the X.509 system, which introduced the certificate authority principle, the web of trust ensured that the message sent by a person actually belongs to that person (anti-impersonation countermeasure).

PGP at a glance

Now, to understand the importance of the web of trust, we will need to take a closer look at the PGP encryption process. Please note that this is just a digest, geeky pun intended. I’ll get to the fun bits later on. As I might have mentioned, PGP uses a blend of symmetric- and public-key cryptography – by the way, this is called a hybrid cryptosystem. When user A wants to relay a message (encrypted) to user B, the plaintext message is encrypted with a symmetric key (RSA or DSA). The symmetric key is generated by user A who, in this particular scenario, is the sender.

When completed both message and the symmetric key – also called the session key – will be relayed to user B who, in this case, is the receiver. The symmetric key sent along with the message will ‘instruct’ the receiver on how to decrypt user A’s “Hello, world!”. Only one thing left to tackle: transmission. Do we leave the message unguarded during the transmission phase? Of course not; in PGP, the message is encrypted with user B’s public key. So, once the message arrives at the other end (user B) he or she will be able to decrypt the session key using the private key. Ultimately, the same key will be used to symmetrically decipher user A’s message.

Okay, so we’ve covered data-in-transit encryption and the pre-transmission message ‘garbling’. What about message auth and the dreaded integrity check? Digital signatures to the rescue! By embedding a digital signature, one can verify the authenticity of the message (i.e., “Hello, world!” was really sent by user A, not user A-prime, impersonating user A).

At the same time, by digitally signing the message you would have provided a much-need integrity check. So, what would happen if someone were to tamper with the message’s content? Well, long story short, decryption would not be possible. To create the digital signature, the sender would use PGP in order to compute a message digest. This message digest or hash is computed from the plaintext. After that, the digital signature’s derived from the plain text by factoring in user A’s (sender) private key.

That’s all fine and dandy, but what’s the deal with this web of trust? To answer this question, let us turn to the “PGP User’s Guide, Volume I: Essential Topics”, the book of all books, signed by none other than Phil Zimmerman himself. In the chapter concerning PGP keys bookkeeping and key validation, Zimmerman says that:

As time goes on, you will accumulate keys from other people that you may want to designate as trusted introducers. Everyone else will each choose their own trusted introducers. And everyone will gradually accumulate and distribute with their key a collection of certifying signatures from other people, with the expectation that anyone receiving it will trust at least one or two of the signatures. This will cause the emergence of a decentralized fault-tolerant web of confidence for all public keys.

From Zimmerman’s appraisal, we can infer the following:

Peer-reviewed keys. Do you trust the sender? In turn, does the sender the other clients he or she might be communicating with? With every public key download, the web of ‘communicants’, grows ever larger and so does the risk of impersonation – how can I be sure that user A is really he or she claims to be? Same question as before. Relying on this sort of peer-reviewed system is neither safe nor efficient.
Identity certification. Introduced in PGP 1.0, identity certification is a cryptographically-enforced anti-tampering and authentication provision. While this provision ensures that no one’s able to tamper with the certificate after it has been created, there’s no way of knowing what happens before the creation of the certificate.
Third-party PKI. So, A and B lead us to C, which in this case refers to a centralized authority, capable of ‘vouching’ for the user’s authenticity or, more specifically, it can say with a high degree of certainty that the public key used by user A really belongs to user A. This authority is called the web of trust or web of confidence as Zimmerman refers to it the PGP manual. Without getting tangled in the intricacies of this system, the web of trust guarantees that, at any given moment, a key shot into public space is bound to a (verified) username and email address.

Legal Conundrums and PGP-related incidents

There are very few well-documented incidents involving PGP encryption. Some scarce footnotes, some legal doodles, and the list end right here. Or does it? There’s gold to be had if you know where to dig. So, let’s start shoveling.

The Name of the Rose

Back in 2003, the Italian police were hot on the trail of the infamous Red Brigade, a left-wing armed organization responsible for several violent incidents including the murder of Aldo Moro, Italy’s 38^th prime minister. During a raid, the Italian authorities and the Federal Bureau of Investigations seized several PDAs that, allegedly, belonged to Red Brigade confederates. Evidence was piling up and the authorities needed just one last piece to complete the puzzle.

Source

The seized PDAs might have provided the necessary information. However, all of them were PGP-encrypted. So, what happened? Well, both the FBI and the Carabinieri attempted to bypass the PGP encryption layers. Their efforts proved to be in vain and, to make matters worse, the only way they might have been able to get ahold of that info would have been to convince or ‘gently’ persuade the suspects into providing them with the credentials. With no legal grounds for obtaining the credentials, the authorities had no choice but to abandon the PDAs. Flawless victory for Zimmerman’s brainchild!

The people vs. Boucher

In late 2006, the “In re Grand Jury Subpoena to Sebastian Boucher” case made headlines in the United States. The case, which was minutely documents, especially due to its constitutional implications, revolved around Boucher, an illegal Canadian immigrant who was accused of disseminating child pornography over the Internet. During Boucher’s trial, several governmental agencies attempted to gain access to Boucher’s laptop which had been previously seized by the US border officers. Of course, the encryption (PGP) could not be broken.

Source

The magistrates ordered Boucher to relinquish the credentials. With no legal precedent, the Court’s ruling proved to be unconstitutional, as giving up the PGP passphrase would violate Boucher’s Fifth Amendment rights. Now that’s a conundrum. To ‘monsieur’ Boucher’s misfortune, the authorities contested the first ruling. Boucher’s Fifth Amendment defense would prove to be inadequate. In 2009, Judge Sessions of the US District Court for the District of Vermont ordered Boucher to provide the authorities an unencrypted version of the laptop’s illicit contents.

Still here? Wonderful! Up next, we’re going to take a closer look at the PGP encryption – hashing, data compression, digital certificates, and how everything comes together.

Factoring the PGP Encryption Algorithm. Applications of PGP in Email Communication

In a nutshell, here’s what the PGP encryption process looks like:

Source

I feel some of you fretting over this. Indeed, math’s pretty disconcerting, to say the least, but all we are made clear in a minute. Now, for me to prove how PGP encryption actually works in a real-world scenario, I’ll once again call upon user A and user B – hope they don’t mind the extra attention. So, without further ado, here’s what happens during a PGP session.

Let’s assume that user A wishes to send a PGP-encrypted message to user B. How does he or she go about it? First of all, the user needs to pick out the asymmetric encryption algorithm (RSA in our case), the hashing algorithm (we’ll go with SHA512), the symmetric encryption algorithm (DES, for the win), and let us not forget about compression (ZIP will do).

With everything on the board, user A can now send a message to user B.

Step 1. User A jots down the message (M) intended for user B.

Step 2. The message itself is used to compute the SHA512 hash. This produces the 64-byte string H.

Step 3. The computed hash will be digitally signed with the help of the RSA algorithm. Lest us not forget the encryption: the computed hash (H) will be encrypted by the private key belonging to user A (PR_a). This step produces the EC or the encrypted hash (i.e., digitally signed hash). The inputs and outputs are as follows: EC input = PR_a + H.

Step 4. The digitally signed hash (EH) is appended – not concatenated, mind you – to the Message (M). Basically, EH+M is in a string array.

Step 5. The EH + M string is fed into the ZIP compression algo. Obviously, the result of this operation would be yet another string array that contains the compressed message and a compressed digitally signed hash (it’s all about the Z).

Step 6. The compressed EH + M string output will be symmetrically encrypted; DES leaps into action. Hold on now! We still need to create the DES session key. Skedaddle-skedoodle, we now have the session key (yeah, I know that it doesn’t rhyme). Now, to get a string array for this step (encrypted output), we will need to feed the compressed message and the compressed digitally singed hash into our DES algo.

Step 7. We’re nearing the finish line. There’s one last item we need to take care of: showing user B how to read (i.e., decrypt) the message. Bear in mind that the message is still encrypted with the session key. We’ll need to figure out how to send the session key to user B. For that, we will encrypt the session key generated during the DES stage using, of course, user B’s public key (PU_b). This can be achieved through asymmetric encryption. So, for RSA inputting, we will use user B’s public key and, of course, the session key.

Step 8. All we need to do now would be to append the encrypted output and the session key and to send them to user B. At this point in time (pre-transmission), the message is garbled up into three string array designed as finalmessage[].

The strings are as follows: the ZIP-compressed message which is, of course, crypted with the session key; EH which is encrypted with our session key and ZIP-compressed, and the DES-encrypted session key. If we were to translate this to code, these strings would look like this: finalmessage[0], finalmessage[1], and finalmessage[2]. Everything gets sent to user B. User A, over and out!

Step 9. Now the fun begins. User B will use his Private Keys (PR_b) in order to decrypt the DES-encrypted session key. RSA again: feed it user B’s private key and the contents of the finalmessage[2] string. User B now has the session key.

Step 10. With the session key decrypted, we can now DES-decrypt strings finalmessage [0] and [1]. Bear in mind that finalmessage[1] and finalmessage[0] will be later fed into the DES algo to obtain their unencrypted versions.

Step 11. Unzipping is achieved by feeding the unencrypted versions of finalmessage [1] and [0] into a ZIP algo.

Step 12. After decompression’s done, we’re left with the EH and the unspoiled message. One last thing to do: verifying user A’s identity, because we really don’t like charlatans. To do so, we’re going to need two types of strings: a calculated hash and a decrypted hash. To get the calculated hash, we will need to SHA-512 the original message.

For the decrypted has, we will start by decrypting the EH with the use of user A’s public key(s). Once more RSA leaps to the rescues. We now have the decrypted hash. To establish user A’s identity, we only need to compare the calculated hash with the decrypted hash. If they match, it means user A is really who heshe claims to be. In standard XOR, the result of this operation would be null. User B can now read user A’s message.

**END TRANSMISSION**

Application(S) of PGP Encryption in Email Communication

Still here? In hopes that I haven’t bored you to death with this interminable tech talk, I’m going to show you now one of the many applications of PGP encryption. In this section, we’re going to send an encrypted message from one email account to another. For this, I’ll be using a free online tool called iGolder. Hard to describe what iGolder is; it’s ‘about us’ page talks about facilitating electronic gold exchange between members. Anyway, that’s beside the point. This website has some great – and free- PGP tools. Enough talk. Let’s send some secret message.

PGP Encryption Lab

For this lab, you will need to access the following resources: a PGP privatepublic key generator, a PGP encrypting tool, and a PGP decryptor. Click on the hyperlinks to gain access to the resources.

In addition to the tools, you’re also going to need two email test addresses. In this case, the sender’s address is: [email protected] and the recipient’s address will be: [email protected]. Ready? Here’s what to do in order to send a PGP-encrypted message from John to Francis (wink-wink).

Please note that the operations described below are for example purposes only.

Step 1. Open the first link (PGP Key Generator). Type in the sender’s address in the “email address” box. Think of an adequate password or passphrase for your PGP public key. Type the password in the second box. When you’re done, click on the “Generate PGP Keys” button. The tool will generate a key pair (private and public key). Save both of them in a text document or something. If you lose them, you won’t be able to send encrypted messages or decrypt received messages.

Example 1

Email Address: [email protected]

PGP-Key PasswordPassphrase: ApplePieDean

PGP Private Key:

—–BEGIN PGP PRIVATE KEY BLOCK—–

Version: BCPG C# v1.6.1.0

lQOsBGAAPsgBCAC1v8qu+3KdNA+zMR+odlY8ihenfkblEr+ZKVHvRRXdswJaMFYg

MZ4CnlT/9aCcO+vdG/s2DiZHVq9E2me4m2CNBQLargm+QCJlFXOjM83c0TueZVbx

TULyAHZaE0qhpwGL2KBML1ND3KUw883eA5p2sqTu4DQu06WJVPirEio0jO7v7JxI

BbwdjXTRTj3v90JUl80m4bmshUNZh2eIPXdjfuY4insEgCVGyh4xzdA2AxRv8RP7

LFZSbtQZggRzZjCMxOYMEyMB53bgtU4PGgyjMkFvkJKbxs4kd6AupLByLV3aAT7u

zRaH5NGUaal0NxQnOlUGSvqpRaiJW3msq0E7ABEBAAH/AwMCCq9Z75OR95Rg/Vpr

jj2BzQaqXAFKPjcJMC1bqfypCkznGFIjQ5J+xkm+nHzjY3S2ICZfp4yfIRjaJFz8

Mt25LPnoqSSIvY6rMkYcp1KomXgf1Ar/BkaYziWN/DWbTfmIp22V7gNzoGlGa/j9

V8ul1mYHD15/oelULHdATHp87/p5iWWLg/5sdqePDeVBE/PjmK/xuz6O22m9VkhR

pt0/AG9tfEIJ60y6/JFU7foPaeHwvzHDd4fFRV/33mUynYAggbb2hgyO6FF2JXAB

m7U9aNw3lIs47AGemqoadtnCnv8nsoQTcKfW0Bm3qv0sRr3WQednFq40ic947TpJ

1l86xBPL5Ih31qIowx8iDdgqTXcb8YDUYd7aiR56ibjoRQPwhgjvT6USWbpogABy

+soszGDCz5pGUfLlOI8FOQytR110kUPcSCcDuYgcAMy2ZyL+B8wCShQpVQeOtjpH

CSo6aeWBVOFLGF/iXIL+V2XSgvyzk33qDxbsSFNl/5fwEAV0nRNa5RQoTcloF/eB

+c+CAq/+E38baaxGWma1792IDIDkUTZTulGIRh1RlCTeTlRoLLrVHyt54DRHdCSl

wq7FMJ3S226esyUFgY1HoBvyYIf0RkgXdtPr9i9iSI7HXqMjQgOZ0AlbPRlZx/sj

BVcIjiw34RsHm6PxIFYKFhnHUUhSsYW2qjo++6ty/sRbgf8mjFnnDhhPe2AzLkm1

0L11Jp7yfVm/23CeC+7JShd3yLVoO49nXLMf7cYisfQre4lWchcI31yRrPPCxTVV

s/nrO1Wlq8UyX0WBr4rovKd64qqt3QF0NvxxpRVIPAv5+qfVbbdnn26DBSmJklG3

UuWhzYPHnHQ+F5a/JHJSDhIYL1+CblrB3jXnR6r4sLQQam9obkBqb2huZG9lLmNv

bYkBHAQQAQIABgUCYAA+yAAKCRAkcbQzRuL25DdXB/4hsWpCNqgGOb2jLw6skb7K

Wl8+lpTNW67BWIZOsEM8xRhI5zRgsoQWoI51GLGrW8uNREfQ4zcEOiK1BNzdBvnU

GTKChUWvwNMer2hDen8UH23QAc0IQ4wUTrerepcAbJKfkAANfUCDs7fLDyxiulJN

MEa2Bj9v36tu4ZB1ncaWjay77fmcN4cLeIegqvpdAfMdyy1Vc1uAEH6ejVua7Uhx

aRYU1SV717LI+gzOng76snvUdXb5xS3kGXRRYnd/dl2V57oG2nqzhZH5HtBIO1ZU

x9/48XUD42bmiw8KAH9VWnNzVrYMQM+C8TdXQ4f3UsijTwv/rpyV4ItOYkrymwwx

=7uiu

—–END PGP PRIVATE KEY BLOCK—–

PGP Public Key:

—–BEGIN PGP PUBLIC KEY BLOCK—–

Version: BCPG C# v1.6.1.0

mQENBGAAPsgBCAC1v8qu+3KdNA+zMR+odlY8ihenfkblEr+ZKVHvRRXdswJaMFYg

MZ4CnlT/9aCcO+vdG/s2DiZHVq9E2me4m2CNBQLargm+QCJlFXOjM83c0TueZVbx

TULyAHZaE0qhpwGL2KBML1ND3KUw883eA5p2sqTu4DQu06WJVPirEio0jO7v7JxI

BbwdjXTRTj3v90JUl80m4bmshUNZh2eIPXdjfuY4insEgCVGyh4xzdA2AxRv8RP7

LFZSbtQZggRzZjCMxOYMEyMB53bgtU4PGgyjMkFvkJKbxs4kd6AupLByLV3aAT7u

zRaH5NGUaal0NxQnOlUGSvqpRaiJW3msq0E7ABEBAAG0EGpvaG5Aam9obmRvZS5j

b22JARwEEAECAAYFAmAAPsgACgkQJHG0M0bi9uQ3Vwf+IbFqQjaoBjm9oy8OrJG+

ylpfPpaUzVuuwViGTrBDPMUYSOc0YLKEFqCOdRixq1vLjURH0OM3BDoitQTc3Qb5

1BkygoVFr8DTHq9oQ3p/FB9t0AHNCEOMFE63q3qXAGySn5AADX1Ag7O3yw8sYrpS

TTBGtgY/b9+rbuGQdZ3Glo2su+35nDeHC3iHoKr6XQHzHcstVXNbgBB+no1bmu1I

cWkWFNUle9eyyPoMzp4O+rJ71HV2+cUt5Bl0UWJ3f3Zdlee6Btp6s4WR+R7QSDtW

VMff+PF1A+Nm5osPCgB/VVpzc1a2DEDPgvE3V0OH91LIo08L/66cleCLTmJK8psM

MQ==

=NchC

—–END PGP PUBLIC KEY BLOCK—–

Step 2. Repeat Step 1 to generate private-public keys for the second email address.

Example 2

Email address: [email protected]

PGP-Key PasswordPassphrase: CatDarkOverlord

PGP Private Key:

—–BEGIN PGP PRIVATE KEY BLOCK—–

Version: BCPG C# v1.6.1.0

lQOsBGAAQJQBCACoZFSAW6c8d3ljOkz+KUgGH5lvpm9bkxXJY2ip/9B6Hv4QG6JH

Te8pfxEElmrjww95cq21kjUil7NJ5QmwNemv0ZHqisBFU2JJklJMFs9rXl9PXxJd

Sv2fZYccujHE6mq8lpm0mNTYIZo2iyaE4+pKaeGR2Xwl+YVhsWBYppuPl8TXIJXN

pK+zPNP1XUhHgP9+/jOsYDRrL5+V+y4Ei33uSkD0d6p/t/OVHozu6WFIeGV/jug/

Mo/0J2wVgsyRfl9/0wQpjstFqZIgsDK6FU1+jGvQrPoTSVJAu7qaeNECk2tbRVd6

kAuwKyT/AMgZ8bjW1DALPUFvEjoKZOXOTA6nABEBAAH/AwMCzl5hRTzYYsJg4zHC

fDrZgAlsyVrfjARBncpEyRGD7wGYYX9694CAAedR+RxS0SXsh8uhZZg+c1gpoNiX

ch9gBKrhI9nbHcbd401sGZPA0JnspQ0C1nmNS8pbduZMrnYCCkCBYqq2X39whqmQ

j2dKKkusU8ypuUM3HpOhOTLyPMPeTRxC58xcEbo10wq33Q2D3RTYdcfkUXMUgPra

0OE7C+3StJjydMMnjE/Dx/y25cn2Xz4pA/SOzP86nrqnDj8Tdzg6UxRmZANqE0iw

y0Nw8Yzu/kLcY3QD6hHXocYJeYPUU1wDfzj1aSHtvxP5UeXBN18lm2fEoGy7EGxj

lXAQOCTX1dGhyPdyDorfWaeBNfu4iWfZORW6LUcmXXPg/2qYa1G+J96VYcWRoG+m

ORApZzTyYARSUEUw9NvvgldoTJph0clNIHsB0B9h7GZnnojgov1gwLk9ZVe+xXA/

5TdzfZfPMol3V9j24L/Uc9uspL+4yXUoYq/qXVL/vc26qUQG7CmVuCiWnwhr4h1a

7W7hUlWccA8JOeD1w1ibyTE2tKX+/Au+mpLkZdJHVcFVA0aBbJJ6ktzZGlNTACDw

MqBzZfNkMsrrkO3+vR+7vXQWRD4Pve2XMrDXBXwWAkYuPPcRDCu1to4OaRHVjR/m

/BixJVXbpquYBr4rgWHWBeIF42b1yi3Yf5ge8E0nDkVUqwS5/DMsLCjt+6mEIdC2

MuJqUDKm64qCcspWA3tSduGG+4lgtYBGuvuU7Bc2DfZEZpIG0jTfrYrgOtT51ZtJ

m0QY/YajwNwQXoZgMQsxQdnJwvAy9QhqFqLivFpMmaqZ87wKPlPH0OdCY7fbdS8b

zjDjjzOj5DHXXNbX9SSoKlCbwyosAT0bZaudIQVuZLQVZnJhbmNpc0BmcmFuY2Vz

Y2EuY29tiQEcBBABAgAGBQJgAECUAAoJEFI4ODBJCpKDz34IAKfUKpGhrq3UNtM2

qzCS0cJnZDzKlx7wBsRKjkkXw1wyPJqZWeXh8zfZOUBqMn/SV4lc11ghLcIDqtta

WGdBMSQJbr9EuT17Ds+sx3fiyigUUoix4aRxAyKMG3ckSEZq/v9E7HjIwbMyTnkm

hby+eEks0OgDGZdAGqbKwqgaArUVVXBHa/dAz25BfiGksvob7TtlleGKdHYIniOZ

dTA/feRlDeMgLahYwX5lFgguiYVNBNvyG9hcVfrk70+ftAdBv0Vo3H5brr20inWn

NUY+h401Uy2X+8MyHCMBvUhtr2nqefAdP3sppSsAdbrJPuU5d9sC374c+NagUsCd

SB1ds7g=

=ZmYA

—–END PGP PRIVATE KEY BLOCK—–

PGP Public Key:

—–BEGIN PGP PUBLIC KEY BLOCK—–

Version: BCPG C# v1.6.1.0

mQENBGAAQJQBCACoZFSAW6c8d3ljOkz+KUgGH5lvpm9bkxXJY2ip/9B6Hv4QG6JH

Te8pfxEElmrjww95cq21kjUil7NJ5QmwNemv0ZHqisBFU2JJklJMFs9rXl9PXxJd

Sv2fZYccujHE6mq8lpm0mNTYIZo2iyaE4+pKaeGR2Xwl+YVhsWBYppuPl8TXIJXN

pK+zPNP1XUhHgP9+/jOsYDRrL5+V+y4Ei33uSkD0d6p/t/OVHozu6WFIeGV/jug/

Mo/0J2wVgsyRfl9/0wQpjstFqZIgsDK6FU1+jGvQrPoTSVJAu7qaeNECk2tbRVd6

kAuwKyT/AMgZ8bjW1DALPUFvEjoKZOXOTA6nABEBAAG0FWZyYW5jaXNAZnJhbmNl

c2NhLmNvbYkBHAQQAQIABgUCYABAlAAKCRBSODgwSQqSg89+CACn1CqRoa6t1DbT

NqswktHCZ2Q8ypce8AbESo5JF8NcMjyamVnl4fM32TlAajJ/0leJXNdYIS3CA6rb

WlhnQTEkCW6/RLk9ew7PrMd34sooFFKIseGkcQMijBt3JEhGav7/ROx4yMGzMk55

JoW8vnhJLNDoAxmXQBqmysKoGgK1FVVwR2v3QM9uQX4hpLL6G+07ZZXhinR2CJ4j

mXUwP33kZQ3jIC2oWMF+ZRYILomFTQTb8hvYXFX65O9Pn7QHQb9FaNx+W669tIp1

pzVGPoeNNVMtl/vDMhwjAb1Iba9p6nnwHT97KaUrAHW6yT7lOXfbAt++HPjWoFLA

nUgdXbO4

=gj4V

—–END PGP PUBLIC KEY BLOCK—–

Step 3. Encrypt your message. Using the PGP Encryption tool, generate the encrypted message for your recipient. In our case, we are going to send an encrypted message from [email protected] to [email protected]. To do that, fill out the first box with Francis’s PUBLIC KEY, type the message you wish to encrypt in the second box, and press the “Encrypt Message” button to PGP-encrypt the message. Your secret ‘love letter’ will appear in the third box.

Example 3