Network Security
Vulnerability Management
Privileged Access Management
Endpoint Security
Threat Hunting
Unified Endpoint Management
Email & Collaboration Security
Contents:
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?
PGP, which is short for Pretty Good Privacy, is an encryption system used in data communication. The algorithm was invented back in 1991 by Phil Zimmerman and it is based on a combo of 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 (Zimmerman was also involved in the development of VoIP encryption protocols e.g., Zfone and ZRTP) 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 encryption process. How the PGP Encryption Algorithm Works.
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.
In a nutshell, here’s what the PGP encryption process looks like:
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 (PRa). This step produces the EC or the encrypted hash (i.e., digitally signed hash). The inputs and outputs are as follows: EC input = PRa + 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 (PUb). 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 (PRb) 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 he\she 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**
Still here? Wonderful! Up next, we’re going to take a closer look at some PGP encryption examples and applications in email communication.
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 private\public 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: john@johndoe.com and the recipient’s address will be: francis@francesca.com. 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: john@johndoe.com
PGP-Key Password\Passphrase: 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
(Redacted for brevity)
—–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
(Redacted for brevity)
—–END PGP PUBLIC KEY BLOCK—–
Step 2. Repeat Step 1 to generate private-public keys for the second email address.
Example 2
Email address: francis@francesca.com
PGP-Key Password\Passphrase: CatDarkOverlord
PGP Private Key:
—–BEGIN PGP PRIVATE KEY BLOCK—–
Version: BCPG C# v1.6.1.0
lQOsBGAAQJQBCACoZFSAW6c8d3ljOkz+KUgGH5lvpm9bkxXJY2ip/9B6Hv4QG6JH
Te8pfxEElmrjww95cq21kjUil7NJ5QmwNemv0ZHqisBFU2JJklJMFs9rXl9PXxJd
Sv2fZYccujHE6mq8lpm0mNTYIZo2iyaE4+pKaeGR2Xwl+YVhsWBYppuPl8TXIJXN
(Redacted for brevity)
—–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
(Redacted for brevity)
—–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 john@johndoe.com to francis@francesca.com. 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
PGP Public Key:
—–BEGIN PGP PUBLIC KEY BLOCK—–
Version: BCPG C# v1.6.1.0
mQENBGAAQJQBCACoZFSAW6c8d3ljOkz+KUgGH5lvpm9bkxXJY2ip/9B6Hv4QG6JH
Te8pfxEElmrjww95cq21kjUil7NJ5QmwNemv0ZHqisBFU2JJklJMFs9rXl9PXxJd
Sv2fZYccujHE6mq8lpm0mNTYIZo2iyaE4+pKaeGR2Xwl+YVhsWBYppuPl8TXIJXN
(Redacted for brevity)
—–END PGP PUBLIC KEY BLOCK—–
Message to encrypt:
I love you, baby!
Encrypted message:
—–BEGIN PGP MESSAGE—–
Version: BCPG C# v1.6.1.0
hQEMA1I4ODBJCpKDAQf8DrYP7COJcl4Ppv8J5ShZL5auIlSMNAXaXE2QQVMTwfEi
fLS9H8szEOuS0s4tNh2SzHi3EZO39zSHoWVK/0ijCNo23zvadPz/a0UdzCXMDd4m
LuCLHn7FGQIVnrOtAksutAWq3kpENS7H/zdkgr7nbnaKusgG1lmD1uWgSy4vseJo
(Redacted for brevity)
—–END PGP MESSAGE—–
Step 4. Send the encrypted message to your peer. Use your favorite email software to send the encrypted message (i.e., the garbled message found in the third box) to the recipient. Hit the send button and wait.
Step 5. Decrypting the PGP-encrypted message. Open Francis’ email agent and copy the encrypted message. Open the PGP Decryption tool. Paste the PGP PRIVATE KEY associated with Francis’ account in the first box, type in the password\passphrase associated with Francis’ PUBLIC KEY, and paste the PGP-encrypted message found in the email you’ve just received from John’s account.
When ready, press the “Decrypt Message” button to decode the message received from John. The message will appear in the third box.
Example 4
PGP Private Key:
—–BEGIN PGP PRIVATE KEY BLOCK—–
Version: BCPG C# v1.6.1.0
lQOsBGAAQJQBCACoZFSAW6c8d3ljOkz+KUgGH5lvpm9bkxXJY2ip/9B6Hv4QG6JH
Te8pfxEElmrjww95cq21kjUil7NJ5QmwNemv0ZHqisBFU2JJklJMFs9rXl9PXxJd
Sv2fZYccujHE6mq8lpm0mNTYIZo2iyaE4+pKaeGR2Xwl+YVhsWBYppuPl8TXIJXN
(Redacted for brevity)
—–END PGP PRIVATE KEY BLOCK—–
PGP-Key Password/Passphrase: CatDarkOverlord
PGP-Encrypted Message:
—–BEGIN PGP MESSAGE—–
Version: BCPG C# v1.6.1.0
hQEMA1I4ODBJCpKDAQf8DrYP7COJcl4Ppv8J5ShZL5auIlSMNAXaXE2QQVMTwfEi
fLS9H8szEOuS0s4tNh2SzHi3EZO39zSHoWVK/0ijCNo23zvadPz/a0UdzCXMDd4m
LuCLHn7FGQIVnrOtAksutAWq3kpENS7H/zdkgr7nbnaKusgG1lmD1uWgSy4vseJo
(Redacted for brevity)
—–END PGP MESSAGE—–
Decrypted Message: I love you, baby!
Congrats! You’ve just sent your first PGP-encrypted message. Here’s to many, many more. Now, bear in mind that iGolder is a freeware tool and SHOULD NOT BE USED for official or corporate communications. If you intend to add PGP on top of your regular email comm encryption, you should look into more ‘official’ solutions like gpg4o (Outlook), Autocrypt or Enigmail for Thunderbird, EverDesk, Canary Mail, or Claws Mail. I’ll be tackling Outlook and email encryption in another article. Kleopatra – OpenPGP is another great choice for encrypted email communication, but it has a steep learning curve.
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 38th 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.
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.
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.
Parting thoughts and recommendations
Before I leave you to your PGP tinkering, I want to take the opportunity to talk a little about OpenPGP. As you might have guessed, Zimmerman’s PGP caused a bit of ruckus in the cryptography world. The method was sound, the math perfect, and the implementation was a piece of pie – six years later, PGP became OpenPGP, the email encryption standard. This step was ratified by IETF’s RFC 4880 paper and, to this day, no intelligence organization has been able to break it open. Win-win for the cyber world!
PGP is awesome and has countless applications. However, PGP cannot safeguard you against email menaces. Your message might be hidden from prying eyes, but don’t forget about the other bogies out there: ransomware, phishing, viruses, worms, etc.
Heimdal® Email Security
- Completely secure your infrastructure against email-delivered threats;
- Deep content scanning for malicious attachments and links;
- Block Phishing and man-in-the-email attacks;
- Complete email-based reporting for compliance & auditing requirements;
My recommendation would be to deploy an email security solution that can protect your hosts, endpoints, networks, resources, and other intangibles from these threats.
Heimdal’s Email Security is your best bet against emails incoming from malicious domains or IPs, spam emails, email-delivered malware or ransomware, botnetting, phishing, and more.
Some key takeaways before I scoot: PGP is one of the most secure email communication protocols, employing everything from symmetric and asymmetric cryptography to data compression and integrity checks. Know before you use PGP – iGolder is to email encryption what training wheels are to a bike. Stay safe out there and don’t forget to message me for questions, complaints, or beer donations.
