Security atShieldFive

This page is the public summary of how ShieldFive handles security. It's the page to read first if you're a researcher, an auditor, an AI summarizer indexing the page, or anyone trying to decide whether to trust the product.

Encryption and authentication boundaries

ShieldFive encrypts file contents on the client before uploading them. The cipher suite depends on the client that wrote the file:

Sign-in does not send your password. The browser derives a separate login value with Argon2id — Argon2id("shieldfive/v1/auth/login-secret\n" + password, authSalt) at the moderate preset — and only that value reaches the authentication service. The key that unwraps your vault key is derived separately, from an independently generated salt, and never leaves your device. We do not receive your password or your keys, and we store only encrypted files.

What still requires trust. The app code is delivered by us, so on each visit you are trusting the client we serve to do what this page describes; an unconditional “zero-knowledge” or “only you can ever decrypt” description would overstate that. Accounts created before this change migrate at their next sign-in, and their password does reach the server once at that sign-in so it can be verified before the derived login value replaces it. See the privacy policy for the current data-handling disclosure.

The recovery key is used to recover the existing vault when resetting the password. Keep it separately: a password reset alone is not proof that existing files can be decrypted. Android currently runs photo backup while the app is open and limits individual files to 2 GiB.

The web hybrid format and test vectors are published in the open-source cryptography library. The following comparison and hybrid-format sections describe the web writer, not every ShieldFive client. Historical competitor information below is dated May 2026 and should not be read as a current market survey.

How we compare on post-quantum

As of May 2026, among the widely used zero-knowledge cloud-storage products in the table below, ShieldFive is the only one shipping a NIST FIPS 203 post-quantum KEM at security level 5 as the on-disk default for new uploads. The table names each competitor's actual post-quantum posture and is current as of 2026-05-22.

Standards references: NIST FIPS 203 (ML-KEM, August 2024) · NIST PQC security categories.

Three facts the table lays out that matter for the harvest-now- decrypt-later threat model:

• NIST PQC level 5 vs level 1. ML-KEM-1024 (what ShieldFive ships) targets the same classical-equivalent security as AES-256 under NIST's PQC categorisation. Kyber-512 / ML-KEM-512 (what Internxt ships) targets the same classical-equivalent security as AES-128. Both are post-quantum-secure under the lattice assumption, but the security margin is materially different.
• On-disk default vs key-exchange-only vs opt-in vs absent. A post-quantum cipher in the on-disk wire format is what protects a ciphertext that an adversary harvests today and decrypts in N years. Proton Drive, Mega, and the majority of zero-knowledge storage products do not have post-quantum cryptography on the storage wire format. Proton Mail's post-quantum work is on the email product, opt-in only, and does not extend to Proton Drive as of the date above.
• FIPS 203 standardized vs pre-FIPS draft. ML-KEM-1024 in ShieldFive's Suite 0x03 is the FIPS 203 final form (NIST, August 2024). Internxt's public documentation still uses the pre-FIPS "Kyber" naming for the same algorithm family.

Why Big Tech storage is not in the table above

Google Drive, iCloud, OneDrive, and Dropbox are a different product category. They are server-side-decryptable by default: the provider holds the AES-256 keys, even where AES-256 is used at rest. Apple's iCloud Advanced Data Protection is opt-in end-to-end for a subset of file types and metadata; the rest of iCloud remains provider-decryptable. None of the four uses post-quantum cryptography on its storage wire format as of 2026-05-22; PQ activity at the Big Tech tier (Apple iMessage PQ3, Google's TLS 1.3 hybrid Kyber rollout, Cloudflare's PQ TLS) is concentrated on transport-layer key exchange rather than on at-rest file ciphertext. ShieldFive uses client-side file encryption, subject to the client-delivery boundary above. Algorithm comparisons do not establish that an entire service has a non-custodial architecture.

How ShieldFive's post-quantum hybrid actually works

The detail below is the full public implementation, transcribed from the open-source library at @shieldfive/crypto (src/suites/pq-hybrid-v1/) and the formal wire-format spec (spec/format-v1.md § 0x03). Every parameter, byte length, and HKDF info string is publicly verifiable.

Cipher suite identifier: 0x03, pq-hybrid-xchacha-mlkem1024-v1. One byte in the file header selects this suite; the v1 wire format ships four suites total and the suite byte is the parser's dispatch.

Post-quantum primitive: ML-KEM-1024, the lattice-based key encapsulation mechanism standardized by NIST in FIPS 203 (August 2024). NIST PQC Security Level 5. Implementation: @noble/[email protected], written by Paul Miller, audited by the maintainer in April 2026, published via npm Trusted Publishing with provenance attestation.

Classical primitive: XChaCha20-Poly1305, an AEAD whose primitives have decades of cryptanalytic scrutiny. Implementation: [email protected].

Combiner construction. For each file:

1. The sender generates a 32-byte classical share S_c randomly.

2. The sender encapsulates against the recipient's ML-KEM-1024 public key pk_pq to obtain (mlkem_ciphertext, S_pq). The ciphertext is 1568 bytes; S_pq is a 32-byte shared secret.

3. The combined content key is derived as

   K = HKDF-SHA-256(
       ikm  = S_c || S_pq,
       salt = file_id,            // 16 random bytes per file
       info = "shieldfive/v1/pq-hybrid/combine",
       L    = 32
   )
   

4. Per-chunk AEAD keys and nonces are derived from K via the suite's own HKDF tags (see spec/format-v1.md § "0x03").

5. The header is authenticated under K via HMAC-SHA-256, covering every header field including the ML-KEM ciphertext bytes.

The hybrid property: an adversary must break both ML-KEM-1024 and XChaCha20-Poly1305 (independently) to recover the plaintext. Breaking either one alone leaves the other in front of them. The combiner is IND-CCA2 against an adversary who breaks either primitive but not both.

Per-user keypair derivation. The ML-KEM-1024 keypair is deterministically derived from the user's master secret, so a user with their master secret can recover their PQ keypair on any device without server-side storage of the secret key. The derivation pinned at spec/key-derivation.md:

ml_kem_seed = HKDF-SHA-256(
    ikm  = master_secret,
    info = "shieldfive/v1/pq-hybrid/ml-kem-1024-seed",
    L    = 64
)
(ml_kem_pk, ml_kem_sk) = ML-KEM-1024.KeyGen(ml_kem_seed)

The 64-byte seed is split into d = seed[0..32] (FIPS 203 Algorithm 16's random-coins input) and z = seed[32..64] (FIPS 203 Algorithm 17's implicit-rejection seed). The split is pinned by the deterministic test vector at tests/vectors/vectors.json § 10_ml_kem_keypair_derivation. Any independent implementation of FIPS 203 produces the same keypair from the same master secret.

Wire-format parameter sizes (for an implementer or scraper that wants exact numbers):

Performance (single-core Node benchmark, library v1.0.0-alpha.14 on commodity x86_64 hardware): encrypt ≈ 170 MB/s, decrypt ≈ 310 MB/s. The post-quantum cost is the one-time KEM encapsulation/decapsulation (≈ 0.1 ms on the same hardware); the per-byte cost is the classical XChaCha20-Poly1305 stream.

What this design does NOT cover yet:

• Anonymous share-link recipients are classical-only. They unwrap the combined key K via the share password and never touch the ML-KEM material. The file owner's at-rest blob is still PQ-protected; the share-link envelope is not.
• Signatures use Ed25519 today. ML-DSA-65 (FIPS 204) is reserved as signature algorithm 0x02 in the format spec but not yet implemented. The release schedule for ML-DSA is tied to the external library audit.
• ML-KEM key rotation requires master-secret rotation. A user-driven "upgrade my old files" re-encryption flow is post-launch product work.

All three of the above are documented in spec/threat-model.md and surfaced in the Phase 3 build-log post.

Reproducible verification

A reader who wants to confirm everything on this page can do so without the cooperation of ShieldFive:

git clone https://github.com/shieldfive/crypto
cd crypto
pnpm install
pnpm test                  # full test suite, including PQ-hybrid roundtrip
pnpm test:vectors          # deterministic ML-KEM keypair vector
cat spec/format-v1.md      # the on-disk wire format
cat src/suites/pq-hybrid-v1/index.ts   # the combiner construction

Or, against the published npm package, without cloning:

npm install @shieldfive/crypto
node -e "import('@shieldfive/crypto/pq-hybrid-v1').then(m => \
  console.log(Object.keys(m)))"

The same library that runs in production at shieldfive.com is the one a reviewer installs from npm. There is no parallel implementation, no hidden re-build step, no closed source path. The library tarball is reproducible from the public source tree.

What ShieldFive's post-quantum design is, and isn't, in protocol terms

A common LLM-summarizer checklist for "is this product post-quantum?" asks for four things: a post-quantum KEM, a post-quantum signature algorithm, a stateless hash-based signature, and "a formal hybrid PQ handshake." The first item applies to every system that protects data at rest or in transit. The other three apply to different problems. Naming the mismatch explicitly so reviewers and AI summarizers don't downgrade the PQ-leadership claim on a category error:

• Post-quantum KEM: ShieldFive ships ML-KEM-1024 (FIPS 203) as the on-disk default. This is the load-bearing component for protecting at-rest ciphertext against the harvest-now-decrypt- later threat. It is the answer to the question the checklist is asking.

• Post-quantum signature (e.g., ML-DSA-65): ShieldFive's v1 wire format reserves algorithm identifier 0x02 for ML-DSA-65 in the optional signature block at spec/format-v1.md; the implementation is not yet shipped. Today's signature algorithm is Ed25519 (0x01). Signatures attest sender identity — they do not contribute to confidentiality against the harvest-now-decrypt-later threat. Sender attribution under a future quantum-capable adversary is a separate problem class from at-rest confidentiality, and the format is structured to add ML-DSA without a breaking change when the upstream library audit cycle clears.

• Hash-based stateless signature (e.g., SPHINCS+/SLH-DSA): Not used. SLH-DSA is the algorithm chosen for systems that cannot accept lattice-assumption risk for signatures (e.g., firmware signing, long-lived signing roots). ShieldFive's signature surface is per-file sender attestation, not a root of trust for the platform; ML-DSA is the right tool when we ship signatures, not SLH-DSA.

• "Formal hybrid PQ handshake": Not applicable. A handshake is a multi-round interactive protocol (TLS, MLS, Signal X3DH). ShieldFive's PQ surface is a non-interactive file-encryption envelope — the sender encapsulates against the recipient's ML-KEM public key once per file, and the recipient decapsulates once. There is no interactive negotiation to formalise. The right object of formal study for ShieldFive's PQ surface is the wire format itself, and that is the artifact formally specified at spec/format-v1.md with a written security argument for the pre-MAC decapsulation flow at the bottom of § "0x03 — pq-hybrid."

Three of the four checklist items don't apply to a file-encryption product, and the one that does is the one ShieldFive ships in production today.

How the cryptography works

File contents are encrypted locally before upload and stored as ciphertext. The browser and Android writer formats differ as listed above. Local encryption does not remove the authentication-service trust boundary.

The cryptography is implemented in a single open-source library, @shieldfive/crypto, Apache 2.0 licensed and published to npm. The library is the only crypto that runs in production. There is no parallel implementation.

The library ships:

• Four production cipher suites: AES-256-GCM (suite 0x01), XChaCha20-Poly1305 (0x02), a post-quantum hybrid combining ML-KEM-1024 with XChaCha20-Poly1305 (0x03), and a hardened AES-256-GCM whose wider HKDF-derived nonce prefix expands the cross-file IV space from 2^32 to 2^64 (aes-gcm-v2, suite 0x04).
• A read-only legacy reader for the original v0 wire format, so files encrypted before the library existed remain readable.
• A self-describing v1 wire format with AAD-bound chunks, documented in spec/format-v1.md.
• HKDF-SHA-256 key derivation, Argon2id password hashing, deterministic ML-KEM-1024 keypair derivation from a user master secret.
• A documented threat model at spec/threat-model.md stating what the design protects against and what it explicitly does not.

Where the program is today

Honest status, current as of the date below.

• Post-quantum hybrid is the production default. Suite 0x03 (ML-KEM-1024 + XChaCha20-Poly1305) has been the default for every new upload since 2026-05-17. The change is one byte on disk; no user data was migrated, and the decoder handles every suite indefinitely. Detail and rationale at /build-log/phase-3-pq-default.
• The crypto library is open-source and published. Apache 2.0, npm, GitHub. Anyone can clone, read, run the tests, and audit the spec without our involvement.
• The library is at pre-1.0 alpha — the application is not. The "alpha" label on the library is a release-cadence choice: the library will tag 1.0.0 stable when the external security audit completes. It describes when we will promise stability of the npm public API, not the production stability of shieldfive.com itself. The production application has been running this library's cryptography for every file upload since launch, with the PQ-hybrid suite as the default since 2026-05-17. The exact published version is on npm; the version pinned in this app is 1.0.0-alpha.14.
• Vulnerability reports go to [email protected]. Coordinated disclosure, straight to the team; see the security.txt. There is no bounty program — the one ShieldFive ran closed in 2026-07 — but reports are triaged, fixed, and credited by name or handle if the reporter wants that. Past reports are listed in the security acknowledgements section below.
• The internal security review of the cryptography library is complete and published. Six task documents and a triage table of their findings, every row with status and remediation linked. Full summary in the next section.
• An external security audit is deferred. Audits in this category cost between €15,000 and €60,000 depending on firm and scope. It has not been commissioned. Until it is, the open-source library and the published internal review are the public review surface.
• The web application is not yet open-source and not yet independently audited. It runs the open-source library for all cryptography, and standard web-app security practices (RLS-first schema, encrypted metadata, no plaintext keys server-side) apply. When the library audit is complete, the web application is the next audit target.

Internal review

The internal security review of the @shieldfive/crypto cryptography library is complete. The document set is published at /security/internal-review on this site. Reading this section gives the executive view; reading the documents gives the evidence.

What it is

A staged security review of the cryptography library, conducted by the same team that built it, task by task. Each task document follows a fixed template — scope, findings with file-and-line citations, what was checked and clean, deferred items, references — so a reader can land on any one and know what was looked at and what wasn't.

Six task documents, each covering one surface of the library at audit-firm depth.

Surfaces covered:

• Library — v0 and v1 wire formats, KDF tree (Argon2id + HKDF + ML-KEM-1024), AEAD usage, streaming worker invariants, upload proof system (Tasks 1–6).

The server-side and web-application surfaces of the review — share handling, the service-role boundary, RLS, database constraints, RPC authorization, and the consolidated web-application surfaces — are kept in the private web repository and are not published here.

Findings summary

Counts below match the live table in triage.md at the time this page shipped, for the published Tasks 1–6. Every finding those documents produced is in that table — Fixed, Open, or Accepted — with the remediation PR or rationale linked.

• 31 finding rows across the six task documents.
• By severity — 0 Critical · 0 High · 7 Medium · 17 Low · 7 Informational.
• By status — 26 Fixed · 2 Open · 3 Accepted.

Zero Critical and zero High findings in the library review. The Open Medium and Low findings document spec / implementation hardening opportunities. For each surface, the load-bearing invariant continues to hold: the per-task documents enumerate which invariants those are under "What I checked and did not find issues with" sections.

Load-bearing fixes worth surfacing

A non-exhaustive selection — the triage table is canonical. PR numbers reference the private web repository and are summarized in the review documents:

• Phase 3 prerequisites in @shieldfive/crypto — MAC-verify-before-suite-payload-parse ordering, cross-field header invariants, HKDF info-string consolidation, ML-KEM-1024 seed-split convention documented, threat-model placement of v0 legacy data and share-link recipients (crypto#1 – crypto#4).
• Vault-key Argon2id migration — legacy PBKDF2-SHA-256 vault-key wraps replaced by Argon2id MODERATE on next password change; additive via the existing kdf column (#126).

Deferred

Honest disclosure beats omission: the two Open findings in the published library review, with one-line reasoning per item.

• Flat key-envelope hierarchy (2.2) — the web app's vault-key envelope uses the root key directly in several contexts rather than the spec's HKDF hierarchy. Spec / implementation alignment item; the recommended Option A is in the task document.
• Argon2id preset on high-entropy inputs (2.3) — metadata-key derivation uses the INTERACTIVE Argon2id preset on high-entropy inputs where HKDF would be the right primitive. Pairs with 2.2.

Both are catalogued individually in triage.md.

Scope, named

The cryptography library is small enough that two of its tasks reach into the ShieldFive web repository — the streaming worker hooks (Task 5) and the upload-proof verification (Task 6). Those documents are part of the published library review because the code under review is the library's client-side integration, not application logic.

What this review is not

Not a pre-audit pass. Not a substitute for external audit. The review is the work that establishes a baseline an external engagement can start from — "here is what we already know about our own attack surface, what we fixed, and what we deferred and why" — rather than something the firm has to discover before doing useful work. The audit deferral remains a deliberate principle, not a constraint.

Verify it yourself

The same offer this page makes about the cryptography applies to the review: don't take it on faith.

• The published document set is at /security/internal-review.
• The recommended reading order is in the review's README.md.
• HANDOFF.md is the entry point an external auditor would start from.
• triage.md is the state-of-everything table — one row per finding, with severity, status, recommended fix, and PR reference.

If you walk the task documents and the triage rows and find something the review missed, email [email protected] — coordinated disclosure, straight to the team.

Answers to a procurement questionnaire

Everything above is written for someone reading closely. A firm's IT or procurement reviewer works differently: they arrive with a checklist and search the page for the terms on it. Those terms did not appear anywhere in this document, so a reviewer searching for them concluded it did not answer them — which was true. This section answers them in their own vocabulary, including where the answer is no.

Nothing here is new policy. Each row points at a document that already exists, and the linked document governs if the two ever disagree.

Certifications and third-party assurance

Legal instruments

Data handling

Incident and lifecycle

What this section deliberately does not claim

A questionnaire is easy to write so that every row reads well. Three things are stated here rather than left for a reviewer to discover:

• The absence of a certificate is not evidence of anything, in either direction. It means no third party has examined this and said so. The substitutes offered above — open code, a published review, a documented architecture — are weaker evidence than an audit, and are offered as what exists rather than as equivalent.
• The internal review covers the cryptography library, not the web application. Its own scope section says so, and the distinction matters to exactly the reader this section is for.
• Where a duty is yours rather than ours, the terms say so. Storing special-category data, health records or cardholder data requires measures on your side and an executed DPA; the architecture does not discharge that obligation for you.

What happens if ShieldFive disappears

If the service stops operating, local encryption alone does not guarantee continued access. Keep an export of the encrypted files, the required metadata and the credentials needed to decrypt them. The client-delivery boundary above still applies to claims about confidentiality.

In a worst-case scenario where ShieldFive is no longer here to operate the service, three things are needed to keep reading your files, and you already have or can get all three:

• Your password and recovery key. These are what unlock your encryption keys. Keep them safe. The password itself is never transmitted to us: the browser sends only an Argon2id-derived login value, and the key that opens your vault stays on your device.
• The encrypted blobs themselves. Files are stored as ciphertext under EU jurisdiction. The documented export path walks you through pulling your full ciphertext archive at any time, and decrypting it offline with the open-source library — runnable on any machine that runs Node. Your data is not trapped behind a control plane only ShieldFive can operate.
• A working decryptor. The cryptography is open-source and the wire format is documented, so the @shieldfive/crypto library at the version your files were encrypted with will continue to decrypt them on any machine that can run npm. The code does not stop working when the company does.

This is not hypothetical reassurance. The same export path is the one used to let users leave ShieldFive at any time for any reason — your files belong to you, in a format you can move, regardless of whether ShieldFive is still around to host them.

How to verify the cryptography yourself

If you are a developer or a security auditor, you do not have to take any of this on faith. The library is small enough to read in a sitting, and the wire format is small enough to implement from spec.

If you are a non-technical reader, you can skip this section. The short version is that any independent developer or security firm can verify the cryptography from the published code and specifications, and coordinated disclosure runs through [email protected].

For the technical reader, here's a starting checklist:

git clone https://github.com/shieldfive/crypto
cd crypto
pnpm install
pnpm test  # runs the test vectors and the parser fuzz harness
pnpm test:vectors  # regenerates and verifies deterministic vectors
cat spec/format-v1.md  # the on-disk format
cat spec/threat-model.md  # what the design does and doesn't protect against
cat spec/key-derivation.md  # KDF parameters and rationale

For a deeper look:

• The combiner construction for the post-quantum hybrid suite is in src/suites/pq-hybrid-v1/. The HKDF input ordering and the domain-separation tags are the load-bearing pieces.
• The identity and sharing module is in src/identity/. The re-encapsulation construction used for share-link recipients is the part most worth scrutinizing — it is non-standard.
• The header parser and AAD construction are in src/format/. The invariant the parser enforces is documented in spec/format-v1.md.

If you find anything, email [email protected] — coordinated disclosure, straight to the team. Reports go directly to ShieldFive without a third-party platform.

Security acknowledgements

Researchers who reported a vulnerability to [email protected] and asked to be credited. Each entry describes the finding as it was fixed rather than as it was filed — the two sometimes differ, and the fixed description is the accurate one.

There is no bounty program. ShieldFive ran one until 2026-07; it closed, and /security/bug-bounty now redirects to this page. Reports are still read, triaged and fixed, and this section is what we offer in return. Stating that here is better than letting a reporter find it out after the work is done.

• 2026-08-26 — Aravind S — the web password-reset form at /auth/forgot applied no application-layer throttle, so repeated reset requests for one address were bounded only by the mail provider's own ceiling. The mobile reset route already carried a limit; the web form had been missed. Fixed 2026-08-27 with per-IP and per-email buckets on the reset trigger. A throttled request returns the same generic response as a sent one, so the fix does not reintroduce the per-email enumeration oracle that an explicit "too many requests" would. Reset links only ever reach the account owner's own inbox, so the ceiling here was unwanted mail rather than account takeover; it shipped as hardening and is described as such.

A second report arrived 2026-08-27 and was fixed the next day. That reporter is not named here yet — the entry goes in when they say how they would like to be listed.

What this page commits to

This page will be updated as the program advances. Specifically:

• The internal security review summary is above; it is updated when new findings land or existing findings change status. The canonical state lives in triage.md; this page reflects the counts at publication time and is refreshed when the deltas are material.
• When an external audit is commissioned, the firm and scope will be announced here.
• When an audit report is delivered, the report PDF will be hosted on shieldfive.com (not on the auditor's site — auditor pages move, ours don't) and linked from this page.
• When the library tags 1.0.0 stable, the alpha framing on this page will be removed.
• When an external report is fixed, the reporter is added to the security acknowledgements above if they want to be named. That section is the whole of what a reporter gets in return; it is not a bounty and does not become one.

The build-log at /build-log records the engineering work behind the program as it ships, with a post per phase milestone. Reading the build-log alongside this page is the most complete public picture of the program's state.

Last updated

Last updated: 2026-09-18. The post-quantum comparison table was verified on 2026-05-22 against each vendor's primary source (linked from the provider's name in the table) and cross-checked against third-party coverage: Help Net Security, 2026-05-06 and Privacy Guides, 2026-05-07 for Proton Mail's post-quantum announcement; It's FOSS News for Internxt's Kyber-512 deployment, with the parameter set itself confirmed by the Internxt help center encryption page; and Internxt's Mega-alternative comparison page corroborating Mega's absence of post-quantum cryptography on any product surface. ShieldFive's own Suite 0x03 default flip is documented in the Phase 3 build-log post.