Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
Assuming a product shelf life of 30 years and the product which is released now in 2021, what is the recommendation/suggestion for hashing or encryption algorithms to use in the product? That means, should I directly make use of the superior algorithms(SHA-512 for hashing, AES-256 for encryption) or should this be driven by SAL(Security Assurance Level) or any other different factors?
Also, are there any recommendations from NIST to choose these based on the product's shelf life?
Using SHA-512 and AES-256 as you suggest is generally not wrong. But this may change in the future.
In detail: It depends on the usecase.
Do you need a block cipher or a stream cipher? Do you want to hash passwords or something else? There are multiple possible algorithms available.
It is required to use appropriate functions, and not outdated/broken functions. But maybe even more important: Every algorithm can be broken in the future. So it is very important that your product has the ability to be updatable and introduce new hash-/encryption-algorithms which replace the old ones.
30 years is a really long time for cryptography. Quantum computers might be established there already, but it is hard to predict. Most publications don't look that far in the future. The ECRYPT-RSA Recommendations from 2018 look this far though. Based on this AES-256 for symmetric encryption and SHA-512 as hash should be sufficient. But the paper also explicitly states on page 59:
Again we reiterate these are purely key size guidelines and they do not guarantee security, nor do they guarantee against attacks on the underlying mathematical primitives.
Apart from that there is more than the algorithm to deal with. The secrets used in these algorithms need to be protected too for such a long time, both against stealing but also against loss. And the protection should also match the sensitivity of the data, i.e. a teenagers diary needs likely much less protection than top secret government information.
Also, there is a difference between encrypting sensitive data now and protecting these for 30 years or doing a short term encryption of only temporary sensitive communication in 30 years. In the first case the attacker has 30 years time to break the encryption, in the latter case the data might already be useless after some weeks so breaking - which essentially limits the time the attacker is willing to spend to break the data.
Assuming a product shelf life of 30 years...
As commenters have pointed out, this is an unreasonably long expectation for the shelf life.
what is the recommendation/suggestion for hashing or encryption algorithms to use in the product? That means, should I directly make use of the superior algorithms(SHA-512 for hashing, AES-256 for encryption) or should this be driven by SAL(Security Assurance Level) or any other different factors?
Since it is very hard to predict the future, I would suggest building your system with current-day best practices. But also, if possible, include the ability to update your system/product in the future. Updating is an important part of "security agility," which lets us adjust to the unknown future. In particular, you could build your system with an eye towards being able to update encryption algorithms in the future.
Also, are there any recommendations from NIST to choose these based on the product's shelf life?
NIST SP 800-57 provides recommendations for key management.
For symmetric cryptography: use algorithms with 256-bit strength, such as SHA-512, SHA3-512, SHAKE256, KMAC256, HMAC-SHA-512, Chacha20-Poly1305, AES-256 (in various modes, preferably AEAD modes), Camellia-256 (ditto). Few people will commit to any prediction of security in 30 years, although Ecrypt does. NIST also have recommendations but they don't go as far as 2051. Using robust algorithms in their maximum strength is your best bet anyway. All of these are widely implemented algorithms.
For asymmetric cryptography: nobody knows. If quantum computers work the way we think they might work, they will completely break all the asymmetric cryptography that's in use today. (In contrast, for symmetric cryptography, the effect will be merely to halve the resistance for a given key size.) And if the physics does work, then it's reasonable to think that the technology will get there in less than 30 years. There is an effort to standardize post-quantum cryptography (PQC), but it's still at an exploratory stage, where some cryptographers propose methods and their colleagues try to break them, sometimes successfully, sometimes not. In the short term, PQC is more risky than well-established asymmetric cryptography based on factoring (RSA) or discrete logarithm (ECC).
The only way to keep a device secure for years, let alone decades, is to keep updating it. Make sure your system has cryptographic agility, i.e. the ability to change which cryptographic primitives it uses. For asymmetric cryptography, you can test agility today by supporting both finite-field methods (RSA, DH) and ECC. You can also start implementing PQC methods, but keep in mind that they're likely to evolve rapidly in the next few years. Implementing PQC methods now is a good idea, at least as testing-only features, because they have an impact on system design: they are not drop-in replacements for classic primitives. For example, many PQC signature schemes are stateful: you can't just generate a key once and keep signing an arbitrary large number of messages. PQC signatures and keys also tend to be much larger than classic ones.
The ability to upgrade is important not just for the ability to change cryptographic algorithms. It must also be possible to fix software bugs and to implement resistance to new attacks. Attacks only every get better, and attack techniques that are considered exotic today may become commonplace tomorrow. For example, fault injection attacks were for a long time only a concern on very high-security devices such as smart cards and certain military applications. Then came rowhammer, which showed that fault injection can be carried out on a PC, purely in software. In 30 years, it's likely that the attack techniques will improve a lot, and no software made today will still be secure. Be updated or be pwned.
The software assurance level is pretty much irrelevant to the choice of cryptographic mechanism. It's relevant to the choice of implementation: a higher assurance level means an implementation with better design, more extensive testing, more countermeasures for side channel and fault injection attacks, etc. It's also relevant to where cryptography is used: a higher level tends to require more redundant controls (for example, you may need to have better resistance to hardware tampering, which requires additional encryption inside the device). But even at the most basic level of assurance, cryptography pretty much starts at “unbreakable assuming a perfect implementation”.
One approach I know from a source close to me is to combine multiple algorithms. Theirs was a case of a bank wanting to keep hashes of documents for decades for integrity guarantees. To make sure integrity could be guaranteed except in a particularly broken scenario, they started with two currently unbroken algorithms, and generated hashes for each document using them both separately (algo1(document) + algo2(document)). The plan was that in case one of the algorithms were broken they could simply swap that one out for another algorithm while maintaining the guarantee of the second algorithm. This way, unless both algorithms are broken at the same time, there's always a trustworthy set of hashes.
I'm not a crypto expert, but I expect for encryption you'd nest the algorithms, encrypting with one and then the other. To swap one out you'd have to decrypt at least one layer and re-encrypt.
