I already mentioned the problems of cryptocurrency such as lack of alternative Internet and the use of standardized public cryptography. Let's examine the second.
Quote from the original Satoshi's paper:
What is needed is an electronic payment system based on cryptographic proof instead of trust...
Emphasis above is mine to stress the following point.
The next quote is from the web page at
www.ciphersbyritter.com/GLOSSARY.HTM#Proof
Security Proofs in Practice
While the mere existence of a math security proof may inspire
hope, it should provide no confidence.
Only the fulfilled conclusion of a proof can really give confidence,
and that is only possible when all assumptions can be
guaranteed and are in fact guaranteed.
Moreover, security proofs provide confidence only for someone who
can and does ensure that each and every assumption the proof
requires is actually met in practice.
That is hardly ever possible for users.
Although a proof may seem to offer users some confidence even
with partially fulfilled assumptions, that is logically wrong.
Unless all assumptions are completely fulfilled
and absolutely guaranteed, a proof guarantees
nothing at all!
Unfortunately, the typical proof has an all-knowing "omniscient"
form that implies a context quite unlike what users have in
reality.
Real users are limited in what they can guarantee, and so generally
can not ensure the assumptions made in such proofs,
which means the proof has given them nothing at all.
In mathematics, every assumption is equally important, but in
practice, some assumptions are more equal than others.
Whereas a user just might be able to guarantee some assumptions,
others are completely outside user control.
But assumptions which cannot be controlled or verified also cannot
be trusted, which means the "proven" conclusion cannot be trusted
either.
Such a "proof" provides no basis for confidence in practice, even
though cryptography often claims otherwise.
Academic ProofIn academic cryptography there are many "proofs" in the sense of the second definition above: the proof process, not the result. These proofs (2) make assumptions, and their results are true only if all their assumptions are true, but usually that is not proven, nor even provable. In a real sense, these proofs are best described as lemmas for the desired theorems of reality which do not (and probably cannot) exist. Note that a mathematical proof (2) is considered valid, and can be considered important, even if the assumptions in it cannot be achieved in practice.
A cryptographic proof (2) can be more difficult to understand than outsiders might think. Only rarely is there a clear statement of every assumption which the author of the proof thinks has been made. Sometimes, some of the assumptions needed in proofs are hidden (such as those implicit in the use of particular operations with which an outsider may be unfamiliar), but even hidden asumptions must be fullfilled for the proof to "work." The inability to decide whether all assumptions have been exposed and fullfilled makes proofs difficult to depend upon in practice.
Moreover, a cryptographic proof (2) may use terms of art which can be deceptive in not having the same meaning as the exact same phrase in more general cryptography. This problem of meaning carries through to the conclusion, where a language description of the results may not correspond to the long-accepted use of the exact same terms in cryptography or security.
To use a proof in actual systems, it is important to understand what it really says in the broader context of the outside world:
Are all of the assuptions known? (Can we prove that?)
Can all the assumptions be guaranteed? (Can we prove that in an implemented system?)
Are the guaranteed results really what we need?
There is no "proof" that using any particular cipher (such as DES or AES) improves security over using no cipher at all. This is because a user cannot know if the cipher is being broken by an opponent in secret. And if the cipher is being broken, using that cipher is probably worse than having no cipher at all, because users will be mislead into not taking even ordinary precautions. (The possibility of repeatedly using a broken cipher can be addressed by multiple encryption and by having and using many different ciphers.)
Unfortunately, often someone will see an academic result and say: "A cipher using this technique is proven secure." Usually, such a statement is false. When we say "secure" we are talking about a final result, not a process which may or may not end in that result. No cipher is proven secure in practice, and only a very few (generally inefficient) ciphers are proven to depend upon some fairly well examined math problem which has not been solved.
Sometimes the situation is even worse: Sometimes, a ciphering technique will be said to be secure, provided the underlying cipher is secure. But since we cannot know whether the underlying cipher really is secure, the argument seems to be a form of circular reasoning: We cannot tell whether the enabling assumption is true until we know the outcome, and, in cryptography, we generally cannot expect to know the outcome. And if we somehow do know the outcome, we do not need the proof! Such a proof adds nothing at all to practical security.
Mathematical proofs may change and develop over time; see: Method of Proof and Refutations. Also see the Triple-DES is Proven to be Very Secure? discussion (locally, or @:
http://www.ciphersbyritter.com/NEWS5/PROVSEC.HTM) and my IEEE Computer article "Cryptography: Is Staying with the Herd Really Best?" (Copyright 1999, IEEE) (locally, or @:
http://www.ciphersbyritter.com/ARTS/R8INTW1.PDF). Also see the short article by: Devlin, K. 2003. "2003: Mathematicians Face Uncertainty." Discover. 25(1): 36. January, 2004.