« Version 4.1 - 2.0 RSA | Main | Version 4.1 - 2.0 IPsec »

Version 4.1 - 2.0 Symmetric Encryption

Before I start into the types of symmetric encryption, I would like to first start with the 4 common modes.

ECB - Electronic Code Book { encodes each n-bit block independently, uses the same key }
CBC - Cipher Block Chaining --- Uses an IV
CFB - Cipher Feed Back --- Uses an IV
OFB - Output Feed Back --- Uses an IV

ECB is the only mode that doesn't use an Initialization Vector.

Without an IV, the same data sent twice is exactly the same. With an IV, the same data looks different each time.

What I did for this section was make a chart to help remember the differences.


RC4 is the stream cipher, the rest are block ciphers. RC4 can actually use various key lengths, but commonly uses the 128-bit key. It's normally used in Wireless. It's pretty weak and is vulnerable to multiple attacks.

The only reason any of the guides mention DES is to compare it to 3DES. It is very weak and is considered insecure. The Wikipedia page is interesting to read because it outlines the history of the development of this cipher. It calls to mind the struggles between those inventing cryptography and the US Government's desire to be able to break the code if needed. To look at this and know this struggle was in the 70's - and compare it to the situation to get into the iPhone of the San Bernadino terrorist more recently. Well, it seems that the more things change, the more they stay the same. But that stuff won't be on the test. What might be is that DES uses "16 identical stages of processing, termed rounds" - that seems to be significant to people making up exams and study guides on this topic. [I've seen that in study guides from Security+ to CISSP.] What they probably won't ask about is the Feistel scheme. As far as attacks, they will probably only focus on brute-force and key space. I don't even think they would bother with weak keys or semi-weak keys. (Something you would probably need to understand for the CISSP, but not CCIE Security.) There are attacks other (faster) than brute-force, but I really doubt those would appear in a question, but they are interesting. The only other thing that I would point out about DES is that out of the 64-bit key, 8 bits are used for parity. This means you _effectively_ have just a 56-bit key. At the time when 8 MB of RAM was a lot, that may have been okay. Today, you're probably wearing more processing power than you need to crack DES. The Wikipedia section near the bottom about SDES was interesting. It was developed to help students learn cryptanalysis. As someone with an interest in ciphers, this sounds so cool.

Moving on to 3DES - which is more relevant to current exams. Always remember that there is a struggle between key length and brute force - and crypto systems are designed based on time. You want your algorithm and key length to be strong enough that by the time brute force is used, the information no longer needs to be safeguarded.

You can relate key length to number of characters in a password (when looking at brute-force cracking). If you have a password of 4 characters, and you use the available keyspace of 26 letters (the alphabet), it would take 26 to the power of 4 (456,976) combinations to try them all. If you add the numbers and special characters, you take a much higher number to the power of 4. Just adding the numbers 0 - 9 as possible characters (adding 10 more to the keyspace) turns a 4 character password into 1,679,616 possible combinations. So let's stick with that 36 character keyspace as a simple example and compare the 4 character password to a 5 character password. Adding one more character brings the number of possible combinations from 1,679,616 to 60,466,176. With just one more character! The point being is that the key length increases the number of possible combinations - and increases the amount of time needed to brute-force the key.

These may seem like large numbers of possible combinations. For us to manually try that many combinations would be daunting. But computers chew through this quickly. And as time goes on, processors get faster and computers can zip through more combinations faster. You want your calculations to show that with the technology available today, it would take so long to brute-force that even if computers got really, really, really fast in the future, the information would still remain secure. If a reasonably priced computer would take 6 centuries and a million-dollar computer would take 2 centuries to brute-force something, a future computer would be expected to take at least 30 to 50 years to do the same. Yeah, that would be considered secure.

So now let's relate this key length to comparing DES to 3DES. 3DES can use 1, 2 or 3 keys. 3DES using 1 key is basically equivalent to DES. If you take the same key and encrypt, decrypt (now you're back to plain text) and encrypt again - well the first two basically are futile. So why would you do that? (Not recommended, but is a way to be backwards-compatible with DES.) Another option is to use 2 keys. You would encrypt with K1, decrypt with K2 and then encrypt with K1 again (K3 = K1). For this - you have two keys --> 2 X 56 = 112 key bits. However, due to certain known-plaintext attacks, it is "designated by NIST to have only 80 bits of security." And the third option is to use 3 independent keys. [This is the scenario expected in the test.] In this case, you encrypt with K1, decrypt with K2 and then encrypt with K3. So that would give you -> 3 X 56 = 168 bits. But due to the meet-in-the-middle attack, the effective security it provides is only 112 bits (just like 2 keys).

Now look at these numbers. 1 key = 56 bits, 2 keys = 112 bits and 3 keys = 168 bits. Now look at the chart above. It says 3DES uses 192 or 168 bits for a key. I'm looking at this and thinking that if I see something like this on a test, I better read the question very carefully. The first set of numbers is based on each key having 56 bits (with 8 bits parity). So where did those other numbers come from? 56 X 3 = 168. 64 X 3 = 192. So materials in some of the study guides are basically assuming you are using 3 independent keys with or without parity.

3DES was basically invented as a "temporary" solution while a better algorithm was created. That better algorithm is AES. It was a standard established by NIST and is a FIPS standard (used by the US Government). It is based on the Rijandel family of ciphers. It uses "a design principle known as a substitution-permutation network" which is "fast in both software and hardware." Important points are that it uses 128 bit data blocks - using 3 key lengths -> 128, 192, 256 bits. Look at those numbers. Don't they look familiar? 2 X 64, 3 X 64 and 4 X 64 !

One of the things that I don't remember being prominent in the study materials is the number of rounds of operations in AES. They mention the 16 rounds in DES, but nothing is mentioned about AES. So this might be interesting to note:

10 cycles of repetition for 128-bit keys.
12 cycles of repetition for 192-bit keys.
14 cycles of repetition for 256-bit keys.

In the chart, I included IDEA and Blowfish. IDEA is not available in the public domain, so I don't think there would be any likelihood of a question on that type of encryption. And Blowfish wasn't even mentioned in most of the study guides. Blowfish is interesting because it is released to the public domain and can be used by anyone. It is a 16 round Feistel cipher and incorporates the hexadecimal digits of pi (now there's a random number generator - albeit known random numbers). Although interesting, I doubt either one would be tested for its details or functionality. However, these could show up as "distractors" or possibly in a general question on symmetric vs asymmetric encryption.

Looking at this post, I think I'm set with this topic. This is material I've covered for very many exams. The biggest problem with this topic is that you don't actually use or configure the functionality of the protocols. The protocols just function the way they do. You configure something to use 3des or aes, but you don't configure the protocol itself. So much of this is academic. But you have to know it - so you know why you're using aes and not des. And it's likely there will be some form of question on it. Review and remember. Hopefully the charts or commentary added in might be helpful.


Sections

Powered by
Movable Type 3.2