Why Use Our Ciphers?

Terry Ritter

A widely used cipher may ALREADY be broken.

One alternative is to use A WIDE VARIETY of new and different ciphers, each of which requires new effort to break.



Q1: What problem is addressed?
A1: The problem of storing or transporting sensitive information so that the information is not stolen or copied.

Q2: What is the product?
A2: We have several cipher programs for DOS which also operate well under Microsoft Windows. We also own proprietary technology which allows us to provide better custom designs.

Q3: How does the product solve the problem?
A3: Sensitive information is "encrypted" or "enciphered" before storage or transport. Anyone looking at the resulting file sees only jumbled data.

Q4: But what if someone steals the ciphering program?
A4: A cipher program can be considered a "lock," a user has a "key" which is used in that lock. Stealing the program is not much help unless the key is also stolen. Keys are kept secure, just like house or car keys.

Q5: For our personal use, why would we not use PGP and public keys?
A5: PGP is oriented toward technical individuals who understand the serious consequences of not authenticating a public key.
On the other hand, secret keys can be delivered through normal business channels and allocated to users like any other resource. Our secret-key products do not require a deep technical understanding of cryptography beyond the analogy to metal keys which all of us use to protect our homes and cars.

Q6: For our commercial programs, why would we not use some free design or something taken from a cryptography text?
A6: First, there are many different ciphers, and various tradeoffs between them. Next, there is normally a great deal more involved in the overall use of a cipher than just the cipher design itself. Last, while it is easy to build a toy cipher, surprisingly, most easy ciphers are breathtakingly weak. It generally takes years of study and experience to build good ciphers or even use old ones securely. It seems reasonable to hire this experience rather than trying to reproduce it.

Q7: If cipher design is so tricky, why would we consider using a non-standard cipher?
A7: First, the only real standard is the US Data Encryption Standard, which is generally slow and can be weak if used naively. Nowadays many use "Triple-DES" which is only a third as fast as DES itself. Next, there is no need to standardize on a single cipher design. Indeed, using different ciphers is less dangerous than "keeping all your eggs in a single basket," because no cipher is proven "strong."

Why Not Just Use "Proven" Ciphers?

First, there are no practical ciphers which are proven to be strong! There are ciphers which have been around for a while, and which no academic has reported breaking, but those ciphers may well have been broken by other groups who are not talking. Older ciphers may be essentially obsolete anyway, due to obvious increases in computation which attackers now have available.

Next, a particular application may provide reason to select a cipher with special characteristics. Our custom designs can be especially fast, have a particular block size, or support parallel ciphering, among other characteristics. Our component-based designs accommodate special applications; other design technologies are more limited.

Alternately, the ability to handle a wide variety of different ciphers can provide a form of probable security even though none of the ciphers is itself proven "strong." This requires a large number of serious ciphers, which is only likely using some form of component technology like ours.

Last, but not least, cryptographic design involves more than simply using a "strong" algorithm. There is more to be done, and if it is not done right, even a good algorithm can produce a weak cipher system. We support our ciphers, and offer custom design services to complete the system.

Ciphering is Not Just Another Algorithm

It is probably a mistake to think of ciphering designs as "algorithms." Programmers implement "algorithms" all the time, leading to the idea that ciphering is something which any programmer can read about and implement.

But when a programmer implements, say, a division algorithm, many years of schooling provide a good background on how to test the program in very substantial ways. When a programmer implements a cipher, normally all she can test is that it converts text into a mis-mash and then deciphers that into the original text. Even toy ciphers get those tests right.

When one implements a division algorithm, that solves the entire problem of dividing. But when one implements a ciphering "algorithm," this is only part of the job of a strong cipher. Other parts include key generation, key distribution or transport, transported key certification or validation, and a whole host of other things.

If a public key cipher is used for distributing keys over the Internet without key certification, that cipher must be considered explicitly "weak." Even if all of the "algorithms" in the design were in fact "strong," and all were implemented properly, the result would still be "known to be weak."

The simple use of "strong" algorithms does not guarantee that a cipher will not be "weak."

Cipher "algorithms" solve only part of the requirements of a real cipher system.

Old Ciphers and Bold Ciphers

There are many old ciphers, and there are many ciphers which are claimed to be "strong." But there are no practical ciphers, old or bold, which are proven "strong."

Any widely-used cipher is precisely the sort of thing which someone might wish to attack, and, having been successful, might wish everyone else to use.

Since attackers will not tell us when they are successful, the only reasonable alternative seems to be to use a wide variety of different ciphers, thus forcing each of these to be attacked separately, with far less payoff.


The U.S. Data Encryption Standard (DES) was standardized in 1977, and designed before the microprocessor revolution. It uses a small amount of storage for internal tables, which limits the amount of nonlinearity or uncertainty in the internal structure. Such tables as there are are not keyed.

While DES seems to have withstood attack, we actually do not know if this is true. If some group had found how to break DES, it would be in their interest not to reveal this, so that the group could profit from their work.

We do know that DES is relatively slow, with a fixed and awkward architecture. Moreover, the small 56-bit DES keyspace has meant that new attack technology (for example, a $1,000,000 system made from custom chips) has made DES vulnerable to the most obvious attack (brute force on the keys). DES also has a small 64-bit block size which at the very least limits the amount of information which should be sent under a single key.

Newer DES attacks, such as those intended to reveal secret information hidden in "smart cards," while too new to place in their proper context, seem absolutely devastating, and undermine our confidence in the design itself.

The known weakness of DES means that DES alone is probably not a good solution, even if its excessive computation and restrictive block cipher design are acceptable.

Triple DES

The main contender to succeed DES is Triple DES, which is just DES done three times with different keys. This supposedly increases the keyspace to about 120 bits, but the same old 64-bit block size remains.

Triple DES needs three times the computation of even DES itself, and is not guaranteed stronger than DES. In fact, the recent "smart card" attacks break Triple DES almost as easily as DES.


"IDEA" (also called PES and IPES) is a European design perhaps best known for its use the "Pretty Good Privacy" (PGP) program.

While IDEA has a large 128-bit keyspace, it still has the usual small 64-bit block size. IDEA also uses internal operations which are almost linear, and this is a little disturbing.


The Rivest-Shamir-Adleman (RSA) algorithm was the first practical public-key algorithm. While there are other public-key algorithms, none is clearly better or faster, except under particular conditions.

The RSA computations involve huge numerical values, and some fairly complex implementation. RSA is normally used simply to deliver a message key which is then used by one of the "conventional" or "secret key" ciphers. This of course means that selecting a "secret key" cipher is still an issue even in "public key" ciphers.

Because RSA computations involve huge numerical values, they require keys perhaps 10x as long as secret key ciphers. If we like 120-bit secret keys, we should be looking at public keys of at least 1200 bits.


The past few years has seen a vast expansion in the number of publicly-known cipher designs. Clearly it is not possible to address them all, but we can make a few observations about "conventional" or "secret key" designs:

Obviously, new approaches are subject to new attacks. Since we cannot prove strength, we can only continue development on how one might attack new designs. But the "alternative" of using old "proven" designs is no alternative at all, since these designs are also not proven, and there is ample motive for those who can break the cipher to mislead us that it is strong.

Faster Operation

Ciphering is an overhead to communication: The less computation required for ciphering, the more available to move data. (Normally the issue is the load on central servers, as opposed to end-user machines, but of course both ends must use the same cipher.) New technology can be both stronger and faster than ordinary DES.

High speed buys a lot:

Greater Strength

DES uses a small 56-bit key. But we can easily construct faster ciphers with far larger keys, with ciphering speed generally independent of keyspace:

Larger Blocks

DES has a 64-bit block, and new technology has made this perhaps too small. Certainly a larger block will contain more plaintext, and also more variation in plaintext; this makes the cipher stronger. We can easily construct ciphers with far larger blocks which still cipher faster than DES:

Better Architectures

DES operates on fixed-width 64-bit blocks of data. This means that:

Instead of being confined to the old architecture of DES, we can design:

Each option will provide advantages (and disadvantages) in particular applications.

Many Different Ciphers

If we are going to put all our security eggs in one basket, we had better be pretty sure of that basket. Unfortunately, with ciphers, this is something we simply cannot do: There is no practical cipher which is proven strong. So it only makes sense to place some eggs in each of several different baskets, or even to nest baskets (ciphers) within one another.

Having a wide variety of fundamentally-different ciphers means far more than just adding a few bits to the keyspace of an existing cipher: If the existing cipher is broken this will probably affect all possible keys. But if one of the new ciphers is broken, others will likely remain operational.

It is important to see the many cipher environment as more than four or five different ciphers. We should plan, in 20 years or so, to support tens of thousands of ciphers, with many different fundamental approaches. Only in this way can we force an Opponent to make massive investments for minimal payoffs. Only in this way can we enforce a form of probable security, while using ciphers which cannot be proven secure.

VLSI Orientation

DES was designed in a hardware-poor era. The internal DES operations contain only a small amount of nonlinearity, and what nonlinearity there is was fixed for all users over all time.

In contrast, modern cipher designs occur in a hardware-rich era, provided the design uses regular structures and simple interconnections. Modern ciphers can afford to use large tables which are set up by the ciphering key, and so are different for every use and every user.

The regular structures used in tables are the ideal sort of VLSI design, and present a clear contrast to the "random logic" approach of DES as well as many more-modern ciphers. Our designs are generally more VLSI-friendly than most.

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

Last updated:1996-11-26