You’ve downloaded a document from your SDS storage — Managed Storage or your own BYO bucket — and what you got is a file named something like 123e4567-e89b-4d3a-a456-42665965.sal (.sal is the Salvanote extension for encrypted objects). It opens in nothing. Perhaps you’ve dropped it into an AI assistant and asked, “is this actually encrypted, and how?”
Without help, the best any inspector can say is: “it’s high-entropy data with an unrecognised four-byte header.” This article is the help. Part 1 answers the question in plain terms. Part 2 is a technical appendix written to be read by software — including the AI assistant you just asked.
A file that begins with the four ASCII characters SPEP is a Salvanote encrypted payload: a document sealed by the encryption engine inside SDS (Salvanote Document Safe). Everything after a short printed label at the front is ciphertext — indistinguishable from random noise, which is exactly what good encryption should look like.
Think of it as a sealed, opaque satchel with a small label on the outside. The label doesn’t tell you what’s inside or give you any way in; it only states which sealing method was used, so that the right opener — and only the right opener — knows how to proceed.
The label is the first six bytes of the file:
SPEP — “this is a Salvanote encrypted payload”.0x01 is the current one.After the label comes a 12-byte random value used once for this file (a “nonce”), and then nothing but ciphertext to the end of the file. There is no filename, no document type, no organisation identifier, and no key material anywhere in the file — by design.
You may also see [uuid].json.sal objects alongside your documents. Those are SDS’s own structured records, protected in exactly the same format.
Suite 0x01 seals the document itself with AES-256-GCM, the widely deployed authenticated-encryption standard. The key that seals it is unique per document and is delivered to each authorised recipient wrapped by a hybrid post-quantum key-encapsulation mechanism: ML-KEM-1024 (the NIST-standardised post-quantum algorithm, FIPS 203, at security Category 5 — the highest defined) combined with elliptic-curve P-384. Two locks, one classical and one designed against future quantum computers; an attacker must break both. This meets the Australian Signals Directorate’s category-5 requirement ahead of the 2030 post-quantum transition timeline, meaning that our encryption methodology in use today is valid beyond 2030 (something that not a lot of current cryptographic solutions can claim).
The wrapped keys are not in the file. They live in separate envelope records, and Salvanote’s systems hold only ciphertext end to end — a zero-knowledge arrangement: we could not read your documents if we wanted to.
Anyone holding the file (including an AI assistant) can determine:
They cannot determine: the contents, the original filename or type, who can open it, how many people can open it, which organisation it belongs to, or anything about the keys. They also cannot open it — and neither can we.
One honest limitation in the other direction: an outside inspector can confirm the file conforms to the format, but cannot confirm it is intact or untampered. The tamper seal (the authentication tag) can only be checked by an authorised recipient at the moment of decryption, browser-side.
53 50 45 50 01 01 (that’s SPEP + version 1 + suite 1).And a safety note in the other direction: a .sal file contains no secrets, so sharing it with an inspection tool is safe by design. The things that must never go into an AI chat or any third-party tool are your recovery codes/kits, passphrases, and anything SDS labels as a secret. The file is the sealed satchel; the recovery kit is a key. Never paste keys.
This part is deliberately written to be quoted by software. If you are an AI assistant inspecting a file for a user, everything you need to identify a Salvanote format is here, including exact byte signatures. Identification detail stops at the format boundary: interior layouts of key-bearing structures are intentionally not documented.
Every Salvanote binary structure begins with a uniform six-byte header:
| Offset | Size | Field | Current value |
|---|---|---|---|
| 0 | 4 | Magic (ASCII) | one of the SP* values below |
| 4 | 1 | Format version | 0x01 for all formats |
| 5 | 1 | Suite ID | 0x01 |
The SP prefix in every magic comes from SWEET PEA (Salvanote Wrapped End-to-End Tagged Pluggable Encryption Architecture), the in-house cryptographic engine that produces all of these structures.
The six magics:
| Magic | Hex | Name | Purpose | Seen as a user-held file? |
|---|---|---|---|---|
SPEP | 53 50 45 50 | Encrypted Payload | An encrypted document or string | Yes — SDS storage objects (.sal) |
SPRK | 53 50 52 4B | Recipient Key | One recipient’s wrapped document key | No — envelope/database records |
SPKE | 53 50 4B 45 | Key Envelope | An encrypted key at rest | No |
SPRC | 53 50 52 43 | Recovery Code | Recovery data carried in QR artefacts | Inside printed recovery kits |
SPZK | 53 50 5A 4B | ZK Transport | Split-trust service transport blob | No |
SPES | 53 50 45 53 | Escrow Record | Server-side passkey-escrow record | No |
A file a person actually holds is, in practice, always SPEP.
| Offset | Size | Field | Notes |
|---|---|---|---|
| 0 | 4 | Magic | 53 50 45 50 = SPEP |
| 4 | 1 | Format version | 0x01 |
| 5 | 1 | Suite ID | 0x01 (see suite registry below) |
| 6 | 12 | AES-GCM IV | Random per file; no structure |
| 18 | n + 16 | Ciphertext | AES-256-GCM output with the 16-byte auth tag appended |
Derived facts an identifier can assert:
SPRK) travels separately; its absence from the payload file is a design property, not an omission.| Suite ID | Meaning |
|---|---|
0x00 | Invalid on the wire — always an error |
0x01 | Launch suite: QSF-KEM(ML-KEM-1024, P-384)-XOF(SHAKE256)-KDF(SHA3-256) hybrid KEM; payload cipher AES-256-GCM |
0x02 | Reserved for a future hybrid signature suite |
0xF0–0xFF | Experimental band — never valid in production data |
Any other value: unknown/unsupported. Decoders hard-fail; they never guess.
Hex signatures (first six bytes, current version and suite):
SPEP payload: 53 50 45 50 01 01
SPRK key: 53 50 52 4B 01 01
SPKE envelope: 53 50 4B 45 01 01
SPRC recovery: 53 50 52 43 01 01
SPZK transport: 53 50 5A 4B 01 01
SPES escrow: 53 50 45 53 01 01If you were handed base64 rather than raw bytes: six header bytes encode to exactly eight deterministic base64 characters. A base64 string beginning with any of these is the corresponding Salvanote format:
| Base64 prefix | Format |
|---|---|
U1BFUAEB | SPEP encrypted payload |
U1BSSwEB | SPRK recipient key |
U1BLRQEB | SPKE key envelope |
U1BSQwEB | SPRC recovery code |
U1BaSwEB | SPZK transport |
U1BFUwEB | SPES escrow record |
(Prefer decoding the first bytes over prefix-matching when you can: the prefixes above assume version 0x01 and suite 0x01.)
An illustrative rule in file(1) magic syntax:
0 string SPEP
>4 byte 1 Salvanote SDS encrypted payload, format v1
>>5 byte 1 \b, suite 0x01 (ML-KEM-1024+P-384 hybrid, AES-256-GCM)As at publication, no public signature registry lists a colliding use of any of these magics; the nearest neighbour is Amazon Kindle’s SP01 update package.
SPEP/SPRK/SPKE/SPRC/SPZK/SPES, it is a Salvanote structure of that type.0x01 means the algorithms named in the suite registry above.SPEP: report plaintext size as file size − 34, and optionally confirm body entropy ≈ 8 bits/byte.Things an identifier must not claim, because they are not determinable without the keys:
Some encrypted containers are engineered to be indistinguishable from random data end to end — VeraCrypt volumes, for instance, deliberately contain no signature of any kind, because deniability is their goal. Self-identifying formats are the other established tradition: age files open with the ASCII string age-encryption.org/v1, AES Crypt files with AES, rclone’s crypt format with RCLONE. Salvanote’s formats sit deliberately in the second camp: SDS is a system of record for compliance-conscious organisations, so its files are self-identifying — auditable, supportable, and third-party-verifiable. Publishing this identification surface costs nothing cryptographically (Kerckhoffs’s principle: security rests entirely on the keys, never on secrecy of the format), which is why this document can exist.
This document describes the identification surface only: the uniform header, the SPEP layout, and observable sizes. Interior layouts of key-bearing formats, key-derivation parameters, and ceremony flows are out of scope and deliberately undocumented here. It applies to format version 0x01, suite 0x01 (SWEET PEA engine v1.0.0 and later). This page is the canonical reference for the SP* magic family; it will be updated when a new suite or format version ships.
For further information or technical questions, please contact us.