|This article needs additional citations for verification. (December 2007)|
Demonstrating the resistance of any cryptographic scheme to attack is a complex matter, requiring extensive testing and reviews, preferably in a public forum. Good algorithms and protocols are required, and good system design and implementation is needed as well. For instance, the operating system on which the crypto software runs should be as carefully secured as possible. Users may handle passwords insecurely, or trust 'service' personnel overtly much, or simply misuse the software. (See social engineering.) "Strong' thus is an imprecise term and may not apply in particular situations.
Cryptographically strong algorithms
This term cryptographically strong is often used to describe an encryption algorithm, and implies, in comparison to some other algorithm (which is thus cryptographically weak), greater resistance to attack. But it can also be used to describe hashing and unique identifier and filename creation algorithms. See for example the description of the Microsoft .NET runtime library function Path.GetRandomFileName. In this usage, the term means difficult to guess.
An encryption algorithm is intended to be unbreakable (in which case it is as strong as it can ever be), but might be breakable (in which case it is as weak as it can ever be) so there is not, in principle, a continuum of strength as the idiom would seem to imply: Algorithm A is stronger than Algorithm B which is stronger than Algorithm C, and so on. The situation is made more complex, and less subsumable into a single strength metric, by the fact that there are many types of cryptanalytic attack and that any given algorithm is likely to force the attacker to do more work to break it when using one attack than another.
The usual sense in which this term is (loosely) used, is in reference to a particular attack, brute force key search — especially in explanations for newcomers to the field. Indeed, with this attack (always assuming keys to have been randomly chosen), there is a continuum of resistance depending on the length of the key used. But even so there are two major problems: many algorithms allow use of different length keys at different times, and any algorithm can forgo use of the full key length possible. Thus, Blowfish and RC5 are block cipher algorithms whose design specifically allowed for several key lengths, and who cannot therefore be said to have any particular strength with respect to brute force key search. Furthermore, US export regulations restrict key length for exportable crypto products and in several cases in the 1980s and 1990s (e.g., famously in the case of Lotus Notes' export approval) only partial keys were used, decreasing 'strength' against brute force attack for those (export) versions. More or less the same thing happened outside the US as well, as for example in the case of more than one of the crypto algorithms in the GSM cellular telephone standard.
The term is commonly used to convey that some algorithm is suitable for some task in cryptography or information security, but also resists cryptanalysis and has no, or fewer, security weaknesses. Tasks are varied, and might include:
Cryptographically strong would seem to mean that the described method has some kind of maturity, perhaps even approved for use against different kinds of systematic attacks in theory and/or practice. Indeed, that the method may resist those attacks long enough to protect the information carried (and what stands behind the information) for a useful length of time. But due to the complexity and subtlety of the field, neither is almost ever the case. Since such assurances are not actually available in real practice, sleight of hand in language which implies that they are will generally be misleading.
There will always be uncertainty as advances (e.g., in cryptanalytic theory or merely affordable computer capacity) may reduce the effort needed to successfully use some attack method against an algorithm.
In addition, actual use of cryptographic algorithms requires their encapsulation in a cryptosystem, and doing so often introduces vulnerabilities which are not due to faults in an algorithm. For example, essentially all algorithms require random choice of keys, and any cryptosystem which does not provide such keys will be subject to attack regardless of any attack resistant qualities of the encryption algorithm(s) used.
Since use of strong cryptography makes the job of intelligence agencies more difficult, many countries have enacted law or regulation restricting or simply banning the non-official use of strong crypto. For instance, the United States has defined cryptographic products as munitions since World War II and has prohibited export of cryptography beyond a certain 'strength' (measured in part by key size), and Russia banned its use by private individuals in 1995. It is not clear if the Russian ban is still in effect. France had quite strict regulations in this field, but has relaxed them in recent years.
- PGP is generally considered an example of strong cryptography, with versions running under most popular operating systems and on various hardware platforms. The open source standard for PGP operations is OpenPGP, and GnuPG is an implementation of that standard from the FSF.
- The AES algorithm is considered strong after being selected in a lengthy selection process that was open and involved numerous tests.
Examples that are not considered cryptographically strong include:
- The DES, whose 56-bit keys allow attacks via exhaustive search.
- Wired Equivalent Privacy which is subject to a number of attacks due to flaws in its design.
- The Clipper Chip, a failed initiative of the U.S. government that included key escrow provisions, allowing the government to gain access to the keys.
- Almost all classical ciphers.
The SSL protocol, used to secure Internet transactions, is generally considered strong, but an early "international" version, with a 40-bit effective key to allow export under pre-1996 U.S. regulations, was not.
- Path.GetRandomFileName Method (System.IO), Microsoft
- Farber, Dave (1995-04-06). "A ban on cryptography in Russia (fwd) [Next .. djf]". Retrieved 2011-02-14.