This section includes the following topics:
This section discusses basic encryption techniques and concerns which form a basis of the discussions on strong cryptography and VPN integrity in the following sessions.
A very simple encryption algorithm is alphabetic rotation. Consider the following example:
The encryption algorithm moves all letters one step "up" in the alphabet, changing "a" to "b", "m" to "n" etc.
The decryption algorithm moves all letters one step "down" in the alphabet, changing "b" back to "a", "n" back to "m" etc.
Consider the following message:
THIS IS A SECRET MESSAGE
In crypto-speak, this is known as the plaintext. This message, processed by the above encryption algorithm, changes "T" to "U", "H" to "I", etc, forming the ciphertext:
UIJT JT B TFDSFU NFTTBHF
Such an algorithm could be shared between members of a group wanting to communicate "securely" with each other. However, if a member of the group were to leave the group, the group would have to devise a completely new algorithm so that the security of the group's communication is intact.
Hence, such fixed algorithms cannot be revealed to anyone but the intended set of recipients.
All recent encryption algorithms make use of keys. In a keyed encryption algorithm, the algorithm itself may be known to many, but without the appropriate key, no one can easily decrypt messages intended for someone else.
In this example algorithm, the key would be the number of steps that the alphabet is rotated during encryption and decryption. Considering that the english alphabet is 26 letters, the maximum rotation useful is 25. This limitation of the number of possible combinations is known as the key space of the algorithm.
Naturally, the above algorithm is very simple and the key space is very limited. Anyone armed with paper, a pen and knowledge of the algorithm would be able to crack a message encrypted using a given "key" in a few minutes by testing all possible combinations until something that looks like normal text appears.
A larger key space takes longer to crack when attempting to decrypt a message by testing all possible combinations.
If all the cryptanalyst has to work on in the above algorithm are two letters, for instance the letters "VQ", there is no way of telling if "VQ" is "UP" shifted one step or if it is actually "TO" shifted two steps.
With more ciphertext available, ambiguities such as the above are more easily resolved. The two ciphertext words "VQ AQW" would decrypt to "TO YOU" and "UP ZPV", respectively, given the above situation. Here, we have learned that the correct number of steps is two.
One should not encrypt too much data using the same key. If possible, the key should be changed every once in a while.
The alphabetic rotation example given in the previous section would hardly suffice in a real world scenario, but it does serve well in explaining the basics of encryption.
The best encryption algorithms available today are all public. That is, their integrity is not dependent on keeping their design a secret. The strength of the algorithm relies in how secure the key is.
For all practical purposes, the only way to "crack" a message encrypted with such an algorithm is to attempt to decrypt the message with all possible keys, one by one, until the correct one is found. This is known as brute force cracking an encrypted message.
Being able to determine which key is correct means that you'll have to know what to expect to see when the message has been decrypted. If you set your automatic tool to look for words in the english language, you'll never find the correct key if the original message is written in Swedish. Taking this into account, it is easier to break into a VPN connection if one can guess what kind of traffic is passing through it.
The time needed to brute force crack a message is dependent on the available key space, and a great portion of luck.
A key space of forty bits results in 1 099 511 627 776 unique combinations. A key space this large was long considered "secure enough", but recent advances in computer technology has lead to dramatic increases in cracking speed. A student with access to a few classrooms equipped with standard PCs can crack such keys in a week, given that a complex enough encryption algorithm was used. A very large organization, or country, with access to multiple supercomputers, can likely crack such keys in near real time.
Every bit added to the key length doubles the number of unique combinations. Using the above student as an example, a key length of 46 bits would mean that such an exhaustive search would take a full year, or, more precisely, 64 weeks. A key length of 50 bits would take more than a decade to crack.
Note: The above calculations are not precise measures of crypto strength. If an algorithm is less complex (i.e. faster), one will be able to attempt more combinations in the same time frame; i.e. a longer key is needed. If it were more complex, shorter keys would provide the same degree of protection, from a brute force perspective.
Surely we have all seen companies marketing products with "new private super ciphers that no one else has". However, if the strength of such an encryption algorithm depends on the fact that no one knows how it works, the security of the algorithm is compromised as soon as it is mass marketed. If it has a flaw, all that is needed is for one cyber villain to reverse-engineer the algorithm from a purchased product. Once such a flawed algorithm is exposed, your security is no security.
Not that we are saying that such "private" super ciphers do not exist. It's just that history has proven that such attempts usually end in failure. It has proven near impossible to design a secure algorithm without years and years of mathematical and crypto theory study and then have the result be subjected to public scrutiny for many years. Again, if the security of the algorithm depends on the secrecy of the algorithm itself, it is only a matter of time before it is broken, since all users of it have access to its inner workings.
A cryptographic algorithm that survives close scrutiny and does not depend on the secrecy of its design is referred to as a strong cryptographic algorithm.
Think of an encryption algorithm as a box or a safe used to "shield" the contents of encrypted messages from public view.
If I have a poorly designed safe, but place it in a remote and hidden place, my secrets are fairly safe as long as no one finds out where my safe is. I can also tell my friends where it is and what its combination (key) is so that they can share secrets with me. However, if someone learns the location of the safe (how the algorithm works), the algorithm is compromised and can no longer be used.
If I have a well-designed safe, I can place it in the middle of town square. I can publish the designs of the safe in all local newspapers. I can let everyone who wishes review identical unlocked copies of the safe. If no one can get to the contents of the safe without the proper combination, I have strong security.
The security of strong algorithms is only dependant on the key (combination), which can easily be altered for different safes used to store messages for different people that do not necessarily have to trust each other.
There are a number of cryptographic algorithms that are considered strong. Most of them could be implemented in the IPsec framework, but only two are declared as part of the official standard: DES, the Digital Encryption Standard, and 3DES, Triple-pass DES.
DES uses a 56-bit key and is considered equal in strength to most other algorithms that use 40-bit keys. Triple-pass DES uses three different keys in three DES passes, forming a theoretical key length of 168 bits. However, some cryptographic researchers claim that it may be possible to "take shortcuts" in cryptanalyzing 3DES encrypted messages, rendering the effective key space much shorter than 168 bits.
Many IPsec implementations support other common encryption algorithms.
The Amaranten Firewall IPsec implementation supports the following encryption algorithms:
DES (56 bits)
3DES (168 bits in theory)
Blowfish (40-448 bits)
CAST-128 (128 bits)
AES (x-y bits)
In addition to encryption, IPsec also employs Authentication to ensure the integrity and authenticity of encrypted data.
One might easily think that encryption provides good enough protection; it does after all ensure that no one can listen to what is being said. However, encryption does not provide any sort of protection against alteration of the encrypted data.
If someone can intercept the encrypted data stream and modify it, the result on the receiving end, after decryption, would also be altered. The end result of the modifications would certainly be unpredictable to the person intercepting the data stream, but if his goal is to harm in subtle ways, modification of the encrypted data may certainly be enough. What if, for instance, a document is sent for printing in hundreds of thousands of copies, and the text is garbled on every tenth page?
This is where authentication comes into play. Authentication serves to prove to the recipient that the data was actually sent by the person claiming to have sent it. And more importantly, it proves that the data has not been altered after leaving the sender.
Authentication does not automatically safeguard against marauders tampering with the encrypted data stream. However, should someone alter the data, it can be detected, and the damaged data can be resent. If someone were to alter all encrypted data, the data stream would indeed be disrupted, but that is still preferable to receiving corrupted data.
Compared to a fixed connection scenario, we believe that these characteristics, taken as a whole, are desirable. If you use a fixed connection such as a fiber optic cable, someone can still cut your cables and disrupt communication through them. However, if your only means of protection in your fixed connection private network is the security of your cables, and that physical security is lacking in any aspect, you still cannot be sure that no one has dug them up out of the ground somewhere and is listening to everything that you are sending or making subtle alterations to the data sent. With an encrypted and authenticated VPN such as IPsec provides, only the disruption of communication is a concern.
Encryption does not only come in the form of VPNs. Separate documents may be encrypted, entire hard disk may be encrypted, and individual connections and protocols may be encrypted.
A VPN, such as IPsec, is not a silver bullet that solves all confidentiality and integrity requirements that one may possibly have.
During the past several years, many applications have provided cryptographic protection on a session-by-session basis, using protocols such as SSL, TLS and SSH.
SSL, Secure Sockets Layer, is a standardized way of encrypted communication that has been deployed to protect many protocols. When you visit "secure" web sites, you may have noticed that the URLs begin with the letters "https://" rather than "http://". This is HTTP wrapped up inside SSL.
TLS, Transport Layer Security, is the successor to SSL and provides much the same functionality but with much firmer standardization and foothold in the IETF.
SSH, Secure Shell, has become a world standard in remote administration and connectivity in a "shell" environment, that is, a command prompt based environment.
The common denominator between all these protocols is that each individual application that wishes to communicate securely must implement its own cryptographic algorithms. If an application does not have a built-in crypto engine, it can normally not use the above session-by-session protocols.
However, session-by-session protocols are fairly easy to setup, in that they do not require any extra hardware, they rarely require any configuration over and above that required to get non-encrypted communication to work, and they can easily provide user-by-user authentication.
VPNs work on a lower level than do session-by-session protocols: they work on raw IP data rather than individual TCP sessions.
In a multi-user host, such as a Unix host or a terminal server, a VPN cannot easily distinguish between individual users. Rather, it treats all users on that host the same way. This is exactly what happens with a fixed connection private network, so keeping in mind what a fiber optic cable in the ground would do for you nearly always provides a good enough analogy for connectivity analysis purposes.
We do not expect to see the session-by-session encryption standards disappear in the near future. Rather, we see them living side by side with VPNs for a fairly long time to come. Perhaps in the future, VPNs such as IPsec will be a silver bullet solution for all cryptography requirements, but we are nowhere near that yet.
For those of you that want more information on cryptography than we can provide in this short introduction, we highly recommend the book Applied Cryptography, Second Edition by Bruce Schneier, ISBN 0-471-12845-7.
Applied Cryptography is an excellent introduction to the concepts of cryptography and expands onto subjects such as symmetric vs. asymmetric encryption, authentication and one-time pads. It also includes example algorithms and source code for those that are interested in implementing their own encryption software.