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."
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.
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.
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.
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.
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:
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:
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:
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.
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.
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.