Note: session encryption as described in this page is not implemented yet

Echo protocol and Session encryption

One of the problems of TOFU is that the first message has to go unprotected. To protect all payload (including the primary one) there are protocols needed, which provide the guarantee that even the first payload goes protected.

The p≡p Echo protocol initiates the first message with empty payload. Such a message is called a “ping”. The answer to this message is called “pong”.

The p≡p Session encryption is providing encryption before a secure channel exists to a communication partner, so in case the first message cannot be a “ping” there’s an alternative without this problem.

Echo protocol

The p≡p Echo protocol is quite easy: a ping message is being sent when the p≡p engine must assume that communication of the own user with a new communication partner will happen soon. This ping message and the answering pong implement the TOFU handshake before the first user message is to be sent out.

The p≡p engine assumes that if the app calls outgoing_message_rating() with an unknown addressee’s identity then a ping is necessary if it can be expected that this will be a p≡p user, too. For transports with all p≡p users that is given. For transports with mixed users there must be criteria like address matching with a Media Key pattern to decide if this is expected to be a p≡p user.

The p≡p engine assumes that if decrypt_message() is called with multiple identities in To: and/or CC:, and the message is protected, then unknown addressees’ identities will get a ping, because a group reply is likely to happen.

Privacy issues

The p≡p echo protocol leaks privacy in offline transports, because it is possible to test when a communication partner is online. Therefore, it is possible to switch it on or off.

p≡p session encryption [note: this is not implemented yet]

The p≡p session encryption depends on p≡p echo protocol. It is based on the ideas of the p≡p Reader of p≡p security.

When encrypt_message() is being called and some identities in To: and/or CC: do not have a default key, which leads to a secure channel, then a session key is created for each communication partner without a default key leading to a secure channel, respectively. The message is then encrypted with these session keys additionally to the default keys of the other communication partners. The session key is stored with the identity, where it’s for, respectively.

When the p≡p engine of the receiving communication partner detects that the message, which is coming from a communication partner is without secure channel and cannot be decrypted, it sends a ping back to the identity in From:

The p≡p engine of the original sender then receives the ping and has a secure channel, sending a pong back attaching the missing session key, so the receiving communication partner can later decrypt the message and import the session key out of a secure channel.

The rating of such a decryptable message goes unreliable on the receiving side while yellow on the sending side by default for a limited number of messages (default: 3). If the message contains a claim for using a matching session key and the sender key authentication is valid then the rating goes reliable on the receiving side as well. That is why the p≡p engine of the sending side adds a claim for all used session keys to the opt_fields of the inner message.

Like with the p≡p echo protocol in case of outgoing_message_rating() for offline transports with mixed users the p≡p engine only creates a session key if there is evidence that the communication partner likely is a p≡p user. This is the case if the communication partner’s address matches a pattern for a Media Key.

The format of the session key claims as part of the opt_fields is:

[("pEp-session-fpr", "1233456677"), ("pEp-session-fpr", "987654332"), ...]

Because a session key is a shared secret between two communication partners the rating of “reliable” risks that one of the communication partners compromises the shared secret and the other does not get aware of this. Therefore, a receiver accepts a limited number of messages with a session key from one communication partner (default: 3). If this number is exceeded then the rating on the receiving side stays unreliable until there is a secure channel established to the sending communication partner.


Because the p≡p session encryption is derived from the p≡p Reader protocol it can be used for advertising the usage of p≡p the same way the concept of the p≡p Reader works. In this case the p≡p session encryption is configured to send to other users than p≡p users, too.