Architecture & Technical Security
Understand the local encryption implementation, key management via URL fragment and irreversible deletion.
- Encryption AES-256-GCM
- Keys Generated client-side, stored in the URL fragment (#)
- Transport TLS 1.3 Strict
- Server storage Opaque encrypted capsule only
- Decryption Performed locally by the recipient's browser
- Destruction Automatic (irreversible deletion) after reading
🧠 The Fundamental Principle
A system's security is not measured by its commercial promises, but by its mathematical inability to compromise the data it processes.
The ITYLOS protocol adopts a Zero-Trust model regarding the server infrastructure: the server must never have the information necessary to reconstruct plaintext data (Key + Algorithm + Data). Trust is delegated to the user's browser.
⚙️ Architecture and Transmission Flow
The system relies on the strict separation between encrypted data (sent to the server) and the decryption key (kept in the URL).
1. Sender Browser
- Key generation (WebCrypto)
- Encryption AES-256-GCM local
- Payload preparation
2. ITYLOS Server
- Receiving the encrypted capsule
- UUID generation
- Decryption key unknown
3. Ephemeral Link
- The key is placed in the URL fragment (
#key) - The fragment is never transmitted to the server by the browser
4. Recipient Browser
- Retrieving the opaque capsule
- Decryption via the key from the
# - Irreversible deletion order
🔐 Cryptographic Implementations
We do not invent our own cryptography. ITYLOS relies exclusively on standardized, audited primitives natively integrated into modern browsers.
AES-256-GCM
Reference standard for authenticated symmetric encryption. Ensures both total confidentiality of the capsule and the guarantee that it has not been altered.
Web Crypto API
The entropy (randomness) needed is produced directly by the operating system via crypto.getRandomValues().
Ed25519
High-performance asymmetric elliptic curve used to sign certificates making our audit log unforgeable.
TLS 1.3 / HSTS
The transport of the encrypted envelope between the client and infrastructure is protected against network interception (MitM).
🎯 Security Assumptions & Limitations
Every security model has a defined scope. Technical honesty requires clarifying what the system covers, and what it materially cannot prevent.
Security assumptions (Trust Model)
- The client browser is not compromised (no malware/keylogger).
- The browser's Web Crypto API implementation is reliable.
- The HTTPS (TLS) transport channel is intact.
- The server infrastructure is not compromised at root (integrity of distributed source code).
Known system limitations
- ITYLOS cannot prevent a screenshot by the recipient.
- Does not protect against voluntary copying of the plaintext secret once decrypted.
- Does not protect against local interception if the client machine is infected.
- Does not replace a permanent asynchronous messaging tool (like Signal or PGP).
📋 Logging Policy
Good security requires total transparency about what is stored. Here is the detail of our application logging policy:
What we do not know
- The plaintext message content
- The decryption key (URL fragment)
- Uploaded plaintext files
- The optional protection password
- Persistent IP addresses at application level
What we process
- The technical identifier (UUID) of the capsule
- The opaque encrypted data blob
- Expiration parameters (UTC timestamp)
- Public cryptographic audit signatures
- Temporary IPs (exclusively at firewall/anti-DDoS level)