Permalink
Browse files

fixed some spelling and clarified some details

Thanks Johannes for the feedback!
  • Loading branch information...
JanAhrens committed Mar 22, 2014
1 parent 36ccb40 commit dde49e87525c0ad23ea902d2809de178af05af4a
Showing with 21 additions and 22 deletions.
  1. +21 −22 threema-protocol-analysis.tex
@@ -92,7 +92,7 @@
\section{Introduction}
Threema is a commercial mobile messaging application for Android and
iOS. Its features include chatting with contacts, group conversations and
sharing images. All communication are said to be
sharing images. All communication is said to be
end-to-end encrypted using a keypair generated by the application on
its first launch.
@@ -102,8 +102,8 @@ \section{Introduction}
and can not be reviewed without the agreement of its authors.
The application includes a
\href{https://threema.ch/validation/}{Validation Logging} feature that
can be used to log the in- and outgoing messages. This feature does
log the message bodies, but not all the data that is exchanged with
can be used to log the in- and outgoing messages. This feature
logs the message bodies, but not all the data that is exchanged with
the server. There is no way to prove that the message that is being
logged correlates to data that is being sent by the application.
To enable an independent review I will describe the details of the
@@ -136,7 +136,7 @@ \section{The NaCl library}\label{sec:nacl}
NaCl provides the
$\mathit{crypto\_box}$ function, among other primitives, that can be used to exchange
authenticated messages between a sender and a recipient. Given a
message $m$ the ciphertext $c$ is produced by using the recipient's
message $m$, the ciphertext $c$ is produced by using the recipient's
public key $PK_r$, the senders secret key $SK_s$ and a
nonce $n$.
@@ -203,9 +203,9 @@ \section{Handshake}\label{sec:handshake}
unique 24 byte nonce for every message\footnote{This method is explained in
\href{https://stackoverflow.com/questions/13663604/questions-about-the-nacl-crypto-library/13663945\#13663945}{this}
Stack Overflow discussion.}. I will be using the notation
$n_{xm} = \mathit{nonce}(\mathit{NP}_x, m)$ to express that the nonce $n_{xm}$ is
$n_{xi} = \mathit{nonce}(\mathit{NP}_x, i)$ to express that the nonce $n_{xi}$ is
based on the nonce prefix $\mathit{NP}_x$ and the counter
value $m$.
value $i$.
\subsection{Client Hello}
@@ -217,7 +217,7 @@ \subsection{Client Hello}
It will also generate a 16 byte random nonce prefix
$\mathit{NP}_c$, that is used to generate unique nonces later on.
\begin{figure}
\begin{figure}[h]
\centering
\begin{bytefield}{16}
\bitheader{0,15} \\
@@ -289,7 +289,7 @@ \subsection{Authentication}
\wordbox[lrb]{1}{}
\end{leftwordgroup}
\end{bytefield}
\caption{The Authentication packet is fully encrypted with the short-term keys}
\caption{The Authentication packet. It is fully encrypted with the short-term keys.}
\label{fig:authentication-packet}
\end{figure}
@@ -299,17 +299,17 @@ \subsection{Authentication}
\bitheader{0,7,8,15,16,23,24,32} \\
\begin{leftwordgroup}{128 byte}
\bitbox{8}{username $u$} & \bitbox[ltr]{24}{system data} \\
\bitbox[lr]{8}{system data (cont.)} & \bitbox{16}{server nonce prefix $\mathit{NP}_s$} & \bitbox{8}{nonce for $\mathit{ciphertext}_c$} \\
\bitbox{16}{nonce for $\mathit{ciphertext}_c$ (cont.)} & \bitbox{16}{$\mathit{ciphertext}_c$} \\
\bitbox[lr]{8}{system data (cont.)} & \bitbox{16}{server nonce prefix $\mathit{NP}_s$} & \bitbox{8}{$\mathit{random\_nonce}$} \\
\bitbox{16}{$\mathit{random\_nonce}$ (cont.)} & \bitbox{16}{$\mathit{ciphertext}_c$} \\
\bitbox{32}{$\mathit{ciphertext}_c$ (cont.)}
\end{leftwordgroup}
\end{bytefield}
\caption{Structure of the $\mathit{authentication\_data}$ that is being encrypted as $\mathit{ciphertext}_b$}
\label{fig:ciphertext_c-authentication}
\end{figure}
With the $\mathit{ciphertext}_c$ (Equation~\ref{eq:username_authentication}) inside the
$\mathit{authentication\_data}$ the client is verifying that it
With the $\mathit{ciphertext}_c$ inside
$\mathit{authentication\_data}$ (Equation~\ref{eq:username_authentication}) the client is verifying that it
possesses the private key $\mathit{LSK}_c$ that belongs to the long-term public key $\mathit{LPK}_c$ and is linked to the
username $u$.
@@ -321,7 +321,7 @@ \subsection{Acknowledgment}
In the last step of the handshake, the server acknowledges that the
authentication data provided by the client is valid. The 32 byte
packet is fully encrypted and can be decrypted as show in
packet is fully encrypted and can be decrypted as shown in
equation~\ref{eq:acknowledgment}. Its content is meaningless and
contains only zeros. When the packet can be decrypted, the handshake
is completed and a connection with the Threema server has been established.
@@ -398,8 +398,8 @@ \subsection{Sending and receiving messages}\label{sec:messages}
\hline
Type & Description \\ \hline
\texttt{0x01} & Text message \\ \hline
\texttt{0x90} & User typing notification \\ \hline
\texttt{0x80} & Message delivery receipt \\ \hline
\texttt{0x90} & User typing notification \\ \hline
\end{tabular}
\caption{Message types used inside the data packet \texttt{0x01} and \texttt{0x02}}
\label{tb:message_types}
@@ -419,7 +419,7 @@ \subsection{Sending and receiving messages}\label{sec:messages}
\tikzstyle{inststyle}=[rectangle, anchor=west, minimum width=4.5cm, minimum height=0.8cm, fill=white]
\newthread{client1}{$Client_a$}
\newthread{server}{Server}
\newthread{server}{$Server$}
\newthread{client2}{$Client_b$}
\mess{client1}{Send $m_1$: ``Hello''}{server}
@@ -441,10 +441,10 @@ \subsection{Sending and receiving messages}\label{sec:messages}
Acknowledgments are data packets sent after the client or server have
received a message packet. Each acknowledgment packet includes the related message id and
the sender of the message. The identifier \texttt{0x81} is used by the server to
acknowledge the queuing of messages. The client uses the identifier
\texttt{0x82} to acknowledge that is has received a message. If the server does
not receive on acknowledgment, it will attempt to re-transmit the
message. The same applies to the client if the server does not send an acknowledgment.
acknowledge that it has queued a message. The client uses the identifier
\texttt{0x82} to acknowledge that is has received one. If the server does
not receive an acknowledgment, it will attempt to re-transmit the
message. The same applies to the client if the server does not acknowledge the queuing of a message.
Figure~\ref{fig:message-ack} shows the structure of an acknowledgment packet.
\begin{figure}[h]
@@ -495,10 +495,9 @@ \section{Decrypt client-server communication}\label{sec:intercept}
server's short-term public key $\mathit{SPK}_s$ as well as the nonce
prefixes $\mathit{NP}_c$ and $\mathit{NP}_s$. In order to calculate
the counter values used to generate nonces by the client and the
server you either need to have all exchanged packets or brute force
the correct value.
server you either need to have all exchanged packets or guess the correct value by using brute force.
If you posses all exchanged packets, another way of deciphering the
If you have all exchanged packets, another way of deciphering the
transport encryption is to use the server's long-term public key
$\mathit{LPK}_s$ together with the client's short-term secret key
$\mathit{SSK}_c$. Using both keys it is possible to decipher the whole

0 comments on commit dde49e8

Please sign in to comment.