La seguridad es la arquitectura, no una idea de último momento.
Q-Audion está cifrado de extremo a extremo desde la primera línea de código, con un intercambio de claves híbrido clásico y post-cuántico, almacenamiento de claves anclado al hardware en cada plataforma, y un proceso de ingeniería medido frente a estándares de seguridad publicados y redactados de forma independiente.
Un intercambio de claves híbrido pensado para los próximos veinte años, no solo para hoy.
Cada sesión está protegida por dos problemas criptográficos independientes a la vez. Comprometerla — incluso con un futuro ordenador cuántico — exige romper ambos.
Acuerdo de claves post-cuántico
ML-KEM-1024, el mecanismo de encapsulación de claves post-cuántico estandarizado por el NIST (FIPS 203), combinado con X25519 clásico en una construcción híbrida — la seguridad nunca baja de lo que X25519 por sí solo ya garantiza.
FIPS 203 · Categoría 5Identidad autenticada
Cada dispositivo firma su propio material de clave con Ed25519 (RFC 8032). La identidad es verificable de extremo a extremo — incluso en persona, mediante comparación de safety number y verificación NFC tap-to-verify.
Claves ancladas al hardware
El material de clave privada se genera y utiliza dentro de StrongBox en Android y del Secure Enclave en iOS siempre que el dispositivo lo permita — ese material de clave nunca sale de esa frontera de hardware.
Sesiones con forward secrecy
Las claves de mensajes y llamadas avanzan continuamente mediante ratchet. Una clave recuperada en un momento dado no expone las conversaciones anteriores ni posteriores.
Diseñado para dejar el menor rastro posible de ti.
Los fallos de privacidad son casi siempre fallos de metadatos. Nuestra infraestructura de servidor está construida para retener lo mínimo posible sobre quién habla con quién.
Remitente sellado
Las notificaciones push transportan un identificador opaco y salted — nunca un nombre de remitente, una vista previa del contenido, o cualquier cosa que un pipeline de notificaciones fuera de nuestro control pudiera leer.
Adjuntos cifrados
Fotos, notas de voz y archivos se sellan con XChaCha20-Poly1305 antes incluso de salir del dispositivo, y luego se mantienen bajo una segunda capa AES-256-GCM con clave de hardware mientras permanecen en caché en disco.
Efímero por elección
Los temporizadores de mensajes y adjuntos que desaparecen se aplican del mismo modo en cada plataforma, manteniendo sincronizados los dispositivos de los interlocutores.
Números de teléfono, con hash
El descubrimiento de contactos funciona a partir de un hash unidireccional y salted del número de teléfono — nunca el número en claro — de modo que las listas de contactos siguen siendo ilegibles para el servicio que las coteja.
Las partes que nunca ves, sostenidas con el mismo rigor.
Una mensajería vale lo que vale el pipeline que la construye y la distribuye. Cada commit pasa por las mismas puertas automatizadas antes de llegar a un dispositivo.
Certificate pinning, verificado de forma continua
Cada cliente fija el certificado TLS del servidor — y un job automatizado diario verifica de forma independiente que el certificado en vivo sigue coincidiendo con el fijado, en cada plataforma, de modo que cualquier deriva se detecta el mismo día.
Dependencias fijadas y verificadas
Cada librería de terceros está bloqueada a una versión exacta, verificada por checksum. Una build no puede fusionarse con una dependencia no fijada o no verificada — el pipeline la rechaza automáticamente.
Escaneo de seguridad continuo
El código fuente de cada cliente y del servidor pasa por escaneos de seguridad automatizados de forma continua, buscando las clases de vulnerabilidad más relevantes para una aplicación criptográfica en red.
Secretos nunca en el código fuente
Las credenciales de producción viven solo en el entorno de ejecución de la máquina que las necesita, inyectadas al iniciar el proceso — nunca commiteadas, nunca plantilladas en un archivo de configuración del repositorio.
Nos medimos con el mismo rigor que usaría un auditor.
En lugar de declarar nuestra propia definición de "seguro", mantenemos nuestro proceso de ingeniería anclado a marcos escritos y mantenidos por la comunidad de seguridad — y nos reevaluamos a medida que el producto evoluciona.
La referencia del sector sobre lo que una app móvil orientada a la seguridad debe hacer bien — desde el almacenamiento local de datos hasta la interacción con la plataforma y la criptografía.
Aplicado a nuestros servicios backend: autenticación, gestión de sesiones, control de acceso y diseño de API, verificados con la misma checklist que usan los auditores independientes.
Guía cómo gobernamos, identificamos, protegemos, detectamos, respondemos y recuperamos como organización de ingeniería — no solo cómo se codifica una funcionalidad concreta.
Cómo leer esto: son autoevaluaciones internas, realizadas frente a marcos publicados públicamente y actualizadas a medida que cambia el código — no un certificado emitido por un tercero. Cuando exista un sello formal auditado de forma independiente para alguna afirmación que hagamos, nombraremos al auditor y enlazaremos directamente la credencial.
Contacto
Se publicará aquí junto con el public key block antes de la release 1.0 pública.
Abrir un draft security advisory en la pestaña Security del repositorio Q-Audion relevante (GitHub private vulnerability reporting).
Nuestros compromisos
- Acuse de recibo dentro de 48 horas hábiles tras la recepción
- Triaje y clasificación de severidad dentro de 5 días hábiles
- Ventana de divulgación coordinada de 90 días por defecto, extendida solo con acuerdo del reporter cuando una corrección compleja lo requiera
- Crédito público en las release notes salvo solicitud de anonimato
Bug bounty
Un programa bug bounty gestionado estará operativo antes de la 1.0 pública. Mientras tanto, ofrecemos recompensas de buena fe caso por caso para findings de alto impacto.
Scope
- +Todo el código servidor Q-Audion (identidad, gestión de claves, transporte, grupos, prekeys, file storage)
- +Todos los clientes Q-Audion publicados en Android, iOS y Desktop (Windows / macOS / Linux cuando se entregue)
- +Diseño de protocolos criptográficos (handshake PQ, double ratchet post-cuántico, protección de metadatos del remitente, Sigsum Key Transparency)
- +Drift de la wire spec que cause comportamiento cross-platform inseguro
- −Problemas que requieren acceso físico a un dispositivo desbloqueado
- −XSS auto-infligido sin cruzar una frontera de confianza
- −Versiones browser/OS obsoletas fuera de ventanas de soporte del vendor
- −DDoS volumétrico sin logic flaw
- −Ingeniería social del personal Q-Audion
- −Reportes basados en salida de scanner automatizado sin proof-of-concept funcional
Wire specification abierta
El contrato cross-platform del protocolo es byte-idéntico entre todos los clientes Q-Audion. La spec está espejada en los repositorios cliente y en el repositorio server como commit gating para cualquier cambio wire. Revisores independientes pueden leerla antes de abrir una sesión — y las implementaciones de librería (liboqs, BouncyCastle, @noble/post-quantum) se cross-validan contra vectores KAT compartidos.
Builds reproducibles (objetivo 1.0)
Todos los artifacts de release 1.0 (APK, IPA, instaladores Desktop) estarán firmados con Sigstore. La reproducibilidad independiente desde fuentes es criterio de go-release: cualquiera puede verificar que el binario entregado coincida con el código fuente público.