A99A Ltd.  
49000, Дніпропетровська обл., місто Дніпро, ВУЛИЦЯ ШЕВЧЕНКА,
будинок 59, офіс 217 

Hohha Messenger 
October, 8, 2018 

This is the d
​ raft​ of communication protocol implemented by our Hohha Messenger Software. 
This is not a complete, finalized document yet. Any contribution and or comment will be 
appreciated. 

Hohha Communication Protocol 

  

Our aim is to ensure the privacy and integrity of 

messages and attachments against every possible 
attacker, including Hohha Operator itself. For this, 
we suggest using Hohha Communication Protocol 
with end-to-end Encryption & Authentication. 

Philosophy 
Hohha Protocol dictates usage of quantum-resistant 
encryption algorithms and its philosophy is based on 
symmetric key usage whenever possible. 

Hohha never uses Diffie-Hellman Key exchange, 

unless it is "absolutely necessary". We are going to 
elaborate details of DH key exchange later. 

Hohha Protocol encourages and supports Pre-shared symmetric keys whenever possible. 
Nowadays, it's very easy to exchange symmetric keys via optical means, like qr-codes, barcodes 
etc. During a pre-shared key exchange, keys, even in encrypted form, are never sent via public 

 
 2  
channels. They are not even sent to Hohha Servers. They are just exchanged privately 
between two devices. Even by bypassing any wireless communication channel if possible. And 
this makes Pre-shared keys, the most secure method of communication ever known.  

Protocol details 
 

Hohha backend servers 

Hohha backend servers are intermediary servers which are responsible of two essential duties: 

1. To ensure that any data sent from Alice to Bob will be delivered to Bob, in the same order 
as Alice has sent, as soon as Bob logins to Hohha Servers with correct password and 
delete that data as soon as Bob confirms he has received them. Hohha servers don’t 
save any key, not public nor private nor symmetric, used for end-to-end encryption 
between users. Only the symmetric key(s), used by clients to communicate with backend 
servers are stored on servers.   
2. To ensure that once Alice communicates with Bob, she will continue to communicate 
with someone who knows the login password of Bob. No one else, who doesn’t know 
Bob’s password can use this identity to communicate with Alice. But that doesn’t mean 
Bob, Alice is communicating with, is Bob she knows from real life. It may be someone 
else. Hohha backend servers can’t give any guarantee about real identity of anyone in 
the system. ​But Hohha Protocol gives that guarantee at front-end implementation if 
Alice and Bob use Pre-shared keys, which we consider below. 

Hohha Protocol imposes embedding a public key at front-end implementation and encrypting 
server login credentials with that public key, even if implementation already uses a standard TLS 
connection to server. The goal of this encryption is not only to encrypt login credentials, but also 
to have a security countermeasure against MITM attacks and DNS poisoning. The 
implementation details of this public encryption is left to implementation. The implementation 
may choose any quantum resistant public key cryptography method. Hohha Messenger uses a 
Curve25519 & NTRU Prime hybrid model, similar to method mentioned in Diffie-Hellman Hybrid 
key exchange section, to implement this countermeasure.     

 
 3  

Symmetric keys and forward secrecy1  

 

For both PSK and DH, minimum 32 random bytes(MK) must be exchanged between peers. Then, 
two distinct 32 bytes keys, SKey and RKey must be derived from MK.  

SKey will be used to encrypt messages to be sent to other end and RKey must be used to 
decrypt messages received from other end.  

Alice’s SKey is Bob’s RKey and Bob’s SKey is Alice’s RKey. 

Any deterministic method may be used to “expand” MK to any desired key size. MK may be used 
as input parameters of a hash function (e.g. SHA512) or as seed of a pseudo random number 
generator. 

Forward secrecy​ is provided by using a R

​ FC 5869​ compatible key derivation method: 

After having successfully encrypted and sent a message to other end; SKey, message plaintext 
and nonce(if there is any nonce or HashLen bytes 0) must be concatenated and SHA512 or 
SHA256 result must be set as new SKey. Old SKey must be discarded. 

When an incoming message has successfully been decrypted and saved, RKey, message 
plaintext and nonce(if there is any nonce or HashLen bytes 0) must be concatenated and 
SHA512 or SHA256 result must be set as new RKey. Old RKey must be discarded. 

At this point, we must mention some properties imposed by Hohha Communication Protocol: 

a. If somehow, any of decryption & authentication operations fails, both Alice and Bob 
must be warned and then Diffie-Hellman key exchange negotiation must start between 
them. This is a very important security feature. With the help of this warning, even if 
login password of Alice has been compromised, Bob will be warned that the person 

1
Thanks to metzdowd.com encryption group list members ​Bertrand Mollinier Toublet, Ersin Taşkın, 
Peter Fairbrother, Alfie John and others t​ o convince us to add forward secrecy to this protocol.  
 
 4  
he’s chatting with, may not be Alice(it may also mean that Alice is using a different 
device than the last device she communicated with Bob).    
b. Protocol messages must be delivered to other end. It means, once a protocol message 
is sent from an application which implements this protocol, there must be a 
mechanism which ensures re-sending of protocol messages in case of failure, until 
their receipt is confirmed.  
c. Protocol messages must be delivered in order: Bob has to receive messages sent by 
Alice, in the same order as Alice has originally sent. 

Pre-shared key support  

 

It's meaningless to impose any method for PSK.  

Alice and Bob may both type same shared key with keyboard on their computers. 

Or Bob can scan with his camera, the random key created by Alice, as a qr-code or as a barcode 
representation. 

Minimum 32 bytes random MK must be exchanged between peers and two distinct keys: SKey 
and RKey must be derived from MK on both peers, as mentioned in Section S
​ ymmetric keys and 
forward secrecy​. 

Hohha Messenger implements optical, qr-code based symmetric key exchange. 

   

 
 5  

Symmetric encryption algorithms 

 

Hohha Protocol supports any symmetric encryption set which ensures that: 

a. Received packet is encrypted with the shared symmetric key(authentication) 

b. Received packet hasn't been modified or corrupted(integrity check). 

Hohha Protocol also imposes two additional properties to implement optional encryption 
algorithms instead of imposing a unique algorithm : 

a. The symmetric encryption type and nonce(if necessary) must be sent with every message 
packet​.  
b. Receiver is responsible of using the appropriate algorithm for decryption & authentication​. 

Actually, Hohha Messenger implements two symmetric encryption & authentication algorithm 
sets and user is free to choose one of following algorithms:   

 
 6  

1. Hohha Dynamic XOR Encryption Algorithm, developed by Ismail Kizir. 

This very strong encryption algorithm is designed with its own packet format and authentication 
mechanism. 

It supports variable key sizes. We suggest using 256 or 512 bit key bodies, which fit on one cpu 
cache line, in order to minimize the risk of cpu cache and/or timing attacks. 

Nonces are included in encrypted packet itself. There is no need to send nonce values 
separately.  

Hohha algorithm has also built-in authentication support and ensures both authenticity and 
integrity of messages. 

It's unnecessary to use other signature schemes for verification of the packet integrity.  

It's a patent free, MIT Licensed algorithm. 

Source code can be obtained from: ​https://github.com/ikizir/HohhaDynamicXOR 

2. Xsalsa20 and Poly1305 

Hohha is relatively new algorithm, which is not enough studied by independent security experts. 
That's why, Hohha Messenger also supports xsalsa20 - poly1305, developed by D.J Bernstein, 
as an optional algorithm set for encryption and authentication. 

This algorithm set is a relatively well studied, de-facto standard; combined of two different 
algorithms for encryption & authentication. It supports fixed 256 bit key length. 

It's also a patent free, MIT Licensed algorithm set. 

But it requires two different algorithms for encryption & authentication. This increases cpu 
usage. 

 
 7  

And Nonce values must be sent separately, not with the original encrypted packet.  

There are many implementations of this algorithm set in various languages.  

A famous and easy to use implementation can be obtained from: 

https://github.com/dchest/tweetnacl-js 

Other implementations of the protocol are free to support more sets as long as they meet 
previous criterias we mentioned. 

3. Xsalsa20 and Poly1305 + Hohha Dynamic XOR hybrid encryption 

This is the default and safest encryption mode. 

Messages are first encrypted with XSalsa20 and Poly1305 and then encrypted with Hohha 
Dynamic XOR algorithm. 

Since, every message encrypted twice, this is also the slowest mode. 

   

 
 8  

Diffie-Hellman Hybrid key exchange 

 

If Alice and Bob have no way to be physically together, and they have no other means to 
exchange a shared-secret, Diffie-Hellman key exchange is unavoidable. We use a slightly 
modified version of classical DH Algorithm for quantum safety. 

As IBM and many others have publicly announced, RSA and elliptic curve algorithms will be 
broken in a few years by emergence of quantum computers2. NIST has ongoing projects for 
standard quantum resistant encryption algorithms3. Therefore, Hohha Protocol imposes 
quantum-resistant algorithms for DH key exchange. 

Lattice based cryptography is a very promising and quantum resistant alternative to RSA and 
elliptic curves. 

But, there are two main issues we must consider before using Lattice based encryption 
algorithms: 

1. Quantum resistant algorithms, including lattice based ones, may use very large 
public/private key pairs. To solve this, we decided to use NTRU Prime algorithm, 
developed by Daniel J. Bernstein, Chitchanok Chuengsatiansup, Tanja Lange, and 
Christine van Vredendaal. This is an NIST Standard Candidate Project for quantum 
resistant encryption, backed by both US Government, Dutch Government and European 
Union4. It has two variants: Streamlined NTRU Prime and NTRU LPrime. Hohha 
Messenger uses StreamLined version. The public key size is 1218 bytes and ciphertext 

2
 
https://www.zdnet.com/article/ibm-warns-of-instant-breaking-of-encryption-by-quantum-compu
ters-move-your-data-today/ 
 
3
​https://csrc.nist.gov/projects/post-quantum-cryptography 
https://www.nist.gov/topics/physics/introduction-new-quantum-revolution/cryptography-quantum-age 
 
4
​https://ntruprime.cr.yp.to/ 
 
 
 9  
size is 1047 bytes. Although key and ciphertext sizes are still large when compared 
to classical non-quantum safe algorithms like RSA and Curve25519, they are still 
acceptable for a quantum resistant algorithm.  

2. Lattice based cryptography is relatively new and implementations are not extensively 
studied. According to D.J. Bernstein, even without using quantum computers, "​Several 
ideal-lattice-based cryptosystems have been broken by recent attacks that exploit special 
structures of the rings used in those cryptosystems.5" To resolve this issue, we decided to 
use hybrid encryption: On DH key exchange, we encrypt the key with both classical 
Curve25519 and quantum safe NTRU Prime algorithms. In an ideal situation, DH key 
exchange between Alice and Bob occurs only once and speed difference has a marginal 
effect. 

If Alice wants to send a message to Bob and if they haven’t any common secret already: 

a. Alice first checks her Public key waiting list. This is a simple list containing a user id and 
a list of messages waiting to be sent to this user. If Bob is not already on that list: Alice 
adds Bob to her Public key request waiting list, along with the new message id to be sent 
to Bob, when symmetric key will be set by both users. And she continues to apply next 
step(b). If Bob is already on that list, it means there is already an ongoing DH key 
exchange and Alice is waiting for Bob to send the answer. Alice just adds new message 
id to be sent to Bob, to this list and does nothing else.  

b. Alice creates two ephemeral public/private key pairs: A Curve25519(AP1) key pair and a 
NTRU Streamlined Prime key pair(AP2). The private key of AP1 will be called AP1Prv and 
public key of AP1 will be called AP1Pub. The private key of AP2 will be called AP2Prv 
and public key of AP2 will be called AP2Pub. She also saves them to disk.   

5
​https://ntruprime.cr.yp.to/ 
 
 10  
c. Alice sends a PUBKEY_REQ_CMD command to Bob which contains: 
1. AP1Pub 
2. AP2Pub  

When Bob receives a PUBKEY_REQ_CMD from Alice, he will : 

a. Create minimum 32 random bytes (MK) as seed of main keys to be used for their future 
communication with Alice. Note that, at the end of a successful DH key exchange 
operation, MK will be used to derive two distinct keys SKey and RKey as described 
previously in section S
​ ymmetric keys and forward secrecy​ and then will be discarded.   

b. Create two ephemeral public/private key pairs: A Curve25519(BP1) key pair and a NTRU 
Streamlined Prime key pair(BP2). The private key of BP1 will be called BP1Prv and public 
key of BP1 will be called BP1Pub. The private key of BP2 will be called BP2Prv and public 
key of BP2 will be called BP2Pub. The unique purpose of AP1, AP2, BP1, and BP2 is the 
end-to-end encryption of MK. So that, nobody except Bob and Alice will have MK and 
decrypt their communication. 

c. Create a 32 bytes temporary random symmetric key TK.  

d. Encrypt TK with AP2Pub by using NTRU Streamlined Prime algorithm in order to obtain 
ciphertext CiphTK 

e. Obtain a common shared key CS1 by giving BP1Prv and AP1Pub as parameters to 
Curve25519 function. The result of the function, CS1, is a 32 bytes sequence. 

 
 11  

f. Bob will then xor every byte of CS1 with every byte of TK, storing the result in TKK by 
a simple C loop as: ​for (unsigned t=0; t<32; t++) T
​ KK[t] = C
​ S1[t] ^ TK[t]; 

g. TKK is now our temporary 32 bytes key to be used to encrypt MK(If implementations 
want to use different key sizes, larger than 32 bytes, they can use deterministic methods 
to produce arbitrary length keys from 32 bytes keys. They can use 512 bit hash of a 256 
bit key for example. Or they can use a deterministic PRNG by supplying 256 bits as seed 
in order to obtain a larger key of desired size. Hohha Messenger uses such a 
deterministic technique. But we will omit that part to avoid over-complexity) 

h. Bob, will then encrypt & sign MK with key TKK and will obtain ciphertext CiphMK. Bob 
can use any symmetric encryption & authentication algorithm set supported by the 
implementation. 

i. Bob will save an internal structure to disk containing SHA512 fingerprint of the 
concatenation of BP1Pub, BP2Pub, AP1Pub, AP2Pub. T
​ his SHA512 fingerprint is a 
countermeasure against a possible Man In the Middle Attack by anyone, including 
Hohha Operator itself. Both Alice and Bob can check this fingerprint anytime and if 
both Alice and Bob have same fingerprint, then, this will be the proof of the fact that 
there is noone in the middle.​ Protocol implementation must show this fingerprint to 
users anytime they wish! 

j. Bob will then send a CMD_PUBKEY_RESP command to Alice, which contains: 

1. CiphMK 
2. A simple one byte code to identify which symmetric encryption & authentication 
algorithm Bob used to encrypt CiphMK 
3. BP1Pub 
4. BP2Pub 

 
 12  
5. CiphTK 
6. Optional Nonce parameter, used to encrypt CiphMK, if required by the symmetric 
encryption algorithm used by Bob.   

k. Bob will derive two distinct keys; SKey and RKey as described previously in section 
Symmetric keys and forward secrecy​.  

l. Bob will check if there are messages waiting to be sent to Alice when a symmetric key is 
established and he will send all messages to Alice by encrypting them by using any 
algorithm set he wishes, by using SKey as the key. 

m. Bob will delete AP1, AP2, BP1 and BP2 from disk and memory. They were ephemeral. 
MITM countermeasure fingerprint has already been saved. And there is no need for 
those keys anymore. 

When Alice receives a CMD_PUBKEY_RESP command from Bob, she will first check if Bob is in 
her Public key request waiting list. If not, this is a possible attack. Protocol implementation must 
warn the user about this attack. Else Alice will: 

a. Decrypt CiphTK by giving AP2Prv as parameter to NTRU Streamlined Prime decryption 

function and she will obtain TK 

b. Obtain CS1 by giving AP1Prv and BP1Pub as parameters to Curve25519 function.  

 
 13  

c. Will xor every byte of CS1 with every byte of TK, storing the result in TKK by a simple 
C loop as: ​for (unsigned t=0; t<32; t++) T
​ KK[t] = C
​ S1[t] ^ TK[t]; 

d. Decrypt CiphMK by using appropriate symmetric decryption & authentication algorithm 

set, by using TKK as key to obtain MK, the main symmetric key to be used for future 
communications with Bob. If decryption or authentication fails, implementation must 
warn Alice about a possible attack attempt. 

e. Save an internal structure to disk containing SHA512 fingerprint of the concatenation of 
BP1Pub, BP2Pub, AP1Pub, AP2Pub. ​This SHA512 fingerprint is a countermeasure 
against a possible Man In the Middle Attack by anyone, including Hohha Operator 
itself. Both Alice and Bob can check this fingerprint anytime and if both Alice and Bob 
have same fingerprint, then, this will be the proof of the fact that there is noone in the 
middle.​ Protocol implementation must show this fingerprint to users anytime they wish! 

f. Derive two distinct keys; SKey and RKey as described previously in section ​Symmetric 
keys and forward secrecy​. Note that Alice’s SKey is Bob’s RKey and Alice’s RKey is Bob’s 
SKey. 

g. Encrypt all messages waiting to be sent to Bob by using SKey as key and she will send 
them to Bob. (See also CMD_RESEND_MSG below) 

h. Delete AP1, AP2, BP1 and BP2 from disk and memory. They were ephemeral. MITM 
countermeasure fingerprint has been saved and there is no need for them anymore. 

 
 14  

Bob or Alice: Anyone who receives a message from the other, must send a receipt 
confirmation to other party as soon as the message is decrypted & authenticated. This is a very 
useful feature, but also an important security precaution imposed by the protocol. We are going 
the consider below why this is necessary.  

   

 
 15  

Hohha Protocol guarantees that once you communicate with a 

user, you will always communicate with same user! 
Let’s consider this scenario: 

Alice wants to send a message to Bob. They already negotiated for a symmetric key by any 
mean: It may be a PSK or a symmetric key negotiated via DH. 

Alice encrypts her message with actual symmetric key and sends to Bob. 

But Bob, is offline. Because, Bob lost his phone. 

Bob buys a new phone, installs Hohha Messenger and logins to Hohha Servers with a correct 
password. 

Login is accepted. Server sent all the data accumulated while he was offline, including Alice’s 
messages. 

But Bob hasn’t the last established key with Alice on this new device. Decryption will fail! 

In this case, the implementation must immediately warn both Bob and Alice(Alice will be warned 
later, when she receives DH request) that a new key is being negotiated and the person they are 
communicating with, may not be the person they think to be. Because, even if Bob claims he’s 
Bob and knows Bob’s password, he hasn’t the last key they have used for communication! Bob 
may be someone else, who stole Bob’s password and who is trying to login from another device 
hoping that Alice believes he’s Bob! 

Then, Bob sends a CMD_RESEND_MSG to Alice, along with list of message ids he requests. 
Because, he hasn’t the right key to decrypt those messages.. 

When Alice receives that CMD_RESEND_MSG she must first check if the messages requested 
are already received by Bob(recall that every message received must be confirmed as soon as it 
is properly decrypted & authenticated). If the messages requested are already marked as 
received, it means, someone is trying to attack. Someone may have stolen Bob’s password and 
trying to write to Alice to establish a new symmetric key to communicate with Alice and also 
tries to read the messages Alice has sent to Bob! Or Hohha Operator, pretending to be Bob, is 
sending a fake request as Alice in order to steal previous messages sent. Alice must be 

 
 16  
immediately warned about this attack attempt by the implementation and request must be 
refused. Else, if messages are not marked as received, Alice simply adds message id to 
message resend queue and send those messages to Bob as soon as new key negotiation 
succeeds. Alice will be also warned by messenger implementation about this request.    

 
 17  

Attachments 
 

Hohha Protocol supports attachments. Attachments are encrypted with a separate symmetric 
attachment key AK. AK will be first encrypted with previously established common symmetric 
key MK, in order to obtain its ciphertext CiphAK. The symmetric algorithm code used for 
encryption, CiphAK and its nonce(if necessary) are sent to other party along with the message. 
When a message containing an attachment is received, in order to obtain AK, CiphAK must be 
decrypted. Then, AK(and its nonce if necessary) will be used to decrypt the attachment with 
appropriate symmetric algorithm. 

Group messages 
 

Hohha Protocol supports encryption of group messages with the help of user-to-user end-to-end 
encryption we mentioned earlier. When Alice wants to send a message to group consisted of 
Alice, Bob and Mallory, she encrypts that message for Bob and Mallory individually, with their 
established symmetric keys. And sends those individually encrypted messages to each of them 
separately. If no symmetric key is established yet with a particular user, a new DH Hybrid key 
exchange starts with that particular user, as we mentioned above. And the message is sent 
when new key is established.