The National Security Agency (NSA, USA) has announced the “Commercial National Security Algorithm Suite 2.0” (CNSA 2.0, you can find the announcement here and some FAQ here).
There are a few points of interest related to this announcement:
- first of all, NIST has not completed the selection and standardization of all possible Post Quantum Cryptography algorithms, which should be completed by 2024, but the NSA has anyway decided to require the implementation of the algorithms already standardized by NIST (see NIST SP 800-208) and to suggest to get ready to implement the others which will be standardized in the next years; this can be interpreted as NSA has some kind of urgency in introducing the new algorithms and that it foresees that Quantum Computers able to break current cryptographic algorithms like RSA will arrive in a not too far future;
- the already standardized new PQC algorithms are to be used only for software and firmware signing, and the transition to them must begin immediately;
- the timelines are quite short considering the time it takes to implement, also in hardware, all the new algorithms, summarizing: the already standardized new PQC algorithms must be implemented by 2025 and exclusively used by 2030; all others new PQC algorithms should be supported or implemented by 2025 and exclusively used by 2033;
- the above mentioned timelines suggest that NSA believes that a Quantum Computer able to break current cryptographic algorithms like RSA could be available by 2035 or around.
Cryptographic algorithms change, evolve, are retired. This is nothing new, but still we are not good in swapping an old, weak or deprecated algorithm for a new one. There are many issues that make this quite complex, like
- algorithms can be implemented in hardware for performance, substituting them with software implementations can notably degrade the performance of the system, and new hardware implementation can take years to implement and require changing many hardware components
- new algorithms have different software interfaces which can require that all programs using them have to be updated accordingly.
Experience of the last 30 years shows us that it can take many years to change to new cryptographic algorithms: from DES to AES, from MD4 and MD5 to SHA-0, SHA-1, SHA-2 and SHA-3. To make things even more complicated, long term sensitive information must be kept securely encrypted for many years, which requires using algorithms which will remain effective for the same time span, whereas digital signatures must be re-applied with the new and stronger algorithms before the old ones are deprecated.
To all this, we can add the threat of Quantum Computers which, in case they will become really operational, will be able to break practically all current asymmetric algorithms (eg. RSA). Do we need to change all asymmetric algorithms with the new Post Quantum Cryptographic algorithms as soon as these will be available? And how long will this take? What if one of these new PQC algorithms, which are based on new types of math, will be broken short time after its deployment?
So we need to vastly improve the “agility” of swapping from old to new cryptographic algorithms and to be proactive in doing it. This requires designing new interfaces and processes which will easily allow to swap one cryptographic algorithm for a new one.
Post Quantum Cryptography (PQC) is the name which describes new cryptographic algorithms which should be safe to use even if a real Quantum Computer will arrive. NIST competition to designate these algorithms has started in 2016, now is in its 4th round and is supposed to end by 2024.
This year NIST, for round 4, has selected 4 final candidates and 4 potential replacements in case any of the 4 front runners will drop out. But this year already two candidates have been invalidated due to the discovery of serious security weaknesses: in February, at the end of round 3, it was the case of Rainbow, and these days (see here), in round 4, is the case of SIKE, a potential replacement candidate.
The weaknesses discovered apply only to the algorithms which have been invalidated, but the fact that they have been discovered so late in the NIST selection process should make us wonder if the timeline will be maintained or more time will be needed to completely test and evaluate these new algorithms.
Another example of how difficult is to securely implement cryptography: a study (read here a summary) shows that Mega’s encryption scheme had (patches have already been applied) some faults which in some situation allowed a skilled attacker to access user data in clear.
This is a recurring theme (see eg. this older post), how difficult it is to implement Cryptography in the “right” way. It requires a lot of knowledge and expertise in Cryptography, programming skills are not enough.
Recently I read this article “PRACTICAL BRUTEFORCE OF AES-1024 MILITARY GRADE ENCRYPTION” by Kudelski Security Research, in which they show how it was possible to brute force what was called “AES-1024 military grade encryption“. AES is not broken (and “AES-1024” does not really stand for AES with 1024-bit keys) but the main problem was the custom procedure adopted to transform a user chosen password into an AES encrypting key.
Which again shows how it is difficult to implement Cryptography to attain the expected security goals.
It seems that in one year or so we could (or should I write “will”?) finally see the beginning of the demise of passwords. The FIDO Alliance is proposing an extension of their UAF protocol which should make it possible to access many online and company applications without a password. The trick is to use the user’s smartphone as the authenticating device with two significant requirements: the user should confirm her/his identity on the smartphone with a biometric authentication, and the smartphone should be directly connected to the device (PC) which is performing the authentication by eg. Bluetooth. More information can be found on the FIDO website (here) and other articles (eg. here and here).
Still I am worried about the security of smartphones: more and more information, functionalities and security features are based on them, but, for example, we haven’t yet solved the problem of patching the Android system which most smartphone use. And what about using just the smartphone (or tablet) and not a PC to access online / company applications?
I do not really know what is going on, but news on Quantum Computers (or “Quantum Information Science” – QIS) and Post Quantum Crypto keep piling up, the last one coming from the White House (see eg. here).
Openssh has released a few days ago version 9.0 (here the announcement) which features the “hybrid Streamline NTRU Prime + x25519 key exchange method by default.” In other words, the key exchange is performed by the standard X25519 ECDH key exchange algorithm (the previous default) paired with the NTRU Prime, a Post Quantum Crypto algorithm “believed to resist attacks enabled by future quantum computers.” If one of the two algorithms fails to protect the confidentiality of the encryption key, the other should continue to protect it, even if a quantum computer will be able to successfully attack X25519 ECDH alone.
We do not know if or when Quantum Computers will arrive: 10 years “at best” for Quantum Computing, “at worst” for Cryptography.
Today Post Quantum Cryptography (PQC) aims to provide algorithms resistant to Quantum Computers but it is still in an development phase (see eg. NIST for details).
Concerning information security and Quantum Computer, today we should worry about at least two issues:
- how long it will take to perform the transition to Post Quantum Crypto algorithms;
- how to protect information encrypted today with standard algorithms but that should still be protected in 10 or more years.
For the second point, one possibility is to adopt already today the emerging PQC algorithms and “double encrypt” sensitive long-term data with a current algorithm and PQC-devel algorithm, with the hope that if one of the two fails the other will keep protecting the data. And based on this IBM announcement (see also here), this seems to be starting right now.
And the the weak link is … the human factor.
Not surprisingly, recent reports (see eg. here) describe how attackers abuse even MFA processes based on Authenticator Apps (on mobile phones). Of course it requires anyway some work, in a generic scenario it requires to know already the username and password of the account or service under attack and protected by MFA. But after that, bombing the user with second factor authentication requests on the mobile App (in the middle of the night) sometimes leads to receive access (by someone who actually would like to sleep).
This should not be possible with FIDO2 token or biometrics based MFA, but the “human factor” is often very little predictable…