Curiosity is one of the most common human traits, matched by the wish to conceal private information. Lovers, spies, and the military all resort to information hiding to pass messages securely, sometimes deliberately including misleading information. Steganography, a mechanism for hiding information in apparently innocent pictures, may be used on its own or with other methods.
Encryption fundamentally consists of scrambling a message so that its contents are not readily accessible while decryption is the reversing of that process. These processes depend on particular algorithms, known as ciphers: Suitably scrambled text is known as cipher text while the original is, not surprisingly, plain text. Readability is neither a necessary nor sufficient condition for something to be plain text. The original might well not make any obvious sense when read, as would be the case, for example, if something already encrypted were being further encrypted. It's also quite possible to construct a mechanism whose output is readable text but which actually bears no relationship to the unencrypted original.
A key is used in conjunction with a cipher to encrypt or decrypt text. The key might appear meaningful, as would be the case with a character string used as a password, but this transformation is irrelevant -- the functionality of a key lies in its being a string of bits determining the mapping of the plain text to the cipher text.
Until recently, aided by the development of computer power, a very common method of encryption was to use some form of substitution. This might be as straightforward as the claimed hiding of the real name of the computer in 2001: A Space Odyssey where shifting the letters HAL one position in the alphabet yields a plausible result. In numerous spy stories words or phrases or arbitrary series of letters taken from innocent documents or books are used to generate messages, to construct keys, or to create substitution tables to encrypt or decrypt text.
Protecting access to information for reasons of security is still a major reason for using cryptography. However, it's also increasingly used for identification of individuals, for authentication and for non-repudiation. This is particularly important with the growth of the Internet, global trading and other activities. The identity of e-mail and Web users is trivially easy to conceal or to forge, and secure authentication can give those interacting remotely confidence that they're dealing with the right person and that a message hasn't been forged or changed. In commercial situations, non-repudiation is an important concept ensuring that if, say, a contract has been agreed upon one party can't then renege by claiming that they didn't actually agree or did so at some different time when, perhaps, a price was higher or lower. Digital signatures and digital timestamps are used in such situations, often in conjunction with other mechanisms such as message digests and digital certificates.
The range of uses for cryptography and related techniques is considerable and growing steadily. Passwords are common but the protection they offer is often illusory, perhaps because security policies within many organizations aren't well thought out and their use causes more problems and inconvenience than seems worth it. In many cases where passwords are used, for example in protecting word processed documents, the ciphers used are extremely lightweight and can be attacked without difficulty using one of a range of freely available cracking programs.
Unfortunately there is also considerable pressure on legislators to bring in absurd laws, such as the Millennium Compliance Act in the United States, which essentially removes the onus on organizations to take the trouble to protect themselves sensibly or to suffer the consequences of inaction. The mechanism protecting video recordings, for example, CSS, is pitifully weak and the utility DeCSS has no difficulty circumventing it and making the material available on other platforms.
Security issues are generally not well understood or implemented, so it's useful for developers to understand some of the principles that apply to encryption and to learn of the mechanisms that are used. Writing cryptographic algorithms is a difficult and complex task, but implementing existing mechanisms sensibly into applications or drawing on reputable products to facilitate information hiding or authentication is quite different and potentially a very valuable skill.
The fact that digital data can be sampled and abstracted, or changed, without fear of detection is one reason why the use of cryptography is growing rapidly. This is particularly the case across the internet where face to face contact doesn't happen and where messages can travel through systems where they can be vulnerable: Web sites may hold sensitive data that should be protected; credit card numbers and other sensitive personal data needs to be transmitted securely; e-mail is as easily read as a postcard; entry to restricted areas may need controlling; units of value -- digital cash, electronic bonds, and the like -- can't sensibly be left lying around without protection; content providers want to protect their films or TV programs or music so that only subscribers can have access; remote access to networks needs controlling; mobile phones, PDAs, and laptops can readily be lost or stolen; ATMs should only distribute cash to legitimate requests. These are some instances where cryptography is needed and used.
The aim of this article is to introduce, in general terms, the relevant background, consider broadly some of the techniques used, and consider some of the implications. Other articles will then look in more detail at different topics.
The oldest kind of encryption method, used for thousands of years, is known as secret key, or symmetric, encryption and where the same key is used both to encrypt the plain text and then to decrypt the cipher text. Mechanisms used can vary greatly but they all share the vulnerability arising out of the need to share the key and so risk it falling into the wrong hands. Once a key becomes known to someone not authorized, then the security based on that key is compromised. This might not matter if only one message is involved but the very nature of electronic communication means that the same key is likely to be used repeatedly and it won't necessarily be known that the key is no longer secret.
It's quite possible, of course, for the key to be shared among a number of people, as a set of mathematically constructed files, so that a minimum combination of any elements is needed before the key can be used, but this doesn't alter the general principle.
Symmetric systems are generally fast and can now be made effectively impossible to break. Like anything of this sort, there is no absolute guarantee, but it's quite reasonable to say that with the knowledge available at present and with access to current levels of computing power, a properly constructed system can be made entirely secure.
Different ciphers are vulnerable to different forms of attack and in some cases particular groups of keys can be much less secure than others. However, the greater the length of a key -- all other things being equal -- the progressively more difficult it becomes to break the encryption.
Software code is a valuable resource and many companies go to great lengths to protect their source code, taking a view diametrically opposed to that of the Free Software Foundation or of the open source movement. However, in the case of ciphers it's essential that the algorithms be fully and freely published for public scrutiny. In the case of a word processing program, it may be irritating but it doesn't normally matter enormously if some bug or other is present. And bugs invariably are present, even without the current tendency to rush out immature products. In the case of encryption software, or at least the cipher part of it, a bug is far more critical and can have extremely serious consequences. The only realistic way of identifying such flaws is to open the internal workings to peer evaluation and analysis. Put simply, do not trust and do not use any encryption software whose central elements, including the encryption algorithm, are not publicly accessible and which have not been subjected to peer evaluation. The history of cryptographic developments shows numerous instances in which this policy has been vindicated.
The 1976 paper New Directions in Cryptography contained details of a protocol for devising a system of public/private key pairs; it was subsequently known by the names of the authors, Whitfield Diffie and Martin Hellman, then at Stanford University. The Diffie-Hellman algorithm is now in the public domain and is used as the basis for a large number of what are known as public key systems.
Public key systems use two keys constructed from prime numbers and which complement each other such that one key is used for encrypting plain text which can then be decrypted by, and only by, the other. This is also known as asymmetric cryptography.
One of the key pairs is kept private and is known as the private key while the other, the public key, is widely publicized. The unique nature of the process is that anyone who knows my public key can encrypt a message that can then only be decrypted by me using my secure private key. Conversely, I can encrypt a message with my private key and anyone decrypting it, using my freely-available public key, can be confident that it came from me. In practice, things get more complex than this and as asymmetric keys are typically very long in comparison with symmetric keys (perhaps 768 bits versus 56 or 128 bits), processing text can be slow. One of the most widely-used public key systems is that developed in 1977 by three researchers at MIT -- Ron Rivest, Adi Shamir, and Leonard Adelman, using the concepts introduced by Diffie and Hellman. This became known by their initials, RSA, and was patented in the US in 1983.
Public key systems can also be made unbreakable, subject to the caveats and conditions expressed earlier. Methods of attack on such systems generally consist of attempts to factor numbers, and factoring large primes is notoriously difficult. However, other approaches are also taken and it's perfectly possible that new mathematical techniques will be discovered that could severely compromise one or more of these ciphers, or render it completely useless. Further, just as secret key cryptography is vulnerable to the single key falling into the wrong hands when distributed, public key cryptography is vulnerable to what's known as the spy-in-the-middle risk. This is discussed more fully later but consists essentially of fooling a user into thinking that a public key comes from one source when, in reality, it comes from another. For this reason, public key cryptography is usually associated with other security methods, such as digital certificates, which seek to confirm the integrity of the public key. Obviously the system is also vulnerable to the private key's becoming known but as this key doesn't normally need to be shared, this risk shouldn't be great.
I mentioned earlier that message authentication is becoming as important as information hiding. What's needed here is a mechanism to reassure a recipient that the message has indeed come from the claimed sender and that it hasn't been changed since it was created. The integrity of the message is typically provided by using a hashing technique to generate what's known as a message digest. Hashing is the technique that involves a string of characters of variable length being converted to a fixed-length result, usually 128 bits. In practice, any change to the message -- even one as trivial as adding or removing a space -- will result in a different hash value being created when the process is run.
The following simplified model shows how these different elements can work together to protect a message from casual scrutiny and have it received with confidence that it has come from me, the authorized sender:
- I apply to my plain text message an appropriate process to generate a hash value to be used as a message digest.
- I encrypt this digest, but not the message itself, with my private key, confirming to anyone who can decrypt it with my public key that it came from me.
- I generate for one-time use a secret key that I use to rapidly encrypt the text of the message.
- I encrypt this secret key using my recipient's public key and send the whole bundle to him.
My addressee uses his private key to obtain the secret key, uses that in turn to decrypt the message, applies to it the same message digest algorithm and compares it with the message digest that he's decrypted using my public key. Provided they match, he can be sure that the message came from me and is unchanged.
Although practical use may be more complex, this is fundamentally how the very widely used program, Pretty Good Privacy (PGP), and some other applications work, elegantly incorporating complementary elements that work together in an efficient and rapid way.
Security is about managing risk, not eliminating it. Cryptography is an important part of any security strategy and is increasingly being used in the background in a very wide range of situations. Developments in computer technology mean that ciphers that earlier would have been considered completely secure may now have become insecure or only moderately secure. At the same time, these same advances have made it possible to use longer and longer keys in reasonable time frames while new algorithms or variants on earlier ones are being used. Some, such as elliptic curve or quantum cryptography, show considerable promise but may still be too esoteric for general use.
It's perfectly possible now to implement systems that, for all practical purposes, are completely secure over any reasonable period. The question then becomes one of how such systems are to be implemented, and understanding the implications in machine and in human terms. There is the additional point that although absolute authentication may appear an attractive option, it carries the considerable risk that if a person's digital identity is stolen the consequences can be catastrophic. Governments - which treat cryptosystems as munitions and which want to control their dissemination and use -- have become increasingly nervous of what they offer even though they have variously relaxed laws pertaining to export and use. Although they may not wish to admit it, they're fighting a battle that's impossible to win without implementing severe limitations on accepted freedoms of action.
For developers, there are considerable opportunities both in developing applications that use encryption techniques and in understanding through the strengths and weaknesses of the various systems, how some security risks may properly be managed within an organization's constraints.
Murdoch Mactaggart is a freelance
writer and business consultant who writes on software development, the Internet
and on business and management issues around these areas. Whether readers can
make accurate sense of what he writes is a moot point but, flexible though he
tries to be, he generally sticks to English rather than introducing languages of
his own making. Contact him at IBMDev@TextBiz.com.
Comments (Undergoing maintenance)
Table of contents
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags