How It Works

The Server

The server is a secure, hardened application running on a cloud server located in the European Union, behind an HTTPS reverse proxy with automatic certificate management. It handles five core functions:

• REST API — account creation, login, contact management, cryptographic key distribution.
• WebSocket signaling — real-time message delivery, call setup, online/offline presence, typing indicators.
• Media relay — relays audio between call participants via WebRTC SFU with DTLS-SRTP encryption.
• File relay — temporarily stores encrypted file blobs for transfer between contacts (24-hour retention).
• Push notifications — sends notifications when you're offline so you never miss a message or call.

The Android App

A native Android app using Kotlin and Jetpack Compose. It handles:

• All encryption and decryption of messages and files on your device — the server never sees plaintext for these.
• Key generation and management (identity keys, session keys, pre-keys).
• HD audio encoding/decoding through the Opus codec (48 kHz, 192 kbps) via WebRTC.
• Local storage in an AES-256 encrypted database.
• Real-time communication via WebSocket with automatic reconnection.

The app communicates with the server exclusively over HTTPS (TLS 1.3) with certificate pinning — it will only accept the specific TLS certificate belonging to sys32.net. This means even if a certificate authority is compromised, the app cannot be tricked into connecting to an impostor server.

Registration

Creating an account requires only a username (3–8 characters, lowercase letters and digits), a password (minimum 8 characters, must include uppercase, digit, and special character), and a display name (1–15 characters, shown to your contacts). No email, phone number, or personal information is required or stored. This is by design — the less data the server holds, the less there is to protect or leak.

Login & Sessions

Your password is verified against a bcrypt hash — a deliberately slow algorithm that makes brute-force attacks impractical even if the database is stolen. On successful login you receive two tokens: an access token valid for 24 hours (identifies you for all API calls and the WebSocket), and a refresh token valid for 30 days that lets the app get a new access token without re-entering your password. Refresh tokens are single-use — each use generates a new one and invalidates the old. If a refresh token is stolen and used, the legitimate user's next refresh will fail, creating a theft detection signal.

Account Lockout

After 5 consecutive failed login attempts, your account is temporarily locked for 15 minutes. During the lockout, even the correct password will not work. The server is designed so that the response time is identical whether the username exists, the password is wrong, or the account is locked — preventing attackers from learning anything through timing analysis.

Password Recovery & Deletion

There is no password recovery mechanism. Since no email or phone number is stored, there is no "reset password" email to send. You can change your password while logged in. Changing your password immediately invalidates all sessions on all devices — any device that was logged in must re-authenticate. Account deletion requires your current password (in addition to a valid session), preventing a stolen session from being used to permanently destroy your account.

Cryptographic Algorithms

Key Exchange — X3DH

When you first communicate with someone, your apps use the X3DH protocol to establish a shared secret without any prior communication:

1. Identity keys — Every user has a permanent X25519 key pair, generated when they first create their account. The public key is uploaded to the server. A corresponding Ed25519 key (used for digital signatures) is mathematically derived from the same private key.
2. Signed Pre-Key (SPK) — A medium-term key, rotated regularly. Its public key is digitally signed with your Ed25519 identity key to prove it belongs to you. The signature is verified before any session is accepted — if the signature doesn't match, the session is rejected.
3. One-Time Pre-Keys (OTPKs) — A large pool of single-use keys. When someone initiates a session, they claim one of your OTPKs from the server, which is then atomically deleted — preventing anyone from replaying the initial handshake.
4. The computation — The initiator performs four Diffie-Hellman exchanges using combinations of their keys and the recipient's public keys. The results are combined and fed through HKDF-SHA256 to produce a shared secret that only the two participants can compute.

Message & File Encryption — Double Ratchet

Once X3DH establishes a shared root key, every subsequent message and file transfer key uses the Double Ratchet algorithm — the gold standard for secure messaging, also used by Signal:

• Forward secrecy — Every message advances a chain key via HMAC-SHA256, producing a unique message key that is destroyed after use. Compromising the current chain key reveals nothing about past messages — the hash function is mathematically one-way.
• Post-compromise security — Every message also advertises a fresh X25519 public key. When the recipient receives it, they perform a new Diffie-Hellman exchange and mix the result into the root key. If a key was stolen, the encryption self-heals after one round-trip of messages — future messages become secure again without you doing anything.
• Message authentication — Every encrypted message includes an HMAC-SHA256 authentication tag. Before decrypting, the recipient verifies this tag. If it doesn't match, the message is rejected — guaranteeing it hasn't been tampered with in transit.

Key Storage on Your Device

All cryptographic material on your phone is protected by multiple layers of encryption:

1. Encrypted database — Your local message database is encrypted with AES-256. It cannot be opened without the correct passphrase.
2. Secure preferences — The database passphrase, session tokens, and identity keys are stored in Android's hardware-backed encrypted storage. Both keys and values are encrypted.
3. Hardware Keystore — The master encryption keys live in your phone's secure hardware (Trusted Execution Environment or Secure Element, depending on the device). They never leave the secure hardware and cannot be extracted, even with root access.

When you log out or switch accounts, identity keys are explicitly wiped so the previous user's cryptographic identity cannot be reused.

Sending a Message

1. The app encrypts your message using the Double Ratchet session established with that contact. Each message gets a unique encryption key and a random initialization vector (IV) — even identical messages produce completely different ciphertext.
2. An HMAC-SHA256 authentication tag is computed over the ciphertext and IV to prevent tampering.
3. The encrypted packet is sent through the WebSocket to the server.
4. The server stores the encrypted blob temporarily and delivers it to the recipient in real-time. If the recipient is offline, the message is queued and a push notification is sent.
5. Once delivered and confirmed, the server permanently deletes the message. The only copies are on your device and the recipient's device.

Receiving a Message

1. The app receives the encrypted packet through the WebSocket.
2. The HMAC-SHA256 authentication tag is verified — if it doesn't match, the message is rejected (tampering detected).
3. The message is decrypted using the Double Ratchet session key.
4. The decrypted text is stored in your local encrypted database.

Typing Indicators & Read Receipts

Typing indicators are transient signals sent through the WebSocket — they are never stored in any database. They simply show the other person that you're typing, and disappear when you stop. Read receipts tell the sender you've seen their messages.

Uploading a File

1. The app generates a random file encryption key and a unique file identifier.
2. The file is encrypted chunk by chunk with AES-256-CTR. Each chunk gets a unique initialization vector — even identical chunks produce completely different ciphertext.
3. The filename is encrypted inside the file body. The server only sees an opaque blob. It does not know the original filename, contents, or file type.
4. The encrypted blob is uploaded to the server. The server verifies that you and the recipient are accepted contacts, and that the file meets size and storage limits.
5. The file encryption key is transmitted through the Double Ratchet session — just like a regular encrypted message. Only the recipient can decrypt it.

Downloading & Retention

Downloads support resumable transfers — large files can be paused, resumed, and streamed. Only the sender and recipient can download a file; the server verifies identity on every request. Files are deleted from the server immediately after the recipient's first download. Undownloaded files are cleaned up after 24 hours. File identifiers are strictly validated to block path traversal and other injection attacks.

Audio Quality

Vocis HD uses the Opus audio codec at 48 kHz sample rate (twice the 24 kHz used by most VoIP apps), 192 kbps variable bitrate (adapts to the complexity of the audio), and 20 ms frame size (50 frames per second for smooth, low-latency audio). Audio is mono — optimized for voice clarity.

Audio Encryption & Transport

Audio calls use WebRTC, the same real-time communication protocol used by major messaging apps. All WebRTC media is encrypted with DTLS-SRTP:

• The DTLS handshake negotiates encryption keys between the app and the server's SFU (Selective Forwarding Unit).
• Each audio frame is encrypted with AES-128-GCM or AES-256-GCM, depending on the negotiated cipher suite.
• The SFU relays encrypted audio between call participants — each leg of the call has its own independent DTLS-SRTP session.
• The Opus-encoded audio (48 kHz, 192 kbps) is transmitted over UDP for low latency and resilience to network conditions.

This is the same encryption model used by WhatsApp, Signal, and Telegram for voice calls — hop-by-hop encryption where the relay server decrypts and re-encrypts audio between participants. It provides strong protection against network eavesdroppers while enabling the server to efficiently relay audio with minimal latency.

Call Resilience

• A foreground service keeps the call active when you switch apps or lock your screen.
• An audio health monitor (running on a dedicated Java thread) continuously re-applies audio configuration to keep the microphone active on devices with aggressive battery optimization (Samsung One UI, Xiaomi HyperOS).
• The WebRTC connection uses UDP, which survives background network restrictions that freeze TCP sockets on some OEMs.
• Abandoned calls (where a peer disconnects without properly ending the call) are automatically detected and cleaned up.

Where the Server Runs

The server is a hardened, single-purpose application running on a cloud server in the European Union. All connections use HTTPS with TLS 1.3. The server software is designed to be self-contained — it has no external dependencies beyond the operating system itself, reducing the attack surface.

The server is protected by multiple layers:

• HTTPS termination with automatic certificate renewal — all traffic is encrypted in transit.
• Strict firewall — only the minimum necessary network services are exposed. Everything else is blocked.
• Automatic security updates — the underlying system applies critical security patches automatically.
• Process isolation — the server runs with minimal privileges and auto-restarts if it ever fails.

Database

The server uses an embedded database — a single file on disk with no separate database server, eliminating an entire class of network-based database attacks. It stores:

• User accounts (username, bcrypt password hash, display name)
• Contact relationships and contact requests
• Encrypted message blobs (temporary — deleted after delivery)
• Public cryptographic keys (identity keys, pre-keys for X3DH handshake)
• Push notification device tokens
• Hashed session tokens
• Supporter purchase records (for deduplication)

Network Security

• HTTPS only — all connections use TLS 1.3, with automatic certificate renewal.
• Certificate pinning — the app only accepts the specific cryptographic identity of sys32.net. A fraudulent certificate from a compromised authority is rejected at the operating system level, before any data is sent.
• Trust anchor restriction — the app only trusts system-level certificate authorities, not user-installed ones (which could be added by corporate proxies or malware).
• HSTS — the server instructs browsers and compatible clients to never connect over plain HTTP.
• Security headers — all responses include protections against MIME type sniffing, clickjacking, and protocol downgrade attacks.

Authentication Security

• bcrypt password hashing — a deliberately slow algorithm. Brute-force resistant even if the entire database is stolen.
• Timing attack protection — the server performs the same cryptographic operations regardless of whether the username exists, the password is correct, or the account is locked. Response times are intentionally identical in all cases, preventing attackers from learning anything through timing analysis.
• Token version invalidation — changing your password immediately invalidates all sessions on all devices.
• Password required for deletion — a stolen session token alone cannot permanently destroy your account.

Rate Limiting & Abuse Prevention

All API endpoints are protected by per-IP rate limiting with different thresholds based on sensitivity. Registration and authentication have the strictest limits to prevent brute-force attacks. Higher-volume endpoints (like contact management and key operations) have more generous limits to accommodate normal usage.

Input Validation

Every piece of data sent to the server is strictly validated before processing: usernames (character set and length enforced), passwords (complexity requirements), display names (dangerous characters stripped), file identifiers (strict pattern matching to block injection attacks), cryptographic keys (format and size verified before storage), and request body sizes (capped to prevent memory exhaustion).

Code & Device Protection

• Code obfuscation — the release APK is obfuscated with R8 full mode to hinder reverse engineering.
• Debug symbols stripped — release builds contain no debug information that could aid analysis.
• Backup disabled — app data (tokens, keys, messages) is excluded from cloud backups and device transfers. Your encrypted data stays on your device.
• Debugging tools disabled in production — server debugging features are completely inaccessible in the production environment.

Voluntary Support

Vocis HD offers optional Supporter Badges (bronze, silver, gold, platinum) purchased through Google Play Billing. Each purchase adds to your lifetime support total, which determines your rank. Badges can be purchased multiple times. Google Play handles all payment processing — the server never sees or stores payment card information, billing addresses, or financial data. Purchase tokens are cryptographically verified and recorded for deduplication.

Supporter Badges are purely cosmetic. They do not affect messaging speed, call quality, encryption strength, file transfer limits, or any app functionality. All communication features work identically for every user.

A public Hall of Fame leaderboard shows all supporters ranked by lifetime contribution. You can opt out of the public leaderboard at any time by contacting support.

What the Server Stores