Cryptographic stack
Detailed specification of every algorithm used: ML-DSA-65 (FIPS 204), ML-KEM-768 (FIPS 203), XChaCha20-Poly1305 (RFC 8439), SLH-DSA (FIPS 205), HKDF, BLAKE3, and the libsodium / BoringSSL primitives.
Cryptographic specification, threat model, architecture.
The UltimaOS whitepaper is a consolidated technical specification of the cryptographic stack, the threat model, and the architectural choices that make UltimaOS verifiable. It is the source of truth for any security claim made on this site.
Detailed specification of every algorithm used: ML-DSA-65 (FIPS 204), ML-KEM-768 (FIPS 203), XChaCha20-Poly1305 (RFC 8439), SLH-DSA (FIPS 205), HKDF, BLAKE3, and the libsodium / BoringSSL primitives.
Explicit enumeration of adversary capabilities UltimaOS defends against: passive network observers, malicious infrastructure providers, malicious workspace admins, device theft, compelled disclosure, and quantum harvest-now-decrypt-later.
Full specification of the 3-of-5 social recovery scheme, including key generation, secret sharing parameters, recovery ceremony, and operational guidance for users and trustees.
The whitepaper describes the UltimaOS architecture from the user's device through the EU infrastructure to the recipient's device, covering all trust boundaries and the cryptography applied at each.
Web and desktop clients built on a shared TypeScript core. Local storage encryption with passphrase-derived keys. Sandbox isolation between apps. Open-source code under the AGPL-3.0 license.
Stateless API servers behind a load balancer, durable object storage, encrypted blob store with EU-only replication, no plaintext processing pipeline.
Account key generation on first device, device-specific key derivation, optional hardware-key support, social recovery configuration, and rotation ceremonies.
Continuous deployment with reproducible builds, signed updates, hardware security modules for signing keys, regular third-party audits, and a public bug bounty program.
The whitepaper assumes the reader is a security engineer or cryptographer. Notation follows the IETF conventions. Every algorithm is identified by its RFC or FIPS number.
The whitepaper does not require access to the source code to be useful, but cross-references specific source files for the implementation. Auditors can validate claims against the code.
The whitepaper is updated whenever the cryptographic stack changes. Each version is dated and changelogged. The PDF includes an Ed25519 signature for integrity verification.
The whitepaper is the canonical reference for any UltimaOS security claim. If you are writing a security assessment or vendor review, cite the latest version with its signature.
The whitepaper is available as a PDF from the UltimaOS press kit or directly from the engineering documentation portal. The PDF includes an Ed25519 signature for integrity verification.
Yes. Each version of the whitepaper is signed with the team's release key. The signature is published alongside the document so readers can verify they have an unmodified copy.
The whitepaper is updated whenever the cryptographic stack changes — typically 1 to 3 times per year. The version history is on the whitepaper page with dates and a summary of changes.
Yes. The AI inference architecture is described, including the encryption of prompts and responses, the routing of inference to OpenAI-compatible endpoints, and the user-controlled API key handling.
Yes. The whitepaper is published under CC-BY-4.0 for the text and the algorithms described. The PDF may be redistributed with attribution. Cite the version number and date.
Currently the whitepaper is published in English only. Translations to French, German, and Spanish are planned for 2027 once the document stabilizes.
Yes. Appendix A includes test vectors for the key encapsulation, signing, and symmetric encryption primitives. These match the official NIST test vectors where applicable.
Each release is reviewed by at least two independent cryptographers not employed by UltimaOS. Their names are listed in the acknowledgments section of the whitepaper.