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 wants to make encryption simple and invisible to the user. At p≡p privacy always takes precedence over security. Example: A public key server is secure but does not provide privacy, so p≡p does not support the concept and distributes public keys directly.
To achieve this, p≡p introduces new processes and data formats that are used for p≡p to p≡p communications. p≡p always encrypts and signs all its messages. p≡p is not OpenPGP, but uses keys in the OpenPGP format.
In order to support all users, p≡p has also implemented an OpenPGP mode which supports and automates OpenPGP standards as much as possible when the other party is an OpenPGP user.
p≡p also always ranks the security of communication by analyzing crypto-algorithms, key length, key validity, signatures, etc., and based on this, creates a privacy status rating represented in easily recognizable green/yellow/red symbols.
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.
When two p≡p users send messages between each other, the very first message is not encrypted. From the second message onwards, all communication is encrypted.
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:
- No Color (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 a message will be sent or has been received unencrypted. This represents the most common situation today. Unreliable Security means that a message has been received with unreliable encryption or an unreliable signature.
- Yellow (Secure)
The communication is encrypted and signed 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 and signed using state-of-the-art technology and your communication partner is verified and trusted. Trust is confirmed with a handshake 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 cryptographic error occurred. The communication channel must be considered unsecure and any exchanged information not private.
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).
By default, p≡p shows 5 Trustwords. This ensures at least 64 bits of entropy. For additional security, you can expand to 10 Trustwords, which results in at least 128 bits of entropy. More information can be found here: https://tools.ietf.org/html/draft-marques-pep-handshake-04#section-3.1.1
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:
The Trustwords are displayed in the same order for both communication partners in their native languages. The users need to make sure that they both display the Trustwords in the same language (Trustwords in another language are completely different and are not translated). If the communication partner uses PGP, the PGP fingerprint is shown as well. The handshake dialog, then offers two options:
‘Confirm’ button: If the communication partner has the same Trustwords, then the user presses the ‘Confirm’ button to confirm them and from then on all email exchanged with this communication partner will be Green (Secure & Trusted) and there will be no known attack on that communication anymore.
‘Reject’ 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). In case you selected ‘Reject’ by mistake, you need to perform a ‘Reset’ for this communication partner. Before you can do another Handshake, your communication partner needs to send you a message.
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:
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).
Within enterprise environments, the trust created by the handshake, can be automatically rolled out to all employees. This makes the handshake between employees superfluous.
Before using p≡p Sync make sure your devices are using the correct time and date. In case time and date differ significantly, you might run into issues with synchronisation.
When using p≡p on two or more devices at the same time and the devices have at least one email account in common, p≡p will automatically start a sync process between the devices. This ensures that you can read encrypted messages on all your devices. If multiple devices use the same email account, the p≡p Sync wizard will appear on all devices. It looks like this:
On the second screen of the wizard you will see Trustwords.
If the Trustwords match on both devices, you can confirm. This will create a p≡p Device Group. The following dialog disappears automatically during the p≡p Sync process and disappear automatically after the p≡p Device Group has been created.
All devices within the device group sync data in the background automatically. At the moment p≡p Sync is only syncing private keys. In future versions Trust (to ensure you see the same Privacy Status across all your devices) and configuration will be synced as well.
p≡p Sync works fully peer-to-peer and data is not sent anywhere else than your own email account. The communication between the devices is encrypted.
p≡p Sync Messages are coming as attachments in p≡p messages. All such p≡p messages have their sender and the recipient same - it’s the owner of the email account.
Once your device group is created (between two devices), you can add more devices at any time. Just make sure p≡p is running on one of the existing devices and on the new device (that has the same account configured). The p≡p Sync wizard will show up automatically after a few seconds and you can repeat the steps above.
Please note that once your device is added to Device Group and afterwards p≡p Sync is disabled, the device will no longer be part of the Device Group and you’ll have to group devices again when you enable p≡p Sync. After p≡p Sync is disabled on one device, the other devices get informed and will generate new keys so that device with disabled p≡p Sync cannot read new mails anymore. Also the device, where p≡p Sync has been disabled, creates new keys.
There are two types of resets available. You can do a reset for a communication partner. In this case, your p≡p deletes all encryption information it has about a communication partner (keys and trust status). You can also do a reset for your own account(s). In this case p≡p revokes your existing keys and generates new keys.
Usually, a Reset is needed in one of the following situations:
Your communication partner cannot read your messages¶
Should you get into the situation where your communication partner cannot read your messages (Privacy Status “Cannot Decrypt”), you need to reset p≡p for your communication partner (this might happen if your communication partner uses new keys, e.g. because a new device is being used and it hasn’t been synced with the old one).
One way to do this is create a new message for your communication partner, enter the email address in the To field and click the Privacy Status icon. Then, click the “Reset” button.
If the communication between you and your communication partner has been Secure & Trusted (green), you will have to do another Handshake after the reset.
You cannot read messages from your communication partner¶
Should you get into the situation where you cannot read messages from your communication partner (Privacy Status “Cannot Decrypt”), ask your communication partner to do a reset for your contact as described in the previous section.
If the communication between you and your communication partner has been Secure & Trusted (green), you will have to do another Handshake after the reset.
Somebody (potentially) got access to your keys¶
If you lost one of your devices, a potential attacker might get access to your keys (e.g. because the hard disk wasn’t encrypted or a weak password has been used). Somebody with access to your keys could send messages in your name and read your encrypted messages. Therefore you should change your key. This can be done by doing a reset for your own identity.
The best way to do this is to reset your own identity on another device within your device group (e.g. when you have a laptop and phone and your phone gets stolen, you can do the reset on your laptop. Go to File -> p≡p -> Accounts -> Reset All Accounts). When you do a reset of your own identity, your 20 most recent communication partners will automatically receive your new keys.
After you do a reset and send a message to your communication partner, they will receive encrypted messages as Secure (yellow) and not Secure and Trusted (green). You need to re-verify your identity by doing a handshake. This is because the attacker could also do a reset of your own identity in case the attacker is able to access your device.
By default, p≡p will attach your public key to all outgoing messages (Passive Mode disabled). Therefore, communication partners without p≡p will see an attachment called “pEpKey.asc” in all messages received from you.
The Passive Mode is disabled by default, which allows encrypted communication from the second e-mail (the reply from the communication partner).
If you enable 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. As a consequence, the first 2 messages between two communication partners will be unencrypted (instead of only the first message when Passive Mode is disabled).
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.
This can be useful if the communication partner is on the road without their devices and, exceptionally, can only view their e-mails on a public computer in the Internet-shop.
The user can do this by clicking on the Privacy Status icon and selecting ‘Disable Protection’.
Store messages securely¶
p≡p offers to save encrypted messages on the mail server either encrypted or unencrypted. 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 never 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).
By default, encrypted messages are not decrypted, except for mail servers with a local IP address (see next 2 sections).
Store messages encrypted (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 the next section, are “Untrusted”.
Drafts are saved encrypted in the draft folder of the mailbox and synced between devices.
Store messages unencrypted (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.
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.255.255.255 (10/8 prefix)
172.31.255.255 (172.16/12 prefix)
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.
Changing Server Trust¶
Changing the server trust is possible at any time. It generally only affects new messages and existing messages which are re-opened.
Changing from trusted to untrusted 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 untrusted to trusted 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 p≡p client, it will be stored decrypted on the server.
The mail content will afterwards not be modified again since it is already decrypted.
Sending a message to multiple people with different Privacy Statuses¶
When sending a message to more than one person, you simply add the recipients to the message. The Privacy Status icon at the top will show you, if the message will be sent encrypted (yellow or green icon) or not (no icon).
In case there was no prior communication with one of the recipients using p≡p client or there is no key stored for one of the recipients, the message will NOT be encrypted to any of the recipients in CC/BCC.
With Extra Keys an organization can ensure that all messages can be read with a key owned by the company (e.g. CISO or similar), even if the key of a user is not available. All outgoing messages are additionally encrypted with the defined Extra Keys. If p≡p is configured to store messages encrypted on the server, all encrypted incoming messages that are read by the user are re-encrypted with the defined Extra Keys. An Extra Key is a normal OpenPGP key, that is identified by its 40-digit fingerprint. It is possible to define one or more Extra Keys. The public key part of the Extra Keys needs to be deployed on all systems that use that Extra Key.
The p≡p Proxy uses Extra Keys to decrypt messages anywhere in the mail flow of an organization. This allows to scan emails, e.g. for Antivirus (AV) or Data Loss Prevention (DLP).
p≡p automatically handles all aspects of key and identity management. This section outlines some main areas concerning this topic.
p≡p automatically detects your accounts and will generate keys for you. The key generation is done completely in the background without user intervention. It is possible to import your existing keys. Be aware, that your p≡p automates the key management and therefore your key might change anytime (e.g. if you reset your account or if you sync multiple devices). Keys are valid for 1-3 years by default.
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.
Import of Keys¶
Any public key attached to incoming messages will be imported and used automatically (trust on first use). If a private key is attached to in incoming email, p≡p will import it as well and use it to decrypt messages. However, it will not use the key to encrypt outgoing messages.
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¶
By default, p≡p creates keys without a passphrase. p≡p suggests not use use a passphrase for the following reasons:
A passphrase has a negative impact on user experience, as a user would have to enter a passphrase on a regular basis (e.g. every time the application is opened).
A passphrase protects only the key. Instead, p≡p suggests to encrypt the entire disk, which not only protects the key, but also the data.
A passphrase does not significantly enhance security for keys on the local device. If an attacker is able to access the device of the user to get the private key, it is likely that the attacker could also install a key logger and get the passphrase when the user enters the passphrase.
Since version 1.1.200, p≡p supports a passphrase. It is possible to import a key pair with a passphrase. Alternatively, you can enable “Use a passphrase for new keys”. Once enabled, p≡p will ask for a passphrase when new keys are generated. If you want to create new keys straight away, go to the p≡p Account settings and “Reset All Identities”.
Backup of private keys¶
p≡p does support backup keys on multiple devices over p≡p Sync feature. Simply adding new device to your Device Group will backup all existing private keys on every of your device so you can read old encrypted emails on any of them.
Protect message subject¶
p≡p clients have option to protect the subject of the email. The behaviour is as described in the following section:
The subject is always encrypted in transport and when storing messages on the server for all encrypted messages.
In communication between two p≡p clients, subject of the email is always encrypted in the transport, but if messages are stored encrypted on the server (Untrusted server), the subject is decrypted and stored unprotected on the server if p≡p for Outlook is used.
In communication between p≡p and PGP clients, subject of the email is not encrypted.
Subject protection is enabled by default for all p≡p clients.
As described in 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 recipient’s server, even if the recipient decided to trust their own server. Note that this will only work if the recipient uses a client compatible with this feature.
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.
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.
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. When 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.
For organizations, the p≡p Proxy can be used to decrypt messages anywhere in the mail flow based on Extra Keys. This allows to scan emails, e.g. for Anti Virus (AV) or Data Loss Prevention (DLP).