Generate
Browser WebCrypto generates the file key and a random 8-byte IV base.
Cryptographic Protocol
Don’t trust our claims. Verify the evidence.
WSD evidence does not depend on a logo, screenshot, database entry or assertion from We Secure Data. Each evidence bundle cryptographically binds protected content to its recorded provenance.
The WSD application creates the evidence. Standard cryptography verifies it.
Published protocol
Public algorithms. Proprietary application.
WSD’s application source code remains proprietary. The algorithms, evidence structure and verification procedure are documented so third parties can reproduce the checks. Private keys and customer key material remain secret.
| Component | Implementation |
|---|---|
| Content cipher | AES-256-GCM using browser WebCrypto |
| File key | Fresh random 256-bit data-encryption key for each file encryption |
| Chunk authentication | 128-bit GCM authentication tag and canonical JSON authenticated data |
| Key protection | File keys wrapped using a separate Google Cloud KMS content-encryption key |
| Provenance signature | ECDSA using NIST P-256 and SHA-256 |
| Signature encoding | DER ASN.1 ECDSA |
| Canonicalisation | Deterministic compact UTF-8 JSON with sorted keys |
| Key discovery | /.well-known/wsd-keys.json on the issuing WSD service |
| Audit evidence | Signed daily Merkle anchors and inclusion proofs, when available |
Content encryption
Authenticated encryption begins in the browser.
For encrypted file workflows, the browser generates a new random 32-byte data-encryption key and encrypts the file with AES-256-GCM. Files are processed in chunks, normally 4 MiB.
Construct IVs
Each chunk receives a distinct 12-byte IV: the IV base followed by its big-endian 32-bit chunk index.
Bind metadata
Authenticated data binds the version, object key, chunk index, chunk size, plaintext size and IV base.
Encrypt
AES-GCM produces ciphertext and a 128-bit authentication tag for each chunk.
Wrap the key
The file key is wrapped by KMS with context binding it to its message, document and version.
Changing encrypted bytes, an authentication tag or authenticated metadata causes decryption authentication to fail. WSD stores encrypted content, encryption metadata and the wrapped file key for online-key workflows.
Key separation
Encryption keys and signing keys have different jobs.
The content-encryption KMS key wraps and unwraps per-file data-encryption keys.
The provenance key signs canonical evidence. It does not encrypt customer content.
A separate audit-signing key signs deployment-wide daily Merkle roots.
Signed provenance
How the proof chain is created.
Hash content
SHA-256 fingerprints identify the exact content represented by the evidence.
Build the record
The record binds relevant hashes, object identifiers, recorded identities and recorded UTC times.
Canonicalise
Signing excludes signature, bundle_manifest, bundle_artifacts and public_anchor, then encodes the remaining record deterministically.
Sign in KMS
KMS signs the SHA-256 digest of the canonical bytes using ECDSA P-256.
Identify the key
The evidence records the organisation key ID, exact key version, algorithm and DER-encoded signature.
Independent verification
Verification is a reproducible mathematical check.
Once the relevant public key has been obtained from an authenticated WSD key endpoint or another trusted source, the evidence can be verified without the WSD application, access to the original WSD account, or reliance on a WSD database response.
Verification procedure
- Establish trust in the organisation’s public key or retained key fingerprint.
- Recalculate SHA-256 for each supplied protected file.
- Reconstruct the canonical unsigned provenance payload.
- Verify its DER ECDSA signature with the trusted P-256 public key.
- Check the bundle manifest for missing or changed artifacts.
- When present, verify the audit-event hash, Merkle path and signed public anchor.
The trust root matters
A public key merely included inside an otherwise untrusted bundle proves only that the bundle is internally consistent. It does not, by itself, prove WSD origin.
Origin requires the relevant key to be obtained from the authenticated key endpoint or another trusted source, such as a previously retained public key or fingerprint.
Portable evidence
What an evidence bundle contains.
A bundle can contain the protected files, signed provenance.json, public-key material, a SHA-256 manifest, independent-verification instructions and an offline HTML verifier. Where a valid daily anchor is available, it also contains the signed audit anchor and Merkle inclusion proof. If anchoring is still pending, the bundle records that state instead of claiming failure or completion.
The HTML verifier is a convenience interface, not the source of truth. Another implementation can verify the JSON evidence directly.
What the result means
Cryptography proves specific facts—not every surrounding claim.
The supplied content matches the signed hashes, the record has not changed, and the signature corresponds to the trusted organisation’s public key.
The signature protects the sender identity and UTC time recorded by WSD. It does not independently validate a person’s real-world identity.
The current evidence records a signed WSD time; it does not contain a third-party timestamp-authority token.
Inspect the evidence, not its appearance.
Verification is not a request for WSD to confirm its own database record.
Explore provenance