29

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?

5
  • 1
    keylength.com/en/compare note that this doesn't include a possible Cryptographic Quantum Computer (CQC). Your question is not clear since the details of your program are not known; how do you generate the encryption keys, how do you store them are not mentioned.... There is no real answer to your question other than just saying that any good symmetric cipher with a 256-bit key and a good cryptographic hash function like SHA-512 and Shake are secure against CQC and high probably will be secure in 30 years. Devil in details and the details are missing.
    – kelalaka
    Dec 8 '21 at 18:46
  • 1
    For such long time spans you should consider e.g. for signatures and hashing to use two totally different algorithms in parallel (like SHA-512 and SHA-3). So that if one algorithm is broken you still have one left.
    – Robert
    Dec 8 '21 at 19:42
  • 1
    What else would you use, anyway (besides some configuration in keysize)
    – eckes
    Dec 9 '21 at 9:58
  • 5
    When you buy a car, a really good one even, you still do not expect it to 'just work' for 10 years straight. It will have maintenance requirements due to unexpected and expected yet unforeseeable incidents. In other words, car maintenance is not a product that you buy together with the car, but a continuous process during its use, just like putting gas in it.
    – mafu
    Dec 9 '21 at 13:31
  • 13
    A lot of people have pointed out that 30 years is a very long time, but maybe you can appreciate just how long this is when you think about the following: 30 years ago, AES did not exist, SHA-3 did not exist, SHA-2 did not exist, SHA-1 did not exist, SHA did not exist, MD5 was still in the process of being designed, MD4 barely existed, even MD2 was almost brand-new, DSA had just been published and not standardized yet, SSL did not exist, SSH did not exist, PGP had just been released, the very first tiny piece of Linux source code had just been published. Dec 10 '21 at 20:52
23

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.

7
20

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.

6
  • 12
    The teenagers of today might be the top government in 30 years :-)
    – Bergi
    Dec 9 '21 at 0:03
  • 3
    Quantum computers cannot break AES-256, actually, any secure block cipher with key size 256 is secure against them. Indeed even for 128-bit key size, it is not clear how one can run Grover machine 2^64-times. There is no need for the recommendation here. They are secure!. Even NIST listed this in Post-Quantum project as the security level. Similar applies to the hash functions, too.
    – kelalaka
    Dec 9 '21 at 0:41
  • 1
    @kelalaka: Not break but weaken. That's why a doubling of the key size for symmetric encryption is recommended - you already mention Grover's algorithm. Apart from that, all of this applies only to what we know today. 30 years are not a small time for cryptography. Note that the relevant cryptography we have today is based only on the believe that the algorithms are computationally sufficiently secure, but not on an actual mathematical proof. Dec 9 '21 at 5:53
  • @SteffenUllrich may weaken in the classical sense, not in Grover's way. We know that is asymptotically optimal. AES withstand 20 years of attacks and even the Bitcoin Miners need 35 years to brute force a single AES-128. The biggest concern is the multi-target attacks whenever applicable. We already know that brute-forcing AES-256 is physically impossible. AES-256 is now the gold standard in the industry.
    – kelalaka
    Dec 9 '21 at 11:04
  • @kelalaka : The real trick with quantum computers is we don't know if they don't enable some sort of non-brute force break that is infeasible to execute classically but becomes very tractable on a quantum computer. Of course that's probably hard to discover just like tractable classical breaks - but still, it "increases the room", so to speak, for a discovery. Dec 9 '21 at 23:13
9

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.

5

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”.

0

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.

3
  • Note that the combination of two algorithms, if not designed carefully, may sometimes be only as strong as the weaker algorithm. For example -- with both the hashing scheme that you describe and the encryption scheme that you describe, you'd want to make sure to use separate, unrelated keys, so that if an attack is developed that exposes the key of one, that doesn't automatically neutralize the other. And I'm guessing that you'd also want to minimize other common factors between the two implementations, so as to reduce the risk that a single side-channel attack compromises both.
    – ruakh
    Dec 10 '21 at 8:16
  • 1
    @ruakh - Yes, that is true. But you could calculate + store both hashes separately and accept it only if both hashes match. Then you're relying on both hashes and if one got broken, the other one is still robust.
    – Matt
    Dec 10 '21 at 9:30
  • @Matt: Right, sorry -- somehow I was thinking of HMACs stored with the document, with the implicit threat model being "hashing scheme has weakness that allows attacker to sign arbitrary documents", rather than just plain hashes stored separately (and somehow known to be trusted), with the implicit threat model being "hashing scheme has weakness that allows attacker to generate documents with arbitrary hash".
    – ruakh
    Dec 10 '21 at 18:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.