Return to Answer

The simple answer is nobody can prove that an algorithm won't break in a given period of time. The achievable goal is increase the probability that no effective attack will be developed without warning. There are a couple of characteristics which increase the probability that a particular cipher will remain secure and if degraded will do so 'gracefully'.

1. Time. Time is the major test of an algorithm's strength. The fact that researchers all around the world have had a decade to break SHA-2 and so far failed is a good sign. It doesn't mean that SHA-2 won't be broken tomorrow but the risk of that is lower today than when the algorithm was new and untested. For that reason I have more confidence of the security of SHA-2 relative to SHA-3. Sometimes older is better.

2. Widespread usage. Time gives experts the opportunity to attack an algorithm but it doesn't mean much if nobody has broken xyz algorithm for a decade if nobody has tried to break xyz algorithm for a decade. A break on a major algorithm (SHA-2, AES, ECC) is a big deal and will attract more attention that some algorithm your brother cooked up so this a reason to not roll your own.

3. Bit strength. 128 bit security (2^128 operations) is for all practical purposes beyond brute force both today and for a long time in the future. So why are there algorithms with higher bit strength if 128 bit is 'unbreakable'? It is an insurance policy. Many attacks reduce the complexity of an attack. So instead of 2^128 operations to find a collision it might 'only' take 2^90 or 2^84. Those are larger numbers but it is feasible given enough time, money, and improved efficiency (Moore's law). On the other hand a break which reduces the complexity for a collision from 2^256 operations to even 2^160 is not usable. One should migrate away from the algorithm because there would be an increased risk that more sophisticated attacks would reduce that further but it would not present an 0-day risk.

4. An open transparent cryptographic algorithm/system It should go without saying that you shouldn't be trusting your secrets to closed source systems which can't be independently verified but this happens more often than you might imagine. Whole drive hard drive encryption for example is notorious for being a 'magical black box'. Optimally you should be able to independently verify how the hash or cipher text is being produced. Cryptographic algorithms are deterministic. So if a device or software claims to be using AES-256 then given the same inputs (cleartext, key, IV) it should produce the same output as another AES-256 implementation.

There are 'provably secure' hashing algorithms. Most hashing algorithms use rounds of mix, rotate, and reduce functions. The 'problem' is there is no way to prove that there is no faster way to find a collision than a brute force search for example. Provably secure hashing algorithms are based on mathematical proofs of known hard problems (like integer factorization). The 'provable' comes from the fact that it can be shown in a mathematical proof that a collision (or some other attack) will require a given number of operations in worst case scenario as long as no faster solution for the underlying mathematical problem is known. If that assumption turns out to be false so does the stated security but it does provide a stronger theoretical foundation as many of these mathematical problems are well understood.

The problem with provably secure hashing algorithms is they generally tend to take longer and require more resources for a given level of security when compared to traditional hashing algorithms. SWIFFT is an example of a provably secure hashing algorithm. It is not suitable for all circumstances so this isn't an endorsement of that algorithm for any particular usage.

The simple answer is nobody can prove that an algorithm won't break in a given period of time. The achievable goal is to increase the probability that no effective attack will be developed without warning. There are a couple of characteristics that indicate a particular cipher may remain secure and if degraded will do so 'gracefully'.

1. Time. Time is the major test of an algorithm's strength. The fact that researchers all around the world have had a decade to break SHA-2 and so far failed is a good sign. It doesn't mean that SHA-2 won't be broken tomorrow but the risk is significantly reduced compared to when SHA-2 was brand new. For that reason I have more confidence in the security of SHA-2 relative to SHA-3 over the short to medium term. Sometimes older is better.

2. Widespread usage. Time gives experts the opportunity to attack an algorithm but it doesn't mean much that nobody has broken xyz algorithm for a decade if nobody has tried to break xyz algorithm for a decade. A break on a major algorithm (SHA-2, AES, ECC) is a big deal and will attract more attention that some algorithm your brother cooked up. Correspondingly a large amount of the cryptanalysis occurs on the common high usage algorithms. This is one reason why rolling your own crypto is dangerous. The only way to have any confidence that it is secure is to have a large number of credible experts try to break it over a long period of time. That simply will not happen with an obscure algorithm.

3. Bit strength. 128 bit security (2^128 operations) is for all practical purposes beyond brute force both today and for the conceivable future. So why are there algorithms with higher bit strength if 128 bit is already 'unbreakable'? It is an insurance policy. Many attacks reduce the complexity of an attack. So instead of 2^128 operations to find a collision it might 'only' take 2^90 or 2^84. Those are larger numbers but it is feasible given enough time, money, and improved efficiency (Moore's law). On the other hand a break which reduces the complexity for a collision from 2^256 operations to even 2^160 is not usable. One should migrate away from the algorithm because there would be an increased risk that more sophisticated attacks would reduce that further but it would not present an 0-day risk. This is not an absolute guarantee. The break may be so severe that it cripples even a higher bit strength implementation but combined with the other principles that should be astonishingly unlikely.

4. An open transparent cryptographic algorithm/system It should go without saying that you should not trust your secrets to closed source systems which can't be independently verified, but this happens more often than you might imagine. Whole drive hard drive encryption for example is notorious for being a 'magical black box'. Optimally you would want to independently verify how the hash or cipher text is being produced. Cryptographic algorithms are deterministic, so if a device or software claims to be using AES-256 then given the same inputs (cleartext, key, IV) it should produce the same output as another known AES-256 implementation. If it doesn't then one of them is not implementing AES-256.

Combined these factors greatly reduce the possibility that an algorithm will break without warning however we can't prove that a cryptographic system is secure today or will remain secure tomorrow.

There are 'provably secure' hashing algorithms. Most hashing algorithms use rounds of mix, rotate, and reduce functions and they are assumed there is no faster algorithm to 'break' them than brute force but the problem is that for all these algorithms there is no way to prove that no faster algorithm exists to find a collision. Provably secure hashing algorithms are based on mathematical proofs of known hard problems (like integer factorization). The 'provable' comes from the fact that it can be shown in a mathematical proof that a collision (or some other attack) will require a given number of operations in worst case scenario as long as no faster solution for the underlying mathematical problem is known. If that assumption turns out to be false so does the stated security but it does provide a stronger theoretical foundation as many of these mathematical problems are well understood.

The problem with provably secure hashing algorithms is they generally tend to take longer and require more resources for a given level of security when compared to traditional hashing algorithms. SWIFFT is an example of a provably secure hashing algorithm. It is not suitable for all circumstances so this isn't an endorsement of that algorithm for any particular usage. Given the lack of widespread usage it would violate at least one of the factors outlined above so I include it more for completeness.

The simple answer is nobody can prove that an algorithm won't break in a given period of time.

So the goal is to increase the probability that there will not be an effective attack on the algorithm in a given period of time. There are a couple of characteristics which increase the probability that a particular cipher will remain secure and will degrade 'gracefully'.

The simple answer is nobody can prove that an algorithm won't break in a given period of time. The achievable goal is increase the probability that no effective attack will be developed without warning. There are a couple of characteristics which increase the probability that a particular cipher will remain secure and if degraded will do so 'gracefully'.

There are 'provably secure' hashing algorithms. Unlike most hashing algorithms which are based on mix and reduce functions, these algorithms are based on mathematical proofs of known hard problems (like integer factorization). Despite the name they are not absolute proofs. The 'provable' means that that it can be proven there is no faster solution possible as long as the underlying mathematical problem is not solvable in polynomial time. If that assumption turns out to be false so does the stated security but it does provide a stronger theoretical foundation as many of these mathematical problems are well understood.

The problem with provably secure hashing algorithms is they generally tend to be much less efficient than 'classical' cryptographic hashing algorithms.

 SWIFFT is an example of a provably secure hashing algorithm. Please understand the limitations and differences in provably secure hashing algorithms. Using SHA-2 as a pseudorandom function would be fine but using SWIFFT would be a very bad idea.

There are 'provably secure' hashing algorithms. Most hashing algorithms use rounds of mix, rotate, and reduce functions. The 'problem' is there is no way to prove that there is no faster way to find a collision than a brute force search for example. Provably secure hashing algorithms are based on mathematical proofs of known hard problems (like integer factorization). The 'provable' comes from the fact that it can be shown in a mathematical proof that a collision (or some other attack) will require a given number of operations in worst case scenario as long as no faster solution for the underlying mathematical problem is known. If that assumption turns out to be false so does the stated security but it does provide a stronger theoretical foundation as many of these mathematical problems are well understood.

The problem with provably secure hashing algorithms is they generally tend to take longer and require more resources for a given level of security when compared to traditional hashing algorithms.  SWIFFT is an example of a provably secure hashing algorithm. It is not suitable for all circumstances so this isn't an endorsement of that algorithm for any particular usage.