QNSQY File Format Specification

1. Overview

QNSQY is a post-quantum encrypted container format developed by Quantum Sequrity for healthcare, defense, and other regulated organizations migrating from classical to post-quantum cryptography. The format encapsulates AEAD-encrypted data sealed by NIST-standardized post-quantum algorithms, with optional digital signatures, multi-recipient access control, threshold key sharing, and a tamper-evident audit chain.

This document describes version 6 of the format, current minor version 6.1. The format identifies itself by the four ASCII bytes QNS6 at file offset 0. Implementations at minor version 6.1 conceal the producing tier and most feature flags inside the AEAD-protected encrypted header (see section 12). Files written by 6.0 producers continue to decrypt unchanged; readers select the parsing path on the minor version field at offset 6.

2. File identification

3. Fixed header layout (bytes 0–127)

Readers MUST validate the magic at offset 0, the major version at offset 4, and reject any file whose major version differs from the supported value (currently 6). For v6.1 readers, byte 8 MUST be zero, and bytes 14–15 MUST contain only the public flag bits (mask 0x0046); a non-zero value in those reserved positions MUST cause the file to be rejected.

4. Algorithm identifiers

QNSQY uses NIST-standardized post-quantum primitives by default. The complete enumeration of allowed identifiers is specified by the reference implementation; the table below lists the principal values.

Signatures (when present) use ML-DSA-44/65/87 (NIST FIPS 204), SLH-DSA (NIST FIPS 205), or LMS / HSS (RFC 8554, NIST SP 800-208), encoded in the optional QSIG trailer block (section 7).

5. Feature flags

The flag word at offsets 14–15 carries two disjoint sets of bits. The public mask (0x0046) drives parser layout decisions and stays in plaintext in v6.1. The private mask (0x01B9) controls cryptographic and feature behavior that the reader only needs after AEAD decryption; in v6.1, those bits live inside the encrypted-header meta prefix and the corresponding plaintext bits MUST be zero.

v6.1 readers MUST reject files where any private-mask bit is set in the plaintext flag word. Public-mask bits can be tested before the encrypted header is decrypted. Private-mask bits are only available after the encrypted-header meta has been authenticated by AEAD verification.

5a. Encrypted header meta (v6.1, 4-byte prefix)

v6.1 prepends a four-byte structure to the encrypted-header plaintext:

The remainder of the encrypted-header plaintext follows the same structure as in v6.0 (Argon2 parameters, confirmation block, wrapped DEK, KEM material, Merkle tree information, etc.). Encryption of the entire concatenated plaintext (meta + contents) is performed with the AEAD algorithm declared in the fixed header.

6. File body

Header size floor. A minor-version 6.1 writer reserves a fixed 32768-byte region for the encrypted header and zero-fills whatever the real header does not use, so the encrypted-header length at byte 80 (the true, unpadded length) is at most 32768. The MAC and QSDT marker follow at fixed offsets immediately after the 32768-byte region. Consequently every QNSQY file has a minimum size of 128 + 32768 + 32 + 4 = 32932 bytes, plus a 16-byte AEAD tag per chunk, plus the payload, plus (in recipient or hybrid mode) a plaintext KEM ciphertext block. The 65536-byte limit stated in sections 2, 3 and 8 is the READER's maximum accepted declared length, a denial-of-service bound and forward-compatibility margin, not the writer's reservation. The fixed region exists for four reasons: a DoS bound on header parsing, capacity for the worst-case header (HQC-256 hybrid, about 22 KB), a single-pass streaming write in which header contents such as the Merkle root are known only after the data chunks are written, and in-place rekey that rewrites the header into the same reservation. The fixed region is NOT a size-privacy mechanism: the true header length is present in plaintext at byte 80. Size-fingerprint resistance is provided separately by the opt-in paranoid padding mode.

7. Optional trailers

A QNSQY file MAY be followed by one or more append-only trailer blocks. Each trailer begins with its own four-byte ASCII magic.

8. Security considerations

QNSQY files are encrypted with NIST-standardized post-quantum cryptography. The format does not execute code. Implementations MUST validate the QNS6 magic and the major version field before parsing any further content. Implementations MUST reject files whose declared encrypted header length exceeds 65536 bytes. The fixed header includes an Argon2id salt and a key commitment field which together prevent password-based decryption oracle attacks. The 32-byte BLAKE3 keyed-hash MAC over the headers prevents tampering. The AEAD construction over data chunks provides per-chunk authenticity. Improper key management MAY lead to permanent data loss; the format does not provide built-in key recovery and recommends external mechanisms (key escrow, threshold sharing) for that purpose.

9. Interoperability considerations

QNSQY is defined and maintained by Quantum Sequrity. Implementations should reject unknown major version bytes. Minor version increments preserve backward compatibility. A FIPS-mode build of the reference implementation restricts algorithm identifiers to NIST-approved values (ML-KEM, ML-DSA, SLH-DSA, LMS, AES-256-GCM, SHA-2 / SHA-3, HKDF, PBKDF2). Wrappers in standard interoperable carriers (CMS per RFC 5652, S/MIME per RFC 8551, JWE per RFC 7516, age-encryption.org) are produced by the reference implementation via the --carrier flag.

10. Related specifications

• QSPG — Polyglot carrier variant
• QSDN — Deniable encryption variant

11. v6.1 privacy refactor (informational)

Version 6.1 is a non-breaking minor revision that hides the producing tier and the six private feature flag bits from observers who can see the file but cannot decrypt it. v6.0 producers continue to be readable: a v6.1 reader detects the on-disk minor version and follows the v6.0 backward-compatibility branch with the legacy plaintext layout for pre-existing files.

The wire-format change is limited to: (a) zeroing byte 8 (tier) on disk, (b) zeroing all private-mask bits in the flag word at offsets 14–15, (c) prepending a four-byte EncryptedHeaderMeta to the encrypted header plaintext that carries the authoritative tier and private flag bits, and (d) replacing the FLAG_INTEGRITY plaintext gate with a structural indicator at reserved[24] == 0x01 so the integrity hash remains verifiable without the decryption key. The header MAC scope and AEAD construction are unchanged; the moved fields are authenticated by the same MAC and AEAD tag that already protect the encrypted header.

The privacy claim is precise and excludes two residual signals that the format intentionally leaves plaintext-visible:

• Integrity-presence indicator at reserved[24] == 0x01. By design, so verify-integrity works without the decryption key. A passive observer learns whether the file carries an integrity hash, but cannot recover the hash value's relation to plaintext.
• Escrow trailer magic. When the optional escrow trailer is appended after the chunked body, the trailer's four-byte ASCII QSEC magic is plaintext-visible at end-of-file. Operators who need the existence of escrow itself to be hidden MUST NOT use the escrow feature.

The fixed header also continues to reveal the format magic, version, algorithm tags, Argon2id parameters, salt, key commitment, encrypted-header length, plaintext file size, and the public flag bits. These fields are required for the parser to start decrypting and are not part of the privacy claim.

12. IANA media type registration

A single IANA media type registration is intended to cover the .qs primary format: application/vnd.quantumsequrity.qnsqy. The registration application has been drafted per RFC 6838 §5.6 and is published in the reference-implementation repository at docs/iana/application-vnd-quantumsequrity-qnsqy.md; submission to IANA via the form at iana.org/form/media-types is a pending human step. Until provisional acceptance lands on the IANA media-types registry, the type string above is a vendor-tree identifier under our control but is not yet IANA-listed. The internal sub-formats .qsdn, .qspg, .qss2, .qsv, .qsig, .qsthresh, .qstl, .qsym, .qskf, and .qsabe remain QNSQY-internal tooling formats and are not being submitted as separately registered media types.

The reference-implementation repository also includes a PRONOM signature definition (UK National Archives, in docs/iana/application-vnd-quantumsequrity-qnsqy.md Appendix A) and a magic(5) entry proposal for upstream file(1) integration (Appendix B). PRONOM and libmagic submissions are also pending human steps tracked at docs/iana/registration-tracker.md.

13. Reference implementation and contact

Reference implementation: a Rust implementation of the QNSQY format is available under commercial license. Evaluation builds and binary downloads: quantumsequrity.com/download. Source-license enquiries: [email protected].

Specification queries and IANA / PRONOM registration matters: [email protected].