![\"Retail](\"https:\/\/dmsretail.com\/RetailNews\/wp-content\/uploads\/2022\/05\/RETAIL-ONLINE-TRAINING-728-X-90.png\")
<\/a><\/p>\n<\/p>\n
So far in this pillar we made the\u00a0key exchange itself<\/em> quantum-safe by bolting a post-quantum algorithm (ML-KEM) onto it. That\u2019s the headline approach, and in Part 4 we watched it run. But it\u2019s not the only way to beat \u201charvest now, decrypt later.\u201d There\u2019s an alternative road that gets you to the same<\/em>\u00a0destination without any new crypto algorithm at all.<\/p>\n It\u2019s called a\u00a0Postquantum Preshared Key (PPK)<\/strong>, defined in\u00a0RFC 8784<\/strong>. Let\u2019s understand it, then prove it works.<\/p>\n Note: this Part uses the same RFC 8784 takes a completely different route to the harvest-now-decrypt-later problem. Instead of a new algorithm, it mixes a\u00a0static, out-of-band preshared key<\/strong>\u00a0into the IKE key schedule. The key property:\u00a0the PPK never travels on the wire.<\/strong>\u00a0It\u2019s distributed ahead of time, so both peers already know it.<\/p>\n Here\u2019s why that defeats a future quantum computer. Suppose an attacker records your handshake today and, years from now, uses a quantum computer to recover the X25519 shared secret from it. They\u00a0still<\/em>\u00a0can\u2019t derive your traffic keys, because those keys also depend on the PPK, which was never transmitted and which their recording therefore doesn\u2019t contain. No PPK, no keys. The recorded session stays locked.<\/p>\n Two roads, one destination.<\/strong>\u00a0ML-KEM (RFC 9370) makes the\u00a0math<\/em>\u00a0quantum-hard and is negotiated like any other algorithm. PPK (RFC 8784) makes\u00a0no new cryptographic assumption<\/em> about the exchange; it just requires that a high-entropy secret stays secret and is shared out of band. That means PPK works even on legacy gear that cannot negotiate ML-KEM, which makes it a practical first step<\/strong>: get post-quantum confidentiality today, migrate to ML-KEM once both ends support it.<\/p>\n<\/blockquote>\n The catch is operational, and it\u2019s a big one: every peer\u00a0pair<\/em>\u00a0needs the same secret pre-shared and rotated, which is exactly the key-distribution headache public-key crypto was invented to avoid. (At scale, the secrets are either managed manually or generated by Quantum Key Distribution appliances needing a full mesh of point-to-point fibers, none of which scales gracefully.) So PPK is a transitional step, not a destination. Also note: PPK protects only the\u00a0derived keys<\/em>; authentication here is still a classical PSK.<\/p>\n This uses the same two-container key-exchange lab as Part 4. If you don\u2019t already have it running, clone the repo, build, and start both peers (only Docker required):<\/p>\n To make the \u201calternative to ML-KEM\u201d point crystal clear, this exercise drops the key exchange back to\u00a0classical-only X25519<\/strong> on purpose (standing in for a legacy device that does not support ML-KEM) and lets the PPK provide the quantum resistance entirely on its own.<\/p>\n Shell into the initiator ( Then uncomment the two PPK lines in the connection:<\/p>\n And uncomment the secret block at the bottom:<\/p>\n Make the same edits in the responder, then reload both with\u00a0 Reminder: these are lab secrets.<\/strong>\u00a0That hex value is a throwaway for learning. In the real world a PPK is a high-entropy secret you\u2019d generate securely, distribute out of band, store carefully, and rotate. Never reuse lab keys anywhere that matters.<\/p>\n<\/blockquote>\n From the initiator:<\/p>\n Four lines in the log tell the whole story:<\/p>\n Notice what\u2019s\u00a0missing<\/em>\u00a0compared to Part 4: the selected proposal is plain\u00a0 If you capture the run (same\u00a0 Because we set\u00a0 Reload just the initiator and re-initiate. This time it\u00a0fails<\/strong>: the mismatched PPK changes the\u00a0 There\u2019s your proof: the PPK isn\u2019t decorative; it\u2019s baked into the keys. Get it wrong and the tunnel simply won\u2019t come up.<\/p>\n Tidy up your clone.<\/strong>\u00a0Because\u00a0 Mainly as a\u00a0stepping stone<\/strong>. Equipment that can\u2019t negotiate RFC 9370 \/ ML-KEM yet, but needs harvest-now-decrypt-later protection\u00a0today<\/em>, can deploy a PPK now and migrate to ML-KEM once both ends support it. The price is the classic preshared-key burden (secure distribution, storage, and rotation of a \u2265256-bit secret across every peer pair), which is exactly why it\u2019s a transition, not a home.<\/p>\n So the two roads complement each other: PPK for \u201cI need protection now on legacy gear,\u201d ML-KEM for \u201cI can negotiate it and want it to scale.\u201d Plenty of real deployments will use both<\/em>\u00a0during the migration years ahead.<\/p>\n Over the last four posts we\u2019ve taken the urgent pillar end to end: the threat, the contenders, the hybrid showdown, a real captured handshake, and now a second independent road to the same safety. You\u2019ve seen, really\u00a0seen<\/em>, that quantum-safe key exchange is here, practical, and affordable today.<\/p>\n Now we flip to the\u00a0other<\/strong>\u00a0pillar, and it behaves\u00a0completely<\/em>\u00a0differently. No \u201charvest now, decrypt later\u201d here, but a sneakier deadline that catches almost everyone off guard. In\u00a0Part 6<\/strong>\u00a0we start the authentication story and meet the post-quantum signatures. See you there, and bring your curiosity, because this half has a twist.<\/p>\n<\/p><\/div>\nkey-exchange\/<\/code>\u00a0lab as Part 4.<\/p>\n
\nThe idea: mix in a secret that never travels<\/h2>\n
\n
\nSet up the lab<\/h2>\n
git clone<\/span> https:\/\/github.com\/juliogomez\/pqc.git
\ncd<\/span> pqc\/key-exchange
\n
\n
\ndocker compose build
\ndocker compose up -d
\ndocker compose ps
\n<\/code><\/pre>\n
\nLet\u2019s prove it: drop to classical KE and let the PPK carry it<\/h2>\n
docker exec -it ike-initiator bash<\/code>) and edit\u00a0swanctl.conf<\/code>. First, switch the proposal to classical-only (same toggle as Part 4):<\/p>\n# proposals = aes256gcm16-prfsha256-x25519-ke1_mlkem768
\nproposals = aes256gcm16-prfsha256-x25519
\n<\/code><\/pre>\n ppk_id = pqc-lab-ppk
\n ppk_required = yes
\n<\/code><\/pre>\n ppk-lab {
\n id = pqc-lab-ppk
\n secret = 0x5c9a3f1e8b7d4602af19e3c8d05b6f27a4e91d83c2b7f0a6e5d4c3b2a1908f7e
\n }
\n<\/code><\/pre>\nswanctl --load-all<\/code>. The output now lists the PPK alongside the auth PSK:<\/p>\nloaded ike secret 'ike-psk'
\nloaded ppk secret 'ppk-lab'
\n<\/code><\/pre>\n\n
\nInitiate and confirm the PPK is in play<\/h2>\n
swanctl --initiate --child pqc-child
\n<\/code><\/pre>\n[ENC] generating IKE_SA_INIT request 0 [ SA KE No ... N(USE_PPK) ]
\n[CFG] selected proposal: IKE:AES_GCM_16_256\/PRF_HMAC_SHA2_256\/CURVE_25519
\n[ENC] generating IKE_AUTH request 1 [ IDi AUTH SA TSi TSr ... N(PPK_ID) ]
\n[CFG] using PPK for PPK_ID 'pqc-lab-ppk'
\n<\/code><\/pre>\nCURVE_25519<\/code>: no\u00a0KE1_ML_KEM_768<\/code>, no\u00a0IKE_INTERMEDIATE<\/code>, no fragments. This is an old-fashioned classical handshake.\u00a0And yet it\u2019s now quantum-resistant<\/strong>, entirely thanks to the PPK:<\/p>\n\n
N(USE_PPK)<\/code>\u00a0rides in the\u00a0cleartext<\/em>\u00a0IKE_SA_INIT<\/code>, each peer advertising support.<\/li>\nN(PPK_ID)<\/code>\u00a0rides inside the\u00a0encrypted<\/em>\u00a0IKE_AUTH<\/code>, signalling which PPK is in use.<\/li>\nusing PPK for PPK_ID 'pqc-lab-ppk'<\/code>\u00a0is strongSwan confirming the secret was found and mixed into the key schedule.<\/li>\n<\/ul>\ntcpdump<\/code>\u00a0recipe as Part 4), three contrasts with the ML-KEM runs stand out:<\/p>\n\n
#43<\/code>, no fragments.<\/strong>\u00a0Just the plain two-round-trip classical handshake. The quantum resistance is riding entirely on the PPK, invisible in the packets.<\/li>\nUSE_PPK<\/code>\u00a0is public;\u00a0PPK_ID<\/code>\u00a0is private.<\/strong>\u00a0Discovery (\u201cdo we both support it?\u201d) is in the cleartext\u00a0IKE_SA_INIT<\/code>;\u00a0which<\/em>\u00a0PPK is selected travels encrypted inside\u00a0IKE_AUTH<\/code>.<\/li>\n
\nProve it\u2019s actually required<\/h2>\n
ppk_required = yes<\/code>, a peer that doesn\u2019t hold the matching PPK can\u2019t complete the handshake. Let\u2019s prove the secret is genuinely folded into the keys. Terminate the tunnel, then,\u00a0in the initiator only<\/em>, change its\u00a0ppk-lab<\/code>\u00a0secret to a different value (simulating a peer that doesn\u2019t know the real one):<\/p>\n ppk-lab {
\n id = pqc-lab-ppk
\n secret = 0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef
\n }
\n<\/code><\/pre>\nSK_pi<\/code>\/SK_pr<\/code>\u00a0keys, so the responder can\u2019t verify the initiator\u2019s AUTH payload and rejects it:<\/p>\n[ENC] parsed IKE_AUTH response 1 [ N(AUTH_FAILED) ]
\n[IKE] received AUTHENTICATION_FAILED notify error
\ninitiate failed: establishing CHILD_SA 'pqc-child' failed
\n<\/code><\/pre>\n\n
config\/<\/code>\u00a0is bind-mounted, your\u00a0vi<\/code>\u00a0edits were written to your repo files. Since they\u2019re git-tracked, one command from the host (in\u00a0key-exchange\/<\/code>) snaps both peers back to the shipped state:\u00a0git restore config\/<\/code>. That re-comments the PPK lines, restores the secret, and switches the proposal back to hybrid: a clean slate for the next run.<\/p>\n<\/blockquote>\n
\nWhen would you actually use this?<\/h2>\n
\nThat\u2019s a wrap on key exchange<\/h2>\n