![\"Retail](\"https:\/\/dmsretail.com\/RetailNews\/wp-content\/uploads\/2022\/05\/RETAIL-ONLINE-TRAINING-728-X-90.png\")
<\/a><\/p>\n<\/p>\n
In Part 6 we met the post-quantum signatures and learned\u00a0why<\/em>\u00a0authentication has a sneakier quantum deadline than key exchange. Now let\u2019s get tactile. We\u2019re going to generate real post-quantum keys and certificates with our own hands, line them up next to the classics, and\u00a0weigh them<\/strong>. The size story is the single most important thing to internalise about post-quantum authentication, and the best part is you measure it yourself with nothing fancier than\u00a0 OpenSSL<\/strong>\u00a0is the first mainstream OpenSSL with\u00a0native<\/strong> support for all three NIST PQC algorithms (ML-KEM, ML-DSA, and SLH-DSA) built right in. No external plugins, no patches, no extra add-ons to install. If you\u2019ve got 3.5 or newer, you generate post-quantum keys and certificates with plain, ordinary OpenSSL commands, the same kind you\u2019d use for any classical key (check your version with Wait, if OpenSSL does ML-KEM, why did we use strongSwan for the key exchange?<\/strong>\u00a0Fair question. OpenSSL is a crypto\u00a0library<\/em>, not a VPN; its PQC support is wired into\u00a0TLS and certificates<\/strong>, not IKEv2. So OpenSSL is perfect for\u00a0making and inspecting<\/em>\u00a0the keys and certificates here, but it can\u2019t run an IKEv2 handshake. That\u2019s why anything happening on the actual VPN wire (the key exchange in Parts 4\u20135, and the authentication coming up in Part 8) is strongSwan\u2019s job. Two tools, two jobs.<\/p>\n A tiny throwaway container gives us a clean 3.5+ environment in seconds:<\/p>\n Then inside you install openssl:<\/p>\n All commands below run in that same shell.<\/p>\n You\u2019ll see the ML-DSA and SLH-DSA families listed, for example:<\/p>\n There they are: straight from OpenSSL\u2019s default provider, no plugins required.<\/p>\n We\u2019ll generate a key\u00a0and<\/em>\u00a0a self-signed certificate for eight algorithms in one loop. Quick note on the yardstick: a\u00a0self-signed certificate<\/strong>\u00a0(subject = issuer, signed with its own key) is the cleanest possible comparison: it bundles exactly one public key and one signature with no external CA, so the size reflects\u00a0only<\/em>\u00a0the algorithm\u2019s footprint. We also output\u00a0DER<\/strong>\u00a0(the compact binary encoding that actually travels on the wire), not the base64 PEM text you usually see.<\/p>\n Notice that for the post-quantum algorithms, generating a key uses the\u00a0exact same one-liner<\/em> as a classical one; only the algorithm name changes. That\u2019s the beauty of OpenSSL 3.5: post-quantum isn\u2019t a separate, special workflow, it\u2019s just another algorithm you pass to the same command.<\/p>\n Brace yourself:<\/p>\n Look at that jump! Let\u2019s put it in plain terms with the underlying numbers:<\/p>\n An Ed25519 certificate is just\u00a0326 bytes<\/strong>. The equivalent ML-DSA-65 cert is\u00a05516 bytes<\/strong>, roughly\u00a017\u00d7 larger<\/strong>. And SLH-DSA-128f? Its signature\u00a0alone<\/em>\u00a0is\u00a017088 bytes<\/strong>, bigger than many entire web pages. Notice SLH-DSA\u2019s quirk too: a tiny 32-byte public key, but a gigantic signature.\u00a0Whoa.<\/em><\/p>\n Wait, why isn\u2019t the cert just key + signature?<\/strong>\u00a0Good catch. For ML-DSA-65, key (1952 B) + signature (3309 B) = 5261 B, yet the cert is 5516 B, about 255 B more. A certificate isn\u2019t a simple concatenation; it\u2019s a structured X.509 document embedding the key and signature alongside metadata (version, serial, validity dates, issuer\/subject names, algorithm OIDs, a few extensions, plus ASN.1\/DER framing on every field). That overhead is roughly\u00a0fixed<\/em>\u00a0(~230\u2013260 B) regardless of algorithm, which is why it dominates a tiny Ed25519 cert but barely registers on a chunky ML-DSA one.<\/p>\n Handshakes don\u2019t carry one cert; they carry\u00a0certificate chains\u00a0plus<\/em>\u00a0a handshake signature<\/strong>. Swap a 3-cert ECDSA chain (~1.2 KB total) for an ML-DSA-65 chain and you\u2019re suddenly shipping\u00a015\u201320 KB<\/strong>\u00a0in the handshake. In IKEv2 that means the\u00a0 And \u201cleaning hard on fragmentation\u201d isn\u2019t just a minor detail. Fragmentation was designed as an occasional fallback for the rare oversized message; post-quantum flips that so\u00a0almost every<\/em>\u00a0handshake is large and fragmented. That brings real costs:<\/p>\n None of this\u00a0breaks<\/em>\u00a0PQC auth (strongSwan handles it), but it\u2019s why \u201cthe certs got bigger\u201d turns into round trips, retransmits, and middlebox trouble at scale. We\u2019ll watch exactly this happen on the wire in Part 8.<\/p>\n A common worry, so before we sign anything ourselves (we\u2019ll do that in Step 5), here\u2019s what to expect per signature:<\/p>\n The takeaway:\u00a0ML-DSA signs and verifies right alongside Ed25519 and ECDSA<\/strong>, while\u00a0SLH-DSA\u2019s\u00a0 Certificates are about\u00a0trust<\/em>, and trust comes from signatures that can\u2019t be forged. Let\u2019s prove it.<\/p>\n You should see\u00a0 Now tamper with the message and watch it fail:<\/p>\n Want to\u00a0feel<\/em>\u00a0the SLH-DSA difference? Time it:<\/p>\n Noticeably slower, and the signature more than twice the ML-DSA size. That\u2019s the hash-based trade-off in action: ultra-cautious security, but you\u2019d never want it on a high-volume handshake.<\/p>\n You generated post-quantum certificates, measured the size hit with your own hands, watched ML-DSA and SLH-DSA sign and verify (and reject a forgery), and felt the SLH-DSA speed penalty. The \u201ccerts get bigger\u201d story is no longer something you read; it\u2019s something you weighed.<\/p>\n But certificates sitting in a folder are only half the fun. In\u00a0Part 8<\/strong>\u00a0we hand these certs to strongSwan and use them to mutually authenticate a\u00a0real<\/em>\u00a0IKEv2 VPN tunnel: classical ECDSA first, then bleeding-edge post-quantum ML-DSA. We\u2019ll watch the handshake balloon and fragment exactly as predicted, and stand right at the bleeding edge where this stuff is still being built. See you there!<\/p>\n<\/p><\/div>\nls<\/code>. Everything runs in a throwaway alpine<\/code>\u00a0container with OpenSSL, so all you need is Docker.<\/p>\n
\nopenssl version<\/code>).<\/p>\ndocker run --rm<\/span> -it alpine:3.22 sh
\n<\/code><\/pre>\napk add --no-cache openssl
\nopenssl version
\nmkdir<\/span> -p \/pqauth && cd<\/span> \/pqauth
\n<\/code><\/pre>\n
\nStep 1: Confirm the PQC algorithms are there<\/h2>\n
openssl list -signature-algorithms | grep -iE \"ml-dsa|slh-dsa|ed25519\"<\/span>
\n<\/code><\/pre>\n{ 1.3.101.112, ED25519 } @ default
\n{ 2.16.840.1.101.3.4.3.18, id-ml-dsa-65, ML-DSA-65, MLDSA65 } @ default
\n{ 2.16.840.1.101.3.4.3.20, id-slh-dsa-sha2-128s, SLH-DSA-SHA2-128s } @ default
\n...
\n<\/code><\/pre>\n
\nStep 2: Mint a self-signed cert<\/h2>\n
algs=\"ED25519:ed25519 EC:ecp256 RSA:rsa3072 ML-DSA-44:mldsa44 ML-DSA-65:mldsa65 ML-DSA-87:mldsa87 SLH-DSA-SHA2-128s:slh128s SLH-DSA-SHA2-128f:slh128f\"<\/span>
\n
\nfor<\/span> entry in<\/span> $algs<\/span>; do<\/span>
\n alg=${entry%%:*}<\/span>; name=${entry##*:}<\/span>
\n case<\/span> \"$alg<\/span>\"<\/span> in<\/span>
\n RSA) openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out \"$name<\/span>.key\"<\/span> ;;
\n EC) openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out \"$name<\/span>.key\"<\/span> ;;
\n *) openssl genpkey -algorithm \"$alg<\/span>\"<\/span> -out \"$name<\/span>.key\"<\/span> ;;
\n esac<\/span>
\n openssl req -x509 -new -key \"$name<\/span>.key\"<\/span> -out \"$name<\/span>.crt\"<\/span> -days 365 -subj \"\/CN=$name<\/span>-peer\"<\/span> -outform DER
\ndone<\/span>
\n<\/code><\/pre>\n
\nStep 3: Weigh them<\/h2>\n
ls<\/span> -la *.crt | awk '{print $5\" \"$9}'<\/span> | sort<\/span> -n
\n<\/code><\/pre>\n326 ed25519.crt
\n389 ecp256.crt
\n1043 rsa3072.crt
\n3987 mldsa44.crt
\n5516 mldsa65.crt
\n7474 mldsa87.crt
\n8139 slh128s.crt
\n17371 slh128f.crt
\n<\/code><\/pre>\n\n\n
\n \nAlgorithm<\/th>\n Security<\/th>\n Public key<\/th>\n Signature<\/th>\n Cert (DER)<\/th>\n<\/tr>\n<\/thead>\n \n Ed25519<\/td>\n ~128-bit<\/td>\n 32 B<\/td>\n 64 B<\/td>\n 326 B<\/td>\n<\/tr>\n \n ECDSA P-256<\/td>\n ~128-bit<\/td>\n 65 B<\/td>\n ~70 B<\/td>\n 389 B<\/td>\n<\/tr>\n \n RSA-3072<\/td>\n ~128-bit<\/td>\n 384 B<\/td>\n 384 B<\/td>\n 1043 B<\/td>\n<\/tr>\n \n ML-DSA-44<\/strong><\/td>\n NIST L2<\/td>\n 1312 B<\/td>\n 2420 B<\/td>\n 3987 B<\/td>\n<\/tr>\n \n ML-DSA-65<\/strong><\/td>\n NIST L3<\/td>\n 1952 B<\/td>\n 3309 B<\/td>\n 5516 B<\/td>\n<\/tr>\n \n ML-DSA-87<\/strong><\/td>\n NIST L5<\/td>\n 2592 B<\/td>\n 4627 B<\/td>\n 7474 B<\/td>\n<\/tr>\n \n SLH-DSA-128s<\/td>\n NIST L1<\/td>\n 32 B<\/td>\n 7856 B<\/td>\n 8139 B<\/td>\n<\/tr>\n \n SLH-DSA-128f<\/td>\n NIST L1<\/td>\n 32 B<\/td>\n 17088 B<\/td>\n 17371 B<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
\nWhy size matters<\/h2>\n
IKE_AUTH<\/code>\u00a0exchange balloons and leans hard on\u00a0fragmentation<\/strong>: the same pressure ML-KEM put on\u00a0IKE_INTERMEDIATE<\/code>\u00a0back in the key-exchange pillar, but now on the authentication leg.<\/p>\n\n
\nStep 4: Are they slow?<\/h2>\n
\n\n
\n \nAlgorithm<\/th>\n Signing<\/th>\n Notes<\/th>\n<\/tr>\n<\/thead>\n \n Ed25519 \/ ECDSA<\/td>\n ~instant<\/td>\n so fast the timing is dominated by just launching the command<\/td>\n<\/tr>\n \n ML-DSA-44\/65\/87<\/td>\n ~instant<\/td>\n sits right alongside the classics<\/td>\n<\/tr>\n \n SLH-DSA-128f<\/td>\n a few ms<\/td>\n noticeably heavier<\/td>\n<\/tr>\n \n SLH-DSA-128s<\/td>\n ~100+ ms<\/td>\n dramatically slower to sign<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n s<\/code>\u00a0(\u201csmall\u201d) variants are hugely slower.<\/strong>\u00a0That slowness is\u00a0exactly<\/em>\u00a0why SLH-DSA is reserved for things you sign rarely (a root CA signs a handful of certs a year, so who cares if each takes 100 ms?) rather than a busy TLS terminator doing thousands of handshakes a second. You\u2019ll feel that difference for yourself with the\u00a0time<\/code>\u00a0command in Step 5.<\/p>\n
\nStep 5: Sign, verify, tamper<\/h2>\n
echo<\/span> \"transfer 1000 to tom\"<\/span> > msg.txt
\nopenssl pkeyutl -sign -inkey mldsa65.key -rawin -in<\/span> msg.txt -out msg.sig
\nwc<\/span> -c < msg.sig
\n
\n
\nopenssl pkey -in<\/span> mldsa65.key -pubout -out mldsa65.pub
\nopenssl pkeyutl -verify -pubin -inkey mldsa65.pub -rawin -in<\/span> msg.txt -sigfile msg.sig
\n<\/code><\/pre>\nSignature Verified Successfully<\/code>. Note the clean split: signing used the\u00a0private<\/strong>\u00a0key, verifying used\u00a0only<\/em>\u00a0the\u00a0public<\/strong>\u00a0key. That\u2019s the whole point of public-key signatures: signing is private, verifying is public.<\/p>\necho<\/span> \"transfer 1000 to mallory\"<\/span> > msg.txt
\nopenssl pkeyutl -verify -pubin -inkey mldsa65.pub -rawin -in<\/span> msg.txt -sigfile msg.sig
\n<\/code><\/pre>\nSignature Verification Failure<\/code>. Change a single byte and the post-quantum signature rejects it: exactly the unforgeable integrity guarantee we depend on, now resting on lattice math instead of elliptic curves.<\/p>\ntime openssl pkeyutl -sign -inkey slh128s.key -rawin -in<\/span> msg.txt -out slh.sig
\nwc<\/span> -c < slh.sig
\n<\/code><\/pre>\n
\nWhat we just did<\/h2>\n