Explain PGP Encryption: An Operational Introduction

If you don’t already know what Pretty Good Privacy (PGP) is; you may have heard of PGP before, perhaps during a discussion on how to secure your communications, or perhaps in one of those how-to maintain privacy guides. PGP is a popular solution for encrypting, decrypting, signing, and verifying messages and files, often found in email communications and package repository identity verification (because security matters).

Most generic guides simply explain PGP at a high-level or how to encrypt and decrypt messages using specific software, and not much more than that. The goal of this introduction to PGP is to illustrate a more timeless and operational approach to using PGP safely, with respect to both information security and operational security.

Firstly, we introduce PGP theoretically and practically, this means understanding how PGP works and what we can actually do with PGP. To better understand our security stance, we assess the CIA Triad, a theoretical Information Security model, that considers the confidentiality, integrity, and availability of information. Next, we get familiar with our threat model (similar to OPSEC Model); in this step, we analyze personalized risks and threats. To mitigate any identified threats and reduce risk, we implement operational security practices.

At a more concise glance, we will discuss the following:

• PGP, OpenPGP & GPG
• Public & Private Key Pairs
• Information Security (CIA Triad)
• Confidentiality: message encryption, information storage
• Integrity: message/file authenticity, web of trust
• Availability: key servers, web of trust, metadata
• Assessing Threats & Risk
• Threat Modeling
• Operational Security
• Clients & Use Guides: Windows, Linux, Mac, Web

With that caveat in mind, let’s jump straight in.

PGP, OpenPGP & GPG: What is it?

PGP is a protocol used for encrypting, decrypting and signing messages or files using a key pair. PGP is primarily used for encrypting communications at the Application layer, typically used for one-on-one encrypted messaging. You may find yourself needing to use PGP if you want to be certain that only the intended receiver can access your private message, thwarting the efforts of intercepting parties, or if you just want to verify the sender’s identity.

There are different variations of PGP: OpenPGP, PGP and GPG, but they generally all do the same thing. Here is the quick terminology run-down:

• PGP: Pretty Good Privacy, original proprietary protocol. Released in 1991.
• OpenPGP: Pretty Good Privacy, but it is an open-source version, and it has become the universally-accepted PGP standard. Released in 1997.
• GPG: GNU Privacy Guard, another popular solution that follows OpenPGP standards. Released in 1999.

When someone says PGP, it is generally safe to assume that they are referring to the OpenPGP standard.

Public & Private Key Pairs

The usability of PGP depends on the public/private key pair encryption schematic.

Every PGP user has both a public and private key. A public key is the key that other people use to encrypt a message that only you can open. A private key is the key that allows you to decrypt the messages sent to you based on your public key, the private key can also be used to generate message and file signatures. A public key can be shared, but a private key should never-ever be shared.

You may be wondering “well, what do these messages and keys actually look like?” Let’s take a look at how public keys, private keys, encrypted messages, and signed messages appear to end-users.

Identifying Keys and Messages

Public Key (share this with anyone):

—–BEGIN PGP PUBLIC KEY BLOCK—–

Version: Keybase OpenPGP v2.0.76

Comment: https://ift.tt/1mNmK1N

xsFNBFpo9noBEACqdg1hJZ1vWg7U9iRg8O8bzk1UJnUHlFLwK7PKtQ3W5xw1Pc7R

iRQieC3J0OS78kCFPWecgPnNGocJ0L+vOyCFFgGOOWlL2B3OWsEYC3/cwrAeFGGV

[…]

Zqgeg9rJ2Rbefl3T82hX2EmZ9RQ5cce/h69BhE7FVaYPKGEvRZBxygYEAOvnb+CN

smDa/ELVNDwZr8I4VwuzuH5sT8wNTdjShiQJh8YmgYpz1/kWL4A=

=qoNC

—–END PGP PUBLIC KEY BLOCK—–

Private Key (never share this)

—–BEGIN PGP PRIVATE KEY BLOCK—–

[ … don’t ever share these contents … ]

—–END PGP PRIVATE KEY BLOCK—–

Encrypted Message (share this with intended receiver):

—–BEGIN PGP MESSAGE—–

Version: Keybase OpenPGP v2.0.76

Comment: https://ift.tt/1mNmK1N

wcBMA4dM7ocdUsXqAQf/TwDwN2/08jr/IQLIQJlmCsGIV7rUupYKmu1boNMqdth6

zBU6b+wL0tIRLxZEIsvCb+xu6MmOBBuJ5+E8YEeJHTbMPWJu42v78yw5EvEXj0XC

6oLRoMrTZ7nJ8kcBuA2tiilDedr0cf+dDOjjFVYYQN3/7SlnwHMavSMFNScFoWva

ZIFbYvgsQhTIjMtVxofqhcQuFkfuHmqShRaOb3V8cv3G8gkqBxEeyMsQfDQJ3Nd4

k3rNmFuku60NA5kRInugHdF9bXAh9o4JYAcP5L184r8hJrBdAXSNhxeHUEMIkMeQ

Umv+05H+dY5SnAEaNEAmRCXUH2yMdUlCic9NKIFgsdJAAaic7bR0VeFfycoIBAFg

8rpU+4aMnmpi3qBEsIKnK163sETWjnJ88b74VcM/GlfILIGs4vlWMA6qoGOTbCVF

dw==

=NHPA

—–END PGP MESSAGE—–

Signed Message (used for identity or integrity verification):

—–BEGIN PGP SIGNED MESSAGE—–

Hash: SHA512

This is a PGP signed message for Cypher’s AlienVault article.

—–BEGIN PGP SIGNATURE—–

Version: Keybase OpenPGP v2.0.76

Comment: https://ift.tt/1mNmK1N

wsBcBAABCgAGBQJany5gAAoJEMDU+sakHUdIphUH/RPQTUriV0w0hCJoZucy9LvO

+ib4b8n2nLjopC06Cuq6AAQnrkxuUkcz8ujrxssyeqG1zaRAB6yCpun4I7Gk4fQe

mDI7cJwZYXNgdiZ/D/44X1R54L2XuzF4xbONmuj1K1n7wYKmqe9Kf4hEdesQnnqv

hGPLMFsXJpYIXmRbJG38oC5zn0+rq672My3kCddMVv/7maAB06rqlTOB5Hmth60J

JSmWCQT3ZH8nKYxbc108lhvhUySqeicH3oV3OQLagrpAwkF4SiKhoVemlCzg6ETQ

CkgSF7FyQk14g0UYh4O9k72FyZ0tjpWgb9ab1lYW/adN3MYcuGSoC+WDyvHJzGA=

=rfws

—–END PGP SIGNATURE—–

Identifying Fingerprints & Key IDs

Every public-private key pair has an associated “fingerprint,” a unique key identifier.

A fingerprint can also be shared in Long Key ID or Short Key ID form, which are just shorter, more convenient forms of the fingerprint. Let’s look at how these look to an end-user.

Fingerprint:

A007 854D 1989 C009 270C E809 51A0 2702 86C6 8C92

Long Key ID: 64-bits of fingerprint (vulnerable to collisions):

51A0 2702 86C6 8C92

Short Key ID: 32-bits of fingerprint (very vulnerable to collisions):

86C6 8C92

Be careful when sharing shortened Key IDs since collision attacks are possible, and someone may attempt to impersonate your Key ID.

Information Security

As security-conscious individuals, we should understand what information we are sharing, how we can ensure integrity through signing and identity verification, and the confidentiality of said information. From a more administrative perspective, we also need to ensure the availability of information and operational resources.

We will examine how each of these three conditions affect one another, that is: confidentiality, integrity, and availability. These three conditions relate to the security of information and systems directly. Similarly, we consider authentication and accountability.

Confidentiality, Integrity, and Availability (CIA Triad)

In terms of Information Security, we will primarily examine how confidentiality and integrity is integrated into PGP. These terms are derived from the computer security model dubbed as the CIA Triad (Confidentiality, Integrity, and Availability), the three elements of the triad define the high-level needs of Information Security, as previously discussed. (CIA Triad, InfoSec Institute)

Examining the CIA Triad, and related PGP characteristics:

• Confidentiality: ensuring the confidentiality of information, such that only the rightful parties can examine view information
  • PGP ensures confidentiality for messages, using encryption
  • PGP ensures confidentiality for files, using encryption
• Integrity: ensuring the legitimacy and completeness of a message, such that the information can be validated as legitimate
  • PGP ensures integrity for messages, using message signing
  • PGP ensures integrity for files and software packages, also using signatures
• Availability: ensuring the accessibility of information, such that information is readily available to the appropriate parties
  • PGP ensures availability by providing a globally-sharable public key
  • PGP ensures availability with short-and-long key IDs
  • PGP ensures availability of key information for verification purposes through public key servers

On the topic of availability, there are some end-user usability issues to be conscious of:

• PGP is slow; manually encrypting and decrypting messages with a client is slow
• PGP is awkward; the fact of the matter is that PGP is awkward and clunky to use
• Due to PGP availability being awkward and slow, many people choose to not use PGP
• Despite being awkward and slow, PGP is still a universally-accepted standard for email encryption, and there aren’t really any notable encryption protocols (that I know of.)

In a realistic operational environment, we must assess the trade-offs between confidentiality, integrity, and availability. By assessing our needs and adversaries, we can create a threat model to meet our personalized circumstantial needs, we will discuss threat modeling.

Encryption vs Signing

There will be some overlap between confidentiality and integrity, so let’s clear this up:

• By encrypting a message or file, we increase the level of confidentiality
• By signing a message or file, we increase the level of integrity

We can either encrypt a message or sign a message, or we can sign and encrypt a message.

You may be pondering; how does this all actually work? How do I sign, encrypt, and decrypt my messages? How do I sign a file? How do I ensure these “confidentiality” and “integrity” conditions? Well, keep reading; next, we discuss confidentiality, integrity, and availability more in-depth along with use cases for PGP.

Confidentiality

Confidentiality is achieved when we are assured that our message is kept private, such that only the sender and receiver can read the message. In a PGP-encrypted conversation, no others can intercept the message in plaintext (provided we practice good OPSEC).

PGP allows us to encrypt/decrypt messages in the comfort of increased privacy and confidentiality, such that only the intended parties can view the messages.

Encrypting and Decrypting Messages

There are several use cases for ensuring confidentiality through encrypted messaging. For example:

• Contact page on a website, allow people to contact you privately
• Private messages on a discussion forum (normally stored in plaintext!)
• Secure email messaging (also normally stored in plaintext!)

Every PGP user has a key pair: their own private and public key. To encrypt a message, you will need the receiver’s public key, and your own private key. To decrypt a message, you will need the sender’s encrypted message and your own private key to decrypt it.

The private key is used for decrypting all PGP encrypted messages meant for you; this belongs to you, and no one else, so don’t ever share it. The public key is what you can safely give to others; this is what senders need to encrypt their message to you.

To encrypt a message:

• Using PGP software, generate an encrypted message using your private key and the receiver’s public key
  • gpg –encrypt –sign –armor -r recipient@email -r your@email.com filename

To decrypt a message:

• Using PGP software, decrypt an encrypted PGP message using your private key and the sender’s encrypted message
  • gpg myfilename

We can create either an unsigned or a signed encrypted message. Either way, the message in this context will be encrypted, it’s a matter of choosing whether we want to associate our identity with the message. By choosing to sign the message, we also choose whether to sign that message such that it is connected to our identity. The same concept applies to file encryption.

Encrypting and Decrypting Files

PGP allows us to encrypt files, such as password storage files, with your own key pair. Only people with your private key can decrypt this file.

To encrypt a file:

• Using PGP software, encrypt a file using your private key. Specify the recipient.
  • gpg –encrypt filename

To decrypt a file:

• Using PGP software, decrypt a file using your private key. Only the intended recipient will be able to decrypt this file.
  • gpg -d filename

Integrity

As previously mentioned, “integrity ensures the legitimacy and completeness of a message, such that the information can be validated as legitimate.”

Using signatures, we can cryptographically prove the integrity and ownership of a message or file. We can also verify the creator’s identity by checking the RSA key-ID associated with their PGP signature, whether it is a message or file. Additionally, a valid PGP signature almost guarantees that a message is delivered exactly as is, without the possibility of having been tampered with.

Web of Trust

A theoretically important part of the PGP design is the web of trust, a cryptographic concept used to establish how trusted a key pair is through decentralized communications and connections. This is useful for message and file integrity during signature verification, this way we can assure that we know who the signing key pair belongs to.

Wikipedia has a very good simplified explanation of the web of trust. Keybase also has an excellent example that relates to their web platform.

If you are still confused, then don’t fret; just think of the web of trust as a method to gage how trusted any particular key pair is by assessing who-knows-who. While the web of trust is theoretically important in PGP’s design, it is practically complex and annoying, so this isn’t incredibly important to understand at a practical level since no one really cares anyway.

Message and File Integrity

We may desire message integrity for any number of reasons:

• Announcements, particularly in high-profile communities with sensitive or controversial content that can influence industrial, political, or societal matters (i.e. Forums, Government)
• Source code commit security; sign Git commits with PGP key to assure that it was you who made a change

We may also desire integrity for a file for similar reasons:

• We want to verify that the files we download are legitimate and haven’t been tampered with. A MD5 or SHA signature is not enough, so we verify the packages using PGP signatures.
• On an Ubuntu or Debian based Linux system, every time you use apt-get to install software, PGP keys are used to verify file integrity

It all comes down to verifying that a piece of data is legitimate, whether it is a message or file, and has not been tampered with. Identity verification is just a bonus feature of PGP signatures.

Message Signing

To sign a message, we will need a PGP client. This process only requires you to have the recipient’s public key and your private key, as per usual.

When to sign messages

• We want to sign our message if we want our identity to be provable and tied to our message.
• We want to sign our message if want to prove that the message is incomplete and has not been tampered with.

When not to sign messages

• We do not want to sign our message if we do not want our identity to be provable or tied to our message.
• We do not want to sign our message if we do not want to expose additional personally identifiable information.

Whether or not you should sign a message can be decided with a simple question: do you want your PGP identity to be tied to your message, or no?

Unsigned Message

An unsigned message is a message without a signature, such that the sender’s identity cannot be verified.

Figure 1 — a diagram showing initial contact over PGP (unsigned)” (PGP, The Privacy Guide)

On the left, we can see how an unsigned message is encrypted. On the right, we can see how the unsigned message is decrypted.

Alice (sender):

Alice encrypts a message containing the data and her public key. Bob will need this public key to encrypt his response to Alice. The message is encrypted using Bob’s public key, such that only Bob can decrypt the message.

Bob (receiver):

Bob receives the encrypted message via email from Alice. Since the message is meant for him, Bob uses his private key to decrypt the message. Next, Alice’s original message also containing her public key is revealed.

Signed Message

A signed message is a message with a signature that can be used to verify the sender’s identity and verify that the data has not been tampered with.

“Figure 2 — a diagram showing initial contact over PGP (signed)” (PGP, The Privacy Guide)

Alice (sender)

• Alice signs the message with her private key, this way Bob can verify that Alice wrote this message with her key pair.
• Alice encrypts the signed message using Bob’s public key, this ciphertext is copy-and-pasted into the email body.
• In this case, Alice chose to include her public key in an encrypted attachment.

Bob (receiver)

• Bob receives the signed encrypted message, decrypts the signed message, and now has a readable PGP signed message in front of him.
• Bob also decrypts the attachment, revealing Alice’s public key.

File Signing

File signing ensures that our document has not been tampered with at any point, and provides a method for identity verification and integrity assurance. It is hard to deny ownership of a signed file since the cryptographic signature only implies that either you created the message or your private key has been stolen.

Signing a File:

• We need PGP software, this is conceptually like signing a message
• When we sign a file (i.e. docx, pdf, txt, etc.), a second signature file is made with the .sig filetype extension
• The new .sig file is your file’s signature. It will need to be in the same directory as the original file for verification checking
• To create and verify the signature, we will need to use a PGP client (i.e. How to Sign and Verify a Document or File using GPG on Linux)
• Provide both the original file and signature to the intended recipient; they can still use the original file, and now will have the option to verify the file

Verifying Message and File Signatures

Verifying Message Signatures

• Using PGP software, you only need a private key to verify a message signature
• Upon verification, the PGP software will either tell you that the signature is good or bad

Verifying File Signatures

• Using PGP software, you only need a private key to verify a file signature
• Upon verification, the PGP software will either tell you that the signature is good or bad

• Unlike a hash-based signature, a PGP signatures associates an identity with a file, adding the additional information:
  • Signed file name
  • Signature creation date
  • RSA key ID used to sign the file
  • File type
  • File size
  • Author’s email

• PGP signature verification is more secure than hash-based signature verification:
  • A hash signature is a one-way function, and can easily be replaced by an intruder
  • A PGP signature is tied to a PGP identity, where an identity can be proven; the private key would have to be compromised in order to sign a file with a trusted key pair as per Web of Trust

If you are a visual/audio learner and are still struggling to grasp the concept of signing and verifying messages and files, this brief video should clear up any confusion.

Availability

We previously described availability as a condition that “assures the accessibility of information, such that information is readily available to the appropriate parties.” Availability is not often discussed in PGP guides, but it is still relevant. Rather than looking at the availability of actual systems, we will consider the availability of information and keys itself.

Availability of information

• Web of trust: key information and relationships are available for analysis
• Key servers: a service that maintains a collection of public PGP keys; users have the option of uploading their keys to key servers. For operational purposes, you should not upload your keys to key servers.
• Metadata: in every email, metadata is made available for analysis. This includes the email addresses, subject line, approximate message size, etc.

Availability of keys:

• Key loss: if you lose your keys, they are no longer available to you and cannot be recovered
• Key management: manage keys in a secure manner

Assessing Threats & Risk

By understanding the risks in using PGP, we can build a threat model and practice operational security accordingly (discussed next).

15 Reasons to Not Use PGP:

SECUSHARE published an article “15 reasons not to start using PGP”. Since I feel that they had communicated some great points regarding the risks of using PGP, I briefly summarized most of their key-points for us to consider. This information will help us understand how and why we should practice good operational security during PGP-involved communications.

1. Misusage: a party may use PGP wrong or respond to an encrypted email in plaintext
2. The OpenPGP Format: PGP is noticeable during packet analysis and surveillance efforts (i.e. government dragnets)
3. Transaction Metadata: metadata reveals context and parties involved in the conversation (i.e. email address, subject line, message size, etc.)
4. No Forward Secrecy: risk of long-term keys being compromised, it is hard and even impractical to use short-term keys
5. Cryptography is Crackable: parties may store encrypted messages and could hypothetically start decrypting messages once technology advances enough to do so (i.e. using quantum computing for cracking RSA cryptography, encrypted messages may be collected and stored via dragnet surveillance, to be cracked in the future)
6. Overexposure: using surveilled services and networks will draw attention to our PGP usage, especially on centralized or cloud-hosted services that participate in surveillance
7. Discovery (Web of Trust): web of trust is publicly available information and can be analyzed for investigative/discovery purposes, and it doesn’t scale well globally
8. PGP Conflates Non-repudiation and Authentication: if a message is signed, we only know that the sender’s private key was used to sign the message, it is possible that the sender’s key could be compromised and used by a third-party (i.e. spy, espionage). Also, by signing a message, we sacrifice any plausible deniability of writing that message
9. Message Size Analysis: we can guess the size of messages based on encrypted length
10. Workflow: group messaging is impractical, PGP is used for one-on-one communication
11. Message Drafts & Message Storage: drafts of messages may be transferred or stored insecurely, in plaintext, without encryption
12. Overhead: DNS / X.509 must work harder, thus more expensive servers and networking equipment may be required at scale
13. Targeted Attacks Against PGP Key IDs: an adversary could generate a PGP key with a matching short-key ID or long-key ID, the shortened key ID could be used for impersonation
14. “I’ve got nothing to hide”: people may not want to use PGP simply because “they have nothing to hide” – this is a worthy consideration, but an invalid excuse to not care about your human right to privacy
15. Public Key Exchange: to use PGP, a public key must be shared. We must exchange public keys securely and privately in a contextually safe manner

PGP’s Attack Vectors

Let’s briefly run through some of the adversary’s potential capabilities, examining PGP as an attack vector, using the CIA Triad model.

Confidentiality Threats:

• An adversary could steal the sender’s private key and decrypt messages
• An adversary could steal the receiver’s private key and decrypt messages
• An adversary could intercept PGP encrypted messages and store them
• An adversary could intercept an email with the sender’s plaintext public key, replace the public key with their own, and intercept the anticipated response

Integrity Threats:

• An adversary could steal our private key and sign messages with our identity
• An adversary could steal a developer’s private key and legitimately sign malicious packages for mass deployment via package managers, infecting users systems at scale

Availability Threats:

• An adversary could revoke our PGP key, disrupting availability
• An adversary could create a duplicate short key ID to imitate our identity on public key servers

Threat Modeling

As operation-conscious individuals, we should take the time to understand the risks and threats associated with the confidentiality, integrity, and availability conditions of PGP. Once we have identified our risks and threats, we can develop a personalized threat model.

A threat model, also referred to as a risk model or OPSEC Model, is essentially a structured representation of all the information that affects the security of an operation. While developing a threat model, we consider the threats that adversaries could take advantage of, and we analyze the risk of any particular event occurring. When assessing a threat model, we must look at our operational activities from an adversarial perspective.

Threat models are designed in different ways, but generally the process is like this:

1. Understand the operational context and goals
2. Identify threats and risks
3. Identify mitigations to remove threats and lower risk
4. Implement mitigations
5. Maintain and revise this threat model

A basic threat model outline for PGP; yours should vary:

1. Understand the PGP technology and capabilities
   1. How does PGP work? What can I do with it?
   2. What information do PGP features reveal?
2. Identify how we will use PGP
   1. Encrypting, decrypting, signing messages and files
   2. Contact people in secrecy
3. Identify whether we will reveal our identity
   1. Yes, reveal identity
      1. Sign the message, or;
      2. Send public key, or;
      3. Reveal personally identifiable information
   2. No, don’t reveal identity
      1. Don’t sign the message, or;
      2. Don’t send public key, or;
      3. Don’t reveal personally identifiable information
4. Identify threats of using PGP (I am using the CIA Triad model, previously discussed)
   1. Confidentiality threats
   2. Integrity threats
   3. Availability threats
5. Identify risk of using PGP
   1. Assets + Threats + Vulnerabilities = Risk
6. Implement mitigations to maintain good OPSEC
   1. Good key management, secure key storage, cautious operational usage
7. Reconsider this threat model on a case-by-case basis

This threat model will help us reduce risk and mitigate threats that would otherwise negatively impact the success of our operational goals. By abiding a well-developed threat model, we can improve our operational security.

Operational Security

Operational security (OPSEC) is a safeguard process that we use in operations to mitigate threats and reduce risk. By applying good operational security practices, we can starve the adversary of information, and continue our operations securely.

The Grugq, a security researcher, says that there are generally three key things to know about using PGP safely, which I am in general agreement with:

1. “Keys — create new keys regularly and destroy old ones”
2. “Key Storage — Use a YubiKey (or any OpenPGP hardware smartcard)”
3. “Operational use — Keep the Subject line clean (it isn’t encrypted), and delete encrypted emails immediately (or periodically.) If necessary, store plaintext emails in an encrypted backup.” (The Zen of PGP, The Grugq)

Keys should be regularly changed and destroyed, stored in a safe manner, and should reveal as little identifiable information as possible. This is generically good practice; however, if we want to run the full yard and assume that we need secrecy, then there is more that we can do.

The Grugq created another article, Operational PGP, explaining how to use PGP safely in an operational context, for the sake of good OPSEC. A variety of factors are considered for OPSEC purposes: metadata, key exchange, key alerts, writing, drafting, composition, attachments, sending, and lastly, receiving. If your goal is to operate in secrecy, then I highly recommend reading his article.

To illustrate how to use PGP in an operationally secure manner while maintaining secrecy, we outline the points made in the Operational PGP article:

• Metadata: a PGP-encrypted email still exposes revealing metadata information that we must be conscious of:
  • Examples: subject, to (receiver), from (sender), dates, times, IP addresses, and sometimes the email application used
• Safer Keys: manage and share keys safely
  • Avoid key loss with “better” key management practices
  • Use more keys for shorter times
  • Do not publish your keys to keyservers
  • Have a plausibly “deniable key exchange” plan
• Compromised Key Alerts: public alert alerting if your key has been compromised)
• Writing: every message must be written, write and store messages in a secure environment
  • Ensure a safe method of writing (ie. text editor, write on local system)
  • Encrypt on the command line
  • Only expose already-encrypted data to the email client
• Drafts: store and handle message drafts securely
  • Do not save message drafts in plaintext
• Composition: quote only the necessary information when replying, less is better
• Attachments: use PGP to encrypt your attachments
  • gpg-zip is a program that can combine the functionality of tar and gpg to “send [attachments] as an opaque encrypted blob”
• Encrypting:
  • Stop PGP from storing extra information about decryption keys in metadata (ie. use –throw-keys with gpg)
  • Use PGP/MIME instead of PGP Inline (what… why?)
• Sending:
  • Set email client to encrypt by default
  • Sign messages explicitly; signing verifies the identity of the sender, which isn’t what we always want
  • Store sent messages locally, and delete them once they are no longer operationally useful
• Receiving:
  • Delete messages once they are no longer operationally useful
  • Set “Trash” to erase things after a set time, “just in case”
• Outreach:
  • Remind your cooperatives/correspondents to preferably use PGP

Client Recommendations                                          

To use PGP, we either need a software client on our local system, or we must use a trusted Web client such as Keybase. This client is what you will use to encrypt and decrypt messages. The clients below are recommended because they are the most popular PGP client solutions as of this writing.

Windows Client

• Client: Gpg4win (Kleopatra)
• Tutorial: https://www.deepdotweb.com/2015/02/21/pgp-tutorial-for-windows-kleopatra-gpg4win/

Linux Client

• Client: GnuPG (GPG)
• Tutorial (or just use `man gpg`): https://hashrocket.com/blog/posts/encryption-with-gpg-a-story-really-a-tutorial

Mac Client

• Client: GPG Suite
• Tutorial: https://www.deepdotweb.com/2015/02/20/pgp-tutorial-os-x/

Web Client

• Client: Keybase         
• Tutorial: Keybase’s website is straight-forward and self-explanatory

Conclusion

PGP is ideal for the sheer fact that so many people use email and it is one of the best solutions available, despite not being perfect. For instant messaging, it may even be better to use XMPP with OTR encryption.

PGP can be used for encrypting, decrypting and signing messages and files. We can use command flags and carefully craft our messages to mitigate unnecessary information sharing. Less information is better; we should do what we can to limit the accessibility of our keys and identity on a need-to-know basis.

To use PGP safely, we should have clear operational goals, understand the protocol itself, know our personalized threats and risk, build a threat model, and practice operational security accordingly. It can be easy to “mess up” when it comes to operational security, PGP rollout should be done with caution.

      

The post Explain PGP Encryption: An Operational Introduction appeared first on Cybersecurity Insiders.

March 26, 2018 at 09:10PM

Posted in: Cyber Security, Cybersecurity Insiders, Hacking, Hacking Articles, Hacking News, Security