SoylentNews is people
SoylentNews
Cryptographer Derek Zimmer at Private Internet Access' blog has a three-part series on the National Institute for Standards and Technology (NIST) and its second round of review for candidate algorithms for post-quantum cryptography. After a general audience introduction to what post-quantum cryptography is, he writes about the selection process used by NIST to eventually settle on a pair of algorithms. After several rounds, there will be only two algorithms selected. One will be for asymmetric public-key encryption, and the other will be for digital signatures. Parts 2 and 3 of his posts summarize each candidate algorithm individually.
NIST Round 2 and Post-Quantum Cryptography (part 1)
NIST Round 2 and Post-Quantum Cryptography – The New Asymmetric Algorithms (part 2)
NIST Round 2 and Post-Quantum Cryptography – The New Asymmetric Algorithms (part 3)
(Score: 3, Informative) by pipedwho on Wednesday February 27 2019, @09:21PM (3 children)
Oh well, since no one is commenting here, let me say some things that I'm kind of excited about.
The previous crop of vetted and standardised public key algorithms (RSA, DSA, DHKE, ECDHE, ECDSA) are based on modular exponentiation or elliptic curve finite fields. The problems they have is that they are very compute intensive for smaller embedded systems in ways that prohibit using the largest more secure key sizes. Elliptic curves are currently the best in the security/performance ratio, but for certain things RSA can be quite efficient if only certain aspects are required (such as verify only).
However, some of the lattice based crypto systems both decrease processing overhead and key size for a given security metric versus other algorithms. For example, NTRU has been around for more than 20 years and is used in a lot of embedded devices, because even as a public key system it is only marginally slower than symmetric encryption algorithms like AES. Key size is also small for an equivalent level of security compared to RSA/DHKE/etc. This a huge benefit to smaller embedded micro controllers that have both limited memory, not much processing power, and finite energy reserves (battery powered).
The AES standardisation process benefitted small systems in this way too, since Rijndael (now known as AES) is far more efficient and secure than Triple-DES (the NIST recommendation at the time) when implemented in software.
I'm looking forward to this standardisation process from the perspective of performance on small systems. NIST obviously needs to make sure the new standards provide sufficient security, but it is quite possible that at the same time we might end up with a set of algorithms optimised for both efficiency and speed compared to the current standards.
Yes, it's true anyone can already use any of these non-standard algorithms for customised embedded system designs. But, too many industries and regulators require NIST based standards as 'best practice', and often reject equally (or potentially more) secure solutions, simply because they don't have NIST's stamp of approval. Which is fair enough, since it is close to impossible for a non-cryptographic expert (and even for some 'experts') to independently evaluate the security and implementations of these non-standardised algorithms. So from a corporate perspective, it's easier to just play it safe and go with something NIST approved - even if it means more expensive, larger embedded devices. Some companies will just alter their security model to avoid public key algorithms altogether.
It's my hope that these new NIST standardised public key cryptosystems provide industries (industrial control, sensor networks, medical, etc) and other standards bodies (Bluetooth, Zigbee, etc) a path to include public key security in their standards to enable secure implementations on small ultra low power systems.
(Score: 0) by Anonymous Coward on Wednesday February 27 2019, @11:06PM (2 children)
The one problem for those ones you talk about is that the standard use of these will probably be TLS or other network-based encryption. The different network people whine about the TCP handshake overhead, so I'd hate to see them when we adopt a lattice system that requires a key exchange of several hundred kilobytes, if not megabytes.
(Score: 2) by pipedwho on Thursday February 28 2019, @06:33AM (1 child)
That’s why I’m hoping they choose one that maintains security with much smaller key sizes. If the keys are too large, it’ll create obstacles to widespread adoption.
(Score: 0) by Anonymous Coward on Thursday February 28 2019, @07:02AM
The problem with PQC is that the basic trade-off is handshake size (which some allow to be processed while streamed in to calculate the key) versus key size versus resource requirements (mainly memory or CPU, and sometimes both) versus forward secrecy (you have to trust that certain data is not stored by the handshaking party). Now, it is possible to reduce them all at the same time without reducing security, but then you give up the guarantee that the exchange can be solved at all, which requires a whole new handshake in a certain percentage of cases where it can't.