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, 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.

What the server can see

Encrypted on your device, so the server holds ciphertext only: file contents, file, folder and album names, thumbnails, the photo capture date, request titles and labels, form questions and answers, and all private keys. Not encrypted, and visible to ShieldFive and to anyone with database access:

• Account email address, and a firm's name and logo.
• Each file's size and its MIME type (for example image/jpeg) as reported by the browser.
• Created, updated and deleted timestamps, and download counts.
• Folder structure: which folder each file and folder sits in.
• Whether two of your files, folders or albums have the same name (case-insensitive). Each name row carries a deterministic keyed hash, name_hash, used for search. The server cannot invert it without your root key, but equal names give equal hashes.
• The cipher suite and public header of each file, and your public keys.
• Share settings and per-share access events (viewer country and a keyed hash of the IP address).
• Request and form structure: number of items, form field types (short text, long text, single choice, date) and their order, limits, expiry, upload counts and sizes.
• IP address and user agent. Cloudflare and Vercel see them on every request. The app reads the client IP (from Cloudflare's cf-connecting-ip header) for rate limiting and download tokens, and stores the IP address and user agent in an audit log for sign-up and privileged operations such as account deletion, email change, MFA unenrolment, session revocation, share creation and checkout.

The full table, with the reason each item is there, is in the security white paper; retention periods are in the privacy policy.

The web hybrid format and test vectors are published in the open-source cryptography library. The following comparison and hybrid-format sections describe the hybrid writer used by the web client, Android build 38 and later, and the iOS and desktop apps in testing.

How we compare on post-quantum

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; it was verified against primary sources on 2026-05-22, and the Proton Drive and Mega rows were rechecked on 2026-10-20 (neither has announced post-quantum encryption for stored files). For default encryption, free tiers and prices across ten providers, see zero-knowledge cloud storage compared.

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. Harvest-now-decrypt-later targets public-key steps: wherever a file key reaches its reader through a classical key exchange (X25519, RSA), a recorded ciphertext becomes readable once that exchange can be broken. A post-quantum KEM in the on-disk wire format is what closes that gap. 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. Which ShieldFive files depend on ML-KEM for this, and which do not, is stated under "The hybrid property" below.
• 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.

Content AEAD: XChaCha20-Poly1305 for the chunks, keyed from the combined key K below. The classical share is wrapped with libsodium secretbox (XSalsa20-Poly1305). Implementation: [email protected].

Combiner construction. For each file:

1. The sender generates a 32-byte classical share S_c randomly and wraps it under a classical envelope key K_c with secretbox.

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. Deriving K needs both shares: S_pq, which requires the ML-KEM-1024 secret key or a break of ML-KEM, and S_c, which requires K_c. XChaCha20-Poly1305 is not one of the two halves; it encrypts the content under K, and a break of it would expose the content regardless of the KEM. What the ML-KEM layer adds depends on where K_c comes from:

• Files you upload to your own vault. K_c is the file's content key, wrapped under the folder-key chain that ends at your vault root key, which is wrapped under a key derived from your password with Argon2id. Every step of that chain is symmetric, and the ML-KEM secret key is itself derived from the root key. These files do not rely on public-key cryptography for confidentiality at rest, so a recorded copy is protected by the symmetric primitives and your password, with or without ML-KEM. ML-KEM adds an independent second share.
• Files and form answers sent to you through a request link or form. The sender has no account and no shared secret with you, so K_c comes from an ephemeral-static X25519 exchange with your published key. X25519 alone would fall to a quantum computer; ML-KEM-1024 is what keeps a recorded upload confidential in that case. An attacker has to break both X25519 and ML-KEM-1024.

The full derivation is in the security white paper.

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, measured with library 1.0.0-alpha.14 on commodity x86_64 hardware and not re-run on the current release): 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:

• Share-link recipients do not use ML-KEM. They unwrap the combined key K with a key derived from the share password (Argon2id), which is symmetric. Send transfers and one-time secrets (suite 0x02) carry a symmetric key in the link and have no ML-KEM layer.
• 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 web app, CLI, MCP server and desktop app use this library, at the version a reviewer installs from npm (published with provenance). The Android app (and the iOS app built from the same code base) is the exception: it has its own TypeScript implementation of the same wire formats, tested against fixtures produced by the library. That implementation is not open source.

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

A common 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, item by item:

• Post-quantum KEM: ShieldFive ships ML-KEM-1024 (FIPS 203) as the on-disk default. It is the component that protects at-rest ciphertext against harvest-now-decrypt-later wherever a file key would otherwise travel by a classical key exchange (request-link and form uploads). Vault files you upload yourself are wrapped under a symmetric key chain and do not depend on it; see "The hybrid property" above. 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 web app's cryptography is the open-source library @shieldfive/crypto, Apache 2.0 licensed and published to npm; the CLI, MCP server and desktop app use it too. The Android app has a second, separate TypeScript implementation of the same wire formats, tested against fixtures produced by the library; it is not open source.

The library ships:

• Four cipher suites: AES-256-GCM (suite 0x01, the web fallback and older Android uploads), XChaCha20-Poly1305 (0x02, Send transfers and one-time secrets), a post-quantum hybrid combining ML-KEM-1024 with XChaCha20-Poly1305 (0x03, the default), 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; in the library, with no production writer).
• 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 new web uploads since 2026-05-17 and for Android from build 38, subject to the AES-256-GCM fallback described above. 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 has stable releases; none has been externally audited. The web app pins 1.0.1. The newest published version is listed on npm; the web app moves to a newer release in its own change, not automatically. A stable version number describes the npm public API, not an audit result. The web app has used this library for file encryption since launch, with the PQ-hybrid suite as the default since 2026-05-17.
• 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 names, no plaintext keys server-side) apply. Some metadata is not encrypted; it is listed under "What the server can see" above. 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.

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. On the current sign-in the password itself is not transmitted to us: the browser sends only an Argon2id-derived login value (older accounts send it once, at the sign-in that migrates them, as described above), 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 (it counts toward the plan's monthly download allowance, like any download, except during a shutdown notice period, when downloads and exports are not counted), 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.

For a Lifetime plan the shutdown commitments are written into the Terms (§5.7): at least 12 months' notice by email and in the app, with export available for the whole notice period, and downloads and exports during that period do not count toward the download allowance (normally 200 GB per 30 days for a Lifetime plan). The plain-language version, with the Lifetime definition and the fair-use rule, is at /lifetime/continuity.

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-07-02 — 0xEr3n — reader-validation consistency hardening in the Suite 0x03 combined-key stream decrypt path of @shieldfive/crypto (low severity, defense in depth). Fixed in 1.0.0-beta.3.

• 2026-07-04 — Mudit Raj — the optional v1 sender-attribution signature in @shieldfive/crypto committed only to the per-chunk AEAD tags, not the ciphertext, so a holder of a file's content key could rewrite chunk ciphertext while signature.verified stayed true (a sender-attribution bypass in both stream suites; high severity, in a feature not yet enabled in any production surface). Fixed in 1.0.0-beta.4 by signing a ciphertext-committing SHA-256 transcript.

• 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.

• 2026-09-23 — andzis11 — the buildUploadProofV3 documentation in @shieldfive/crypto claimed more than the proof covers. It now states that the proof covers the header and the chunk_0 frame only (later chunks are protected by per-chunk AEAD at decrypt time), and the builder rejects chunk_0 lengths the server verifier would reject. Fixed in 1.0.1.

• 2026-09-24 — koalarajin — a name envelope's stored kdf label could be rewritten server-side to make a reader pay a higher Argon2id cost (about 7x CPU and 4x memory per name), plus error-contract and connection-string canonicalisation issues in @shieldfive/crypto's vault module. Fixed in 1.0.1; the reporter re-ran the PoC on 1.0.1 and confirmed the cost no longer rises.

• 2026-10-10 — NH Limon — two password resets started from the same recovery session could run at the same time and leave the sign-in secret from one new password and the stored salt or vault wrap from the other, locking the account owner out (low severity, no access to anyone else's data). Fixed 2026-10-10: a password change now claims the credential row first, so a concurrent change is refused with a "try again" message instead of writing a mismatched pair.

• 2026-10-21 — 0xanarki — two findings in @shieldfive/crypto 1.0.1, both low severity. First, four encoders (0x01, 0x02 and 0x04 encryptBlob, and the 0x01 encrypt stream) accepted a caller-supplied suitePayloadOverride with a non-zero reserved pad, so they wrote files the library's own readers refuse; the encoders now run the readers' check before writing. Second, the specs and README said the library exports no v0 writer and no cross-format auto-detection, but it exports encryptV0 (migration fixtures) and looksLikeV0; the documents now describe both, and both functions are marked deprecated. No production surface called either one. Fixed on main 2026-10-21; ships in the next release.

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 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-10-24. 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.