Saying 'encrypted' precisely

The word does almost no work on its own

Encrypted how, with what, protecting against whom. A claim that does not answer those three questions cannot be assessed, which means a reviewer has to either take it on faith or ask you the questions anyway.

So we would rather publish the specifics. Every item below is a statement a security team can push back on, which is exactly what makes it worth stating.

Passwords: scrypt, with the parameters written down

User passwords are hashed with scrypt at N=16384, r=8, p=1, with a 16-byte random salt per password, and compared in constant time.

The parameters matter as much as the algorithm. Naming a memory-hard function while running it at parameters that fit comfortably on a GPU is a common and entirely hollow claim. Publishing the cost parameters is what turns the sentence into something checkable.

Constant-time comparison is the small detail that gets skipped. A comparison that returns early on the first differing byte leaks information through timing, and the fix costs nothing.

Stored credentials: AES-256-GCM, with the tag verified

Credentials the platform holds for connecting to other systems are encrypted with AES-256-GCM, and the authentication tag is checked on every decrypt.

The second half of that sentence is the half that matters. GCM is an authenticated mode, which means it can tell you that a ciphertext has been tampered with but only if you actually verify the tag rather than treating it as a checksum you can skip when it is inconvenient.

Encrypted values carry a version marker in their stored format. That sounds like housekeeping and is in fact what makes rotating a scheme possible later without a flag day.

Sessions: signed tokens

Session tokens are signed so that the server can detect any modification. Signing is not encryption and we are careful not to conflate the two: a signed token proves integrity and origin, it does not make the contents secret.

Which is why the contents are kept to what is needed for the session and nothing more. Anything sensitive stays server-side and is referenced, not carried.

Integrity: SHA-256 across the audit trail

Audit records and the chain of custody over them are hashed with SHA-256. This is a different property from confidentiality, and worth separating clearly: the point is not to hide the audit trail but to make silent alteration of it detectable.

In a clinical system the audit trail is frequently the most important record in the building. Treating its integrity as a first-class requirement rather than a side effect of database permissions is a deliberate choice.

In transit: TLS at the edge and inward

Traffic terminates over TLS at the edge and travels onward to the application over an encrypted tunnel.

As with everything above, the useful version of this claim is the specific one. 'We use TLS' says nothing about where it terminates or what happens after it does, and those are the parts a reviewer cares about.

Why we publish it this way

A precise claim is falsifiable. If any statement above is wrong, someone can tell us, and that is worth far more than a vaguer sentence that nobody can argue with.

It also disciplines us internally. It is uncomfortable to write down exactly what a mechanism protects, because doing so makes visible what it does not. That discomfort is the mechanism working: it is how a security roadmap gets prioritised by something other than whichever risk was mentioned most recently.

If you are evaluating us and want to go deeper than a public page reasonably should, ask. Security reviews are a normal part of this business and we would rather have the conversation early.