Usually, asymmetric or a combination of asymmetric and symmetric encryption methods are used for secure message exchange. The advantage of asymmetric encryption methods is that messages can be encrypted with the known public key and can then only be decrypted by the owner of the private key. The private key cannot be determined from the public key within a reasonable time. However, asymmetric encryption methods are more computationally intensive and therefore more time-consuming than symmetric encryption methods. For this reason, a combination of both methods can be used to first exchange a symmetric key using asymmetric encryption. This ensures that only the two parties are aware of the symmetric key, which can then be used for symmetric encryption of the communication.

Tweets are usually posted publicly on Twitter. Only those who explicitly set their profile to "private" can decide who they allow as followers and thus recipients of their tweets. This type of publication and visibility should also apply to private networks. Since it is unclear who is the recipient of a private tweet, it is not possible to encrypt the message with the recipient's public keys.

The following three requirements apply to encryption:
\begin{enumerate}
	\item The author can be verified. It is not possible to distribute tweets on behalf of another user on the P2P network.
	\item A private tweet should have the same visibility to other users as a standard tweet on Twitter.
	\item The service provider (Twitter) must not be able to decrypt private tweets or associate them with a user. 
\end{enumerate}

Concrete actions can be concluded to meet these requirements:
\begin{enumerate}
	\item Private tweets must be signed or asymmetrically encrypted so that the author can be clearly identified.
	\item The public key with which the tweets can be decrypted must be distributed over the user's profile. This is the only way to ensure that only authorized users can access the key and that the public key belongs to a specific user without any doubt.
	\item The hybrid OSN application must encrypt the public keys so that Twitter cannot read them and therefore cannot decrypt the private tweets.
\end{enumerate}

\subsection{Realization}
\label{sec:security-relaization}

In the settings, an (asymmetric) key pair can be stored or generated, which is used to encrypt the private tweets. The RSA-OAEP algorithm is used here. Furthermore, the public key can be published on the settings page by clicking on a particular button. The new key together with the current timestamp is recorded in the public key history of the user and stored in IPFS. Listing \ref{listing:public-key-history} shows an example for the public key history. In JSON format, public key and validity start are stored in an array. The address at which the public key history can be retrieved is posted as a normal tweet in the user's timeline during publication. So that this tweet can be found quickly and easily, the id of this tweet is entered in the profile description of the user.

\lstinputlisting[label=listing:public-key-history, caption=Public key history in JSON format. The file is symmetrically encrypted before storing on IPFS.]{listings/key-history.json}

This ensures that only users who can read the user's normal tweets have access to the user's public keys. The history allows you to change the key pair and still ensure that older private tweets can be decrypted.

Since Twitter has access to all the data stored on its servers, it can also find the link to the public key history. It must therefore be prevented that Twitter can decrypt the private tweets of the user by retrieving the public key history. For this reason, the public key history is additionally encrypted symmetrically with the AES-GCM algorithm. The key is stored in the hybrid OSN app and therefore unknown to Twitter.

When writing a new, private tweet, the system checks whether the public key has been published before posting. Only if this is fulfilled will the private tweet be encrypted with the private key and posted.
