One rationale seems to be the standardization of PQ cryptography and thus the ability to go directly from weaker cryptography to PQ, rather than in 2 steps (112->128->PQ).
On the chopping block:
* ECB (\o/)
* Triple DES (TDEA)
* Finite field DSA (for new signatures)
* ECDSA at strengths lower than 112 bits
* RSA below 2048 bits
* RNGs, HMACs, HKDF, PBKDF and hashes based on SHA1 and the truncated 224-bit SHA-2/3 modes
No big surprises. The 224's are interesting, because folklorically they have value in hash constructions where resistance to length extension is useful. In practice, everyone just uses HMAC anyways.
On the one hand i am glad that ECB dies officially as a mode on the other hand i wonder what NIST officially recommends when you want to encrypt data that's shorter than one block. xD
regarding finally transitioning away from SHA1: about fucking time :D
For instance the CTR mode can be used to encrypt any number of bits, down to a single bit.
The problem of the other modes vs. ECB is that they require the generation and the transmission of an "intialization vector", i.e. either a counter value or a random number, depending on the mode, so besides the short encrypted data a longer whole block must be transmitted. This can be avoided only when a set of small data are considered as parts of a long sequence of encrypted data, so the encryption mode is not reinitialized at each new message, but the last state is remembered.
ECB is a valid encryption mode only when it is used to encrypt random numbers having the length of the block (or other kind of data for which there is a strong guarantee that there will be no repeated values). It is secure for challenge-response authentication, if the challenges are unpredictable random numbers. ECB would be a perfectly secure method for encrypting other encryption keys, which must be random, except that one might want to encrypt together with the values of the keys other data, such as identifiers or error detection codes, in which case ECB could not be used to encrypt the additional non-random data.
"Triple AES" sounds as something insecure if it is similar to triple DES. (Insecure in the sense of providing a small additional strength obtained with a big increase in the time and energy needed for encryption/decryption.)
Only amateurs would choose to implement a "Triple AES", so it is very likely that they will also write a buggy implementation. Triple DES has not been used because it was a good strengthening method, but only because it could be used with unmodified hardware modules designed for simple DES. When a cipher strengthening is done in software, there are much better methods.
The best way to strengthen AES above the standard AES-256 is to double the block length from 128 bits to 256 bits. Increasing the key length over 256 bits is much less useful, because the key length is not the weakest point of AES-256. A 256-bit key is strong enough even against quantum computers, but short 128-bit blocks can be a vulnerability in certain applications. The key schedule algorithm of AES, which converts the cipher key into a set of round keys, is mediocre, so the length of the cipher key is the least important concern about the strength of AES.
The original Rijndael proposal had a stronger variant with 256-bit blocks, which has not been retained in the standard. Nevertheless, it is easy to implement it with the Intel/AMD AES instructions or with the Arm Aarch64 AES instructions. Intel has even published an application note describing how to do this, when the AES instructions have been introduced in the Westmere CPUs.
After increasing the block length, increasing the number of rounds can provide additional strengthening. Another choice would be to replace the standard key schedule algorithm with a stronger non-standard algorithm (i.e. one providing more random round keys). Increasing the key over 256 bits provides a much less useful strengthening in comparison with the cost required for executing the additional necessary operations.
I'm surprised to see symmetric algorithms in this list. It's been a while since I worked adjacent to the field (I'm not a cryptographer but spent a lot of time working with them in a past life), but my understanding is that PQ refers to replacing those algorithms that are vulnerable to advances in quantum computing, e.g., public key algorithms, such as RSA, that use relative primes and are therefore subject to attack by efficient implementations of Shor's algorithm.
AIUI, symmetric algorithms such as 3DES are not subject to these attacks, but my understanding could be wrong.
Both ECB and TDEA are dangerously outmoded even if quantum cryptanalysis is never realized; ECB because you can see penguins through it, and TDEA because of the 8 byte block size.
Makes sense to skip the 128-bit step and go straight to post-quantum (PQ) cryptography, especially if it’s inevitable. And yeah, good riddance to ECB, that should’ve been axed ages ago.
Rumors suggest a toy 22bit RSA cipher factorization was recently demonstrated in China on D-wave quantum annealing platforms, and several paper details of the scaling potential were censored.
i.e. the NIST advice to incorporate quantum resistant algorithms shouldn't be taken lightly. For some, transitioning means wrapping a well-tested RSA system in something newer like FIPS 203, 204, or 205.
We live in interesting times for certain, as gnugpg with Kyber support has static build fails on some platforms (libassuan 3.0.1 bug). =3
I don't know of anyone working in the space that takes that demonstration seriously, but I didn't go digging much; let me know if you find someone. For a lot of cryptography engineers, the mention of "D-Wave" is enough to shut down the inquiry.
The document specifies that SHA-1 in HMACs is the be entirely disallowed after 2030. That seems like it would cause needless reimplementation of systems with the associated chance of security problems and expense. SHA-1 used in an HMAC is generally known to be secure.
> The 2048 deprecation in 2030 seems to be about quantum resistance, not about a move to 4096 bit RSA.
From [0], where the 112-bit 'security strength' of 2048-bit RSA is ultimately pulled from:
"The comparable security strengths provided below are based on accepted estimates as of the publication of this Recommendation using currently known methods. Advances in factoring algorithms, general discrete-logarithm attacks, elliptic-curve discrete-logarithm attacks, and other algorithmic advances as well as quantum computing may affect these equivalencies in the future. New or improved attacks or technologies may be developed that leave some of the current algorithms completely insecure."
Their recommendation is to switch to 3072-bit RSA or higher by 2031, since that has a 128-bit 'security strength' by their formula. So I don't think this has much to do with quantum resistance: as GP says, no reasonable RSA key size will help much with that.
SHA-1 is around long enough, that they build precomputation tables. NSA and other state-backed organizations have the capacity to do that. The community should at least up the ante to 256 bit to make things harder.
Readit News
On the chopping block:
* ECB (\o/)
* Triple DES (TDEA)
* Finite field DSA (for new signatures)
* ECDSA at strengths lower than 112 bits
* RSA below 2048 bits
* RNGs, HMACs, HKDF, PBKDF and hashes based on SHA1 and the truncated 224-bit SHA-2/3 modes
No big surprises. The 224's are interesting, because folklorically they have value in hash constructions where resistance to length extension is useful. In practice, everyone just uses HMAC anyways.
*
regarding finally transitioning away from SHA1: about fucking time :D
For instance the CTR mode can be used to encrypt any number of bits, down to a single bit.
The problem of the other modes vs. ECB is that they require the generation and the transmission of an "intialization vector", i.e. either a counter value or a random number, depending on the mode, so besides the short encrypted data a longer whole block must be transmitted. This can be avoided only when a set of small data are considered as parts of a long sequence of encrypted data, so the encryption mode is not reinitialized at each new message, but the last state is remembered.
ECB is a valid encryption mode only when it is used to encrypt random numbers having the length of the block (or other kind of data for which there is a strong guarantee that there will be no repeated values). It is secure for challenge-response authentication, if the challenges are unpredictable random numbers. ECB would be a perfectly secure method for encrypting other encryption keys, which must be random, except that one might want to encrypt together with the values of the keys other data, such as identifiers or error detection codes, in which case ECB could not be used to encrypt the additional non-random data.
Only amateurs would choose to implement a "Triple AES", so it is very likely that they will also write a buggy implementation. Triple DES has not been used because it was a good strengthening method, but only because it could be used with unmodified hardware modules designed for simple DES. When a cipher strengthening is done in software, there are much better methods.
The best way to strengthen AES above the standard AES-256 is to double the block length from 128 bits to 256 bits. Increasing the key length over 256 bits is much less useful, because the key length is not the weakest point of AES-256. A 256-bit key is strong enough even against quantum computers, but short 128-bit blocks can be a vulnerability in certain applications. The key schedule algorithm of AES, which converts the cipher key into a set of round keys, is mediocre, so the length of the cipher key is the least important concern about the strength of AES.
The original Rijndael proposal had a stronger variant with 256-bit blocks, which has not been retained in the standard. Nevertheless, it is easy to implement it with the Intel/AMD AES instructions or with the Arm Aarch64 AES instructions. Intel has even published an application note describing how to do this, when the AES instructions have been introduced in the Westmere CPUs.
After increasing the block length, increasing the number of rounds can provide additional strengthening. Another choice would be to replace the standard key schedule algorithm with a stronger non-standard algorithm (i.e. one providing more random round keys). Increasing the key over 256 bits provides a much less useful strengthening in comparison with the cost required for executing the additional necessary operations.
SPHINCS+ / FIPS 205 should be available soon.
FALCON ...unknown FIPS draft TBA soon.
These are newer quantum resistant algorithms, and should be considered in your future maintenance cycle as they become available in the libraries.
NIST has some of the brightest minds in the world. When they suggest something, than one should probably take the advice very seriously. =3
AIUI, symmetric algorithms such as 3DES are not subject to these attacks, but my understanding could be wrong.
Care to enlighten?
i.e. the NIST advice to incorporate quantum resistant algorithms shouldn't be taken lightly. For some, transitioning means wrapping a well-tested RSA system in something newer like FIPS 203, 204, or 205.
We live in interesting times for certain, as gnugpg with Kyber support has static build fails on some platforms (libassuan 3.0.1 bug). =3
* https://articles.59.ca/doku.php?id=em:20482030
The document specifies that SHA-1 in HMACs is the be entirely disallowed after 2030. That seems like it would cause needless reimplementation of systems with the associated chance of security problems and expense. SHA-1 used in an HMAC is generally known to be secure.
The 2048 deprecation in 2030 seems to be about quantum resistance, not about a move to 4096 bit RSA.
From [0], where the 112-bit 'security strength' of 2048-bit RSA is ultimately pulled from:
"The comparable security strengths provided below are based on accepted estimates as of the publication of this Recommendation using currently known methods. Advances in factoring algorithms, general discrete-logarithm attacks, elliptic-curve discrete-logarithm attacks, and other algorithmic advances as well as quantum computing may affect these equivalencies in the future. New or improved attacks or technologies may be developed that leave some of the current algorithms completely insecure."
Their recommendation is to switch to 3072-bit RSA or higher by 2031, since that has a 128-bit 'security strength' by their formula. So I don't think this has much to do with quantum resistance: as GP says, no reasonable RSA key size will help much with that.
[0] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S..., section 5.6.1
[1] https://en.wikipedia.org/wiki/National_Institute_of_Standard...