La Qlavis Citadel, la especificación publicada de la criptografía de Qlavis · Messenger.

Renovación de claves cada 10 mensajes o 24 horas.

Un ratchet Diffie-Hellman X25519, ratchets simétricos de cadena (claves de cadena avanzadas por HMAC-SHA512, truncado a 32 bytes, con constantes de separación de dominio) y un ratchet ML-KEM-1024 independiente que renueva la raíz post-cuántica cada 10 mensajes o 24 horas, lo que llegue primero.

Cada clave de mensaje exige romper ambos ejes.

Cada clave de mensaje se deriva a la vez del eje clásico y del post-cuántico, de modo que el secreto hacia adelante (forward secrecy) y la seguridad post-compromiso se sostienen frente a un adversario clásico hoy y uno cuántico mañana. Signal y Apple eligieron KEMs de parámetro 768 en sus ratchets por ancho de banda; QTR-1024 lleva ML-KEM-1024 (Categoría 5), cambiando unos 3 KB por rotación por el nivel estandarizado más alto.

Los mensajes perdidos o desordenados no rompen la sesión.

Una encapsulación KEM, a diferencia de un valor DH, no es idempotente, en los ratchets post-cuánticos anteriores, perder el único mensaje que lleva el material de la nueva época rompe la sesión. QTR-1024 re-incluye el mismo ciphertext KEM pendiente en cada cabecera saliente hasta que el par confirma; el receptor mantiene un historial SHA-256 acotado de ciphertexts procesados y desencapsula cada ciphertext distinto exactamente una vez, saltando duplicados sin avanzar el estado; la confirmación se anuncia a lo largo de un número acotado de mensajes posteriores.

Sellado, autenticado y de longitud oculta.

Los cuerpos de mensaje se sellan con AES-256-GCM (nonce aleatorio fresco de 96 bits, etiqueta de 128 bits) con la cabecera vinculada como datos asociados, y se rellenan a bloques uniformes de 256 bytes para que los mensajes cortos no sean distinguibles por longitud en el cable. Antes de cualquier mutación durante el descifrado se toma una instantánea del estado de sesión; una autenticación fallida restaura la instantánea, de modo que un ciphertext manipulado no puede corromper la sesión.

Cada cambio de membresía es una firma, verificada en cada dispositivo.

Cada alta, expulsión, salida, transferencia de propiedad y concesión de administrador va firmada con ML-DSA-87 por el dispositivo actor sobre un mensaje canónico que nombra la sala, la época actual, el actor, el destinatario y, para altas y concesiones, la clave de identidad del destinatario. El servidor verifica la firma antes de actuar y la conserva en el registro de eventos de la sala; el dispositivo de cada miembro reproduce ese registro y vuelve a verificar cada operación bajo claves que fijó por sí mismo, nunca bajo claves recibidas por la red. Las altas y las concesiones fallan cerradas: una operación que no verifica nunca entra en el conjunto de miembros que reciben claves. Las expulsiones fallan seguras: se aceptan incluso sin verificar, porque denegar es la dirección segura. Una expulsión o una salida avanza la época de la sala. Un miembro que ningún dispositivo nuestro fijó jamás lo fija la propia sala, desde la ruta de identidad y bajo sus propias claves atestadas, y el registro se vuelve a verificar desde su primer evento en cuanto existe el pin. La transcripción de un recién llegado empieza en su alta; el historial completo de membresía sigue legible en Seguridad dentro de Room Info.

Claves de remitente: una cadena por dispositivo emisor, entregada solo a miembros verificados.

Cada dispositivo emisor mantiene su propia cadena unidireccional: la clave de mensaje y la siguiente clave de cadena se derivan por HMAC de la clave de cadena actual, así que una clave filtrada después no revela mensajes anteriores. La clave de cadena se entrega a cada dispositivo miembro verificado individualmente. El emisor encapsula con ML-KEM-1024 a la preclave de envoltura rotatoria del dispositivo receptor, firmada por ese dispositivo y renovada cada 30 días, o, si la preclave recibida no verifica, a la clave de identidad certificada del dispositivo, de modo que un servidor malicioso puede acortar la frescura pero nunca redirigir una clave hacia sí mismo. La clave de cadena viaja sellada con AES-256-GCM, ligada a la sala, la época, el dispositivo emisor y el dispositivo receptor, y lleva dentro de la carga sellada la firma ML-DSA-87 del dispositivo emisor, así que ni un miembro ni el servidor pueden plantar una cadena a nombre de otro. Cuando la época avanza, cada emisor inicia una cadena nueva y el dispositivo expulsado no recibe ninguna. Un dispositivo añadido después arranca en la posición actual de cada cadena y no puede derivar lo anterior. Los emisores también renuevan la clave tras 1000 mensajes o 7 días.

Sellado bajo la cadena, firmado por el dispositivo: autoría dentro de un grupo de clave compartida.

Un mensaje de sala se sella con AES-256-GCM bajo la clave por mensaje, con la sala, la época, el dispositivo emisor y la posición en la cadena como datos asociados. Como cada miembro tiene la clave de cadena del emisor, la confidencialidad por sí sola no puede probar quién escribió un mensaje; por eso cada sobre lleva una firma ML-DSA-87 del dispositivo emisor sobre la sala, la época, el identificador del mensaje, la posición y un resumen del texto cifrado. El servidor comprueba esa firma y la época actual antes de aceptar el sobre y, como en los chats individuales, borra el sobre cuando el dispositivo de cada miembro ha confirmado la recepción, con un tope de 14 días para quien nunca vuelve. El dispositivo receptor verifica la firma antes de tocar el estado de su cadena, tanto en la app como en el proceso de notificaciones.

El servidor ve el tamaño y los tiempos de una sala, nunca su nombre, su foto ni sus archivos.

El nombre de la sala, la descripción y la clave de la foto se sellan juntos en un solo blob bajo una clave de metadatos de sala que el servidor nunca tiene. La clave llega a cada dispositivo miembro por la misma entrega firmada y envuelta con ML-KEM-1024 que las claves de cadena, y rota en cada cambio, así que un miembro que se fue no puede leer un nombre posterior. Una foto, un vídeo, una nota de voz o un archivo enviados a una sala se cifran en el dispositivo bajo una clave aleatoria nueva, y esa clave viaja dentro del cuerpo sellado del mensaje; no hay envoltura de claves de archivo por destinatario, y el servidor registra solo quién subió un blob y cuándo caduca, nunca a qué sala o mensaje pertenece. La foto de una sala vive tanto como la sala; cualquier otro blob de sala se borra con el mismo tope de 14 días que los mensajes.

Un código que cada dispositivo calcula por sí solo, y tres límites dichos sin rodeos.

El Room Seal es un código de 12 dígitos y un glifo derivados con SHA-512 (canon del sello v2, con la etiqueta SEAL V2 · SHA-512 bajo el código) de las claves de identidad ML-DSA-87 fijadas de cada miembro verificado y de la época de la sala. Cada dispositivo lo calcula solo; dos miembros que muestran el mismo sello tienen la misma membresía verificada en la misma época, así que un miembro inyectado u ocultado aparece como sellos distintos. Tres límites de la membresía gestionada por el servidor forman parte del diseño y están modelados, no escondidos: el servidor puede ocultar un evento a una parte de los miembros, y el sello es lo que lo expone; la clave de metadatos no rota cuando se expulsa a un miembro, porque un nombre ya leído no se puede desleer, y el siguiente cambio la rota; y un miembro expulsado conserva los mensajes y archivos que recibió mientras era miembro, como en cualquier mensajería de grupo. Lo que el servidor sí aprende de una sala: membresía, roles, épocas, número y tiempos de mensajes, identificadores de dispositivo, y la existencia y el tamaño de los blobs.

Una llamada solo-clásica se rechaza antes de que suene el teléfono.

En el modo de producción con exigencia activa, el relay de señalización valida cada oferta de llamada antes de avisar al receptor y la rechaza salvo que lleve la versión post-cuántica del protocolo, la capacidad de suite post-cuántica requerida, material de ciphertext ML-KEM-1024 bien formado y una bandera afirmativa de medios post-cuánticos. La respuesta pasa comprobaciones simétricas. El dispositivo del receptor, como defensa en profundidad, auto-rechaza de forma independiente una oferta sin material KEM antes de sonar.

Llamante y receptor derivan claves idénticas de encapsulaciones espejadas.

El llamante encapsula contra la clave pública ML-KEM-1024 del receptor y envía el ciphertext en la oferta; el receptor desencapsula, encapsula contra la clave del llamante y responde. Ambos lados derivan idénticamente, claves acotadas a esa única llamada por la sal, claves de señalización y de medios separadas por dominio; el relay solo ve ciphertexts opacos:

master   = HKDF-SHA512( salt = callId, IKM = ss1 ‖ ss2 )
sigKey   = PRF( master, "call:sig" )    , metadatos de señalización
mediaKey = PRF( master, "call:media" )  , cifrado de tramas

Las claves rotan a mitad de llamada sin cortes y sin renegociación.

Cada trama de audio y vídeo se sella con AES-256-GCM bajo la clave de medios. Un temporizador avanza un índice de clave acotado cada cinco minutos; la clave de trama del índice i se deriva determinísticamente de la clave de medios e i, y el índice viaja en los metadatos de la trama , los receptores avanzan sin interrumpir el flujo.

Un servidor que intercambie claves mata la llamada.

Cada parte firma su identificador de llamada y su ciphertext KEM con su clave de identidad ML-DSA-87; la firma viaja con la clave pública post-cuántica del firmante y su atestación cruzada Ed25519 dentro de un campo de señalización opaco que el relay reenvía tal cual. El receptor verifica la atestación bajo la raíz de confianza anclada, verifica la vinculación bajo la clave probada y ancla la identidad post-cuántica a primera vista desde la propia llamada. Un ciphertext manipulado, una atestación ausente, una degradación a suite clásica desde un par capaz o un pin que no coincide terminan la llamada, no hace falta comparar cadenas de seguridad; la llamada hereda la identidad de mensajería ya anclada.

Si una llamada no se puede sellar post-cuánticamente, no se conecta.

No existe un estado de llamada insegura ni una advertencia descartable: cualquier fallo post-cuántico en la ruta de la llamada significa que la llamada nunca se establece o se corta. Una política opcional de IP oculta por llamada restringe la conexión a candidatos solo-relay (TURN), ocultando la dirección del dispositivo frente al par, con una degradación best-effort registrada si no se reúne ningún candidato relay en una ventana acotada.

El servidor guarda un blob opaco que no puede leer, y luego lo borra.

Cada archivo se cifra en el dispositivo bajo una clave aleatoria fresca de 32 bytes con AES-256-GCM y se sube como blob opaco; la clave del archivo, nunca el archivo, se envuelve para cada destinatario vía ML-KEM-1024 dentro del mensaje cifrado de extremo a extremo que lo referencia. El servidor borra el blob cuando el dispositivo del destinatario confirma la recepción durable (descifrado correcto y escritura en el almacén cifrado del dispositivo), con una breve ventana de gracia y un techo independiente de 14 días para los blobs nunca descargados; el registro de entrega deliberadamente no lleva identidad del destinatario. Reenviar re-cifra bajo una clave fresca y sube un blob nuevo, en el servidor, un reenvío no puede vincularse con su original.

Una foto cifrada, una concesión criptográfica independiente por espectador.

Una foto de perfil se cifra una vez bajo una clave simétrica fresca; para cada espectador permitido, el dispositivo del propietario encapsula a la clave ML-KEM-1024 del espectador y sella la clave del avatar bajo el resultado con AES-256-GCM, etiquetando cada envoltura con su suite AEAD, no una única clave de perfil compartida. Rotar el avatar borra el blob sustituido y todas las envolturas antiguas. Los espectadores sin envoltura encolan una solicitud que el dispositivo del propietario atiende en su siguiente conexión, y ese dispositivo reconcilia la cobertura por espectador en cada arranque , ningún espectador queda excluido de forma permanente. El servidor retransmite e indexa envolturas que nunca puede abrir.

La identidad del remitente viaja dentro del cuerpo cifrado.

La identidad del remitente va incrustada dentro del cuerpo cifrado del mensaje, endureciéndola frente a cualquier ruta que despoje o reescriba el sobre de transporte. Dicho con honestidad: el relay sigue viendo el enrutamiento remitente-destinatario mientras existe la fila del mensaje, lo que nunca queda expuesto, en ninguna capa, es el contenido.

La carga del push es solo metadatos de enrutamiento.

La carga lleva identificadores de conversación y de mensaje y el handle del remitente para el renderizado; el cuerpo cifrado lo descarga y descifra una extensión de notificaciones en el dispositivo. Un ajuste local del dispositivo oculta por completo al remitente en la pantalla de bloqueo. Los tokens de push se guardan cifrados en reposo con AES-256-GCM bajo una clave interna del servidor y se descifran de forma transitoria, en memoria, solo en el momento de emitir el push.

Todo lo que reposa en el dispositivo está cifrado.

Toda la base de datos local está cifrada a nivel de página con SQLCipher; la tabla de sesiones del ratchet lleva una capa AEAD adicional por fila. La base del monedero es independiente y tiene sus propias claves. El historial multimedia, el desbordamiento de hilos y las cachés de renderizado se cifran con AES-256-GCM bajo claves guardadas en el Keychain; todos los almacenes llevan la protección de archivos de iOS y están excluidos de la copia de iCloud. El acceso a la app se protege con Face ID / Touch ID con PIN de respaldo; la firma del monedero vuelve a pedir autenticación en cada transacción.

En el servidor no existe ninguna clave que descifre contenido del usuario.

Las claves privadas de los usuarios existen solo en sus dispositivos, en el Keychain y el Secure Enclave. El servidor guarda claves públicas, Ed25519, ML-DSA-87, X25519, ML-KEM-1024, preclaves, el material que cualquier par necesita para iniciar una sesión. Su única clave simétrica interna cifra los tokens de push. El transporte cliente-servidor corre sobre TLS con anclaje de certificados, un segundo sobre alrededor de contenido que ya viaja cifrado de extremo a extremo.

El contenido se purga al confirmarse la entrega, en todos los planos.

El contenido de un mensaje entregado se borra en la entrega (queda un talón sin contenido para el estado de entrega); los blobs multimedia entregados se borran al confirmarse la recepción durable; la fila de señalización de una llamada se borra en el instante en que la llamada termina, el historial de llamadas a largo plazo existe solo en el dispositivo del usuario. Un techo de 14 días respalda todo lo no entregado. Las listas de contactos nunca llegan al servidor. El borrado de una cuenta notifica a cada antiguo contacto individualmente y no retiene ningún registro global de cuentas borradas.

Publicamos la superficie residual en lugar de negarla.

Como intermediario de transporte, el relay ve el enrutamiento mientras existe la fila de un mensaje, marcas de tiempo de eventos, tamaños de ciphertext (los cuerpos van rellenados a bloques de 256 bytes), presencia gruesa (una bandera de conexión difusa; el last-seen redondeado a cinco minutos) y la pertenencia a chats. La postura de cero texto plano es estructural y verificable de forma continua, hay acceso de solo lectura a la base de datos de producción para revisores cualificados bajo NDA.