General Information

This section explains concepts that are important to understand the general functionality of p≡p. Subsequent sections will assume the reader is familiar with this information.

The p≡p concept

p≡p works fully automatic and is easy to use. For encryption p≡p locally analyzes (no data is sent anywhere) the incoming and outgoing e-mails on your device. Once p≡p recognizes that it can protect communication with the communication partner, it will do so automatically. The users will never have to handle the keys. The workflow below shows how p≡p works conceptually. It outlines p≡p’s design & function between p≡p users as well as between p≡p and PGP users.

_images/conceptualpEp.png

Privacy Status

To indicate the security level in place for a given communication situation, p≡p uses traffic lights semantics to distinctly display the Privacy Status to the user. Following Privacy Statuses are possible:

  • Gray (Unknown/Unsecure/Unreliable Security)
    Unknown is commonly used for outgoing messages where no contact or address has yet been added to the To, Cc or Bcc fields of an email or message. Unsecure means that p≡p cannot find a way of sending or receiving the communication with any form of encryption. This represents the most common situation today. Unreliable means that p≡p cannot find a way of sending or receiving the communication reliably. So, for example, the communication could have been sent using S/MIME. With S/MIME it’s known that if one public Certificate Authority (CA) is subverted then the security of the entire system is lost — potentially subverting all the entities that trust the compromised CA.
  • Yellow (Secure)
    The communication is encrypted using state-of-the-art technology. However, your communication partner still needs to be trusted by completing a handshake in order to verify partner’s identity.
  • Green (Secure & Trusted)
    The communication is encrypted using state-of-the-art technology and your communication partner is trusted. Trust is confirmed with a handshake where, using a side-channel (e. g. by phone call), communication partners verify they are each who they say they are and the communication can be fully trusted by all reasonable means expected from a regular user.
  • Red (Mistrusted/Under Attack)
    Mistrusted means that a previous handshake failed. You cannot trust that your communication partner is who they say they are. Under Attack means that either a man-in-the-middle (MITM) attack must be assumed or another (serious) cryptographic error occurred. The communication channel must be considered unsecure and any exchanged information not private.

Trustwords

Trustwords are used to achieve easy contact verification. In p≡p they replace the fingerprints known from PGP. To ensure that there is no man-in-the-middle (MITM) attack on the communication channel, Trustwords need to be compared between two communication partners in a Handshake. Trustwords are common words in a natural language (e.g., English), for example, CAR HORSE BATTERY STAPLE APPLE. After comparing Trustwords between two communication partners, the communication between to partners is not only secure (encrypted), but also trusted (no man-in-the-middle attack).

Handshake

In order to make communication with a partner Secure & Trusted (instead of only Secure), a handshake is required. This is to verify, that the communication between you and your communication partner happens between and only between the two of you and therefore is trusted, meaning there is no man-in-the-middle attack happening.

A handshake is done by comparing the Trustwords between two users through a separate communication channel (e.g. in person or by phone). Both users open the Handshake dialog by pressing on the Privacy Status in a message between them. This is how the handshake dialog looks in p≡p for Outlook:

_images/pEpForOutlook-v1.0.200-ComposeHandshakeYellowFront.png

The Trustwords are displayed in the same order for both communication partners in their native languages. If the communication partner uses PGP, the PGP fingerprint is shown as well. The handshake dialog, then offers two options:

  • ‘Confirm Trustwords’ button: If the communication partner has the same Trustwords, then the user presses the ‘Confirm Trustwords’ button to confirm them and from then on all email exchanges with this communication partner will be Green (Secure & Trusted) and there will be no known attack on that communication anymore. This step is done once with each communication partner and any future communication remains Green (Secure & Trusted).
  • ‘Wrong Trustwords’ button: The user presses this option, if the Trustwords given by the communication partner do not match those shown on the screen. As a result, the rating for the communication partner is downgraded from Yellow (Secure) to Red (Mistrusted). After you selected ‘Wrong Trustwords’ for a communication partner, you cannot undo this.

After a successful handshake, the Privacy Status of the message changes to Green (Secure & Trusted). This is how the message looks now in p≡p for Outlook:

_images/pEpForOutlook-v1.0.200-ComposeSecureTrustedGreen.png

A handshake needs to be done once between two communication partners. All messages you receive from and send to the same communication partner, will show the new Privacy Status Green (Secure & Trusted).

Passive Mode

By default, p≡p will attach the public key of your own identity to all outgoing messages. If you set p≡p to passive mode, it will by default not attach the public key to outgoing messages anymore. Only if p≡p detects that your communication partner has p≡p installed as well, it will attach the public key.

Disable Protection

When composing a message p≡p will show you the Privacy Status of the message. If the Privacy Status is yellow or green, you have the option to disable protection for this specific message. This means that p≡p will send the message unencrypted.

Server Trust (store messages securely)

If the user does not trust the mail server (e.g. because it is a cloud mail provider), then p≡p can store the messages securely (encrypted) on the server. This only applies to messages that have been sent or received encrypted. If a message is sent or received unencrypted, it will not be encrypted on the server.

On the other hand, if the user trusts the server (e.g. when the mail server is hosted on premise), then the user may select to store messages decrypted on a server. In that case, p≡p will decrypt all the encrypted messages and save them unencrypted on the server.

In p≡p for Outlook, if the option “Store messages securely for all accounts” is selected, p≡p will not decrypt messages for any of the accounts. If this option is disabled, the user has the option to change the setting on a per account basis (uncheck “Store messages securely” for any of the listed accounts).

Trusted server

Generally, if a user trusts a server, the data can be saved unencrypted on it. By default, servers with an IP listed in RFC1918 and Unique Local Addresses, are configured as “Trusted”. If a server is configured by using a DNS name (DNS A, AAAA and CNAME RRs), which ONLY resolves to RFC1918 and/or Unique Local Addresses, it is configured as Trusted. All others are Untrusted by default. Drafts are saved unencrypted to the draft folder of the mailbox. “Store Protected” messages are saved encrypted in the draft folder.

The implementation follows the definitions from RFC 1918 (https://tools.ietf.org/html/rfc1918) for IPv4 and RFC 4193 for IPv6 (https://tools.ietf.org/html/rfc4193).

Private IPv6 addresses are defined as having a FC00::/7 prefix. This block is divided into the two blocks fc00::/8 and fd00::/8.

Private IPv4 addresses are the following:

The Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private internets:

10.0.0.0 10.255.255.255 (10/8 prefix)
172.16.0.0 172.31.255.255 (172.16/12 prefix)
192.168.0.0 192.168.255.255 (192.168/16 prefix)

All servers with IP addresses defined by RFC 1918 for IPv4 and RFC 4193 for IPv6 are therefore trusted.

Trusted server is supported for mailboxes that are connected through Exchange and IMAP. It is not supported for EAS.

Keep the following things in mind for trusted servers:

  • Original mail item is completely overwritten with decrypted contents.
  • Color rating and decryption keys are saved to the mail item itself.
  • This means all the above information is then synced back with the server where possible.
  • Every time the mail item is opened, the original color rating is read back from the mail item itself (not recalculated).

Untrusted server

If a user does not trust a server, encrypted messages will not be saved unencrypted on the server. By default, servers with an IP address NOT mentioned in previous section, are “Untrusted”. Drafts are saved encrypted in the draft folder of the mailbox and synced between devices.

Keep the following things in mind for trusted servers:

  • Original mail item is NOT modified, decrypted contents are stored in a separate mail item (mirror) in the pEp store.
  • Color rating and decryption keys are saved to the mirror.
  • The unencrypted information and rating/keys are never synced back to the server.
  • Every time the mail item is opened, the color rating is calculated again. This can be done since the original mail item still exists. It will capture any changes to partner identity trust since the email was first received.

Changing Server Trust

Changing the server trust is possible at any time. Changing the trust generally only applies for new messages. Changing from a trusted to an untrusted server, will also change the privacy status of existing messages.

Changing from untrusted to trusted server

  • When changing from a trusted server to an untrusted server, existing messages on the server, that already have been decrypted, will NOT be encrypted again.
  • The privacy status of existing messages will not be changed.

Changing from trusted to untrusted server

  • When changing from an untrusted server to a trusted server, existing messages on the server will remain encrypted. Only if a message is opened in the local email client, it will also be decrypted on the server.
  • The mail item will be unmodified since it was already decrypted. Due to this, it would simply be detected that the message is unencrypted and displayed as such. As the server is now untrusted, also the privacy status of the message in not Secure or Secure & Trusted anymore.

Extra Keys

With extra keys an organization can ensure that all messages can be read with a company key, in case a key of a user is not available anymore. All outgoing messages are additionally encrypted with the defined extra keys. All incoming messages are re-encrypted with the defined extra keys. Each key is identified by its 40-digit fingerprint. Multiple keys can be specified by entering multiple fingerprints delimited by commas ‘,’.

Key Management

p≡p (specifically the p≡p Engine) automatically handles all aspects of key and identity management. This section outlines some main areas concerning this topic.

In order to encrypt and decrypt messages, p≡p uses keys. Keys are automatically generated when p≡p is setup on a devices. It is only possible to decrypt messages, when the required keys are available. If you are using only one device (e.g. a desktop computer with p≡p for Outlook) all the required keys have been created on that device. Therefore, this device is able to decrypt protected messages you receive from other communication partners.

However, many users use more than one device. For example, they also use a smartphone with p≡p for Android. After setting up p≡p on your second device, you will notice that p≡p cannot decrypt existing messages. This is because the required key is missing. In order to be able to decrypt messages on the new device, it is required to import keys.

Importing keys on a p≡p device from another system using p≡p is very simple. However, keep the following points in mind: * Always start the key import on your new device. For example, if you have been using p≡p for Outlook in the past and just installed p≡p on your Android phone, start the key import process on your Android phone. * A key import is needed for each email address. Even if you have the same two email addresses setup on both your devices, a key import is needed for each email address.

If you start the key import on your new device, it will receive the keys from your existing device and also use these keys for all future communication. Additionally, your new device will also share its key with your existing device. This is to make sure you can decrypt all messages on your existing device as well.

Keep in mind, that key import is currently only working between two devices. If you want to use a third device, do the following:

  1. Switch of your second device (or make sure it is not connected to the internet)
  2. Start the key import on your newest (third) device
  3. Follow the instructions on the screen of the first device
  4. After the key import is finished on the first and second device, you can start/reconnect your second device.

You find the exact description how key import works in the product specific pages.

p≡p automatically detects your identity and will generate a private key for you if you don’t’ already have one. This key generation is done completely in the background without user intervention. If you don’t want to use the generated key, it’s possible to override this and use whatever private key you give that matches your email address. This can be done even after a key is already generated.

When p≡p detects a generated key is about to expire, it will generate a new key or extend the validity of the existing key. The new or changed key will be distributed to communication partners by attaching it to outgoing messages. This will automatically keep messages encrypted between communication partners without user intervention.

Any attached public key to incoming messages will be imported and used automatically. Note that private keys are handled differently.

Use Existing Private Key

Users who wish to use their own private key instead of one automatically generated by p≡p can do so. Please refer to the specific product section to see how you can import existing private keys.

Key with passphrase

p≡p for Outlook does support Keys with passphrases, p≡p for Android doesn’t. When you’ll use private key with passphrase p≡p for Outlook will ask you on a regular basis to enter the passphrase. If you want to cache the passphrase, you can do it. Just follow these steps:

In Windows Explorer go to %appdata%/gnupg/ and create a file gpg-agent.conf (on some systems, this may already exist).

Then, open the file gpg-agent.conf. There are two options, that you probably want to add:

Set the time a cache entry is valid to n seconds. The default is 600 seconds. Each time a cache entry is accessed, the entry’s timer is reset. To set an entry’s maximum lifetime, use max-cache-ttl.

default-cache-ttl n

Set the time a cache entry is valid to n seconds. The default is 600 seconds. Each time a cache entry is accessed, the entry’s timer is reset. To set an entry’s maximum lifetime, use max-cache-ttl.

max-cache-ttl n

n stands for the number of seconds. You can change this to any value you like. 86400 seconds is 24 hours. Keep in mind, that you always have to enter the passphrase after you logoff or restart your computer.

For more information, please consult https://www.gnupg.org/documentation/manuals/gnupg/Agent-Options.html.

Backup keys

p≡p does not support backup keys on Android nor iOS in its first release. Backup keys is possible only on Windows versions of p≡p at the moment. Windows version is using standard Gpg4win keyring and you can export it through GNU Privacy Assistant. More details in Outlook section.

Export private keys from Enigmail

Exporting private keys from Enigmail on any OS is simple. Open your Key Management from Enigmail menu, select File → Export Keys to File, make sure you included the secret key, then store the file in a safe place so it can be use for import to p≡p.

Export private keys from GNU Privacy Guard

Since the majority of PGP users are using GnuPG suite ( https://gnupg.org/ ), we are publishing quick tips how to export your private key from GPG so it can be used for import to p≡p:

Windows

After installation of p≡p for Outlook, The GNU Privacy Assistant (GPA) , which is a graphical user interface for the GnuPG (GNU Privacy Guard), is installed. Simply search for “GPA” in Windows and after opening, you will find a window which lists your private/public keys. Select the ones you want to export and click on the Export button.

Linux

When you are using standard GPG installation, simply open your CLI (command line interface) and write following command:

gpg --export-secret-keys -a name@domain.tld > secret-key.asc

It will create secret-key.asc in your current working directory. Don’t forget to change name@domain.tld for your email account!

Mac OS X When default installation from https://gpgtools.org is used, you will have “GPG Keychain” in your Application folder. After opening of GPG Keychain, you will see all your public and private keys (marked in bold) in the window. Select the ones you want to export and click on Export. Don’t forget to check the “Include secret key in exported file” option when saving the key/s.

_images/gka-key-list.png

Remove passphrase from private key

At the moment, p≡p for Android does not support passphrases for private keys. Therefore you have to remove the passphrase before you send the private key to your Android device.

We strongly advise to only save private keys without passphrases on devices that are encrypted.

Start editing key Windows

First, open the command line (cmd.exe). Depending if you have a 32 bit or 64 bit system, you have to change to a different directory:

For 32 bit systems:

cd "C:\Program Files\GNU\GnuPG"`

For 64 bit systems:

cd "C:\Program Files (x86)\GNU\GnuPG"`

To start editing the key, enter the following command:

gpg2.exe --edit-key name@domain.tld

Don’t forget to change name@domain.tld for your email account!

Follow the instructions in section “Remove passphrase (Mac OS X, Linux and Windows)”

Start editing key Mac OS X and Linux

Open a CLI and enter the following command:

gpg --edit-key name@domain.tld

Don’t forget to change name@domain.tld for your email account!

Follow the instructions in the next section.

Remove passphrase (Mac OS X, Linux and Windows)

Now you can enter the following commands to remove the passphrase:

gpg> passwd

Enter your existing passphrase in the window that opens.

Then, in the window for the new passphrase, leave the field blank and press OK. A warning appears. Choose “Take this one anyway”.

In the next window, click “Yes, protection is not needed”

You are again prompted with a passphrase window. Leave it blank and press OK.

On the command line, confirm the question “Do you really want to do this?” with “y” (yes).

To save the changes, enter the following command:

gpg> save

This is it. Your private key doesn’t have a passphrase anymore.

Key Server

p≡p doesn’t use PGP key servers by default. There are several reasons for this. The frist reason is, that everyone can upload keys to a key server. There is no validation, if an uploaded key really belongs to the person, he claims to be. Therefore you cannot trust the keys you receive from key servers. Second, key servers are also a privacy issue. At least the operator of the key server can see with whom you communicate, because you have to look up keys from the key server.

Further, it is not possible to black list keys in the Beta version of p≡p for Android. This means, after a wrong key is imported, you cannot remove it from your key ring anymore. In future versions of p≡p for Android, the feature will be there. In p≡p for Outlook, black listing keys is already possible.

p≡p uses a different concept: The public key is attached to each email sent. If the other contact has p≡p has well, the public key will be imported automatically and the response is already encrypted. If the other user doesn’t use p≡p, but another OpenPGP compatible solution (e.g. Apple Mail) he has to import the public key manually.

If you want to use key servers anyway, you can enable the “Lookup keys on key server” option in the p≡p options.

Show a warning when a message loses security through reply or forward

When a formerly encrypted message would be sent unencrypted by replying or forwarding, a warning message appears. This option is enabled by default.

Store protected

As described in Server Trust (store messages securely) some users might decide to trust the server, meaning a message will be decrypted and saved on a trusted server unencrypted. As a sender, you have the option to flag a message as “store protected”. Messages with this flag will be stored encrypted on the server, even if the recipient decided to trust it.

Enable p≡p privacy protection

By default, p≡p privacy protection is enabled and all outgoing messages will be encrypted whenever possible. If p≡p privacy protection is disabled, outgoing messages will not be encrypted. It will by default still decrypt incoming messages. However, the user has the option to also disable “Continue to decrypt messages”. In that case, incoming messages that are encrypted, will not be decrypted and are therefore unreadable. The p≡p privacy protection settings can be changed on a per account basis.

Spam

p≡p has a positive impact on spam. While spamers can still send you spam unencrypted, it makes it much more difficult for them to send you spam encrypted. First, because a spamer has to get your public key in addition to the email address. Because p≡p doesn’t upload your public key to a key server, it is difficult for a spamer to collect a large number of public keys. But even if a spamer has a large number of public keys, it takes much more resources to send emails encrypted, because it has to be encrypted for every single recipient. When a spamer wants to send millions of emails, it will take much longer compared to unencrypted emails.

Antivirus

The goal of using p≡p is to keep your communication private by ideally sending all messages encrypted. While a message is encrypted, it is not possible for an antivirus solution to detect viruses. Viruses will only be detected, after the message has been decrypted. If you scan encrypted messages, your antivirus solution will just not find any virus. Most antivirus solutions installed on the local computer (e.g. Windows Defender) will detect viruses just after the decryption of an email. Before you can open an infected message, you will get a warning of your antivirus solution. Just like before you started using p≡p. So even when you send and receive encrypted messages, you don’t have to worry about viruses as long as you use some up to date antivirus software. However, if your provider is scanning incoming (and maybe also outgoing) messages, it won’t be able to detect viruses. Your messages are encrypted, so only you and your communication partner can read it. Therefore, antivirus gateways won’t work anymore for encrypted messages.