Oxys DB Studio

Encryption and quantum resistance

Which connections use a post-quantum key exchange, which ciphers are used, how updates are signed, the setting that requires post-quantum encryption, and what is not post-quantum yet.

A large enough quantum computer would break the key exchanges and signatures most encrypted connections rely on today. Traffic recorded now could be decrypted then (“harvest now, decrypt later”). Oxys DB Studio protects against this wherever it controls the connection, and tells you where it cannot.

In short

WhatHow it is protectedPost-quantum?
Desktop to your team server and task runnerTLS 1.3 with the hybrid key exchange X25519MLKEM768 (ML-KEM-768 combined with X25519), AES-256-GCM or ChaCha20-Poly1305Yes: both ends are ours
AI Helper, update check, sign-in with an identity provider (OIDC)The same key exchange offered first; 256-bit ciphers offered firstWhen the other server supports it, otherwise X25519
SSH tunnelsmlkem768x25519-sha256 key exchange offered firstWith OpenSSH 9.9 or later on the server, otherwise classical
Connections to MongoDB and SQL databasesYour system’s TLS libraryDepends on the library and on the database server (see below)
UpdatesA checksum and two signatures, Ed25519 and ML-DSA-65; both must verifyYes
Saved passwords in the key storeArgon2id, then XChaCha20-Poly1305 with a 256-bit keyYes (256-bit symmetric key)

Every post-quantum algorithm is used in hybrid with a classical one, so a weakness in the newer algorithm still leaves the classical protection in place.

Ciphers: 256-bit first

Every key and token the application generates is 256 bits. The application’s own encrypted connections (team server, task runner, AI Helper, update check, identity providers) offer AES-256-GCM and ChaCha20-Poly1305 only. Your team server and task runner never accept AES-128.

A few third-party servers (an old TLS 1.2 server, or a company proxy that inspects traffic) have no 256-bit cipher. For the AI Helper, the update check and identity providers only, when the first attempt fails for that reason, the application tries once more with AES-128-GCM added. Each such retry is written to the log as a warning naming the server. An attacker on your network can force that retry, so against an active attacker the guarantee for these servers is AES-128 or better; the key exchange stays post-quantum where the server supports it. To rule the retry out, require post-quantum encryption (next section).

Require post-quantum encryption

In Edit › Preferences › Advanced settings › Network, tick Require post-quantum encryption with the team server and the task runner (network.configure with pqTls: "require"; the default is "prefer"). Then:

  • a team server or task runner that does not offer X25519MLKEM768 is refused, with an error naming this setting;
  • a team server reached over plain http:// is refused, unless it runs on this computer;
  • the AI Helper, the update check and identity providers use 256-bit ciphers only, without the AES-128 retry: a server that has none is refused with an error naming this setting.

Third-party servers are not required to offer the post-quantum key exchange: you cannot change them, and requiring it would only lock you out.

On the server side, --tls-pq require does the same for the team server and the task runner (see TLS for the team server and the runner). Switch both ends to require once every desktop has been updated. Where TLS ends at a reverse proxy or load balancer, the proxy chooses the key exchange.

What is not post-quantum, and why

  • Database connections. MongoDB and SQL connections use your system’s TLS library, which picks the key exchange. With OpenSSL 3.5 or later (bundled in the Windows packages; on Linux, for example Debian 13, Fedora 42 or Ubuntu 25.04) X25519MLKEM768 comes first, and it is used if the database server supports it too. With older OpenSSL (Ubuntu 24.04, RHEL 9, Debian 12) the connection is classical. The MongoDB driver has no setting for this; an administrator can set Groups in openssl.cnf. IntelliShell (mongosh) uses its own Node.js TLS library, under the same conditions.
  • The team server’s and runner’s own MongoDB store (when they keep their data in MongoDB). Their container images ship OpenSSL 3.5 (Debian 13) and offer X25519MLKEM768 first, but the database server must support it too. A MongoDB server built on OpenSSL 3.0, as in the official mongo container images today, makes that connection classical.
  • Third-party servers choose for themselves: a server without the post-quantum key exchange gets X25519.
  • Signatures that authenticate (TLS certificates, SSH host keys and user keys) are classical: no post-quantum standard for them is deployed yet. They cannot be recorded now and broken later.
  • SSH servers older than OpenSSH 9.9 get a classical key exchange.
  • The Linux Secret Service (where the default encryption stores passwords on Linux) uses the protocol’s own encryption on the local session bus, never on the network. Choose the key store for a stronger guarantee (see Security).

The full inventory of every cryptographic use, for reviewers, is docs/crypto.md in the source repository.