Security Whitepaper

Белая книга безопасности

Sicherheits-Whitepaper

Documento técnico de seguridad

Documento técnico de segurança

Technical architecture, cryptographic primitives, threat model, and security properties of Sifero Cloud.

Техническая архитектура, криптографические примитивы, модель угроз и свойства безопасности Sifero Cloud.

Technische Architektur, kryptografische Primitive, Bedrohungsmodell und Sicherheitseigenschaften von Sifero Cloud.

Arquitectura técnica, primitivas criptográficas, modelo de amenazas y propiedades de seguridad de Sifero Cloud.

Arquitetura técnica, primitivas criptográficas, modelo de ameaças e propriedades de segurança do Sifero Cloud.

1. Architecture Overview1. Обзор архитектуры1. Architekturüberblick1. Resumen de arquitectura1. Visão geral da arquitetura

Sifero Cloud is a Zero-Knowledge encrypted cloud storage service. All encryption and decryption happens exclusively in the user's browser using the Web Crypto API. The server stores only encrypted blobs and cannot decrypt any user data.

Sifero Cloud - это сервис облачного хранилища с шифрованием Zero-Knowledge. Все шифрование и расшифровка происходят исключительно в браузере пользователя с использованием Web Crypto API. Сервер хранит только зашифрованные данные и не может расшифровать данные пользователей.

Sifero Cloud ist ein Zero-Knowledge-verschlüsselter Cloud-Speicher-Dienst. Alle Ver- und Entschlusselungen finden ausschließlich im Browser des Benutzers über die Web Crypto API statt. Der Server speichert nur verschlüsselte Blobs und kann keine Benutzerdaten entschlüsseln.

Sifero Cloud es un servicio de almacenamiento en la nube con cifrado Zero-Knowledge. Todo el cifrado y descifrado ocurre exclusivamente en el navegador del usuario utilizando la Web Crypto API. El servidor almacena solo blobs cifrados y no puede descifrar ningún dato del usuario.

Sifero Cloud e um servico de armazenamento em nuvem com criptografia Zero-Knowledge. Toda a criptografia e descriptografia ocorre exclusivamente no navegador do usuario usando a Web Crypto API. O servidor armazena apenas blobs criptografados e nao pode descriptografar nenhum dado do usuario.

The cryptographic layer has zero external dependencies for encryption. All file, metadata, note, and chat encryption uses only the browser's built-in Web Crypto API. Argon2id (used for authentication and key derivation) uses hash-wasm, a WebAssembly implementation.

Криптографический слой имеет нулевые внешние зависимости для шифрования. Все шифрование файлов, метаданных, заметок и чата использует только встроенный в браузер Web Crypto API. Argon2id (используемый для аутентификации и деривации ключей) использует hash-wasm, реализацию на WebAssembly.

Die kryptografische Schicht hat null externe Abhängigkeiten für die Verschlüsselung. Alle Datei-, Metadaten-, Notiz- und Chat-Verschlüsselung verwendet nur die browserintegrierte Web Crypto API. Argon2id (für Authentifizierung und Schlüsselableitung) verwendet hash-wasm, eine WebAssembly-Implementierung.

La capa criptográfica tiene cero dependencias externas para el cifrado. Todo el cifrado de archivos, metadatos, notas y chat utiliza solo la Web Crypto API integrada del navegador. Argon2id (usado para autenticación y derivación de claves) usa hash-wasm, una implementación WebAssembly.

A camada criptográfica tem zero dependências externas para criptografia. Toda a criptografia de arquivos, metadados, notas e chat usa apenas a Web Crypto API integrada do navegador. Argon2id (usado para autenticação e derivação de chaves) usa hash-wasm, uma implementação WebAssembly.

Each purpose-specific sub-key is derived using HKDF with a unique info parameter, ensuring that compromising one sub-key does not compromise others.

Каждый целевой подключ выводится с помощью HKDF с уникальным параметром info, что гарантирует: компрометация одного подключа не компрометирует остальные.

Jeder zweckgebundene Unterschlüssel wird über HKDF mit einem einzigartigen info-Parameter abgeleitet, wodurch sichergestellt wird, dass die Kompromittierung eines Unterschlüssels keine anderen gefährdet.

Cada subclave de propósito específico se deriva usando HKDF con un parámetro info único, asegurando que comprometer una subclave no comprometa las demas.

Cada subchave de propósito específico e derivada usando HKDF com um parámetro info único, garantindo que comprometer uma subchave nao comprometa as demais.

2. Key Derivation2. Деривация ключей2. Schlüsselableitung2. Derivación de claves2. Derivação de chaves

2.1 Master Key (Client-Side)(на стороне клиента)(Clientseitig)(lado del cliente)(lado do cliente)

v2 (Current — new users and migrated accounts)v2 (Текущая — новые и мигрированные аккаунты)v2 (Aktuell — neue und migrierte Konten)v2 (Actual — usuarios nuevos y cuentas migradas)v2 (Atual — novos usuarios e contas migradas)

v1 (Legacy — pre-migration accounts)v1 (Устаревшая — аккаунты до миграции)v1 (Legacy — Konten vor Migration)v1 (Legacy — cuentas pre-migración)v1 (Legacy — contas pre-migração)

Argon2id is now used for both authentication and key derivation for v2 users (all new registrations and migrated accounts). Argon2id provides memory-hard protection against GPU/ASIC brute-force attacks, a significant improvement over PBKDF2. The hash-wasm library provides the Argon2id implementation via WebAssembly. PBKDF2 with 600,000 iterations remains as a legacy fallback for v1 users who have not yet logged in to trigger automatic migration. The kdf_version field in the database tracks which KDF each account uses.

Argon2id теперь используется как для аутентификации, так и для деривации ключей для пользователей v2 (все новые регистрации и мигрированные аккаунты). Argon2id обеспечивает защиту с высокими требованиями к памяти против брутфорс-атак на GPU/ASIC, что является значительным улучшением по сравнению с PBKDF2. Библиотека hash-wasm предоставляет реализацию Argon2id через WebAssembly. PBKDF2 с 600 000 итерациями остается как устаревший откат для пользователей v1, которые еще не выполнили вход для запуска автоматической миграции. Поле kdf_version в базе данных отслеживает, какой KDF использует каждый аккаунт.

Argon2id wird jetzt sowohl für die Authentifizierung als auch für die Schlüsselableitung verwendet für v2-Benutzer (alle neuen Registrierungen und migrierte Konten). Argon2id bietet speicherintensiven Schutz gegen GPU/ASIC-Brute-Force-Angriffe, eine erhebliche Verbesserung gegenüber PBKDF2. Die hash-wasm-Bibliothek stellt die Argon2id-Implementierung über WebAssembly bereit. PBKDF2 mit 600.000 Iterationen bleibt als Legacy-Fallback für v1-Benutzer erhalten, die sich noch nicht angemeldet haben, um die automatische Migration auszulösen. Das Feld kdf_version in der Datenbank verfolgt, welchen KDF jedes Konto verwendet.

Argon2id ahora se usa tanto para autenticación como para derivación de claves para usuarios v2 (todos los registros nuevos y cuentas migradas). Argon2id proporciona protección con altos requisitos de memoria contra ataques de fuerza bruta con GPU/ASIC, una mejora significativa sobre PBKDF2. La biblioteca hash-wasm proporciona la implementación de Argon2id via WebAssembly. PBKDF2 con 600.000 iteraciones permanece como respaldo legacy para usuarios v1 que aun no han iniciado sesion para activar la migracion automatica. El campo kdf_version en la base de datos rastrea que KDF usa cada cuenta.

Argon2id agora e usado tanto para autenticação quanto para derivação de chaves para usuarios v2 (todos os novos registros e contas migradas). Argon2id fornece proteção com altos requisitos de memoria contra ataques de forca bruta com GPU/ASIC, uma melhoria significativa sobre PBKDF2. A biblioteca hash-wasm fornece a implementação do Argon2id via WebAssembly. PBKDF2 com 600.000 iterações permanece como fallback legacy para usuarios v1 que ainda nao fizeram login para acionar a migracao automatica. O campo kdf_version no banco de dados rastreia qual KDF cada conta usa.

2.2 Sub-Key Derivation2.2 Деривация подключей2.2 Unterschlüsselableitung2.2 Derivación de subclaves2.2 Derivação de subchaves

Why fixed HKDF salt: Per RFC 5869, HKDF salt is optional. Domain separation is provided by the info parameter. Per-user randomization already occurs at the KDF layer (unique random salt per user for Argon2id/PBKDF2). The version constant enables future protocol upgrades.

Почему фиксированная соль HKDF: Согласно RFC 5869, соль HKDF необязательна. Разделение доменов обеспечивается параметром info. Рандомизация для каждого пользователя уже происходит на уровне KDF (уникальная случайная соль для Argon2id/PBKDF2). Константа версии позволяет обновлять протокол в будущем.

Warum fester HKDF-Salt: Gemäß RFC 5869 ist der HKDF-Salt optional. Die Domänentrennung wird durch den info-Parameter bereitgestellt. Die benutzerspezifische Randomisierung erfolgt bereits auf KDF-Ebene (einzigartiger zufälliger Salt pro Benutzer für Argon2id/PBKDF2). Die Versionskonstante ermöglicht zukünftige Protokoll-Upgrades.

Por que salt HKDF fijo: Segun RFC 5869, el salt HKDF es opcional. La separacion de dominios la proporciona el parámetro info. La aleatorizacion por usuario ya ocurre en la capa KDF (salt aleatorio único por usuario para Argon2id/PBKDF2). La constante de version permite futuras actualizaciones del protocolo.

Por que salt HKDF fixo: Conforme RFC 5869, o salt HKDF e opcional. A separacao de dominio e fornecida pelo parámetro info. A randomizacao por usuario ja ocorre na camada KDF (salt aleatorio único por usuario para Argon2id/PBKDF2). A constante de versão permite futuras atualizações do protocolo.

2.3 Password Verification (Server-Side)2.3 Верификация пароля (на стороне сервера)2.3 Passwortverifizierung (Serverseitig)2.3 Verificación de contraseña (lado del servidor)2.3 Verificação de senha (lado do servidor)

For v2 users, the Argon2id authentication hash is computed client-side using a separate auth_salt (distinct from the key derivation salt). The server never receives the raw password. It stores the Argon2id hash and performs constant-time comparison on login. The authentication hash and the key derivation use separate salts, ensuring the authentication credential cannot be used to derive encryption keys. For v1 legacy users, the server performs server-side Argon2id verification of the raw password. Migration from v1 to v2 happens automatically on login: the client sends both the legacy password and the new client-side hash, and the server updates the stored credential.

Для пользователей v2 хеш аутентификации Argon2id вычисляется на стороне клиента с использованием отдельной auth_salt (отличной от соли деривации ключей). Сервер никогда не получает исходный пароль. Он хранит хеш Argon2id и выполняет сравнение с постоянным временем при входе. Хеш аутентификации и деривация ключей используют разные соли, что гарантирует невозможность использования учетных данных аутентификации для деривации ключей шифрования. Для устаревших пользователей v1 сервер выполняет серверную верификацию Argon2id исходного пароля. Миграция с v1 на v2 происходит автоматически при входе: клиент отправляет как устаревший пароль, так и новый клиентский хеш, и сервер обновляет хранимые учетные данные.

Für v2-Benutzer wird der Argon2id-Authentifizierungshash clientseitig mit einem separaten auth_salt berechnet (unterschiedlich vom Schlüsselableitungs-Salt). Der Server erhält nie das Rohpasswort. Er speichert den Argon2id-Hash und führt beim Login einen zeitkonstanten Vergleich durch. Der Authentifizierungshash und die Schlüsselableitung verwenden separate Salts, sodass die Authentifizierungsdaten nicht zur Ableitung von Verschlüsselungsschlüsseln verwendet werden können. Für Legacy-v1-Benutzer führt der Server eine serverseitige Argon2id-Verifizierung des Rohpassworts durch. Die Migration von v1 zu v2 erfolgt automatisch beim Login: Der Client sendet sowohl das Legacy-Passwort als auch den neuen clientseitigen Hash, und der Server aktualisiert die gespeicherten Anmeldedaten.

Para usuarios v2, el hash de autenticación Argon2id se calcula del lado del cliente usando un auth_salt separado (distinto del salt de derivación de claves). El servidor nunca recibe la contraseña en bruto. Almacena el hash Argon2id y realiza una comparación de tiempo constante al iniciar sesión. El hash de autenticación y la derivación de claves usan salts separados, asegurando que la credencial de autenticación no pueda usarse para derivar claves de cifrado. Para usuarios legacy v1, el servidor realiza verificación Argon2id del lado del servidor de la contraseña en bruto. La migración de v1 a v2 ocurre automáticamente al iniciar sesión: el cliente envía tanto la contraseña legacy como el nuevo hash del lado del cliente, y el servidor actualiza la credencial almacenada.

Para usuarios v2, o hash de autenticação Argon2id e calculado no lado do cliente usando um auth_salt separado (distinto do salt de derivação de chaves). O servidor nunca recebe a senha bruta. Ele armazena o hash Argon2id e realiza comparação de tempo constante no login. O hash de autenticação e a derivação de chaves usam salts separados, garantindo que a credencial de autenticação nao possa ser usada para derivar chaves de criptografia. Para usuarios legacy v1, o servidor realiza verificação Argon2id do lado do servidor da senha bruta. A migracao de v1 para v2 ocorre automaticamente no login: o cliente envia tanto a senha legacy quanto o novo hash do lado do cliente, e o servidor atualiza a credencial armazenada.

3. File Encryption3. Шифрование файлов3. Dateiverschlusselung3. Cifrado de archivos3. Criptografia de arquivos

3.1 Algorithm3.1 Алгоритм3.1 Algorithmus3.1 Algoritmo3.1 Algoritmo

AES-GCM provides both confidentiality (encryption) and authenticity (tamper detection). A unique random IV is generated for every encryption operation using the browser's CSPRNG.

AES-GCM обеспечивает как конфиденциальность (шифрование), так и аутентичность (обнаружение подделки). Уникальный случайный IV генерируется для каждой операции шифрования с использованием CSPRNG браузера.

AES-GCM bietet sowohl Vertraulichkeit (Verschlüsselung) als auch Authentizität (Manipulationserkennung). Für jede Verschlüsselungsoperation wird ein einzigartiger zufälliger IV mit dem CSPRNG des Browsers generiert.

AES-GCM proporciona tanto confidencialidad (cifrado) como autenticidad (detección de manipulación). Se genera un IV aleatorio único para cada operacion de cifrado utilizando el CSPRNG del navegador.

AES-GCM fornece tanto confidencialidade (criptografia) quanto autenticidade (detecção de adulteracao). Um IV aleatorio único e gerado para cada operacao de criptografia usando o CSPRNG do navegador.

3.2 Ciphertext Format3.2 Формат шифротекста3.2 Chiffretext-Format3.2 Formato de texto cifrado3.2 Formato do texto cifrado

v1 (legacy):  [12-byte IV][ciphertext][16-byte auth tag]
v2 (current): [0x02][12-byte IV][ciphertext][16-byte auth tag]
              AAD = fileId (UTF-8)

Version detection: First byte 0x02 indicates v2 format with AAD. Any other first byte triggers v1 fallback (no AAD). This ensures backward compatibility - files encrypted before AAD introduction remain readable.

Определение версии: Первый байт 0x02 указывает формат v2 с AAD. Любой другой первый байт запускает откат к v1 (без AAD). Это обеспечивает обратную совместимость - файлы, зашифрованные до введения AAD, остаются читаемыми.

Versionserkennung: Erstes Byte 0x02 zeigt v2-Format mit AAD an. Jedes andere erste Byte lost v1-Fallback aus (ohne AAD). Dies gewährleistet Abwärtskompatibilität - Dateien, die vor der AAD-Einführung verschlüsselt wurden, bleiben lesbar.

Deteccion de version: El primer byte 0x02 indica formato v2 con AAD. Cualquier otro primer byte activa el respaldo v1 (sin AAD). Esto garantiza compatibilidad retroactiva - los archivos cifrados antes de la introduccion de AAD siguen siendo legibles.

Detecção de versão: O primeiro byte 0x02 indica formato v2 com AAD. Qualquer outro primeiro byte aciona o fallback v1 (sem AAD). Isso garante compatibilidade retroativa - arquivos criptografados antes da introducao do AAD permanecem legiveis.

3.3 AAD Binding (Anti-Swap Protection)3.3 Привязка AAD (защита от подмены)3.3 AAD-Bindung (Anti-Swap-Schutz)3.3 Vinculacion AAD (proteccion anti-intercambio)3.3 Vinculacao AAD (protecao anti-troca)

In v2 format, the file's unique UUID is passed as Additional Authenticated Data to AES-GCM. This cryptographically binds the ciphertext to a specific file ID. If a malicious server swaps one file's ciphertext for another, decryption fails because the AAD (fileId) won't match.

В формате v2 уникальный UUID файла передается как Additional Authenticated Data в AES-GCM. Это криптографически привязывает шифротекст к конкретному ID файла. Если злонамеренный сервер подменит шифротекст одного файла другим, расшифровка не удастся, так как AAD (fileId) не совпадет.

Im v2-Format wird die einzigartige UUID der Datei als Additional Authenticated Data an AES-GCM übergeben. Dies bindet den Chiffretext kryptografisch an eine bestimmte Datei-ID. Wenn ein bösartiger Server den Chiffretext einer Datei gegen einen anderen austauscht, schlagt die Entschlusselung fehl, da die AAD (fileId) nicht übereinstimmt.

En formato v2, el UUID único del archivo se pasa como Additional Authenticated Data a AES-GCM. Esto vincula criptográficamente el texto cifrado a un ID de archivo específico. Si un servidor malicioso intercambia el texto cifrado de un archivo por otro, el descifrado falla porque el AAD (fileId) no coincidira.

No formato v2, o UUID único do arquivo e passado como Additional Authenticated Data ao AES-GCM. Isso vincula criptográficamente o texto cifrado a um ID de arquivo específico. Se um servidor malicioso trocar o texto cifrado de um arquivo por outro, a descriptografia falha porque o AAD (fileId) nao correspondera.

3.4 Per-File DEK (Data Encryption Key)3.4 DEK для каждого файла (Data Encryption Key)3.4 Pro-Datei DEK (Data Encryption Key)3.4 DEK por archivo (Data Encryption Key)3.4 DEK por arquivo (Data Encryption Key)

Each file is encrypted with its own unique random 256-bit key (DEK), generated via crypto.subtle.generateKey(). The DEK encrypts the file content. The DEK itself is then wrapped (encrypted) with the user's file-encryption sub-key and stored alongside the file.

Каждый файл шифруется собственным уникальным случайным 256-битным ключом (DEK), сгенерированным через crypto.subtle.generateKey(). DEK шифрует содержимое файла. Сам DEK затем оборачивается (шифруется) подключом шифрования файлов пользователя и хранится вместе с файлом.

Jede Datei wird mit ihrem eigenen einzigartigen zufälligen 256-Bit-Schlüssel (DEK) verschlüsselt, generiert über crypto.subtle.generateKey(). Der DEK verschlüsselt den Dateiinhalt. Der DEK selbst wird dann mit dem Dateiverschlüsselungs-Unterschlüssel des Benutzers umschlossen (verschlüsselt) und zusammen mit der Datei gespeichert.

Cada archivo se cifra con su propia clave aleatoria única de 256 bits (DEK), generada via crypto.subtle.generateKey(). El DEK cifra el contenido del archivo. El DEK mismo se envuelve (cifra) con la subclave de cifrado de archivos del usuario y se almacena junto al archivo.

Cada arquivo e criptografado com sua propria chave aleatoria única de 256 bits (DEK), gerada via crypto.subtle.generateKey(). O DEK criptografa o conteudo do arquivo. O DEK e entao envolvido (criptografado) com a subchave de criptografia de arquivos do usuario e armazenado junto ao arquivo.

Upload:
  1. DEK = generateKey(AES-256-GCM)        // random per file
  2. ciphertext = AES-GCM(DEK, plaintext, AAD=fileId)
  3. wrappedDEK = AES-GCM(fileKey, DEK)     // wrap with user's key
  4. Store: ciphertext + wrappedDEK

Download:
  1. DEK = AES-GCM-decrypt(fileKey, wrappedDEK)  // unwrap
  2. plaintext = AES-GCM-decrypt(DEK, ciphertext, AAD=fileId)

Benefits of per-file DEK:

Преимущества DEK для каждого файла:

Vorteile des Pro-Datei-DEK:

Beneficios del DEK por archivo:

Beneficios do DEK por arquivo:

• Compromise of one DEK exposes only one file, not all files
• Компрометация одного DEK раскрывает только один файл, а не все
• Die Kompromittierung eines DEK legt nur eine Datei offen, nicht alle
• Comprometer un DEK expone solo un archivo, no todos
• Comprometer um DEK expoe apenas um arquivo, nao todos
• File deletion = DEK deletion = cryptographic erasure (even if ciphertext remains in backups)
• Удаление файла = удаление DEK = криптографическое стирание (даже если шифротекст остается в бэкапах)
• Dateiloschung = DEK-Löschung = kryptografische Löschung (selbst wenn der Chiffretext in Backups verbleibt)
• Eliminacion de archivo = eliminación de DEK = borrado criptográfico (incluso si el texto cifrado permanece en copias de seguridad)
• Exclusao de arquivo = exclusao do DEK = apagamento criptográfico (mesmo se o texto cifrado permanecer em backups)
• Password change requires re-wrapping only DEKs (32 bytes each), not re-encrypting entire files
• Смена пароля требует повторной обертки только DEK (32 байта каждый), а не перешифровки всех файлов
• Passwortänderung erfordert nur die Neu-Umschlusselung der DEKs (je 32 Bytes), nicht die Neuverschlusselung ganzer Dateien
• El cambio de contraseña requiere re-envolver solo los DEKs (32 bytes cada uno), no recifrar archivos completos
• A mudanca de senha requer re-envolvimento apenas dos DEKs (32 bytes cada), nao a recriptografia de arquivos inteiros
• Backward compatible: files without wrappedDEK use the legacy direct-key scheme
• Обратная совместимость: файлы без wrappedDEK используют устаревшую схему прямого ключа
• Abwärtskompatibel: Dateien ohne wrappedDEK verwenden das alte Direct-Key-Schema
• Compatible con versiones anteriores: los archivos sin wrappedDEK usan el esquema heredado de clave directa
• Compativel com versoes anteriores: arquivos sem wrappedDEK usam o esquema legado de chave direta

4. Metadata Protection4. Защита метаданных4. Metadatenschutz4. Protección de metadatos4. Proteção de metadados

4.1 Encrypted Metadata4.1 Зашифрованные метаданные4.1 Verschlusselte Metadaten4.1 Metadatos cifrados4.1 Metadados criptografados

File names, types, and metadata are encrypted with a dedicated metadata-encryption sub-key using AES-256-GCM:

Имена файлов, типы и метаданные шифруются выделенным подключом metadata-encryption с использованием AES-256-GCM:

Dateinamen, Typen und Metadaten werden mit einem dedizierten metadata-encryption-Unterschlüssel unter Verwendung von AES-256-GCM verschlüsselt:

Los nombres de archivos, tipos y metadatos se cifran con una subclave dedicada de metadata-encryption usando AES-256-GCM:

Nomes de arquivos, tipos e metadados sao criptografados com uma subchave dedicada de metadata-encryption usando AES-256-GCM:

{
  "ciphertext": "base64...",  // Encrypted JSON: {type, lastModified, originalSize}
  "iv": "base64..."           // Unique 12-byte IV
}

4.2 HMAC Metadata Signing4.2 Подпись метаданных HMAC4.2 HMAC-Metadaten-Signierung4.2 Firma HMAC de metadatos4.2 Assinatura HMAC de metadados

A dedicated metadata-signing sub-key (HMAC-SHA256) signs the tuple (fileId, encryptedName, encryptedMeta). The signature is stored server-side and verified by the client on each file listing.

Выделенный подключ metadata-signing (HMAC-SHA256) подписывает кортеж (fileId, encryptedName, encryptedMeta). Подпись хранится на сервере и проверяется клиентом при каждом получении списка файлов.

Ein dedizierter metadata-signing-Unterschlüssel (HMAC-SHA256) signiert das Tupel (fileId, encryptedName, encryptedMeta). Die Signatur wird serverseitig gespeichert und vom Client bei jeder Dateiauflistung verifiziert.

Una subclave dedicada de metadata-signing (HMAC-SHA256) firma la tupla (fileId, encryptedName, encryptedMeta). La firma se almacena en el servidor y es verificada por el cliente en cada listado de archivos.

Uma subchave dedicada de metadata-signing (HMAC-SHA256) assina a tupla (fileId, encryptedName, encryptedMeta). A assinatura e armazenada no servidor e verificada pelo cliente em cada listagem de arquivos.

signature = HMAC-SHA256(signingKey, fileId + ":" + encryptedName + ":" + encryptedMeta)

Files without signatures (uploaded before this feature) are displayed normally but without integrity verification. New files always include signatures.

Файлы без подписей (загруженные до появления этой функции) отображаются нормально, но без проверки целостности. Новые файлы всегда включают подписи.

Dateien ohne Signaturen (vor dieser Funktion hochgeladen) werden normal angezeigt, aber ohne Integritätsverifizierung. Neue Dateien enthalten immer Signaturen.

Los archivos sin firmas (subidos antes de esta función) se muestran normalmente pero sin verificación de integridad. Los nuevos archivos siempre incluyen firmas.

Arquivos sem assinaturas (enviados antes desta funciónalidade) sao exibidos normalmente, mas sem verificação de integridade. Novos arquivos sempre incluem assinaturas.

5. Share Links5. Ссылки общего доступа5. Freigabelinks5. Enlaces para compartir5. Links de compartilhamento

5.1 Architecture5.1 Архитектура5.1 Architektur5.1 Arquitectura5.1 Arquitetura

1. User selects a file to share
2. Пользователь выбирает файл для общего доступа
3. Benutzer wählt eine Datei zum Teilen aus
4. El usuario selecciona un archivo para compartir
5. O usuario seleciona um arquivo para compartilhar
6. Client downloads and decrypts the file locally
7. Клиент скачивает и расшифровывает файл локально
8. Client lädt die Datei herunter und entschlüsselt sie lokal
9. El cliente descarga y descifra el archivo localmente
10. O cliente baixa e descriptografa o arquivo localmente
11. Client generates a random 256-bit share key
12. Клиент генерирует случайный 256-битный ключ общего доступа
13. Client generiert einen zufälligen 256-Bit-Freigabeschlussel
14. El cliente genera una clave de comparticion aleatoria de 256 bits
15. O cliente gera uma chave de compartilhamento aleatoria de 256 bits
16. Client re-encrypts the file with the share key (AES-256-GCM + AAD)
17. Клиент перешифровывает файл ключом общего доступа (AES-256-GCM + AAD)
18. Client verschlüsselt die Datei erneut mit dem Freigabeschlussel (AES-256-GCM + AAD)
19. El cliente recifra el archivo con la clave de comparticion (AES-256-GCM + AAD)
20. O cliente recriptografa o arquivo com a chave de compartilhamento (AES-256-GCM + AAD)
21. Encrypted blob is uploaded to the server
22. Зашифрованный блоб загружается на сервер
23. Verschlusselter Blob wird auf den Server hochgeladen
24. El blob cifrado se sube al servidor
25. O blob criptografado e enviado ao servidor
26. Share key is placed in the URL fragment: sifero.cloud/s/shareId#shareKey
27. Ключ общего доступа помещается во фрагмент URL: sifero.cloud/s/shareId#shareKey
28. Freigabeschlussel wird im URL-Fragment platziert: sifero.cloud/s/shareId#shareKey
29. La clave de comparticion se coloca en el fragmento de URL: sifero.cloud/s/shareId#shareKey
30. A chave de compartilhamento e colocada no fragmento da URL: sifero.cloud/s/shareId#shareKey

The URL fragment (#) is never sent to the server per HTTP specification. The server sees only the share ID, never the decryption key.

Фрагмент URL (#) никогда не отправляется на сервер согласно спецификации HTTP. Сервер видит только ID ссылки, но не ключ расшифровки.

Das URL-Fragment (#) wird gemaess HTTP-Spezifikation nie an den Server gesendet. Der Server sieht nur die Freigabe-ID, nie den Entschlusselungsschlussel.

El fragmento de URL (#) nunca se envia al servidor segun la específicacion HTTP. El servidor ve solo el ID de comparticion, nunca la clave de descifrado.

O fragmento da URL (#) nunca e enviado ao servidor conforme a específicacao HTTP. O servidor ve apenas o ID de compartilhamento, nunca a chave de descriptografia.

5.2 Fragment Security5.2 Безопасность фрагмента5.2 Fragment-Sicherheit5.2 Seguridad del fragmento5.2 Segurança do fragmento

5.3 Additional Share Protections5.3 Дополнительная защита общего доступа5.3 Zusätzliche Freigabe-Schutzmechanismen5.3 Protecciónes adicionales de comparticion5.3 Protecoes adicionais de compartilhamento

6. Dead Drop6. Dead Drop6. Dead Drop6. Dead Drop6. Dead Drop

Dead Drop allows any user to receive files anonymously from anyone — without requiring the sender to register, log in, or be tracked in any way. The recipient generates a unique drop link; anyone with that link can encrypt and upload files that only the recipient can decrypt.

Dead Drop позволяет любому пользователю анонимно получать файлы от кого угодно — без регистрации, авторизации или какого-либо отслеживания отправителя. Получатель генерирует уникальную ссылку; любой, у кого есть эта ссылка, может зашифровать и загрузить файлы, которые сможет расшифровать только получатель.

Dead Drop ermöglicht es jedem Benutzer, anonym Dateien von beliebigen Personen zu empfangen — ohne dass sich der Absender registrieren, anmelden oder in irgendeiner Weise verfolgen lassen muss. Der Empfänger generiert einen einzigartigen Drop-Link; jeder mit diesem Link kann Dateien verschlüsseln und hochladen, die nur der Empfänger entschlüsseln kann.

Dead Drop permite a cualquier usuario recibir archivos de forma anónima de cualquier persona — sin que el remitente necesite registrarse, iniciar sesión o ser rastreado de ninguna manera. El destinatario genera un enlace único; cualquiera con ese enlace puede cifrar y subir archivos que solo el destinatario puede descifrar.

Dead Drop permite que qualquer usuário receba arquivos anonimamente de qualquer pessoa — sem que o remetente precise se registrar, fazer login ou ser rastreado de qualquer forma. O destinatário gera um link único; qualquer pessoa com esse link pode criptografar e enviar arquivos que apenas o destinatário pode descriptografar.

6.1 Key Generation6.1 Генерация ключей6.1 Schlüsselgenerierung6.1 Generación de claves6.1 Geração de chaves

When a user creates a Dead Drop, a fresh RSA-4096 key pair is generated client-side via Web Crypto API. The public key is embedded in the drop URL (after the # fragment). The private key is wrapped (encrypted) with the user's master key using AES-256-GCM before being stored on the server. The server never sees the raw private key.

При создании Dead Drop на стороне клиента через Web Crypto API генерируется новая пара ключей RSA-4096. Открытый ключ встраивается в URL ссылки (после фрагмента #). Закрытый ключ оборачивается (шифруется) мастер-ключом пользователя с помощью AES-256-GCM перед отправкой на сервер. Сервер никогда не видит незашифрованный закрытый ключ.

Wenn ein Benutzer einen Dead Drop erstellt, wird ein neues RSA-4096-Schlüsselpaar clientseitig über die Web Crypto API generiert. Der öffentliche Schlüssel wird in die Drop-URL eingebettet (nach dem #-Fragment). Der private Schlüssel wird mit dem Master-Key des Benutzers mittels AES-256-GCM verschlüsselt, bevor er auf dem Server gespeichert wird. Der Server sieht niemals den unverschlüsselten privaten Schlüssel.

Cuando un usuario crea un Dead Drop, se genera un nuevo par de claves RSA-4096 en el lado del cliente mediante la Web Crypto API. La clave pública se incluye en la URL del drop (después del fragmento #). La clave privada se envuelve (cifra) con la clave maestra del usuario usando AES-256-GCM antes de almacenarse en el servidor. El servidor nunca ve la clave privada sin cifrar.

Quando um usuário cria um Dead Drop, um novo par de chaves RSA-4096 é gerado no lado do cliente via Web Crypto API. A chave pública é incorporada na URL do drop (após o fragmento #). A chave privada é envolvida (criptografada) com a chave mestra do usuário usando AES-256-GCM antes de ser armazenada no servidor. O servidor nunca vê a chave privada descriptografada.

6.2 Hybrid Encryption (Sender Side)6.2 Гибридное шифрование (сторона отправителя)6.2 Hybride Verschlüsselung (Absenderseite)6.2 Cifrado híbrido (lado del remitente)6.2 Criptografia híbrida (lado do remetente)

The sender's browser performs hybrid RSA-OAEP + AES-256-GCM encryption entirely client-side:

Браузер отправителя выполняет гибридное шифрование RSA-OAEP + AES-256-GCM полностью на стороне клиента:

Der Browser des Absenders führt eine hybride RSA-OAEP + AES-256-GCM-Verschlüsselung vollständig clientseitig durch:

El navegador del remitente realiza un cifrado híbrido RSA-OAEP + AES-256-GCM completamente en el lado del cliente:

O navegador do remetente realiza criptografia híbrida RSA-OAEP + AES-256-GCM inteiramente no lado do cliente:

1. A random 256-bit AES key is generated for the file
2. The file is encrypted with AES-256-GCM using a random 12-byte IV
3. The AES key is encrypted with the recipient's RSA-4096 public key using RSA-OAEP (SHA-256)
4. The encrypted blob is assembled and uploaded to the server
5. Для файла генерируется случайный 256-битный AES-ключ
6. Файл шифруется алгоритмом AES-256-GCM со случайным 12-байтным IV
7. AES-ключ шифруется открытым ключом RSA-4096 получателя с помощью RSA-OAEP (SHA-256)
8. Зашифрованный блоб собирается и загружается на сервер
9. Ein zufälliger 256-Bit-AES-Schlüssel wird für die Datei generiert
10. Die Datei wird mit AES-256-GCM unter Verwendung einer zufälligen 12-Byte-IV verschlüsselt
11. Der AES-Schlüssel wird mit dem öffentlichen RSA-4096-Schlüssel des Empfängers mittels RSA-OAEP (SHA-256) verschlüsselt
12. Der verschlüsselte Blob wird zusammengesetzt und auf den Server hochgeladen
13. Se genera una clave AES aleatoria de 256 bits para el archivo
14. El archivo se cifra con AES-256-GCM usando un IV aleatorio de 12 bytes
15. La clave AES se cifra con la clave pública RSA-4096 del destinatario usando RSA-OAEP (SHA-256)
16. El blob cifrado se ensambla y se sube al servidor
17. Uma chave AES aleatória de 256 bits é gerada para o arquivo
18. O arquivo é criptografado com AES-256-GCM usando um IV aleatório de 12 bytes
19. A chave AES é criptografada com a chave pública RSA-4096 do destinatário usando RSA-OAEP (SHA-256)
20. O blob criptografado é montado e enviado ao servidor

6.3 Ciphertext Format6.3 Формат шифротекста6.3 Chiffretext-Format6.3 Formato del texto cifrado6.3 Formato do texto cifrado

[2-byte key length (big-endian)][RSA-encrypted AES key][12-byte IV][AES-GCM ciphertext + tag]

6.4 Anonymity Guarantees6.4 Гарантии анонимности6.4 Anonymitätsgarantien6.4 Garantías de anonimato6.4 Garantias de anonimato

• No registration required — the sender does not need an account
• No IP logging — the server does not log sender IP addresses for drop uploads
• No tracking — no cookies, fingerprinting, or analytics on the drop page
• Fragment-only key — the public key is in the URL fragment (#), which is never sent to the server
• Без регистрации — отправителю не нужен аккаунт
• Без логирования IP — сервер не записывает IP-адреса отправителей при загрузке в drop
• Без отслеживания — никаких cookies, фингерпринтинга или аналитики на странице drop
• Ключ только во фрагменте — открытый ключ находится во фрагменте URL (#), который никогда не отправляется на сервер
• Keine Registrierung erforderlich — der Absender benötigt kein Konto
• Kein IP-Logging — der Server protokolliert keine IP-Adressen der Absender bei Drop-Uploads
• Kein Tracking — keine Cookies, Fingerprinting oder Analysen auf der Drop-Seite
• Schlüssel nur im Fragment — der öffentliche Schlüssel befindet sich im URL-Fragment (#), das niemals an den Server gesendet wird
• Sin registro necesario — el remitente no necesita una cuenta
• Sin registro de IP — el servidor no registra las direcciones IP de los remitentes en las cargas de drop
• Sin rastreo — sin cookies, fingerprinting ni analíticas en la página de drop
• Clave solo en el fragmento — la clave pública está en el fragmento de la URL (#), que nunca se envía al servidor
• Sem registro necessário — o remetente não precisa de uma conta
• Sem registro de IP — o servidor não registra endereços IP dos remetentes em uploads de drop
• Sem rastreamento — sem cookies, fingerprinting ou analytics na página de drop
• Chave apenas no fragmento — a chave pública está no fragmento da URL (#), que nunca é enviado ao servidor

7. Chat Encryption7. Шифрование чата7. Chat-Verschlüsselung7. Cifrado de chat7. Criptografia de chat

Chat messages are end-to-end encrypted using per-room keys derived from the user's master key:

Сообщения чата шифруются сквозным шифрованием с использованием ключей для каждой комнаты, выведенных из мастер-ключа пользователя:

Chat-Nachrichten werden mit Ende-zu-Ende-Verschlüsselung unter Verwendung von pro-Raum-Schlüsseln verschlüsselt, die vom Master-Key des Benutzers abgeleitet werden:

Los mensajes del chat estan cifrados de extremo a extremo usando claves por sala derivadas de la clave maestra del usuario:

As mensagens do chat sao criptografadas de ponta a ponta usando chaves por sala derivadas da chave mestra do usuario:

chatKey = HKDF(masterKey, "chat-" + roomId)
encryptedMessage = AES-256-GCM(chatKey, plaintext)

Each message is encrypted as a JSON string {ciphertext, iv} before transmission. The message payload itself is a JSON object {t: text, s: senderName}, meaning the sender name is encrypted within the message payload. The server stores the literal string "encrypted" as the sender_name column. Files shared in chat are also encrypted with the room's chat key.

Каждое сообщение шифруется как JSON-строка {ciphertext, iv} перед передачей. Содержимое сообщения представляет собой JSON-объект {t: текст, s: имяОтправителя}, что означает, что имя отправителя зашифровано внутри содержимого сообщения. Сервер хранит строку "encrypted" в столбце sender_name. Файлы, передаваемые в чате, также шифруются ключом чат-комнаты.

Jede Nachricht wird als JSON-String {ciphertext, iv} vor der Übertragung verschlüsselt. Der Nachrichteninhalt selbst ist ein JSON-Objekt {t: Text, s: Absendername}, was bedeutet, dass der Absendername innerhalb des Nachrichteninhalts verschlüsselt ist. Der Server speichert den Literalstring "encrypted" als sender_name-Spalte. In Chats geteilte Dateien werden ebenfalls mit dem Chat-Schlüssel des Raums verschlüsselt.

Cada mensaje se cifra como una cadena JSON {ciphertext, iv} antes de la transmision. El contenido del mensaje es un objeto JSON {t: texto, s: nombreRemitente}, lo que significa que el nombre del remitente esta cifrado dentro del contenido del mensaje. El servidor almacena la cadena literal "encrypted" como la columna sender_name. Los archivos compartidos en el chat tambien se cifran con la clave de chat de la sala.

Cada mensagem e criptografada como uma string JSON {ciphertext, iv} antes da transmissao. O conteudo da mensagem e um objeto JSON {t: texto, s: nomeRemetente}, o que significa que o nome do remetente e criptografado dentro do conteudo da mensagem. O servidor armazena a string literal "encrypted" como a coluna sender_name. Arquivos compartilhados no chat tambem sao criptografados com a chave de chat da sala.

Messages sent before E2E implementation are stored as plaintext and displayed with a fallback mechanism (decryption failure = display as-is).

Сообщения, отправленные до реализации E2E, хранятся в виде открытого текста и отображаются с механизмом отката (ошибка расшифровки = отображение как есть).

Nachrichten, die vor der E2E-Implementierung gesendet wurden, werden als Klartext gespeichert und mit einem Fallback-Mechanismus angezeigt (Entschlusselungsfehler = Anzeige wie vorliegend).

Los mensajes enviados antes de la implementacion E2E se almacenan como texto plano y se muestran con un mecanismo de respaldo (fallo de descifrado = mostrar tal cual).

Mensagens enviadas antes da implementacao E2E sao armazenadas como texto plano e exibidas com um mecanismo de fallback (falha de descriptografia = exibir como esta).

8. Authentication8. Аутентификация8. Authentifizierung8. Autenticación8. Autenticação

8.1 Registration8.1 Регистрация8.1 Registrierung8.1 Registro8.1 Registro

Anonymous signup: username + password only. No email, phone, or personal data required.

Анонимная регистрация: только имя пользователя + пароль. Не требуется email, телефон или личные данные.

Anonyme Registrierung: nur Benutzername + Passwort. Keine E-Mail, Telefon oder persönliche Daten erforderlich.

Registro anónimo: solo nombre de usuario + contraseña. No se requiere correo electrónico, telefono ni datos personales.

Registro anónimo: apenas nome de usuario + senha. Nao e necessario e-mail, telefone ou dados pessoais.

8.2 Login Flow8.2 Процесс входа8.2 Anmeldevorgang8.2 Flujo de inicio de sesión8.2 Fluxo de login

1. Client computes Argon2id hash of password
2. Клиент вычисляет хеш Argon2id пароля
3. Client berechnet Argon2id-Hash des Passworts
4. El cliente calcula el hash Argon2id de la contraseña
5. O cliente calcula o hash Argon2id da senha
6. Server verifies hash against stored verifier
7. Сервер проверяет хеш против сохраненного верификатора
8. Server verifiziert Hash gegen gespeicherten Verifier
9. El servidor verifica el hash contra el verificador almacenado
10. O servidor verifica o hash contra o verificador armazenado
11. If 2FA enabled: client must provide valid TOTP code
12. Если включена 2FA: клиент должен предоставить валидный TOTP-код
13. Bei aktivierter 2FA: Client muss gültigen TOTP-Code bereitstellen
14. Si 2FA esta habilitado: el cliente debe proporcionar un codigo TOTP valido
15. Se 2FA habilitado: o cliente deve fornecer um codigo TOTP valido
16. Server returns JWT (24h expiry) + user salt
17. Сервер возвращает JWT (истечение 24 ч) + соль пользователя
18. Server gibt JWT (24h Ablauf) + Benutzer-Salt zuruck
19. El servidor devuelve JWT (expiracion 24h) + salt del usuario
20. O servidor retorna JWT (expiração 24h) + salt do usuario
21. Client derives master key from password + salt using Argon2id (v2) or PBKDF2 (v1 legacy)
22. Клиент выводит мастер-ключ из пароля + соли с помощью Argon2id (v2) или PBKDF2 (v1 устаревший)
23. Client leitet Master-Key aus Passwort + Salt mit Argon2id (v2) oder PBKDF2 (v1 Legacy) ab
24. El cliente deriva la clave maestra de la contraseña + salt usando Argon2id (v2) o PBKDF2 (v1 legacy)
25. O cliente deriva a chave mestra da senha + salt usando Argon2id (v2) ou PBKDF2 (v1 legacy)
26. Password is cleared from memory immediately after derivation
27. Пароль немедленно удаляется из памяти после деривации
28. Passwort wird unmittelbar nach der Ableitung aus dem Speicher gelöscht
29. La contraseña se borra de la memoria inmediatamente despues de la derivación
30. A senha e apagada da memoria imediatamente apos a derivação

8.3 Two-Factor Authentication8.3 Двухфакторная аутентификация8.3 Zwei-Faktor-Authentifizierung8.3 Autenticación de dos factores8.3 Autenticação de dois fatores

TOTP (RFC 6238) with 30-second window. QR code generated locally in the browser (no external API calls). Backup codes provided (SHA-256 hashed before storage). Rate-limited: 5 attempts per 15 minutes for disable operations.

TOTP (RFC 6238) с 30-секундным окном. QR-код генерируется локально в браузере (без внешних API-вызовов). Предоставляются резервные коды (хешируются SHA-256 перед сохранением). Ограничение частоты: 5 попыток за 15 минут для операций отключения.

TOTP (RFC 6238) mit 30-Sekunden-Fenster. QR-Code wird lokal im Browser generiert (keine externen API-Aufrufe). Backup-Codes bereitgestellt (SHA-256-gehasht vor Speicherung). Ratenbegrenzt: 5 Versuche pro 15 Minuten für Deaktivierungsoperationen.

TOTP (RFC 6238) con ventana de 30 segundos. Código QR generado localmente en el navegador (sin llamadas API externas). Codigos de respaldo proporcionados (hasheados con SHA-256 antes del almacenamiento). Limitado: 5 intentos cada 15 minutos para operaciones de desactivación.

TOTP (RFC 6238) com janela de 30 segundos. Código QR gerado localmente no navegador (sem chamadas de API externas). Codigos de backup fornecidos (hasheados com SHA-256 antes do armazenamento). Limitado: 5 tentativas por 15 minutos para operacoes de desativacao.

8.4 Session Security8.4 Безопасность сессий8.4 Sitzungssicherheit8.4 Seguridad de sesión8.4 Segurança de sessao

9. Threat Model9. Модель угроз9. Bedrohungsmodell9. Modelo de amenazas9. Modelo de ameaças

9.1 What Sifero Protects Against9.1 От чего защищает Sifero9.1 Wovor Sifero schutzt9.1 Contra que protege Sifero9.1 Contra o que o Sifero protege

9.2 What Sifero Does NOT Protect Against9.2 От чего Sifero НЕ защищает9.2 Wovor Sifero NICHT schutzt9.2 Contra que Sifero NO protege9.2 Contra o que o Sifero NAO protege

10. What The Server Sees10. Что видит сервер10. Was der Server sieht10. Lo que ve el servidor10. O que o servidor ve

10.1 Visible to Server10.1 Видимое серверу10.1 Für den Server sichtbar10.1 Visible para el servidor10.1 Visível para o servidor

• Argon2id password hash (for authentication only, cannot derive encryption keys)
• Хеш пароля Argon2id (только для аутентификации, не может выводить ключи шифрования)
• Argon2id-Passwort-Hash (nur für Authentifizierung, kann keine Verschlüsselungsschlussel ableiten)
• Hash de contraseña Argon2id (solo para autenticación, no puede derivar claves de cifrado)
• Hash de senha Argon2id (apenas para autenticação, nao pode derivar chaves de criptografia)
• KDF salt (public, needed for client-side key derivation)
• Соль KDF (публичная, необходима для деривации ключей на стороне клиента)
• KDF-Salt (öffentlich, für clientseitige Schlüsselableitung benötigt)
• Salt KDF (publico, necesario para la derivación de claves del lado del cliente)
• Salt KDF (publico, necessario para derivação de chaves do lado do cliente)
• Encrypted file blobs (indistinguishable from random data)
• Зашифрованные блобы файлов (неотличимы от случайных данных)
• Verschlusselte Datei-Blobs (nicht von Zufallsdaten unterscheidbar)
• Blobs de archivos cifrados (indistinguibles de datos aleatorios)
• Blobs de arquivos criptografados (indistinguiveis de dados aleatorios)
• Encrypted file names and metadata
• Зашифрованные имена файлов и метаданные
• Verschlusselte Dateinamen und Metadaten
• Nombres de archivos y metadatos cifrados
• Nomes de arquivos e metadados criptografados
• File sizes (in bytes)
• Размеры файлов (в байтах)
• Dateigrößen (in Bytes)
• Tamaños de archivos (en bytes)
• Tamanhos de arquivos (em bytes)
• Timestamps (creation, modification, last access)
• Временные метки (создание, изменение, последний доступ)
• Zeitstempel (Erstellung, Änderung, letzter Zugriff)
• Marcas de tiempo (creación, modificación, ultimo acceso)
• Carimbos de data/hora (criacao, modificacao, ultimo acesso)
• IP addresses (hashed in analytics, raw in security logs)
• IP-адреса (хешированные в аналитике, открытые в логах безопасности)
• IP-Adressen (gehasht in Analytics, roh in Sicherheitslogs)
• Direcciones IP (hasheadas en analítica, sin procesar en logs de seguridad)
• Enderecos IP (hasheados em analítica, brutos em logs de segurança)
• User actions (upload, download, delete, login)
• Действия пользователя (загрузка, скачивание, удаление, вход)
• Benutzeraktionen (Hochladen, Herunterladen, Löschen, Anmeldung)
• Acciones del usuario (subir, descargar, eliminar, iniciar sesión)
• Acoes do usuario (upload, download, exclusao, login)
• Folder structure (encrypted names, parent-child UUID relationships)
• Структура папок (зашифрованные имена, связи UUID родитель-потомок)
• Ordnerstruktur (verschlüsselte Namen, Eltern-Kind-UUID-Beziehungen)
• Estructura de carpetas (nombres cifrados, relaciones UUID padre-hijo)
• Estrutura de pastas (nomes criptografados, relacoes UUID pai-filho)
• Share link existence (without decryption key)
• Существование ссылок общего доступа (без ключа расшифровки)
• Existenz von Freigabelinks (ohne Entschlusselungsschlussel)
• Existencia de enlaces compartidos (sin clave de descifrado)
• Existencia de links de compartilhamento (sem chave de descriptografia)
• HMAC signatures (for client-side verification)
• Подписи HMAC (для верификации на стороне клиента)
• HMAC-Signaturen (fur clientseitige Verifizierung)
• Firmas HMAC (para verificación del lado del cliente)
• Assinaturas HMAC (para verificação do lado do cliente)
• Support ticket content (plaintext, trade-off for admin response capability)
• Содержимое тикетов поддержки (открытый текст, компромисс для возможности ответа администратора)
• Support-Ticket-Inhalte (Klartext, Kompromiss für Admin-Antwortfähigkeit)
• Contenido de tickets de soporte (texto plano, compromiso para capacidad de respuesta del administrador)
• Conteudo de tickets de suporte (texto plano, compromisso para capacidade de resposta do administrador)
• Duress/deadman notification contacts (email, Telegram — plaintext, required for server to send alerts)
• Контакты уведомлений duress/deadman (email, Telegram — открытый текст, необходимы серверу для отправки оповещений)
• Duress/Deadman-Benachrichtigungskontakte (E-Mail, Telegram — Klartext, erforderlich für Server-Benachrichtigungen)
• Contactos de notificación duress/deadman (email, Telegram — texto plano, requeridos para que el servidor envíe alertas)
• Contatos de notificação duress/deadman (email, Telegram — texto plano, necessarios para o servidor enviar alertas)

10.2 Invisible to Server10.2 Невидимое серверу10.2 Für den Server unsichtbar10.2 Invisible para el servidor10.2 Invisível para o servidor

• File contents
• Содержимое файлов
• Dateiinhalte
• Contenido de archivos
• Conteudo de arquivos
• File names (plaintext)
• Имена файлов (открытый текст)
• Dateinamen (Klartext)
• Nombres de archivos (texto plano)
• Nomes de arquivos (texto plano)
• Note contents
• Содержимое заметок
• Notizinhalte
• Contenido de notas
• Conteudo de notas
• Chat messages
• Сообщения чата
• Chat-Nachrichten
• Mensajes de chat
• Mensagens de chat
• Chat sender names (encrypted within message payload)
• Имена отправителей чата (зашифрованы внутри содержимого сообщения)
• Chat-Absendernamen (verschlüsselt innerhalb des Nachrichteninhalts)
• Nombres de remitentes de chat (cifrados dentro del contenido del mensaje)
• Nomes de remetentes de chat (criptografados dentro do conteudo da mensagem)
• Vault passwords
• Пароли хранилища
• Tresor-Passwörter
• Contrasenas de la boveda
• Senhas do cofre
• User's master password
• Мастер-пароль пользователя
• Master-Passwort des Benutzers
• Contrasena maestra del usuario
• Senha mestra do usuario
• Any encryption keys
• Любые ключи шифрования
• Jegliche Verschlüsselungsschlussel
• Cualquier clave de cifrado
• Quaisquer chaves de criptografia
• Share link decryption keys (URL fragment)
• Ключи расшифровки ссылок общего доступа (фрагмент URL)
• Freigabelink-Entschlusselungsschlussel (URL-Fragment)
• Claves de descifrado de enlaces compartidos (fragmento URL)
• Chaves de descriptografia de links compartilhados (fragmento da URL)

11. Infrastructure11. Инфраструктура11. Infrastruktur11. Infraestructura11. Infraestrutura

11.1 Security Headers11.1 Заголовки безопасности11.1 Sicherheitsheader11.1 Encabezados de seguridad11.1 Cabeçalhos de segurança

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; ...
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(self), geolocation=(), payment=()

12. Known Limitations12. Известные ограничения12. Bekannte Einschränkungen12. Limitaciónes conocidas12. Limitações conhecidas

13. Security Roadmap13. План развития безопасности13. Sicherheits-Fahrplan13. Hoja de ruta de seguridad13. Roteiro de segurança

Completed:

Завершено:

Abgeschlossen:

Completado:

Concluido:

• Per-file DEK architecture
• Архитектура DEK для каждого файла
• Pro-Datei-DEK-Architektur
• Arquitectura DEK por archivo
• Arquitetura DEK por arquivo
• E2E chat encryption
• E2E-шифрование чата
• E2E-Chat-Verschlüsselung
• Cifrado E2E de chat
• Criptografia E2E de chat
• AAD binding for file ciphertext
• Привязка AAD для шифротекста файлов
• AAD-Bindung für Datei-Chiffretext
• Vinculacion AAD para texto cifrado de archivos
• Vinculacao AAD para texto cifrado de arquivos
• HMAC metadata signing
• Подпись метаданных HMAC
• HMAC-Metadaten-Signierung
• Firma HMAC de metadatos
• Assinatura HMAC de metadados
• Strict CSP (no unsafe-inline in script-src)
• Строгий CSP (без unsafe-inline в script-src)
• Strikter CSP (kein unsafe-inline in script-src)
• CSP estricto (sin unsafe-inline en script-src)
• CSP rigoroso (sem unsafe-inline em script-src)
• Zero external dependencies for encryption (self-hosted fonts, PDF viewer; hash-wasm for Argon2id only)
• Нулевые внешние зависимости для шифрования (самостоятельно размещенные шрифты, PDF-просмотрщик; hash-wasm только для Argon2id)
• Null externe Abhängigkeiten für Verschlüsselung (selbst gehostete Schriften, PDF-Viewer; hash-wasm nur für Argon2id)
• Cero dependencias externas para cifrado (fuentes y visor PDF autoalojados; hash-wasm solo para Argon2id)
• Zero dependências externas para criptografia (fontes e visualizador PDF auto-hospedados; hash-wasm apenas para Argon2id)
• Panic token hashing in database
• Хеширование токенов паники в базе данных
• Panik-Token-Hashing in der Datenbank
• Hasheo de tokens de panico en base de datos
• Hash de tokens de panico no banco de dados
• Signed releases on GitHub (GPG)
• Подписанные релизы на GitHub (GPG)
• Signierte Releases auf GitHub (GPG)
• Lanzamientos firmados en GitHub (GPG)
• Lancamentos assinados no GitHub (GPG)
• Security Whitepaper published
• Опубликован документ безопасности
• Sicherheits-Whitepaper veröffentlicht
• Documento técnico de seguridad publicado
• Documento técnico de segurança publicado
• Argon2id KDF for key derivation (replacing PBKDF2 for v2 users)
• Argon2id KDF для деривации ключей (замена PBKDF2 для пользователей v2)
• Argon2id KDF für Schlüsselableitung (ersetzt PBKDF2 für v2-Benutzer)
• Argon2id KDF para derivación de claves (reemplazando PBKDF2 para usuarios v2)
• Argon2id KDF para derivação de chaves (substituindo PBKDF2 para usuarios v2)
• Encrypted chat sender names (sender identity hidden from server)
• Зашифрованные имена отправителей чата (идентификация отправителя скрыта от сервера)
• Verschlüsselte Chat-Absendernamen (Absenderidentität vor Server verborgen)
• Nombres de remitentes de chat cifrados (identidad del remitente oculta del servidor)
• Nomes de remetentes de chat criptografados (identidade do remetente oculta do servidor)

Planned:

Запланировано:

Geplant:

Planificado:

Planejado:

This document describes the security architecture of Sifero Cloud as of April 2026.
For updates, see the open-source crypto module and changelog.
Report vulnerabilities to security@sifero.cloud. Этот документ описывает архитектуру безопасности Sifero Cloud по состоянию на апрель 2026 года.
Для обновлений см. криптомодуль с открытым исходным кодом и журнал изменений.
Сообщайте об уязвимостях на security@sifero.cloud. Dieses Dokument beschreibt die Sicherheitsarchitektur von Sifero Cloud, Stand April 2026.
Für Updates siehe das Open-Source-Kryptomodul und das Changelog.
Melden Sie Schwachstellen an security@sifero.cloud. Este documento describe la arquitectura de seguridad de Sifero Cloud a abril de 2026.
Para actualizaciones, vea el módulo cripto de código abierto y el registro de cambios.
Reporte vulnerabilidades a security@sifero.cloud. Este documento descreve a arquitetura de segurança do Sifero Cloud em abril de 2026.
Para atualizações, veja o módulo cripto de código aberto e o registro de alterações.
Reporte vulnerabilidades para security@sifero.cloud.