<story><title>Don’t Rush Quantum-Proof Encryption, Warns NSA Research Director</title><url>https://www.nextgov.com/emerging-tech/2019/11/dont-rush-quantum-proof-encryption-warns-nsa-research-director/161217/</url></story><parent_chain><item><author>Perseids</author><text>The whole premise of the article is broken:&lt;p&gt;1. Every respectable cryptographic protocol designer would hedge their bets by combining a post-quantum cryptography (PQC) algorithm with a classical one, preferable elliptic curve cryptography (ECC), such that you first have to break ECC in order to attack the post-quantum cryptography. ECC is great in that it is both fast, secure, its signatures, ciphertexts and keys are small. Every post-quantum algorithm fails in at least one of the categories, but as ECC excels everywhere, the overhead is basically bound by a factor of two.&lt;p&gt;2. Our focus can&amp;#x27;t be on choosing one PQC algorithm now (and keep it forever), as it is a very young field comparably (as the article agrees). Instead, we need to built up &lt;i&gt;algorithm agility&lt;/i&gt; in our protocols and software, as we are probably going to change PQC algorithms at least once, when the cryptographic community has gained experience in PQC design&amp;#x2F;cryptanalysis and we switch to the second wave PQC algorithms. In practice that means: Never assume keys, ciphertext, signatures are small. Investigate whether it is possible for keys to have &lt;i&gt;state&lt;/i&gt; (see Lamport signature). And the only way to show these properties about protocols and software &lt;i&gt;is to try out some PQC algorithms now&lt;/i&gt;. (Why the urgency? Because software and protocol turnaround time is bonkers in commercial applications. Heck, parts of the payment industry still use single DES in 2019...)&lt;p&gt;Given that the NSA knows both of this, the question is whether the author was clueless or the NSA spokesperson is malicious.</text></item></parent_chain><comment><author>bdamm</author><text>My employer produces low-power devices with hardware cryptography built into them. Without the crypto hardware, almost all crypto (including ECC) is too slow for practical use. It&amp;#x27;s all well and good to have &amp;quot;crypto agility&amp;quot; but that ends when it comes to depending on silicon. So if we&amp;#x27;re making our 20 year plan for, say, the next generation hardware platform that we&amp;#x27;re going to invest many millions of dollars and thousands of engineer hours to build, then which PQC algorithms will we select to be built into our platform? It&amp;#x27;s very unclear at this point.&lt;p&gt;Certainly we can be flexible in key and cert sizes, but also I happen to live in a world where a 1200 byte MTU actually matters a great deal, so it&amp;#x27;s easier to just push the requirement for dealing with enormous certificates down the road for the day when we actually have enormous certificates. Future-proofing isn&amp;#x27;t an issue yet because legacy devices will &lt;i&gt;never&lt;/i&gt; be able to do PQC.&lt;p&gt;The premise is not broken at all, for us.</text></comment>
<story><title>Don’t Rush Quantum-Proof Encryption, Warns NSA Research Director</title><url>https://www.nextgov.com/emerging-tech/2019/11/dont-rush-quantum-proof-encryption-warns-nsa-research-director/161217/</url></story><parent_chain><item><author>Perseids</author><text>The whole premise of the article is broken:&lt;p&gt;1. Every respectable cryptographic protocol designer would hedge their bets by combining a post-quantum cryptography (PQC) algorithm with a classical one, preferable elliptic curve cryptography (ECC), such that you first have to break ECC in order to attack the post-quantum cryptography. ECC is great in that it is both fast, secure, its signatures, ciphertexts and keys are small. Every post-quantum algorithm fails in at least one of the categories, but as ECC excels everywhere, the overhead is basically bound by a factor of two.&lt;p&gt;2. Our focus can&amp;#x27;t be on choosing one PQC algorithm now (and keep it forever), as it is a very young field comparably (as the article agrees). Instead, we need to built up &lt;i&gt;algorithm agility&lt;/i&gt; in our protocols and software, as we are probably going to change PQC algorithms at least once, when the cryptographic community has gained experience in PQC design&amp;#x2F;cryptanalysis and we switch to the second wave PQC algorithms. In practice that means: Never assume keys, ciphertext, signatures are small. Investigate whether it is possible for keys to have &lt;i&gt;state&lt;/i&gt; (see Lamport signature). And the only way to show these properties about protocols and software &lt;i&gt;is to try out some PQC algorithms now&lt;/i&gt;. (Why the urgency? Because software and protocol turnaround time is bonkers in commercial applications. Heck, parts of the payment industry still use single DES in 2019...)&lt;p&gt;Given that the NSA knows both of this, the question is whether the author was clueless or the NSA spokesperson is malicious.</text></item></parent_chain><comment><author>morelisp</author><text>Algorithm agility has been a hilarious disaster for designing secure systems. In reality even protocols like TLS that are nominally agile advance primarily by versioning, not agility - and TLS is somewhat of a best case here compared to e.g. the mess of JOSE.</text></comment>