6.2.1 Input Material

The handshake key derivation is initialized from the following inputs obtained during the handshake:

• ss_c: Client KEM shared secret
• ss_s: Server KEM shared secret
• client_nonce: Random nonce from ClientHello
• server_nonce: Random nonce from ServerHello

The shared secrets ss_c and ss_s are combined using a sequential HKDF-based extraction construction.

6.2.2 KEM Combination and Early Secret

The combined KEM input key material (IKM) is derived using XOR combination:

IKM_kem  = ss_c ⊕ ss_s
IKM      = label("palisade v1.2 early") || IKM_kem || client_nonce || server_nonce

The XOR combination provides symmetric, order-independent combination of both KEM shared secrets. Both secrets contribute equally, eliminating order dependency concerns. The XOR result is then fed into HKDF-Extract, which provides the necessary cryptographic mixing.

XOR Combiner Requirements:

When combining two secret inputs of equal length, PALISADE uses octet-wise XOR. Implementations MUST verify both inputs are exactly 32 octets; otherwise the handshake/resumption attempt MUST be aborted.

Security Properties:

• Contributiveness: Both ss_c and ss_s contribute equally to the derived keys.
• Order Independence: The combination is commutative (ss_c ⊕ ss_s = ss_s ⊕ ss_c), eliminating order dependency.
• Symmetry: Compromise of either secret has equivalent security implications.
• Length Requirement: Both shared secrets MUST have equal length (32 octets) for XOR combination.
• Domain Separation: The label "palisade v1.2 early" in the HKDF-Extract input provides domain separation and binds the derivation to PALISADE v1.2, preventing cross-context reuse.

The early secret is then derived:

early_secret = HKDF-Extract(zeros(32), IKM)

The early secret serves as the root of the handshake key derivation tree.

6.2.3 Transcript-Bound Handshake Secret

Let transcript_hash denote the cryptographic hash of the canonical serialized handshake transcript, including all handshake messages and negotiated parameters.

The handshake secret is derived as:

handshake_secret =
    HKDF-Expand(
        early_secret,
        label("handshake secret") || transcript_hash,
        32
    )

The inclusion of the transcript hash in the HKDF info parameter cryptographically binds the derived keys to the exact handshake that produced them.

The master secret is then derived as:

master_secret =
    HKDF-Expand(
        handshake_secret,
        label("master secret"),
        32
    )

The master secret is the root from which all application traffic keys and rekeying material are derived.

6.3 Epoch Key Derivation

PALISADE divides the lifetime of a session into a sequence of epochs, each associated with a unique set of traffic keys.

epoch_0_secret =
    HKDF-Expand(
        master_secret,
        label("epoch 0"),
        32
    )

epoch_n_secret =
    HKDF-Expand(
        epoch_{n-1}_secret,
        label("epoch step"),
        32
    )

6.4 Traffic Key Derivation

For each epoch n, PALISADE derives distinct traffic keys for each communication direction.

c2s_key  = HKDF-Expand(epoch_n_secret, label("c2s key"), 32)
c2s_iv   = HKDF-Expand(epoch_n_secret, label("c2s iv"), 12)

s2c_key  = HKDF-Expand(epoch_n_secret, label("s2c key"), 32)
s2c_iv   = HKDF-Expand(epoch_n_secret, label("s2c iv"), 12)

6.5 Special-Purpose Keys

PALISADE derives additional keys for specific protocol functions from established secrets. These keys are cryptographically separated from traffic keys and MUST NOT be used for any other purpose.

ticket_secret =
    HKDF-Expand(
        master_secret,
        label("ticket secret"),
        32
    )

resumption_psk =
    HKDF-Expand(
        master_secret,
        label("resumption psk"),
        32
    )

early_data_key =
    HKDF-Expand(
        resumption_secret,
        label("early data key"),
        32
    )

6.6 Ticket Key Rotation

To limit the impact of key compromise, implementations SHOULD rotate ticket_secret periodically.

When rotation is implemented:

• At most two active keys (current and previous) SHOULD be retained.
• New tickets MUST be issued using the current key.
• Validation MAY be attempted using either the current or previous key.
• Keys older than the retention window MUST be securely erased.

The recommended rotation interval is 12 hours, though deployments MAY choose different intervals based on threat models and operational requirements.

6.7 Key Separation

The PALISADE key schedule provides explicit cryptographic separation between all derived keys through the use of distinct HKDF labels.

Keys derived for one purpose (e.g., traffic encryption, header protection, ticket encryption) MUST NOT be used for any other purpose.

6.8 Forward Secrecy Properties

Epoch chaining provides forward secrecy within a session:

• Compromise of epoch n keys does not reveal keys from prior epochs.
• Secure erasure of prior epoch secrets prevents backward key recovery.
• Compromise of the master secret reveals future epochs but not erased past epochs.

At the session level, compromise of long-term authentication keys does not compromise past session keys, as ephemeral KEM shared secrets are used for key establishment.

6.9 Key Erasure Requirements

Implementations MUST securely erase key material when it is no longer required.

At a minimum, the following material MUST be erased:

• Intermediate KEM shared secrets after key derivation
• Handshake secrets after derivation of the master secret
• Epoch secrets after derivation of the next epoch
• Traffic keys associated with expired epochs
• Resumption secrets after session establishment
• Rotated ticket secrets

Secure erasure MUST occur as soon as practical after replacement or expiration.

The specific mechanisms used to achieve secure erasure are implementation-dependent and are discussed further in Appendix X (Implementation Considerations).