PUBLISHED: Ritter, T. 1992. Voice and Video Cryptography in a DSP Environment. Presented at, and published in, The Proceedings of The Second Annual Texas Instruments TMS320 Educators Conference, August 5-7 1992, in Houston, Texas.
ABSTRACT: A quick introduction to cryptography leading up to various DSP product possibilities.
Are your customers concerned about information security? If not, they probably should be. Eavesdropping on phone extensions certainly seems common in the movies. Kids with scanners really do listen in on cellular phone conversations for fun; others may have their own reasons. Some wire tapping may occur which is completely outside that authorized by the courts. And there are times in which even honest individuals would like to communicate in absolute privacy.
Cryptography is the art of using a secret to confuse a message so that it may be communicated without being understood except by those who know the secret. We call that secret the "key," because it can be used to "lock" and "unlock" messages. Using cryptography is much like sealing the envelope of a first-class letter, except that nobody can open a cryptographic letter in transit.
Non-enciphered information is called "plaintext" until it is enciphered, then we have "ciphertext." We assume the potential existence of an "opponent" who may someday try to recover the information in our ciphertext by "cryptanalysis," or "cracking" the cipher. We will assume that the opponent will know everything about our equipment except the secret keys; the opponent may even know some of the plaintext we send, and may use this to try and identify our key for later use. "Strong" ciphers can remain "secure" or unbroken despite serious and well-financed technical "attacks." But it is not always necessary to "break" a cipher to penetrate security.
Because the government has traditionally controlled cryptographic technology (especially since WWII), there is currently an argument about whether the public availability of cryptographic equipment will upset the balance between "cops" and "robbers." To the extent that the cops depend upon wiretaps for information, there may be something to this. But cryptography does not obscure income without a source, does not hide the shipment or sale of illegal goods, and has no effect on victims, witnesses, or spies. In fact, about the most cryptography can do is to return things to the way they were when the Constitution was written, when there were no wires to tap, and no radio technology on which to hear private conversations.
The few former officials who comment about government policy on cryptography sometimes say that even minimal ciphers will ensure personal privacy, so that serious cryptography would be overkill for ordinary citizens. But then the question arises: Privacy from whom? If one wishes to keep a secret from the guy down the hall, that is one thing. But keeping a secret from a serious detective agency or a motivated computer "cracker" is quite another. The simple facts are that there are many people who could break simple ciphers, they have lots of equipment to help them, and occasionally these people may be given reason to act.
Some texts claim that the way to tell whether one needs cryptography is to look to what one has to protect, and how much that protection is worth. But modern cryptography need not be expensive, so discussion of worth is really beside the point. Soon, every digital phone, every modem, and every fax machine will have scant reason not to be able to seal the envelope of communication.
Ciphers used by ordinary individuals should be designed to be uncrackable, even with world-class computing resources, because any other solution is just unworkable. If we manage to define a cipher that only the government can crack (only under court order, of course), then, five or ten years later, many governments, corporations, and perhaps even serious criminal enterprises will be able to do the same thing. And if we give all our keys to the government, we can be sure that some of those keys will end up where they are not supposed to be.
Modern cryptography is a computer-based technology, and every kid with a computer and a cipher program can participate. This means that cryptography is already beyond being a National Security issue: Certainly any country has (or could have) many secure cipher designs to choose from. Indeed, some of the best public work in cryptography is coming into the U.S. from Europe, Israel and China, so the science of cryptography is hardly ours to conceal.
Criminals with technical talent (or the resources to buy such talent) can make and use serious cryptography whenever they think it worthwhile. This means that cryptography is beyond being a Crime Fighting issue too, except for unsophisticated crooks. But it is a fearful cost to prevent the use of cryptography by business and private individuals simply on the hope of someday wire-tapping small-time criminal organizations. It would make more sense for law enforcement to encourage the public use of cryptography to address crimes of information theft.
Like most technologies, cryptography may be used for good or evil, but it will be used. I suggest that its best use is in the constitutional protection of privacy and free speech by and for the individual.
Cryptography is only one part of information security, and the creation and management of a secure information environment can be extremely difficult. If users save paper copies of sensitive information, then "acquiring" such a copy would be far easier than any direct technical attack on a cipher. Employees in such an environment can be at risk of temptation, compromise or intimidation. The environment itself could be penetrated by guile or surreptitious entry. And the trash could be examined for documents which were not properly burned or shredded.
If users put sensitive plaintext on disk, such disks also must be kept in a secure area. Since it is not easy to know whether a disk holds secure information, disks cannot be allowed to flow in and out. Portable computers probably should not be allowed in a secure area unless they remain closed or use a comprehensive cryptographic system. Since CRT displays can radiate video information for a block or so, secure machines will use LCD or other low-RF-emission displays.
If a cryptographic key has been compromised, we want to know this so that we can have the keys changed. But usually we will not know when a key is lost, so, to limit damage, we will have to change keys periodically, whether we like it or not. And if someone can "acquire" sensitive information without penetrating the cipher, that information can be used in an effort to get the cipher changed to something less effective. Thus, constant attempts to be aware of any disclosure, and to identify the exact avenue of such disclosure, are yet other security management issues (as well as the basis for a lot of spy intrigue).
Fortunately, personal voice communications are another matter. Unless conversations are recorded and then held insecurely, they are transient, and only exist as "plaintext" while they are occurring. This means that locations for secure conversations need only be transiently secure; we might take a walk around the neighborhood, for example. Of course, we still may worry about electronic "bugs" in offices and rooms. And if someone lets a secret slip after a conversation, well, that is part of security too. But it is not something that cryptography can do anything about.
Talking about the "best" cipher design is something like talking about the "best" computer design. There are many different approaches, and also valid reasons why technically superior designs may not be better.
Because the same cipher must be present at both ends of a conversation, cryptography seems to demand standards. Currently, there are few good standards, possibly due to government opposition. But it is less necessary to have a standard if you have one of the first products available in the right price range.
There are few absolute assurances in cipher design; cryptography may be a product which cannot be guaranteed. During WWII, many apparently "strong" ciphers were broken by direct technical attack. Modern computer ciphers can be far, far more complex than WWII ciphers, but there still are no guarantees. In most cases, it will be impossible to prove that a particular cipher design cannot be broken, or even to guarantee some minimum amount of effort will be required to break it. While we can try to predict the work needed to crack a cipher under the best known attack, we cannot reason about attacks which we do not know. In any case, it is not necessary to "break" a cipher in order to penetrate security.
In analyzing the "strength" of a cryptographic system, we generally must assume that the opponent will know everything about the equipment except the key. Moreover, even if the opponent knows the plaintext of a message, we still expect the design to hide the key. These requirements can be surprisingly difficult to meet.
Perhaps the most awkward aspect of cryptography is the need for keys. In a classic single key cipher, users must have the same key on both ends, cannot communicate keys "in the clear," and each end must hold their key in absolute secrecy. In effect, the secrecy of the entire system rests on the secrecy of the "key," and that key exists in two locations. A momentary lapse in either place could compromise all future communications under that key without breaking the cipher.
In a secret key design, it can be difficult to distribute keys to distant locations. And secure distribution can be effectively impossible within a short time frame, such as when the current key has been exposed and so must be changed right now. But when secret key distribution can be made to work, a personally-delivered key carries an inherent validity which is hard to deny.
A newer approach, still under U.S. patent, is called "public key" technology. Many people eventually find this name confusing, because this scheme, too, relies upon secrecy. Public key is a two- key technology, in which only one of the keys is public; the other (associated) key still must be held in absolute secrecy. One of the key values can be used to encipher a message, but it will take the associated keyşa different valueşto decipher the message. Thus, we can afford to send the "public" key "in the clear," and we only need to protect one location.
Some public key techniques also provide the capability to use a secret key to "sign" a message which anyone who has the associated public key can verify. Thus, various sorts of "certificates" can be issued, including testaments to the validity of particular public key values. Unfortunately, this method of key distribution can imply the creation and maintenance of a bureaucracy of "trusted certification authorities."
If we have a direct end-to-end phone connection, public key technology is great. In such a context, there should be no possibility that anybody could be "in the middle" to delete "key change" messages, re-write the key mentioned in such messages, or convince each end to use a new key. With a valid end-to-end connection, if the far end changes their keys, they just give you their public key "in the clear," and go on.
Unfortunately, it is not always possible to assure that we are not communicating through some high-performance "middleman." In this context, we might seek to use the public key validation feature to certify a new key, but this depends upon having a good key pair in the other direction. This is not possible when we start out, nor if both ends have changed their keys before the current contact. Especially in the context of a store-and-forward computer communications network, many tricks are possible, even with public keys. By pretending to be someone else, a middleman process might be able to convert both ends to known keys and thus penetrate security even though the cipher itself remains technically unbroken.
Public key techniques generally make use of multiplication, exponentiation and division on very large numbers (250 or more decimal digits). Consequently, public key techniques are relatively slow, and they are generally used simply to transfer a secret key. That secret key is then used in a conventional one-key cipher for actually communicating data. Obviously, two-key techniques have not made one-key designs obsolete.
A classic distinction between ciphers is whether they encipher symbols one-by-one, or require some accumulation before enciphering. Accumulating symbols in blocks will imply delay, unless the data are inherently produced in the correct-size blocks. In contrast, stream ciphers encipher each symbol separately, implying a minimum of delay in the cipher process.
Some researchers insist that the defining difference between block and stream ciphers should be that block ciphers always encipher a particular block in a particular way, while stream ciphers encipher subsequent elements differently. Unfortunately, this definition makes Simple Substitution on 8-bit characters a "block" cipher, while my Dynamic Transposition cipher on 4096-bit blocks becomes a "stream" cipher. Other authors distinguish between block and stream ciphers on the basis of whether a ciphertext error is "expanded" by deciphering. But modern variations can be expanding, limited-expanding, or non-expanding in either stream or block formats. Such confusion seems to be the natural consequence of folding new concepts into old definitions.
Another distinction between designs is that ciphers may need to work in an imperfect environment. Errors in the transmitted ciphertext will naturally produce errors in the deciphered plaintext, but in many ciphers, a single transmission error will cause many plaintext errors; this is "error expansion." In voice communication, error expansion can have the effect of moving the connection quality from "passable" to "unintelligible." A partial defense would be to add forward error correction to the ciphertext bit stream. Of course, computer communications which are not time- sensitive can always be made essentially error-free by using automatic error-detection and re-transmission schemes.
Ciphers which do not cause error expansion have their own problems. Typically these create an internal bit-stream (or "running key") which must be kept synchronized to a similar stream at the far end. Transmission errors may be non-expanded if sync is maintained, but if sync is lost, this will have to be detected, and some higher-level process will have to recover it. This could imply a periodic transmission of cipher sync information, or a real-time negotiated re-initialization, and these needs may be more of an imposition than simply dealing with error expansion.
In the case of voice ciphers (generally called "scramblers"), one obvious distinction is between analog and digital cipher technology. It turns out that secure analog scrambling is surprisingly difficult. First, it is necessary to maintain a similar frequency range and energy distribution to allow the ciphertext to be transported over voice channels. Next, the human ear and brain is amazingly adept at hearing words in recorded scrambled conversation, despite extensive processing in both the frequency and time domains. Consequently, good scramblers are usually digital.
Because good voice cryptography works on a digital data stream, it depends upon a good vocoder design and a good modem design. A cipher also places requirements on, and is affected by, the signalling format or "data frame" used for communication, so the system design is not quite as simple as just connecting boxes together. In DSP, the modem, vocoder, and cipher will all be functioning in real time, and this will place serious requirements on the DSP implementation itself.
Special requirements for telephone cryptography require operation in an environment of satellite communication delays, and possibly even conference calls. While it is easy to make a system which will decipher a single communication in several different places, it is more difficult to allow different parties to exchange "cipher origination" status in real time while maintaining security. Such conversations may be essentially half-duplex, although this would be automatic.
When we need digital processing of analog signals we naturally turn to DSP. DSP products with cipher technology might include:
A crypto voice instrument could be constructed which would generate new key-pairs for its users, who could change keys at any time. After assuring that the other party really is who they are supposed to be, the user could direct a public key to be sent to, or accepted from, the far end. The associated private keys would be stored internally, and never displayed, transmitted or otherwise revealed. Since nobody could read such a key and take it away for use (or sale), primary security would reduce to restricting access to the instrument itself. This would seem to be a very useful and flexible approach, both for home and business use. High security might imply guarded sign-in access to exactly the same sort of instrument. New security requirements might imply new keys and increased attention to physical security, but would require no new equipment.
More advanced designs could automatically negotiate public key transfer (but only if just one direction needed a new key). They also might recognize multiple encryption standards (provided each standard was designed to be recognized). In effect, the secure phone might operate almost exactly like a normal phone most of the time, thus requiring a minimum of training for proper use. Similar comments could be made about secure data modems and secure fax machines.
New voice network services can have a major effect on cryptographic ease-of-use and security. For example, if we have the ability to identify the number of a caller, we can use this to automatically identify a corresponding crypto key (if any). Thus, once the system is set up, there need be no frantic moments of remembering the correct key, or consulting key diaries (which must then be held in absolute secrecy). In fact, we need not even re- negotiate keys until we need new ones, and so we minimize the possibility that a hidden "middleman" process could deceive us.
One feature frequently needed by serious ciphers is the ability to produce "really" random numbers. Now, various sorts of Random Number Generator (RNG) designs are used in many ciphers, but here we refer to "really" random numbers. No deterministic machine can produce "really" random numbers, so no program or algorithm can be much help. What we need is some sort of on-chip physically- random source, such as amplified diode noise, dark-current capacitor leakage, etc. Some designs have tried to use multiple deliberately- drifting asynchronous oscillators only to find that the results were not really very random after all.
"Really" random numbers are important, because they are easy to protect in a very strong way. We can send "really" random numbers as short "messages." Since any such "message" is valid, a particular message extends no statistical lever for use in breaking the cipher. This means that we can easily send a random value to the far end using our fixed key, and then use the deciphered message -- a completely random value -- as the key for the actual conversation. These values are known as "message keys," and they prevent us from using the same key over and over, except on "really" random values which do not support analysis.
In the past, good cryptography has been expensive, hard to get and difficult to use. In the future, cryptography will be mostly cheap, widely available and automatic. We have a choice: We can sit back and let the rest of the world develop this market, or we can work at developing it ourselves, by setting standards and providing high quality products at reasonable prices. We can do this now in our own country, while encouraging Congress to allow our equipment to be exported as soon as possible.
The classic historical introduction to the field is Kahn [10], and current governmental issues are discussed in Barlow [1] and Murray [14]. Beker and Piper [2,3] discuss actual equipment design issues, but these are now somewhat dated; Pfleeger [16] and Seberry and Pieprzyk [22] are newer but more professorial. Deavours and others [5] covers a range of real issues in articles reprinted from Cryptologia, and Graff and Sheets [9] gives some information on real video scrambling systems. Ciarcia [4] and Pearson [15] are an excellent example of how tricky the field is; first study Ciarcia (a real circuit design), and only then read Pearson (how the design is broken). Geffe [8] and Siegenthaler [23] provide a more technical lesson, and Kochanski [11,12] cracks some common PC cipher programs. My own work is included mainly to indicate my background for this paper.
1. Barlow, J. 1992. Decrypting the Puzzle Palace.
Communications of the ACM. 35(7): 25-31.
2. Beker, H. and F. Piper. 1982. Cipher Systems. Wiley.
3. Beker, H. and F. Piper. 1985. Secure Speech
Communications. Academic Press.
4. Ciarcia, S. 1986. Build a Hardware Data Encryptor.
Byte. September. 97-111.
5. Deavours, C., D. Kahn, L. Kruh, G. Mellen, and B. Winkel (Eds.)
1987. Cryptology Yesterday, Today, and Tomorrow.
Artech House.
6. Denning, D. 1982. Cryptography and Data Security.
Addison-Wesley.
7. Ding, C, G. Xiao and W. Shan. 1991. The Stability of
Stream Ciphers. Springer-Verlag. Lecture Notes in Computer
Science #561.
8. Geffe, P. 1973. How to protect data with ciphers that are
really hard to break. Electronics. January 4. 99-101.
9. Graff, R. and W. Sheets. 1987. Video Scrambling &
Descrambling for Satellite & Cable TV. Howard W. Sams.
10. Kahn, D. 1967. The Codebreakers. Macmillan.
11. Kochanski, M. 1987. A Survey of Data Insecurity Packages.
Cryptologia. 11(1): 1-15.
12. Kochanski, M. 1988. Another Data Insecurity Package.
Cryptologia. 12(3): 165-173.
13. Meyer, C. and S. Matyas. 1982. Cryptography: A New
Dimension in Data Security. John Wiley & Sons.
14. Murray, W. 1992. Who Holds the Keys? Communications of
the ACM. 35(7): 13-15.
15. Pearson, P. 1988. Cryptanalysis of the Ciarcia Circuit Cellar
Data Encryptor. Cryptologia. 12(1): 1-9.
16. Pfleeger, C. 1989. Security in Computing. Prentice
Hall.
17. Rueppel, R. 1986. Analysis and Design of Stream
Ciphers. Springer-Verlag.
18. Ritter, T. 1990. Substitution Cipher with Pseudo-Random
Shuffling: The Dynamic Substitution Combiner. Cryptologia.
14(4): 289-303.
19. Ritter, T. 1991. Dynamic Substitution Combiner and
Extractor. US Patent 4,979,832, issued Dec. 25, 1990.
20. Ritter, T. 1991. Transposition Cipher with Pseudo-Random
Shuffling: The Dynamic Transposition Combiner. Cryptologia.
15(1): 1-17.
21. Ritter, T. 1991. The Efficient Generation of Cryptographic
Confusion Sequences. Cryptologia. 15(2): 81-139.
22. Seberry, J. and J. Pieprzyk. 1989. Cryptography: An
Introduction to Computer Security. Prentice Hall.
23. Siegenthaler, T. 1985. Decrypting a Class of Stream Ciphers
Using Ciphertext Only. IEEE Transactions on Computers.
C-34: 81-85.
24. van Eck, W. 1985. Electromagnetic Radiation from Video
Display Units: An Eavesdropping Risk? Computers & Security.
4: 269-286.
Note: Cryptologia was previously published by Rose-Hulman
Institute of Technology. As of 1995-07, Cryptologia is published
by the Department of Mathematical Sciences, United States Military
Academy, West Point NY 10996-9902 USA. Subscriptions are $40
per year in the US, and many back issues are available at $11 each.
Terry Ritter is a Registered Professional Engineer, and a
member of IEEE and ACM. Ritter Software Engineering offers
research, development and design services in cryptography, software,
computer architecture and other fields.
ABOUT THE AUTHOR
Terry Ritter, his
current address, and his
top page.
Last updated: 1995-11-11