Chapter 31 — Quantum and post-quantum security: implementation II

Chapter 31 — Quantum and post-quantum security: implementation II

Lesson map

Lesson 31 published. Map, example, EX061.

flowchart TD
  N0["Learning outcomes"]
  N1["31.1 Constant time"]
  N2["31.2 Decapsulation comparison"]
  N3["31.3 Fault attacks"]
  N4["31.4 Randomness and seeds"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX061"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["31.1 Constant time"]
  N2["31.2 Decapsulation comparison"]
  N3["31.3 Fault attacks"]
  N4["31.4 Randomness and seeds"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX061"]

[Learning outcomes]
    |
    v
[31.1 Constant time]
    |
    v
[31.2 Decapsulation comparison]
    |
    v
[31.3 Fault attacks]
    |
    v
[31.4 Randomness and seeds]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX061]

Learning outcomes

You will (1) apply constant-time techniques to lattice code; (2) understand fault attacks and countermeasures; (3) handle randomness and seeds safely; and (4) assess embedded implementations. It deepens Chapter 28 with implementation security.

31.1 Constant time

Lattice implementations must avoid secret-dependent branches, memory accesses and variable-time instructions. Division is a known trap: compilers and processors may implement division by a constant with variable timing, and KyberSlash showed real leaks from secret-dependent divisions (Bernstein et al. 2024). The fix is arithmetic that avoids division (multiplication by precomputed constants and shifts) and verification with timing-analysis tools.

Source code that looks constant-time may not stay so after compilation, so checks run on the binary for each target platform.

31.2 Decapsulation comparison

ML-KEM's implicit rejection compares a re-encrypted ciphertext with the received one. The comparison and the selection between the real key and the rejection key must be constant-time; otherwise timing reveals whether a manipulated ciphertext decrypted "correctly", re-opening chosen-ciphertext attacks.

A naive comparison that stops at the first differing byte finishes sooner for some inputs than for others, and an attacker who submits many crafted ciphertexts can measure the difference. The fix compares every byte and combines the differences with bitwise operations, then selects the key with a mask rather than a branch. Libraries implement this; BPA's review checks that application code never reimplements the comparison or adds an early exit around it.

31.3 Fault attacks

Injecting faults (voltage glitches, clock glitches, lasers) can skip checks or corrupt computations. In signatures, a fault during ML-DSA signing can leak information about the secret key; in deterministic schemes, faults can be especially dangerous. Countermeasures include redundant computation, verifying a signature before releasing it and hardened hardware. These matter for devices an attacker can physically access — gate scanners, smart cards.

Verifying a signature before releasing it costs one extra verification, which for ML-DSA is fast, and it catches faults that corrupted signing. For BPA's central signing service in a secured room, fault risk is low; for devices in the field, an attacker with physical access has time to experiment, so the countermeasures matter more there.

31.4 Randomness and seeds

ML-KEM key generation and encapsulation consume fresh randomness; ML-DSA offers a "hedged" mode mixing fresh randomness with deterministic derivation, which helps against fault and randomness failures (FIPS 204). Seeds that generate keys are as sensitive as the keys themselves.

A failed random number generator in a hedged scheme degrades to deterministic signing instead of leaking the key, which is why BPA enables hedged ML-DSA in its signing service. ML-KEM's 64-byte seeds must be protected like private keys: anyone who obtains a seed can regenerate the decapsulation key. Storage and backup rules apply to seeds in the same way, including destruction when the key is retired.

31.5 Worked example

BPA's gate-scanner vendor provides an ML-DSA verifier for firmware. Since the device only verifies, secret-key leakage is not at stake on the device; the main risks are faults that skip the verification result. Countermeasure: verify twice with different code paths and check a hash of the image after boot.

Using two different code paths means a single glitch is unlikely to skip both checks in the same way. The post-boot hash check adds a further layer: if a fault let an unsigned image start, the mismatch is detected and the device reports it. These steps cost milliseconds at boot, which the scanner can afford.

31.6 Common errors and limits

• Assuming compilers preserve constant-time intent.
• Ignoring physical attacks for field devices.
• Treating seeds as non-sensitive.

Compilers optimise for speed and may introduce branches or table lookups that leak timing, so constant-time claims need checking on compiled code. Field devices such as gate scanners face attackers who can glitch them at leisure, unlike servers in a guarded room. Seeds regenerate keys, so treating them as harmless configuration exposes every key derived from them. BPA's reviews check all three points on each new device class before procurement.

Exercises

• EX061 — Division audit. Explain why coeff // 1665 on a secret value can leak and propose an alternative. Rubric: 3 = variable-time division risk and multiplication/shift alternative.
• EX062 — Fault threat. For a verify-only bootloader, identify the fault threat and two countermeasures. Rubric: 3 = skipped check; redundant verification and post-boot hash.

Synthesis

Implementation security for PQC means constant-time arithmetic and comparisons, fault resistance where attackers have physical access, and careful randomness and seed handling.

Continue studying — chapter 31 of 50

← Chapter 30 (draft) · Course chapter index · Chapter 32 (draft) →