17. Security Considerations

This section summarizes the security properties, assumptions, and limitations of the PALISADE protocol.

17.1 Quantum Threat Model

PALISADE is designed to resist attackers with access to:

• Cryptographically relevant quantum computers (CRQCs)
• Large-scale classical computational resources
• Network-level passive and active adversarial capabilities
• Traffic analysis, timing analysis, and packet-level observation

PALISADE does NOT protect against:

• Implementation vulnerabilities (e.g., buffer overflows, timing leaks)
• Compromise of endpoint devices or operating systems
• Malicious or backdoored cryptographic implementations
• Application-layer information leakage

Correct implementation, hardened runtimes, and secure operational practices are required to realize the protocol's security guarantees.

17.2 Cryptographic Assumptions

PALISADE relies on the following cryptographic primitives and assumptions:

ML-KEM-768 (Kyber768)

Provides post-quantum key encapsulation at NIST security level 3.

Dilithium-3

Provides post-quantum digital signatures at NIST security level 3.

ChaCha20-Poly1305

Provides authenticated encryption for data transport.

SHA-3-256

Provides cryptographic hashing for transcript binding and key derivation.

The security of PALISADE depends on the assumed hardness of the underlying lattice problems (Module-LWE and Module-SIS) and the cryptographic strength of the symmetric primitives.

17.3 Post-Quantum Security Properties

PALISADE provides post-quantum security as follows:

Key Exchange:

ML-KEM-768 provides approximately 128-bit security against quantum adversaries.

Authentication:

Dilithium-3 provides approximately 128-bit security against quantum adversaries.

Symmetric Cryptography:

ChaCha20-Poly1305 and SHA-3-256 remain secure against quantum adversaries, with Grover's algorithm reducing effective security from 256 bits to approximately 128 bits.

Long-term confidentiality is provided by post-quantum key establishment; symmetric cryptography is used only within the lifetime of derived session keys.

17.4 Encrypted Packet Metadata

Only the following fields are visible to network observers:

• Magic value
• Protocol version
• Flags
• Packet length
• Reserved field

All other metadata is encrypted and authenticated, including:

• Epoch identifiers and sequence numbers
• Padding length
• Stream identifiers
• Header flags
• Timestamps (when enabled)

This design minimizes protocol-level metadata leakage and prevents passive observers from inferring session structure or cryptographic state.

17.5 Epoch and Sequence Safety

PALISADE enforces strict nonce and replay-safety rules:

• (epoch_id, seq) pairs MUST never repeat for a given traffic key
• Sequence numbers are capped at 2^40 per epoch
• Rekeying occurs well before sequence exhaustion
• Epoch transitions enforce forward secrecy

Violation of these rules can result in catastrophic AEAD security failure.

17.6 Replay-Safe Session Resumption

Session resumption provides replay-safe semantics through:

• Single-use resumption tickets enforced by the server
• Fresh post-quantum KEM exchange on each resumption
• Strict early-data restrictions and size enforcement
• Early data is explicitly treated as replayable and MUST be limited to safe, idempotent operations.

17.7 Metadata-Resistant Traffic Shaping

Optional traffic shaping mechanisms provide defense-in-depth against traffic analysis:

• Constant-rate transmission reduces timing correlation
• Dummy packets are cryptographically indistinguishable from real packets
• Packet sizes can be bucketed or fixed
• Traffic shaping does not alter cryptographic correctness or replay protection.

17.8 Authenticated Migration

PALISADE migration preserves authentication and session integrity:

• Soft migration is authenticated by the existing encrypted tunnel
• Hard migration is authenticated via resumption tickets and fresh key exchange
• Migration does not alter cryptographic identity or key material
• Session hijacking during migration is prevented by cryptographic authentication.

17.9 Migration Replay Protection

Migration control frames are protected against replay through:

• Mandatory epoch and sequence validation
• Inclusion in the authenticated encrypted channel
• Binding to the current session state
• Optional timestamp validation MAY be used as defense-in-depth but MUST NOT replace epoch/sequence replay protection.

Captured migration messages cannot be replayed successfully outside the valid session context.

17.10 Key Separation and Domain Separation

PALISADE enforces strict key separation:

• Distinct keys for each cryptographic purpose
• Independent keys per traffic direction
• Explicit HKDF domain separation labels
• No reuse of authentication keys as traffic keys

This separation prevents cross-protocol attacks, key substitution, and cryptographic context confusion.