PQC Binary Format v1.0: Technical White Paper

Publication Date: January 7, 2026

Author: Allan Riddel, PQ Crypta

Subject Area: Post-Quantum Cryptographic Data Formats

---

Executive Summary

This white paper presents the PQC Binary Format v1.0, a structured binary data format designed specifically for post-quantum cryptographic keys, ciphertext, and associated metadata. The format addresses critical security requirements in the post-quantum computing era, incorporating constant-time execution patterns and comprehensive side-channel resistance measures to protect against timing attacks, power analysis, electromagnetic emanation analysis, and cache-timing vulnerabilities.

The format provides a standardized container for post-quantum cryptographic primitives including Key Encapsulation Mechanisms (KEMs), digital signatures, and authenticated encryption, with support for hybrid classical/post-quantum schemes. This white paper details the design principles, security architecture, implementation considerations, and practical applications of the PQC Binary Format.

---

Table of Contents

1. 1. Introduction
2. 2. Terminology
3. 3. Binary Format Structure
4. 4. Security Properties
5. 5. Metadata Specification
6. 6. Encoding Rules
7. 7. Validation Guidelines
8. 8. Security Analysis
9. 9. Implementation Recommendations
10. 10. References
11. 11. Appendix A: Algorithm Identifiers
12. 12. Appendix B: Implementation Examples

---

1. Introduction

1.1. Purpose and Motivation

The advent of quantum computing presents a fundamental threat to currently deployed public-key cryptographic systems. The PQC Binary Format v1.0 addresses three critical requirements for post-quantum cryptographic systems:

• Interoperability: Providing a standard binary representation that enables seamless communication across different implementations and platforms
• Security: Implementing constant-time operations and side-channel resistance to protect against both classical and quantum-era threats
• Extensibility: Supporting evolving post-quantum algorithms and hybrid classical/post-quantum schemes as standards mature

1.2. Scope

This white paper describes:

• Binary structure and field layout
• Metadata schema for cryptographic parameters
• Security requirements for implementations
• Validation and verification procedures

This white paper does not define:

• Specific cryptographic algorithms (defers to NIST standards)
• Key generation procedures
• Protocol-level message formats

1.3. Design Goals

Primary Goals:

• Constant-Time Execution: All parsing and validation operations execute in time independent of secret data
• Side-Channel Resistance: Protection against power, electromagnetic, and cache-timing attacks
• Deterministic Serialization: Identical inputs produce identical binary outputs
• Forward Compatibility: Extensible metadata schema for future algorithms

Secondary Goals:

• Compact representation for network transmission
• Self-describing format with embedded algorithm identifiers
• Integrity verification via cryptographic checksums

---

2. Terminology

Post-Quantum Cryptography (PQC): Cryptographic algorithms believed to be secure against attacks by both classical and quantum computers.

Key Encapsulation Mechanism (KEM): A public-key encryption scheme that encapsulates a symmetric key for secure key exchange.

Constant-Time Operation: An operation whose execution time is independent of secret input values, preventing timing-based side-channel attacks.

Side-Channel Attack: An attack that exploits physical implementation characteristics (power consumption, electromagnetic emissions, timing variations) rather than algorithmic weaknesses.

Deterministic Serialization: A serialization process that always produces the same byte sequence for the same logical data structure.

---

3. Binary Format Structure

3.1. Overall Layout

The PQC Binary Format consists of the following fields in sequential order:

Field	Size	Description
Magic Bytes	4 B	Format identifier: "PQC\x01"
Version	1 B	Format version (0x01)
Algorithm ID	2 B	Cryptographic algorithm identifier
Flags	1 B	Feature flags (reserved for future use)
Metadata Length	4 B	Length of metadata section (little-endian)
Metadata	variable	Algorithm-specific metadata (JSON)
Data Length	8 B	Length of encrypted data (little-endian)
Data	variable	Encrypted payload or key material
Checksum	32 B	SHA-256 integrity checksum

Total Header Size: 52 bytes (excluding variable-length sections)

3.2. Field Definitions

3.2.1. Magic Bytes (4 bytes)

Value: 0x50 0x51 0x43 0x01 (ASCII "PQC\x01")

Purpose: Format identification and version signaling.

Validation: Parsers verify magic bytes before processing remaining fields. Mismatched magic bytes result in immediate rejection. Magic byte validation is performed in constant time (4-byte comparison without early termination).

3.2.2. Version (1 byte)

Current Value: 0x01

Purpose: Format version for backward compatibility.

Validation: Parsers reject versions greater than the highest supported version. Future versions may extend the format while maintaining backward compatibility for version 0x01.

3.2.3. Algorithm ID (2 bytes, little-endian)

Purpose: Identifies the cryptographic algorithm used for key generation, encryption, or signature.

Format: 16-bit unsigned integer, little-endian byte order.

Range: 0x0000 - 0xFFFF (65,536 possible algorithms)

Security Note: Algorithm ID comparison is performed using constant-time operations to prevent algorithm fingerprinting via timing side-channels.

3.2.4. Checksum Calculation

The checksum is computed as the SHA-256 hash of all preceding fields using deterministic field-by-field hashing:

checksum = SHA-256(
    magic_bytes ||
    version ||
    algorithm_id ||
    flags ||
    metadata_length ||
    HASH_METADATA_DETERMINISTIC(metadata) ||
    data_length ||
    data
)

Deterministic Metadata Hashing: Since metadata is JSON (inherently unordered), deterministic hashing requires sorted key ordering. The implementation:

1. Parses JSON metadata
2. Sorts all keys lexicographically (UTF-8 byte order)
3. For each key-value pair (in sorted order), hashes the key and value
4. Hashes arrays in element order (no sorting)

---

4. Security Properties

4.1. Constant-Time Execution

The implementation ensures all parsing, validation, and comparison operations execute in constant time relative to secret data. This prevents timing attacks that could leak information about:

• Algorithm selection
• Checksum correctness
• Metadata contents
• Data integrity

Implementation Approach:

The format uses branch-free comparison operations. Traditional comparison loops that exit early upon finding a mismatch are replaced with XOR accumulation:

fn constant_time_eq(a: &[u8], b: &[u8]) -> bool {
    if a.len() != b.len() {
        return false; // Length check is public information
    }
    let mut result = 0u8;
    for (x, y) in a.iter().zip(b.iter()) {
        result |= x ^ y; // Accumulate XOR without branching
    }
    result == 0 // Single comparison at end
}

4.2. Side-Channel Resistance

The format design incorporates protection against physical side-channel attacks including:

• Power Analysis (SPA, DPA): Uniform power consumption through branch-free code
• Electromagnetic Analysis (EMA): Reduced EM emissions variation through constant-time operations
• Cache-Timing Attacks: Uniform memory access patterns independent of secret values
• Speculative Execution Attacks (Spectre, Meltdown): Data-independent control flow

Secure Memory Handling: All sensitive data is securely erased after use using a multi-pass wiping technique:

pub fn secure_wipe(data: &mut [u8]) {
    // Multi-pass wipe for defense in depth
    for pass in 0..3 {
        let fill_byte = match pass {
            0 => 0x00, // First pass: zero
            1 => 0xFF, // Second pass: ones
            _ => 0x00, // Third pass: zero
        };
        unsafe {
            ptr::write_bytes(data.as_mut_ptr(), fill_byte, data.len());
        }
        // Compiler fence prevents optimization
        std::sync::atomic::compiler_fence(std::sync::atomic::Ordering::SeqCst);
    }
}

---

5. Metadata Specification

5.1. Metadata Schema

The metadata field contains a UTF-8 encoded JSON object describing algorithm-specific parameters:

{
  "kem_params": {
    "algorithm": "ML-KEM-1024",
    "public_key_size": 1568,
    "ciphertext_size": 1568,
    "shared_secret_size": 32
  },
  "encryption_params": {
    "algorithm": "AES-256-GCM",
    "key_size": 32,
    "nonce_size": 12,
    "tag_size": 16
  }
}

5.2. KEM Parameters

Describes the Key Encapsulation Mechanism used:

• algorithm (string): KEM algorithm name (e.g., "ML-KEM-1024")
• public_key_size (number): Public key size in bytes
• ciphertext_size (number): Encapsulated ciphertext size in bytes
• shared_secret_size (number): Shared secret size in bytes

5.3. Security Warning

Important: Metadata is NOT encrypted. Applications should not include in metadata:

• Private keys or key material
• Passwords or passphrases
• User identifiable information
• Internal system details that could aid attackers

---

8. Security Analysis

8.1. Threat Model

The PQC Binary Format is designed to resist:

• Timing Attacks: Via constant-time operations
• Side-Channel Attacks: Via secure memory handling and branch-free code
• Integrity Attacks: Via SHA-256 checksums
• Format Confusion: Via strict magic byte and version validation
• Denial of Service: Via size limits and resource validation

Out of Scope:

• Cryptographic algorithm security (defers to algorithm specifications)
• Network protocol security (defers to TLS/QUIC)
• Key management security (defers to key storage specifications)

8.2. Implementation Considerations

Common pitfalls to avoid in implementations:

• Early Termination in Comparisons: Always complete the full comparison loop
• Data-Dependent Branches: Use bitwise operations instead of conditional statements for secret-dependent logic
• Memory Not Zeroed: Use automatic zeroing mechanisms (RAII, defer, destructors)
• JSON Timing Leaks: Be aware that JSON parsing may leak information via timing
• Integer Overflow: Validate lengths before arithmetic operations

---

10. References

Standards and Specifications

• NIST FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM)
• NIST FIPS 204: Module-Lattice-Based Digital Signature Standard (ML-DSA)
• NIST FIPS 205: Stateless Hash-Based Digital Signature Standard (SLH-DSA)
• FIPS 180-4: Secure Hash Standard (SHA-256)
• RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format

Additional Reading

• Bernstein, D.J., et al.: "Post-Quantum Cryptography", Springer, 2009
• Kocher, P., et al.: "Spectre Attacks: Exploiting Speculative Execution", IEEE S&P, 2019
• IEEE 1363.1: Public-Key Cryptographic Techniques Based on Hard Problems over Lattices

Open Source Implementation

• Source Code: GitHub Repository
• Rust (crates.io): pqc-binary-format - cargo add pqc-binary-format
• Python (PyPI): pqc-binary-format - pip install pqc-binary-format
• JavaScript (npm): pqc-binary-format - npm install pqc-binary-format
• Go (pkg.go.dev): bindings/go - go get github.com/PQCrypta/pqcrypta-community/bindings/go
• Documentation: API Documentation on docs.rs
• License: Dual MIT/Apache-2.0

---

Document Version History:

Version	Date	Changes
1.0	January 7, 2026	Initial white paper publication

End of Technical White Paper