It took more than a decade from when MD5 looked like it was going to break to the point when it was actually broken. That's more than a decade of warning. One might suspect that we were fortunate that we got all that time. Even so, it took a long time for the world to move away from MD5.
How can we be sure that when our cryptosystems are flawed, that we'll have enough warning time to change them?
How can we be sure that, say, ECC won't get broken overnight?
We don't.${}{}{}{}{}{}{}{}{}{}$
Moderator note: This answer exists for historical significance, but it does not meet the guidelines for answering questions, so please do not use it as evidence that you can post similar answers here. This answer and its comments are frozen and cannot be changed. More info: meta.
We don't ever know, in the information theory sense, that a crypto algorithm won't fail suddenly. If we ever knew that, we'd quit using it. However, it has been shown that when a crypto algorithm fails, it has a strong tendency to fail according to a two-step process:
The latter is a perfect case for quoting "past performance does not predict future results." There is no guarantee that any future algorithm won't break at any unknown point in time. As a hedge against this, most modern crypto algorithms are designed in multiple rounds using one of the well known structures like a Feistel network. We generally understand how to make Feistel networks which fail gracefully, and those which do not have well-understood mechanics are often regarded with suspicion for many, many years. As a result, there is a tendency (not a guarantee) for measuring weakness in bits to be a reasonable indicator.
Perhaps a better question would be "how bad is it if your current crypto algorithm fails overnight?" If you can put a dollar figure to that, you can at least try to apply Bayesian statistics to put in place rational safeguards against this possibility.
yyyyyyy's answer is the correct short version.
There is only a single cryptographic algorithm that is mathematically proven secure: the one-time pad. It's hardly ever used because it's impractical: the key size is as large as the data to protect. You can prove that any algorithm that is secure against an adversary with infinite computational power is essentially equivalent to a one-time pad, and thus impractical in most situations.
Every practical cryptographic algorithm requires an assumption that some mathematical function cannot be computed in practice (because, for sizes used in practice, the best-known method require billions of computers to work for billions of years, or maybe even require more energy than exists in the universe). We believe that these functions cannot be computed faster because lots of very smart people have spent years of their lives trying in vain. It is, mathematically speaking, possible that someone will find a vastly faster method one day. We consider it unlikely because so many people have failed, but it cannot be ruled out.
A gradual break is more likely than a sudden break because scientific progress tends to make small increments at a time. Scientists are dwarves standing on the shoulder of giants (as Newton famously wrote, as did others before and after him). The popular image of a scientist suddenly becoming enlightened and coming up instantly with a novel, practical idea hardly ever happens. It takes time, and often multiple people, for ideas to mature. Before an actual cryptographic primitive is broken, it's extremely unlikely that there won't be warning signs, such as theoretical advances in a related topic, slight improvements in our understanding of the mathematical structure of the primitive that lead to small but still impractical reduction of computation requirements to break it, etc.
All of this applies to algorithms that have been vetted by the world's top cryptographers. An algorithm proposed by a person or a small team working on their own may well be thoroughly broken because someone else thought of something they didn't. When you involve a significant number of experts, the risk of “nobody thought of this” dwindles.
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.
5. Nothing up my sleeves. Most cryptographic systems require some form of constants. It is always a risk that the constants chosen were chosen because they reduce the effectiveness of the system in a way known to the author but not others. 'Random' constants are a red flag because random values are unprovable. If an algorithm uses e971c59327cabde08439c813b70dae1a as a constant and the author says don't work it was generated on a CSPRNG you should be alarmed. How can you verify that e971c59327cabde08439c813b70dae1a was the result of a random roll and not deliberately chosen because it weakens the algorithm. Nothing up my sleeve numbers are usually used as a way to introduce pseudorandom constants. For example using the first 32 bits of the fractional part of the square root of the first n prime numbers. There is a low risk that such numbers could be chosen and also satisfy the conditions that would weaken the algorithm.
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.
