A Completely different Highway to Quantum Security: The PPK – IPsec Sequence, Half 5


To date on this pillar we made the key trade itself quantum-safe by bolting a post-quantum algorithm (ML-KEM) onto it. That’s the headline method, and in Half 4 we watched it run. But it surely’s not the one option to beat “harvest now, decrypt later.” There’s an alternate street that will get you to the similar vacation spot with none new crypto algorithm in any respect.

It’s known as a Postquantum Preshared Key (PPK), outlined in RFC 8784. Let’s perceive it, then show it really works.

Word: this Half makes use of the identical key-exchange/ lab as Half 4.


The thought: combine in a secret that by no means travels

RFC 8784 takes a very completely different path to the harvest-now-decrypt-later downside. As an alternative of a brand new algorithm, it mixes a static, out-of-band preshared key into the IKE key schedule. The important thing property: the PPK by no means travels on the wire. It’s distributed forward of time, so each friends already comprehend it.

Right here’s why that defeats a future quantum laptop. Suppose an attacker data your handshake at the moment and, years from now, makes use of a quantum laptop to get better the X25519 shared secret from it. They nonetheless can’t derive your site visitors keys, as a result of these keys additionally rely upon the PPK, which was by no means transmitted and which their recording due to this fact doesn’t comprise. No PPK, no keys. The recorded session stays locked.

Two roads, one vacation spot. ML-KEM (RFC 9370) makes the math quantum-hard and is negotiated like another algorithm. PPK (RFC 8784) makes no new cryptographic assumption in regards to the trade; it simply requires {that a} high-entropy secret stays secret and is shared out of band. Which means PPK works even on legacy gear that can’t negotiate ML-KEM, which makes it a sensible first step: get post-quantum confidentiality at the moment, migrate to ML-KEM as soon as each ends help it.

The catch is operational, and it’s a giant one: each peer pair wants the identical secret pre-shared and rotated, which is precisely the key-distribution headache public-key crypto was invented to keep away from. (At scale, the secrets and techniques are both managed manually or generated by Quantum Key Distribution home equipment needing a full mesh of point-to-point fibers, none of which scales gracefully.) So PPK is a transitional step, not a vacation spot. Additionally be aware: PPK protects solely the derived keys; authentication right here continues to be a classical PSK.


Arrange the lab

This makes use of the identical two-container key-exchange lab as Half 4. Should you don’t have already got it operating, clone the repo, construct, and begin each friends (solely Docker required):

git clone https://github.com/juliogomez/pqc.git
cd pqc/key-exchange


docker compose construct
docker compose up -d
docker compose ps        

Let’s show it: drop to classical KE and let the PPK carry it

To make the “various to ML-KEM” level crystal clear, this train drops the important thing trade again to classical-only X25519 on function (standing in for a legacy machine that doesn’t help ML-KEM) and lets the PPK present the quantum resistance completely by itself.

Shell into the initiator (docker exec -it ike-initiator bash) and edit swanctl.conf. First, change the proposal to classical-only (similar toggle as Half 4):

# proposals = aes256gcm16-prfsha256-x25519-ke1_mlkem768
proposals = aes256gcm16-prfsha256-x25519

Then uncomment the 2 PPK traces within the connection:

        ppk_id = pqc-lab-ppk
        ppk_required = sure

And uncomment the key block on the backside:

    ppk-lab {
        id = pqc-lab-ppk
        secret = 0x5c9a3f1e8b7d4602af19e3c8d05b6f27a4e91d83c2b7f0a6e5d4c3b2a1908f7e
    }

Make the identical edits within the responder, then reload each with swanctl --load-all. The output now lists the PPK alongside the auth PSK:

loaded ike secret 'ike-psk'
loaded ppk secret 'ppk-lab'

Reminder: these are lab secrets and techniques. That hex worth is a throwaway for studying. In the true world a PPK is a high-entropy secret you’d generate securely, distribute out of band, retailer fastidiously, and rotate. By no means reuse lab keys anyplace that issues.


Provoke and make sure the PPK is in play

From the initiator:

swanctl --initiate --child pqc-child

4 traces within the log inform the entire story:

[ENC] producing IKE_SA_INIT request 0 [ SA KE No ... N(USE_PPK) ]
[CFG] chosen proposal: IKE:AES_GCM_16_256/PRF_HMAC_SHA2_256/CURVE_25519
[ENC] producing IKE_AUTH request 1 [ IDi AUTH SA TSi TSr ... N(PPK_ID) ]
[CFG] utilizing PPK for PPK_ID 'pqc-lab-ppk'

Discover what’s lacking in comparison with Half 4: the chosen proposal is obvious CURVE_25519: no KE1_ML_KEM_768, no IKE_INTERMEDIATE, no fragments. That is an old school classical handshake. And but it’s now quantum-resistant, completely due to the PPK:

  • N(USE_PPK) rides within the cleartext IKE_SA_INIT, every peer promoting help.
  • N(PPK_ID) rides contained in the encrypted IKE_AUTH, signalling which PPK is in use.
  • utilizing PPK for PPK_ID 'pqc-lab-ppk' is strongSwan confirming the key was discovered and combined into the important thing schedule.

Should you seize the run (similar tcpdump recipe as Half 4), three contrasts with the ML-KEM runs stand out:

  • No #43, no fragments. Simply the plain two-round-trip classical handshake. The quantum resistance is using completely on the PPK, invisible within the packets.
  • USE_PPK is public; PPK_ID is non-public. Discovery (“will we each help it?”) is within the cleartext IKE_SA_INITwhich PPK is chosen travels encrypted inside IKE_AUTH.
  • The PPK itself seems nowhere. That’s the entire level: combined into the keys on each ends, by no means despatched.

Show it’s truly required

As a result of we set ppk_required = sure, a peer that doesn’t maintain the matching PPK can’t full the handshake. Let’s show the key is genuinely folded into the keys. Terminate the tunnel, then, within the initiator solely, change its ppk-lab secret to a distinct worth (simulating a peer that doesn’t know the true one):

    ppk-lab {
        id = pqc-lab-ppk
        secret = 0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef
    }

Reload simply the initiator and re-initiate. This time it fails: the mismatched PPK adjustments the SK_pi/SK_pr keys, so the responder can’t confirm the initiator’s AUTH payload and rejects it:

[ENC] parsed IKE_AUTH response 1 [ N(AUTH_FAILED) ]
[IKE] obtained AUTHENTICATION_FAILED notify error
provoke failed: establishing CHILD_SA 'pqc-child' failed

There’s your proof: the PPK isn’t ornamental; it’s baked into the keys. Get it flawed and the tunnel merely gained’t come up.

Tidy up your clone. As a result of config/ is bind-mounted, your vi edits had been written to your repo information. Since they’re git-tracked, one command from the host (in key-exchange/) snaps each friends again to the shipped state: git restore config/. That re-comments the PPK traces, restores the key, and switches the proposal again to hybrid: a clear slate for the subsequent run.


When would you truly use this?

Primarily as a stepping stone. Tools that may’t negotiate RFC 9370 / ML-KEM but, however wants harvest-now-decrypt-later safety at the moment, can deploy a PPK now and migrate to ML-KEM as soon as each ends help it. The worth is the traditional preshared-key burden (safe distribution, storage, and rotation of a ≥256-bit secret throughout each peer pair), which is precisely why it’s a transition, not a house.

So the 2 roads complement one another: PPK for “I would like safety now on legacy gear,” ML-KEM for “I can negotiate it and need it to scale.” Loads of actual deployments will use each in the course of the migration years forward.


That’s a wrap on key trade

Over the past 4 posts we’ve taken the pressing pillar finish to finish: the menace, the contenders, the hybrid showdown, an actual captured handshake, and now a second impartial street to the identical security. You’ve seen, actually seen, that quantum-safe key trade is right here, sensible, and reasonably priced at the moment.

Now we flip to the different pillar, and it behaves utterly in a different way. No “harvest now, decrypt later” right here, however a sneakier deadline that catches virtually everybody off guard. In Half 6 we begin the authentication story and meet the post-quantum signatures. See you there, and convey your curiosity, as a result of this half has a twist.

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *