The latest articles on DEV Community by Deaksh (@deaksh). https://dev.to/deaksh https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3969760%2F4f1a8377-e712-41e3-8e13-133faaae13b9.JPG https://dev.to/deaksh en Deaksh Fri, 05 Jun 2026 11:31:57 +0000 https://dev.to/deaksh/what-actually-breaks-when-you-migrate-to-post-quantum-cryptography-and-how-to-find-out-before-2m5a https://dev.to/deaksh/what-actually-breaks-when-you-migrate-to-post-quantum-cryptography-and-how-to-find-out-before-2m5a <p>NIST finalised the post-quantum cryptography standards in August 2024 — <br> ML-KEM (FIPS 203), ML-DSA (FIPS 204), SLH-DSA (FIPS 205). Regulators are <br> now asking for migration roadmaps. Most teams don't know where to start.</p> <p>The problem isn't finding the new algorithms. It's knowing what they'll <br> cost you before you commit.</p> <h2> The number that changes everything </h2> <p>ML-DSA signatures are <strong>33× larger</strong> than ECDSA:</p> <div class="table-wrapper-paragraph"><table> <thead> <tr> <th>Algorithm</th> <th>Signature size</th> </tr> </thead> <tbody> <tr> <td>ECDSA-P256</td> <td>72 bytes</td> </tr> <tr> <td>ML-DSA-44</td> <td>2,420 bytes</td> </tr> <tr> <td>ML-DSA-65</td> <td>3,293 bytes</td> </tr> <tr> <td>SLH-DSA-256s</td> <td>29,792 bytes</td> </tr> </tbody> </table></div> <p>That's not just a performance concern. It breaks things structurally.</p> <h2> What actually breaks </h2> <p>-DNSSEC: The UDP limit is 1,232 bytes. An ML-DSA-44 signature alone is <br> 2,420 bytes. Your signed DNS responses will fragment — or worse, get dropped <br> by middleboxes that don't handle fragmented UDP.</p> <p>-JWT tokens: A 2,420-byte signature plus header plus claims blows past <br> the 8KB HTTP header limit most API gateways enforce. Your auth tokens stop <br> working at the proxy layer, not at your app.</p> <p>-TLS handshakes: The CertificateVerify message now spans 3 MTU packets. <br> Some legacy TLS stacks can't handle multi-packet handshake messages.</p> <p>Embedded devices: ML-KEM-768 key generation needs ~2MB of RAM. Most <br> microcontrollers don't have it. IoT devices that do TLS today may simply <br> not be able to do PQC.</p> <p>HSMs: Most hardware security modules don't support ML-KEM or ML-DSA yet. <br> If your private keys live in an HSM, you're waiting on vendor firmware updates.</p> <p>How to find your specific blockers</p> <p>I built <a href="https://github.com/Deaksh/pqc-sandbox" rel="noopener noreferrer">pqc-sandbox</a> to answer <br> this before you touch production.</p> <div class="highlight js-code-highlight"> <pre class="highlight plaintext"><code> bash pip install pqc-sandbox pqc-sandbox demo </code></pre> </div> security cryptography devops opensource