CrypTalk is a free mobile application that allows users to securely communicate by combining multiple well known and proven cryptography methods. By combining strengths of different methods with additional security features, the application offers high security with great user experience.

Basic encryption

At the core of security are fundamental and proven techniques on which the app relies on. These include synchronous AES encryption, with ephemeral keys that have been generated using a well-known elliptic curve Diffie-Hellman (ECDH) protocol. These safely generated keys are used as a foundation for message encryption, where each message is encrypted with a new unique key.

Level 2

In order to maximise security, CrypTalk introduced optional in-person verification which guarantees the identity of the other party, even if the server is compromised. This is done by exchanging the public keys using the QR codes.

Level 3

The highest level of security is based on One-Time-Pad (OTP) encryption, combined with all already mentioned.

The OTP file is generated by movement of a finger, resulting in as much randomness as possible. This file generated by motion is used to additionally process a large file created by device’s native random number generator. The result is a file of entropy greater than 99.9%.

The file is generated locally on the device and shared with the other party via Bluetooth or via direct Wi-Fi connection (2nd option to be implemented, 3rd level currently does not work cross-platform). The goal of this type of exchange was to avoid sharing the file via internet.

This file is then used for an additional encryption layer. Every byte of a message is XOR-ed with one byte from the OTP file. Every used byte is deleted and cannot be retrieved. When the OTP file is consumed, the communication falls back to the previous level, until the 3rd level of encryption is established again.

The first step in establishing a secure communication is to confirm the identity of the server. This is accomplished by providing the server's public key as a part of the application itself.

The diagram above explains how the device A can confirm the identity of the server, as only the server is able to properly encrypt the "OK" message.

All communication between devices goes through a secured envelope, where each message is encrypted with a new ephemeral key.

Before any message is sent, a device must negotiate a temporary secret (S), which is used for key generation for the AES encryption algorithm. In order to generate the secret, each device must create a pair of ephemeral private-public keys (AE and BE), generated from elliptic curve (NIST P-256).

These keys are then exchanged using the ECDH protocol, which is additionally protected by their permanent keys (A and B).

The calculated secret is then used to form a secure tunnel through which the message is sent. For each new message, this whole process is performed in whole, resulting in perfect forward secrecy.

The communication between users (A and B) comes down to two separate stages, A -> Server and Server -> B. Since both of the devices have a secure communication with the server, the communication between A and B is also secure. The messages are stored only temporarily on the server and are encrypted with users permanent, unique, keys (also generated with the ECDH protocol), to which the server does not have access to.

The fore mentioned 3rd level ensures that messages temporarily stored on the server are secured with an additional layer of encryption, so the users do not have to rely on trusting the server.

Overview of included crypto primitives:

  • AES with 256 byte key
  • Elliptic curve Diffie-Hellman (NIST P-256) protocol for key generation
  • Device's native random number generators