Sindook seals files with hybrid post-quantum encryption.

The literature treats these as distinct problems: an adversary can store ciphertext now and wait for quantum-capable attacks, which is the harvest-now, decrypt-later threat, and access-control changes create a separate operational need to update recipients without re-encrypting large payloads. Sindook therefore treats file encryption as a hybrid-encryption problem with a recipient-management layer above it: encrypt the payload once under a random file key, then encapsulate or wrap that key separately for each recipient (Herranz et al., 2010; Zhou et al., 2025).

This separation matches how the hybrid-encryption literature models public-key encryption: a key-encapsulation mechanism establishes shared key material, a data-encapsulation mechanism protects the payload, and the two can be analyzed independently (Herranz et al., 2010; Shibuya & Shikata, 2011). On that view, recipient updates touch only the metadata that carries wrapped keys rather than forcing payload re-encryption. The LUKS keyslot model is best understood as the implementation analogy for this slot-based key management, not the primary literature basis for it.

The case for a hybrid wrap layer is, in the literature, a migration trade-off. Hybrid KEMs are motivated as a transition strategy: they preserve compatibility with deployed classical infrastructure while adding post-quantum protection against future cryptanalytic advances (Liu et al., 2025; Zhou et al., 2025), and formal work on hybrid key exchange shows such combinations can be analyzed rigorously rather than treated as ad hoc redundancy (Chen et al., 2025; Zhou et al., 2025). The strongest support is for the general hybrid approach, not for the claim that any particular combiner forces an attacker to simply defeat both halves; that depends on the combiner and protocol details being instantiated and analyzed correctly (Cremers et al., 2024; Liu et al., 2025). Sindook's choice is X-Wing, X25519 combined with ML-KEM-768 through a SHA3-256 combiner, and the combiner results say the construction holds as long as either side does, which is the margin a decades-long archive needs.

The payload uses a standard AEAD pattern: one random 256-bit file key encrypts the file in 64 KiB chunks, and per-chunk metadata is authenticated as associated data rather than left unauthenticated (Rogaway, 2002). Binding the chunk counter and a final-chunk indicator into the nonce follows the literature showing that protection against reordering, replay, truncation, and drop attacks requires explicit sequencing information beyond basic forgery resistance (Boyd et al., 2016). Each slot derives a distinct wrap key through HKDF-SHA-256 salted by the file nonce, and the associated data binds the slot to the file and to its own KDF parameters. AEAD exists precisely to authenticate unencrypted context such as headers and parameters (Rogaway, 2002), and subtle AEAD design differences can materially affect protocol security when context binding is weak (Cremers et al., 2023), so the claim that a slot cannot be transplanted or downgraded should be read as contingent on correct domain separation and complete metadata authentication, not as an automatic consequence of using AEAD. A MAC keyed by the file key authenticates the whole header, so any slot added, removed, or reordered without the key fails verification before the payload is read; the key-wrap literature makes the same point, that wrapping and metadata protection need authenticated, context-binding constructions rather than bare encryption (Rogaway & Shrimpton, 2006).

This design earns its complexity where files are long-lived, recipients rotate, or ciphertext may be collected by an observer. Cold backups, offsite archives, team documents, and anything crossing email all fit. If a file's secrecy horizon is measured in days, or re-encryption is cheap, the slot machinery buys less. That is the honest boundary of the design.

Two things are deliberately absent. Proxy re-encryption assumes an untrusted party that must transform ciphertext without seeing plaintext; a local tool already holds the key, so the machinery adds nothing. And slots carry no recipient identifiers, which keeps metadata small but means inventory and removing a recipient whose key you do not hold will need a future format version. Both trade-offs are written down in the repository's design documents.