1. Purpose
RavenFlo is an enterprise messenger that runs on the customer’s infrastructure. This note explains what is encrypted, where keys live, what a server is allowed to see, and how an organisation can keep a record without giving the vendor a way to read the chat.
2. What we assume
We assume the customer operates the servers, the directory and the hardware security module. We assume a person’s device can be lost or stolen. We assume the network between sites is not trusted. We assume a record of some conversations will be required later, by the organisation, under its own rules. We do not assume RavenFlo staff will ever need to read a message. The design does not give them a way.
3. End-to-end encryption
A message, file, voice note or call is encrypted on the sender’s device. It is decrypted only on the devices of the people in that conversation. End-to-end encrypted, here, means readable only on those devices. Users cannot turn the encryption off. Servers store and forward a sealed envelope. They do not hold the keys that open it.
4. Keys on the device
Each device creates its own keys. Adding a new device requires a person who already has authority on the account. Revoking a device stops it from reading new messages. Local storage on the device is encrypted. Applications are signed, and connections are pinned so a device is not quietly talking to an impostor server.
5. What servers can see
Servers need to know enough to deliver: that an envelope exists, which device should receive it, and whether policy allows the send. They do not need the plaintext. Mobile push is a wake-up. The notification does not carry the message content. The device then fetches the sealed envelope from the customer’s own server.
6. Post-quantum hybrid encryption
The design combines a classical algorithm in wide use today with a post-quantum key encapsulation method. The aim is that a copy recorded now remains protected if a quantum computer later threatens the classical half. The exact suite is named in the release notes for that version. This is not a claim of being quantum-proof. It is a claim about the shape of the design, and about publishing the names.
7. The compliance key
Some organisations must retain a record. RavenFlo can keep a second copy of a message, sealed to a compliance key that the customer holds in its own hardware security module. Opening that copy requires two authorised approvers, every time. The access is written to an audit log the customer keeps. RavenFlo does not hold this key and cannot approve the access. This is not a backdoor. A backdoor is a way for someone else to get in. This key never leaves the customer.
8. Between servers
Servers that form a cluster authenticate each other with mutual TLS. A headquarters node, a disaster-recovery node, a branch edge node and a DMZ relay are roles of the same software. The relay exists so a phone on a public network can be told to wake up, without that phone needing a path into the heart of the data centre, and without the wake-up carrying the message.
9. What this paper does not claim
- That the software is unhackable, or that encryption removes the need to operate it well.
- That a certification exists. Certifications are listed on the trust centre only when the document exists.
- That using RavenFlo, by itself, satisfies any regulator. It gives the customer controls. The customer’s counsel maps those controls to the obligations.
- A published summary of an independent penetration test. That summary will be linked here when a test has been completed. It has not been, as of 11 November 2026.
10. Disclosure
Vulnerabilities can be reported under the responsible disclosure policy. The contact is also in security.txt.