QuakWrap Trust Center

Review the cryptographic profiles, recipient key lifecycle, data-handling model, release validation, and deployment controls behind QuakWrap.

Open Verified Recipient View product architecture

Current cryptographic profiles

QuakWrap uses ML-KEM-768 as standardized in NIST FIPS 203 and ML-DSA-65 as standardized in NIST FIPS 204. FIPS 140-3 module validation remains a separate enterprise deployment profile tied to a specific module and operating environment.

ML-KEM-768

Recipient-owned post-quantum key establishment standardized in NIST FIPS 203

ML-DSA-65

Sender signatures standardized in NIST FIPS 204

AES-256-GCM

Authenticated encryption for file contents, private key backups, and recipient key wrapping

HKDF-SHA-256

Derives an independent key-encryption key for every recipient device

PBKDF2-SHA-256

Uses 600,000 iterations and a per-device salt for encrypted private-key backups

SHA-256

Supports package fingerprints, signed payload digests, private commitments, and ledger hashes

Release validation

Cryptographic and product checks run as release gates rather than optional documentation.

64 real ML-KEM-768 key generation, encapsulation, and decapsulation cycles

64 real ML-DSA-65 key generation, signing, verification, and tamper-rejection cycles

Exact FIPS 203 and FIPS 204 object-dimension checks

AES-256-GCM round-trip and tamper-rejection tests

HKDF-SHA-256 and 600,000-iteration PBKDF2-SHA-256 execution checks

Static assertions for recipient ownership, multi-recipient wrapping, sender directory binding, and strict package parsing

Production dependency audit, lint, TypeScript, optimized build, and route smoke tests

Desktop and mobile Chromium screenshots plus Vercel preview status before release

Data handling

Sensitive source material is separated from the online records required for delivery, status, ownership, and accountable use.

File contents

Source files are encrypted in the browser. The registry stores package records and fingerprints rather than plaintext file contents.

Recipient keys

Public ML-KEM and ML-DSA keys are published through the directory. Private keys are stored only inside a passphrase-encrypted device backup bundle.

Private identifiers

Identifier values are committed locally with a verification secret. The registry stores the resulting commitment and status.

Online controls

Organization ownership, device status, usage, expiry, revocation, and verification activity use server routes, service-role access, and Postgres row-level security.

Security profiles

Versioned profiles keep portability, identity-bound delivery, private verification, and enterprise controls distinct.

QW-P1 Portable

Available

Self-contained passphrase-protected ML-KEM-768 and AES-256-GCM packages for accountless or offline handoff.

QW-R1 Verified Recipient

Available beta

Recipient-owned ML-KEM-768 device keys, per-device content-key wrapping, ML-DSA-65 sender signatures, and directory-bound sender verification.

Private Verification

Available

Secret-bound commitments for equality and current-status checks without a plaintext identifier registry.

Enterprise Cryptographic Gateway

Planned

A controlled native or server boundary designed around an active CMVP-validated module and approved operating configuration.

Recipient-bound delivery is now part of QuakWrap

QW-R1 encrypts the content key independently to active recipient devices, signs the protected manifest, and verifies the sender against the live QuakWrap directory before opening.