Always encrypted

What "encryption at rest" means

A few plain-English terms make the rest of this chapter easier.

• "At rest" means your data while it's stored on disk, waiting to be used, as opposed to "in transit", which is data moving over the network.
• "Encrypted" means the stored data is scrambled with a secret key. With the right key it turns back into real data; without it, it's noise.
• "Per-tenant" means each customer sharing a server has its own separate key.

"At rest" is your data asleep in its bed. The question a security team asks is: if someone walks off with the disk, what can they read?

Every property value, string, WAL entry and key

In xrayGraphDB, every property value, every string, every write-ahead-log entry and every key is encrypted at rest with AES-256-GCM. The keys that protect the data are themselves wrapped, so a key is never stored in the clear beside the data it protects.

• No off switch — there is no setting, flag or mode that turns encryption off. You can't ship with it disabled by mistake, because it can't be disabled.
• Per-tenant keys — each tenant's property data is encrypted under its own key, so one tenant's key does not unlock another tenant's data.
• AES-256-GCM — a widely used, standardized algorithm that both scrambles the data and detects tampering with it.

It's an apartment building where every unit has its own lock and its own key. Your key opens your door and only your door.

To be exact about scope: the structure of the graph itself (which node connects to which) is stored separately from the property data. Protection for that structure is described in the release notes for the version you run; this chapter only claims what is listed above.

Encrypted in transit, too

xrayGraphDB uses CNSA 1.0 algorithms for data at rest and on the wire: AES-256-GCM for stored records, the write-ahead log and key wrapping, and TLS 1.3 with AES-256-GCM-SHA384 and P-384 on every listener and between cluster nodes. Licences and node identities in Top-Secret and FIPS deployments use P-384.

Toward CNSA 2.0, every TLS connection prefers a hybrid ML-KEM-1024 + P-384 key exchange, and an ML-DSA-87 artifact-signing profile is available. Full CNSA 2.0 conformance is not yet claimed.

FIPS and CNSA, in plain English

• FIPS mode — with FIPS mode on (--fips_mode), xrayGraphDB loads the OpenSSL 3 FIPS provider and refuses to start if it is missing or fails its self-tests. Encryption, TLS, random-number generation and signatures then use that provider, and non-approved algorithms are refused. FIPS mode is off by default.
• CNSA — the U.S. government's suite of cryptographic algorithms for national-security systems. CNSA 1.0 lists algorithms such as AES-256, SHA-384 and P-384; CNSA 2.0 adds post-quantum algorithms such as ML-KEM and ML-DSA.

Using an approved algorithm is like using a well-known, trusted kind of lock. It says which lock is on the door, not that an inspector has signed off on the whole building. This chapter lists the algorithms xrayGraphDB uses and nothing more.

The number you see is the encrypted number

Because there is no unencrypted mode, every performance figure we publish is measured with encryption on. Nobody can quietly turn it off to chase a faster number, because there is nothing to turn off.

Security FAQ

• Can someone ship with encryption off? No. There is no off switch.
• What keeps my customers apart? Each tenant has its own database and its own key, and a user is granted access only to the databases it is given.
• What exactly do you claim? The algorithms the engine uses and what it encrypts, as listed in this chapter. Nothing more.