OV Message: Technical White Paper

1. Introduction

OV Message is an end-to-end encrypted messaging application that operates without a centralized server. Messages are encrypted before sending and decrypted upon receipt, regardless of the transport channel used. The current implementation uses the SMS network, but the encryption protocol is transport-agnostic. It works over any channel capable of transmitting text.

This document describes the cryptographic mechanisms used, the design choices, and the known limitations of the system.

2. Threat Model

2.1 Covered Threats

2.2 Out of scope

3. General architecture

3.1 Technical stack

3.2 Data separation

3.3 Design principle

4. Message encryption protocol

4.1 Overview

OV Message uses a hash-based stream cipher. Each character of the message is encrypted individually using a substitution index derived from SHA3-256, depending on the position, a random index unique to the message, and a subkey derived from the contact key.

4.2 Transport constraint

Standard primitives (AES-CTR, ChaCha20) produce binary output. Using them on an SMS channel would require additional encoding (Base64, Base85) that increases the message size by 33 to 50%. On SMS, every character counts.

The OV Message cipher operates directly in Unicode space. Plaintext is transformed into ciphertext without going through an intermediate binary representation. The ratio is 1:1. One plaintext character produces one ciphertext character.

The chosen design uses SHA3-256 as a position-indexed pseudorandom generator, with a random index per message and a subkey derived by HKDF. Each character is encrypted independently with 256 bits of entropy per position.

4.3 Operating principle

1. Message normalization (Unicode NFC, line breaks standardized)
2. Generation of a random index (CSPRNG)
3. Derivation of a subkey unique to the message via HKDF-SHA256
4. Derivation of a contact-specific cipher alphabet (deterministic permutation)
5. Character-by-character encryption: each position uses SHA3-256 with the subkey, the position, and the index to produce a substitution index within the derived alphabet.
6. Generation of the HMAC-SHA256 tag (see section 5)
7. Formatting of the encrypted message with the index and the tag

4.4 Security properties

4.5 Alphabets

The system uses Unicode alphabets designed to cover 100+ languages as input and produce output in a distinct Unicode space.

5. Integrity and authentication (HMAC)

5.1 MAC key derivation

The MAC key is derived independently from the encryption key via HKDF-SHA256 with domain separation. Each conversation produces a unique MAC key.

5.2 Tag computation

The HMAC-SHA256 tag is computed over the concatenation of additional authenticated data (conversation identifier, message index) and the ciphertext. The tag is truncated to 128 bits.

5.3 Properties

6. Key management

6.1 Contact key generation

Each contact key is generated locally with a CSPRNG. Keys have variable length and high entropy. Variable length makes deducing the key size from metadata difficult.

6.2 Key exchange

OV Message offers two out-of-band exchange methods:

6.3 Pre-generated key pool

6.4 Key derivation

7. Protection of keys at rest (KEK/DEK)

7.1 Objective

Protect contact keys against forensic extraction (Cellebrite, JTAG, RAM extraction) in the event of physical seizure of the phone.

7.2 Architecture

7.3 Backward compatibility

Without a password configured, the keys remain in the secure keystore (protected by Android Keystore). Migration to encrypted mode is transparent upon the first password configuration.

8. File encryption

8.1 Algorithm

Files shared between contacts are encrypted with AES-256-GCM. The AES key is derived via HKDF-SHA256 from the contact key and a random 16-byte salt, with a dedicated info string. A 12-byte IV is randomly generated.

8.2 Integrity checks

GCM authentication guarantees the integrity of the ciphertext and AAD. A file name consistency check is performed after decryption.

9. Anti-replay protection

9.1 Clockless design

• Each received HMAC tag (128 bits) is stored locally.
• A message with a previously seen tag is silently discarded.
• Storage is partitioned by contact and by direction (sending/receiving).

9.2 Alert thresholds

9.3 Key rotation

At each key rotation, the replay store is cleared. The new key produces a new MAC key, so old tags cannot be replayed.

10. Fortress Mode (anti-phishing)

10.1 Principle

Fortress Mode is an active filter that automatically deletes any incoming message that could not be authenticated. It constitutes protection against phishing, identity spoofing, and unsolicited messages.

10.2 3-step filtering

10.3 Dual-layer filtering

Native layer: intercepts messages before they are broadcast to the system. Unknown numbers are blocked immediately, without notification.

Application layer: full cryptographic validation (HMAC + decryption) for messages that have passed the first filter.

10.4 Anonymized notifications

In Fortress Mode, notifications are generic (no sender name, no content preview). Notifications displayed on the lock screen do not reveal the sender's identity or the content of the message.

11. Forensic resilience

11.1 Panic Mode

Two levels of emergency destruction. Triggered by a dedicated alternate password. If self-destruction is enabled, 3 password failures automatically trigger Panic Mode.

11.2 Native auto-lock (process kill)

A native module schedules process termination via an exact system alarm, immune to Doze mode. When the timer expires, the process is killed by the OS and all RAM is freed (DEK, keys, sensitive data). If the application returns to the foreground before expiration, the alarm is cancelled.

11.3 Additional protections

12. Known limits and trade-offs

12.1 No Perfect Forward Secrecy

The application operates without a permanent key exchange server, making the Double Ratchet impractical. A hash ratchet would cause desynchronization on lost or reordered messages.

12.2 Transport metadata

The transport channel exposes metadata (sender, recipient, timestamp). OV Message cannot hide this information because it is part of the underlying transport protocol.

12.3 Padding

Messages are deterministically padded. An observer can approximate the length of the plaintext message. This trade-off is accepted because transport metadata already leaks more information than the message length.

12.4 Audit status

12.5 Initial key exchange

Security relies on the confidentiality of the shared key and the authenticity of the verification channel:

• In person: the QR code is transmitted directly, without an intermediary channel.
• Remotely: hybrid pairing exposes public keys via SMS (observable), but confidentiality relies on the cryptographic robustness of the hybrid KEM ML-KEM-768 + X25519. Identity verification relies on comparing the 12-character hex SAS via an external trusted channel (recognized voice, video). A MITM attacker would need to intercept the SMS and impersonate the voice/face of the correspondent on the verification channel. The latter is therefore the critical link.

13. Positioning

OV Message targets a threat model that conventional messengers (Signal, WhatsApp, Olvid) do not address: operation without a server or Internet connection, resilience to physical phone seizure, and emergency data destruction under duress.

14. Summary of cryptographic parameters