Sealed twice: GhostVault's hybrid ML-KEM-1024 and ML-DSA-87 design

2.1 What a quantum computer changes for a vault

Shor's algorithm [2], whose approach extends to elliptic curves, breaks ECDH and ECDSA on P-384, so classical public-key encryption of a vault's master key would not survive a recording or a stored copy. Symmetric cryptography fares differently: Grover's algorithm speeds up key search only by a square root [3], so a 256-bit AES key keeps roughly 128 bits of strength, and key search on a 256-bit block cipher defines NIST's highest post-quantum security category [1].

2.2 ML-KEM and ML-DSA

ML-KEM, the key-encapsulation mechanism of FIPS 203 [4], derives from CRYSTALS-Kyber [5]; ML-DSA, the signature scheme of FIPS 204 [6], derives from CRYSTALS-Dilithium [7]. ML-KEM-1024 and ML-DSA-87 are their largest parameter sets, in NIST's highest security category; NIST recommends ML-KEM-768 by default and allows larger sets where higher security is required [1]. A vault's contents can stay sensitive for many years, so GhostVault uses the larger sets, the ones NSA's CNSA 2.0 suite calls for; the CNSA 2.0 profile for SSH, for example, requires ML-KEM-1024 and ML-DSA-87 [8]. This is a choice of parameters, not a claim of CNSA 2.0 compliance.

2.3 Hybrids

NIST allows a composite key establishment whose shared secret is the concatenation of two secrets fed to a key derivation, as long as one comes from an approved scheme, and dual signatures that are accepted only when every component verifies [1]. Bindel et al. analyse which ways of combining two KEMs stay secure while either one does [9]. The classical half is insurance against a young algorithm or its code failing: SIKE fell to a classical attack [10], Rainbow, a finalist signature scheme, lost a key on a laptop [11], and Kyber implementations leaked keys through timing [12].

2.4 Argon2id and HKDF

Argon2id is a memory-hard password-hashing function: each guess must fill and revisit a large block of memory, which makes guessing expensive on any hardware. RFC 9106 gives two recommended settings, the second of which is 64 MiB, 3 passes and 4 lanes for environments with less memory [13]. HKDF derives independent keys from one secret with a salt and a context label [14].

3.1 The symmetric core

A vault has a random 256-bit master key (Figure 1). Each key slot wraps it with AES-256-GCM. The payload, which holds the vault's contents, the identity's secret keys and the keyring, is sealed with AES-256-GCM under HKDF-SHA-512(master key, salt ghostvault: + vault id). Its authenticated data is the canonical JSON of the whole header: suite, id, creation time, generation, public identity and every slot. Changing any header byte, a slot, the generation or the identity, makes the payload fail authentication. Each AES-256-GCM box has a random 96-bit nonce and a 128-bit tag.

master key           256 bits, random
├─ passphrase slot   AES-256-GCM(master key), key = HKDF-SHA-512(Argon2id(passphrase), salt = slot context)
├─ recipient slots   AES-256-GCM(master key), key = hybrid KEM (ML-KEM-1024 + ECDH P-384)
│                    to a recovery kit or an escrow vault
└─ payload           AES-256-GCM, key = HKDF-SHA-512(master key, "ghostvault:" + vault id)
                     { vault contents, identity secret keys, keyring }
                     authenticated data: suite, id, created, generation, identity, every slot

3.2 The passphrase slot

Argon2id, version 0x13, runs over the passphrase in Unicode NFKC form with a 32-byte random salt and a 32-byte output. The standard profile is RFC 9106's second setting, 64 MiB, 3 passes and 4 lanes [13]; the high profile uses 256 MiB with the same passes and lanes. The output goes through HKDF-SHA-512 with the slot context as salt [14], and the result wraps the master key, the slot context again serving as authenticated data. The context binds vault id, slot id, slot type and the Argon2id parameters, so a slot cannot be moved to another vault or have its cost lowered. Because the file is untrusted, its parameters are range-checked before any work is done: 19 MiB to 1 GiB of memory, 1 to 10 passes, 1 to 16 lanes, a 16- to 64-byte salt, at most 32 slots, and known slot types only.

3.3 The hybrid KEM combiner

Recipient slots and bundles use a KEM built from ML-KEM-1024 and ephemeral-static ECDH on P-384 (Figure 2). The sender encapsulates to the recipient's ML-KEM-1024 key, which gives a 32-byte secret and a 1,568-byte ciphertext, and runs ECDH between a fresh P-384 key and the recipient's static one, which gives a 48-byte secret. The shared key is:

key = HKDF-SHA-512(ikm = ss_mlkem ‖ ss_ecdh, salt = SHA-512(transcript), info = "GHOSTVAULT v2 hybrid KEM key: " + purpose)

The transcript is the length-prefixed concatenation of a fixed label, the ML-KEM ciphertext, the ephemeral P-384 key, the recipient's ML-KEM key, the recipient's P-384 key and the purpose, such as vault <id> slot <slot id> or bundle <id>. The input follows NIST's composite pattern, the two secrets concatenated before a key derivation [1]; the salt ties the key to both ciphertexts, both recipient keys and one purpose. ML-KEM's implicit rejection is kept: a wrong key or a changed ciphertext yields an unrelated key, and the AES-256-GCM that follows fails. This combiner is GHOSTSHELL's own, not a published construction, and no third party has analysed it.

3.4 Composite signatures

Bundles carry a composite signature: ML-DSA-87 and ECDSA P-384 with SHA-384, both over m = SHA-512(length-prefixed: label, purpose, message). A signature is accepted only if both halves verify, NIST's rule for dual signatures [1]. ML-DSA-87 signs hedged, with fresh randomness each time, and an empty context; the ECDSA half is encoded as r ‖ s in 96 bytes.

3.5 The vault's identity

Each vault has one hybrid KEM key pair and one hybrid signing key pair. The public halves form its GhostVault ID, ghostvault-id:2: followed by the base64url of their canonical JSON; its fingerprint is GV2- and eight groups of four hex digits from SHA-512 over a label and that JSON. The secret halves live only inside the encrypted payload: the 64-byte ML-KEM seed and the 32-byte ML-DSA seed, from which the lattice keys are derived again on each use, and the two P-384 private keys. When decapsulating, the recipient's public key is recomputed from its secret rather than taken from a stored copy.

3.6 Where post-quantum cryptography is used, and where it is not needed

Table 1 lists every place the vault encrypts or signs. Post-quantum cryptography appears exactly where a public key does; everywhere else a 256-bit symmetric key suffices.

4.1 Code and libraries

The cryptography is in src/ghostshell-core/src/ghostvault/: primitives.ts (AES-256-GCM, HKDF-SHA-512, SHA-512, canonical JSON, length prefixes), kdf.ts, pq.ts, vaultFormat.ts, bundle.ts and records.ts; services/vault.service.ts holds the open vault. ML-KEM-1024 and ML-DSA-87 come from @noble/post-quantum 0.7.1 and Argon2id from @noble/hashes 2.4.0. Everything classical, AES-256-GCM, HKDF, SHA-2, ECDH and ECDSA on P-384 and the random numbers, comes from the platform's crypto: BoringSSL in Electron, OpenSSL in Node. The suite string GV2:Argon2id:AES-256-GCM:HKDF-SHA-512:ML-KEM-1024+P-384:ML-DSA-87+P-384 is checked on every container and bundle, and anything else is refused.

4.2 Audit status

@noble/post-quantum states that it has not been independently audited: its authors audited version 0.6.1 themselves in April 2026, and it does not claim constant-time execution. @noble/hashes had an independent audit at version 1.0.0 in January 2022, which left out argon2. Constant time matters for ML-KEM, as KyberSlash showed [12]. In the hybrid the P-384 half runs in BoringSSL, so a weakness in one implementation does not by itself expose a key.

4.3 Operations

Key material held in buffers, the master key and every key derived from it, is zero-filled when it is no longer needed. Table 2 lists what each operation does, in the corrected wording of the 0.2.0 documentation.

5.1 Tests

The app's unit suite, re-run independently for 0.2.0 (245 tests: 244 passed, 1 skipped outside the vault), has 21 vault tests, all passing. They check that AES-256-GCM refuses any change to the ciphertext, nonce, key or authenticated data; that out-of-range Argon2id parameters are refused and that one derivation runs the real standard profile; that the hybrid KEM agrees on its key, and that another purpose, secret key, ML-KEM ciphertext or ephemeral P-384 key gives an unrelated one; that a composite signature fails with a changed message, purpose or key, or with either half taken from another signer; that changing the generation, creation time, identity, KDF passes or payload stops the vault opening; passphrase change and master-key rotation, with identity and keyring kept; escrow ownership and revocation; record files refusing reordering, foreign keys and edits; and bundles refusing a changed note or a swapped sender.

5.2 Sizes and timings

For this paper, the app's own modules (pq.ts, kdf.ts, vaultFormat.ts, bundle.ts) were loaded from the source tree through the app's test hooks into Node 24.22.2 on Windows 11, on a 14th-generation Intel Core i9 laptop processor, on 12 November 2026, while other development processes were running. Each time is the median of the stated number of calls after warm-up calls, each timed with performance.now(); the passphrase derivation was measured in two separate runs. Tables 3 and 4 give the results.

Every public-key operation takes milliseconds, and opening a vault costs one Argon2id derivation, about three seconds at the standard profile. Each guess at a stolen file costs an attacker the same derivation: three passes over 64 MiB of memory. Signing times vary widely because ML-DSA repeats its signing loop a variable number of times [6]. GHOSTSHELL's documentation gives about 7 seconds for the high profile; in these runs it took about 12. The app runs the same code inside Electron, which these figures do not measure.