While developing components of our products, we love to explore use cases and usability through creating real-world test stands.

0fc is a side-product of WebThemis research: while doing some protocol design for front-end clients with WebThemis services, we wanted to try it in a real-world situation. We've set ourselves a novel idea: end-to-end encrypted webchat, inclined towards client anonymity, giving zero trust to the server, built only with typical Themis primitives.

Always seeking real-world testing of any interesting models and ideas we stumble, we've created a simple web application for Absolutely Discrete Communications :)

With 0fc, you:

0fc can run on any Google Chrome browser and here's how it looks:

This post outlines the process, security model and protocol. It may be of interest for security protocol designers, Themis users looking forward to seeing an example of complicated security process fully covered by Themis and people generally interested in cryptography.

If you don't feel like reading long blog posts, here's github repository with a short readme, you may just jump straight to the code.


0fc consists of 2 classical components: client and server.

Clients are responsible for:

Client code consists of PNaCl module holding all security logic, WebThemis/Themis library and HTML/CSS/JS UI


Server is responsible for:

Over WebSocket link, clients talk to the server via SecureSession Themis object, which provides high-level transport security. Server keys are hardcoded into clients, so trust is established based on correlation between real server key and server key fed to client in binaries.

Server code is written in Python, with pythemis extension linking to core C code.


Within this SecureSession link, SecureCell-encrypted messages are transmitted.

The protocol

Room creation

Inviting others (key sharing)

Message exchange

Key management

Server communication

Key rotation

Room orchestration

Chat history

Threat model

Most group chat cases have been thoroughly studied by cryptographic community, for most solutions of varying elegance exist.

However, group chat with emphasis on anonymity, zero trust to server and zero server's intervention into cryptographic / access flow (server only participates in transport security and in encrypted message relay) is quite rare thing.

Assets and targets

Potential attackers could be interested in 3 things:

Current threat model focuses on:

However, every possible user should realize that large-scale attackers can partially identify chatroom members by metadata collection and correlation analysis, including traffic analysis.

To be used in totally discrete manner, 0fc requires transport identity protection.

External dependencies

Server and client rely on a number of external components and their security. However:

  1. PNaCl module, composed of 0fc client, WebThemis, which consists of Themis and LibreSSL's libcrypto built for specific architecture. Vulnerabilities in libcrypto's crypto algorithm implementation are of limited possibility: all Themis build targets are validated with tests known to work across number of cryptoprimitive's implementations equally.
  2. Google Chrome and it's PNaCl environment may be altered on local client to behave differently, specifically tunnel plaintext input/output from JS<>PNaCl interface; this is outside of scope of current research: Chrome is considered to be trusted environment.
  3. Web UI: web UI can be a subject to many attacks (XSS/CSRF/), we've tried to isolate most in-browser attacks with the maximum simplicity of HTML/CSS stack. Moreover, Chrome is known to put extra effort into each page's runtime security, yet this remains the weakest link, because JS code talking to PNaCl object is still subject to all web attacks.

Entry points

Let's enumerate every possible way external attacker might tamper with code's logic of execution:

  1. Parsing messages during encryption: design of SecureCell protects WebThemis from buffer overflows and other malicious actions against encryption/decryption code.
  2. Web UI behavior after decryption: this is considered outside of the scope of current research.


Potential attackers, by attacking the transport layer, could:

Client impersonation: valid clients know the key, invalid clients don't. By impersonating the client (even with valid PEXE from server), attacker only gets to connect to server on transport layer.

Impersonate server: all clients have pre-shared server key in their binaries. If attacker impersonates server, rebuilds client with his keys, and starts serving them instead of trusted server — he'll just take the relaying load instead of a legitimate machine, and will get no access to the attack targets, e.g. actual data. We're specifically fond of this feature :)

Intercept traffic: SecureSession is specifically designed to prevent interception and decryption of traffic. However, by intercepting initial HTTP GET / HTTP response attacker is able to identify the IP address of the potential client.

Modify traffic: integrity control of SecureSession prevents traffic from being tampered by an attacker. However, HTTP traffic could be modified, and PEXE/Web UI/etc. could be replaced with malicious code. In most cases it is a DoS attack — client just won't connect to the server or will not be able to participate in. However, there is a theoretical possibility of cleverly modifying JS code, which could compromise all traffic going to this client. Protecting against integrity attacks on web code is outside of this research's scope, but they are quite obvious.


For us, 0fc shows a few important things:

For you, it might be a useful chunk of code to study ease of Themis usage :) Anyway, take a look yourself.

Write your own articles at Kukuruku Hub


Read Next