Cryptography is War!

Current e-mail crypto designs are just asking for trouble.


Terry Ritter


Only a few different ciphers are used in e-mail crypto products. Some manufacturers talk of someday allowing users to select from six or eight popular ciphers. I say: "Big deal!"

If someone wants to spend time and money attacking a cipher, they are not going to bother with a cipher which protects almost no data. An attacker will select a widely-used cipher, because that has the best payoff. If you use a widely-used cipher, you have the best chance of being exposed!

E-mail systems can and should have a common interface and support arbitrary external ciphering routines. In a decade or two we might have tens of thousands of different custom ciphers, any of which might be used by the same e-mail interface. Each of these ciphers will carry only a tiny fraction of the information protected by a widely-used cipher, and so will be much less attractive and much less likely to be attacked and penetrated.


Security Problems

Messages by Ritter to the "resolving-security mailing list."

Follow the thread, and form your own opinion.


Cryptography is War!

The past has seen the standardization of a single cipher (DES) for most use. The future will see a multitude of different ciphers which users can select from and agree to use. This will improve security for everyone by reducing the amount of information under any particular cipher, thus reducing the motive and resources for anyone to attack that cipher.

Cryptographers try to build secure ciphers, and cryptanalysts try to break those designs. When an academic cryptanalyst breaks a cipher, we just use a new cipher. But when a team of private cryptanalysts break a cipher, why would they announce it? The continued use of a broken cipher is the cryptanalysts' reward, and a resource to exploit.

Cryptographers always think they use strong ciphers, but even after 50 years of mathematical cryptology, no practical cipher has been proven secure. Historically, many ciphers have been broken, sometimes after they have been in trusted use for many years. Fortunately, there is a practical alternative to proving a cipher secure: Give many different user-groups each their own custom cipher and change ciphers periodically. This reduces the value of the information under any particular cipher, which reduces the motivation (and resources) for attacking each cipher.

A system with many ciphers is not the same as a system with one cipher and a slightly larger keyspace. The difference is that any widely-used cipher may already be broken and insecure, and we would not know! Just changing the key in this situation probably will not recover secure ciphering. But in a many-cipher environment, changing the cipher probably will recover security: Direct attacks on serious ciphers are expensive, and resource limitations naturally discourage efforts which will be unprofitable even when successful. In a many-cipher environment there is less information of value under any particular cipher, so there is less reason to attack any of them. Compare this to the current situation, where virtually all information is "protected" by one of a small handful of widely-used ciphers. Widely-used ciphers make ideal targets.

It is sometimes said that a multi-cipher environment is not suitable for "widespread interoperable use," because it is necessary to have the same cipher on both ends. But it always has been necessary to have the same (or related) key(s) at both ends, and doing this is a major part of modern cryptography. Since a key-delivery process could deliver both a key and a cipher, custom ciphers are easily supported (provided we have a good cipher interface).

Having many different ciphers is an aggressive and pro-active strategy for winning the cryptography war. Our company has the knowledge, technology and experience to build a wide range of unique custom ciphers. We aggressively prosecute the cryptography war for the security of our clients and customers.


Terry Ritter, his current address, and his top page.

Last updated:1996-06-20