AES Encryption Modes

Well, I started back through the questions that I missed the first time around and I can tell you I have for sure learned a ton. I’m able to explain concepts that I wasn’t able to before and rationally provide answers rather that give a letter answer because I memorized that as being the answer. So that’s good. I got through 50 questions and realized that there where about 5 that I wanted to blog and legit got about 3 wrong. So far so good. However, if I remember correctly the last half of the 250 that I missed where much harder. I’m going to kind of take my time with it but I’m hoping to get through that set and find out I’m some where in the 90s on the questions I missed the first time. You know, its like a check and re check and the recalibrate and so forth. I mean, 300 bucks is a lot of money to waste if you are not sure about some thing. At least for me. I also have an interview tomorrow. I dont expect it to go very far however I’m super excited that recruiters have started to contact me out of the blue for network admin type roles. Also, its worth noting that this started as several questions and then ended up being so much info about AES thats longer than a typical 5 question post that I cut it down to one post. If your new, prepare for shoe shine head

I got this right and I understand what AES is but I’m not sure that some of these are AES modes and I wanted to take a look at this. HMAC ‘just made sense’ but I couldn’t explain it back to my self. I didn’t like that so lets star at the top

I found this link helpful: How and when do I use HMAC?

Before you close the package and mail it, you make a copy of the photograph. No locked box this time, instead you brush over the copy with a concoction of liquid chemicals. Only you know the recipe (key) for this mixture, and anytime you brush over a copy, you use the exact same brush strokes. The mixture will swirl and blur the copy of the photograph into something resembling modern art; let’s call it an HMAC. You’re not exactly sure what it will look like after it dries, but you know that if you brush any two identical photos with the same recipe and the same brush strokes, the resulting HMACs will look the same. So you place the dried HMAC into the package along with the original photograph and send it off to Sarah. When you get the package back from Sarah, it contains what you hope is the un-altered original photograph along with what you expect is the HMAC you created and included with it. Take the photograph out of the package, copy it, and create another HMAC with that copy (apply your mixture/brush strokes). Compare the HMAC you just created with the HMAC that came back in the package. If they are identical, then you can be sure Sarah and the mail carriers did not alter the photograph. If Sarah had altered the photo, then the HMACs will not be identical. If Sarah had altered the HMAC, then the HMACs will not be identical. If Sarah had altered the photo, and tried to create a new HMAC, then the HMACs will not be identical (she doesn’t know your recipe). Thus you know if the photo (data) is authentic or not, which is exactly what HMACs are used for.

Basically, HMAC insures message validity. However, I still don’t understand how AES or how it interacts with other ‘modes’ so I have to figure that out. Also, it appears the key length for HMAC is 256 but as to how the data validation works as you move into harder to read stuff that seems to indicate they are using SHA256 for data validation with AES and that is a little confusing as HMAC seems to do data validation on its own.

Anyway, so I spent a ton of time on this and don’t really understand the math but if your looking for that you can find it here: ADVANCED ENCRYPTION STANDARD (AES) MODES OF OPERATION

There are tons of sites on this and I kind of had to look at, all of them I could find, to really kind of wrap my brain around this and I’ll go through each one of these. The thing is, none of them mention HMAC but AES is basically a framework that you actually use your algorithm with and I get that. I’m not sure how you inject the algorithm into the framework but personally I’m hoping you select it through a gui. This is one of the tricker parts of this exam, its mostly theoretical. Which is still cool. The other interesting note here is that AES has varying key lengths and I suppose we should figure that out. In addition its worth noting that H stands for hash and you can use MAC without that. The main 5 modes are really complicated to slim down and at the end Ill try to put a summary but this is one of the biggest single points of information that I have found while studying for pretty much anything in computers. I’m actually going to have to look at this and edit it to make sure that I made the points I wanted to clearly haha. That never happens! There is a thing I found on stack exchange that I found a helpful overview but it does not answer all the questions that could possibly come up on test. That said its a helpful starting point. Here is the link and prevalent information: How to choose an AES encryption mode (CBC ECB CTR OCB CFB)?

• ECB should not be used if encrypting more than one block of data with the same key.
• CBC, OFB and CFB are similar, however OFB/CFB is better because you only need encryption and not decryption, which can save code space.
• CTR is used if you want good parallelization (ie. speed), instead of CBC/OFB/CFB.
• XTS mode is the most common if you are encoding a random accessible data (like a hard disk or RAM).
• OCB is by far the best mode, as it allows encryption and authentication in a single pass. However there are patents on it in USA.

There is more really good info on this about authentication methods too, which is contained in another comment. I’m going to share the the entire comment because its great! It is kind of a nightmare for formatting even though, for the first time ever, I clicked the ‘view source’ on a page and copied the HTML over. Have to check and see how wordpress likes it. Took some edits but it looks like its working, the italics note the start and end of the comment and for some reason the guy actually used a bold font and the start of the comments in ordered lists. Looks great, may do that in future posts. I try to use those to notate lifted information as much as possible and if you see me copying text and not doing that, please send an email and I will make the change.

Comparison of the modes

Encryption only:

• Modes that require padding: Like in the example, padding can generally be dangerous because it opens up the possibility of padding oracle attacks. The easiest defense is to authenticate every message before decryption. See below.
• ECB encrypts each block of data independently and the same plaintext block will result in the same ciphertext block. Take a look at the ECB encrypted Tux image on the ECB Wikipedia page to see why this is a serious problem. I don’t know of any use case where ECB would be acceptable.
• CBC has an IV and thus needs randomness every time a message is encrypted, changing a part of the message requires re-encrypting everything after the change, transmission errors in one ciphertext block completely destroy the plaintext and change the decryption of the next block, decryption can be parallelized / encryption can’t, the plaintext is malleable to a certain degree – this can be a problem.

• Stream cipher modes: These modes generate a pseudo random stream of data that may or may not depend the plaintext. Similarly to stream ciphers generally, the generated pseudo random stream is XORed with the plaintext to generate the ciphertext. As you can use as many bits of the random stream as you like you don’t need padding at all. Disadvantage of this simplicity is that the encryption is completely malleable, meaning that the decryption can be changed by an attacker in any way he likes as for a plaintext p1, a ciphertext c1 and a pseudo random stream r and attacker can choose a difference d such that the decryption of a ciphertext c2=c1?d is p2 = p1?d, as p2 = c2?r = (c1 ? d) ? r = d ? (c1 ? r). Also the same pseudo random stream must never be used twice as for two ciphertexts c1=p1?r and c2=p2?r, an attacker can compute the xor of the two plaintexts as c1?c2=p1?r?p2?r=p1?p2. That also means that changing the message requires complete reencryption, if the original message could have been obtained by an attacker. All of the following steam cipher modes only need the encryption operation of the block cipher, so depending on the cipher this might save some (silicon or machine code) space in extremely constricted environments.
• CTR is simple, it creates a pseudo random stream that is independent of the plaintext, different pseudo random streams are obtained by counting up from different nonces/IVs which are multiplied by a maximum message length so that overlap is prevented, using nonces message encryption is possible without per message randomness, decryption and encryption are completed parallelizable, transmission errors only effect the wrong bits and nothing more
• OFB also creates a pseudo random stream independent of the plaintext, different pseudo random streams are obtained by starting with a different nonce or random IV for every message, neither encryption nor decryption is parallelizable, as with CTR using nonces message encryption is possible without per message randomness, as with CTR transmission errors only effect the wrong bits and nothing more
• CFB‘s pseudo random stream depends on the plaintext, a different nonce or random IV is needed for every message, like with CTR and OFB using nonces message encryption is possible without per message randomness, decryption is parallelizable / encryption is not, transmission errors completely destroy the following block, but only effect the wrong bits in the current block

Disk encryption modes: These modes are specialized to encrypt data below the file system abstraction. For efficiency reasons changing some data on the disc must only require the rewrite of at most one disc block (512 bytes or 4kib). They are out of scope of this answer as they have vastly different usage scenarios than the other. Don’t use them for anything except block level disc encryption. Some members: XEX, XTS, LRW.

Authenticated encryption:

To prevent padding oracle attacks and changes to the ciphertext, one can compute a message authentication code (MAC) on the ciphertext and only decrypt it if it has not been tampered with. This is called encrypt-then-mac and should be preferred to any other order. Except for very few use cases authenticity is as important as confidentiality (the latter of which is the aim of encryption). Authenticated encryption schemes (with associated data (AEAD)) combine the two part process of encryption and authentication into one block cipher mode that also produces an authentication tag in the process. In most cases this results in speed improvement.

• CCM is a simple combination of CTR mode and a CBC-MAC. Using two block cipher encryptions per block it is very slow.
• OCB is faster but encumbered by patents. For free (as in freedom) or non-military software the patent holder has granted a free license, though.
• GCM is a very fast but arguably complex combination of CTR mode and GHASH, a MAC over the Galois field with 2^128 elements. Its wide use in important network standards like TLS 1.2 is reflected by a special instruction Intel has introduced to speed up the calculation of GHASH.

Recommendation:

Considering the importance of authentication I would recommend the following two block cipher modes for most use cases (except for disk encryption purposes): If the data is authenticated by an asymmetric signature use CBC, otherwise use GCM.

In addition, this link about key lengths for AES is really awesome: Security Best Practices: Symmetric Encryption with AES in Java and Android

Anyway, I found this site to be the most helpful for an overall understanding so moving into key lengths may be getting ahead of our selves but there is so much to know about this that its as good of place as any to start.The difference in five modes in the AES encryption algorithm its also where I got the images from. So lets get into this and hopefully I’ll come out the other side of this having learned a few things.

This first one is (shockingly, HMAC isn’t discussed but it is clear that its possible to use in the AES framework) (directly copied text): ECB Mode- The ECB (Electronic Code Book) mode is the simplest of all. Due to obvious weaknesses, it is generally not recommended. A block scheme of this mode is presented in Fig. 1.

So they don’t really discuss the variables for these charts but I think we can make some assumptions that for some reason they decided to use ‘k’ as a variable for the actual encryption while P is the data being encrypted and C is the encrypted text. I’m not really sure if it actually breaks it into segments and then balls it up or how that works but I get the idea that its basic.

Here are some more lifted ideas about ECB: For example, if a ciphertext from the ECB mode is known to encrypt a salary figure, then a small number of trials will allow an attacker to recover the figure.

In general, we do not wish to use a deterministic cipher, and hence the ECB mode should not be used in most applications. In the database encryption, we can use ECB to encrypt the tables, indexes, wal, temp files, and system catalogs. But with the issues of security, we don’t suggest to use this mode.

As you can see “don’t use this is a running theme” while no one talks about HMAC. This is from a PDF that I will hopefully attach to this blog but if not you can find it here: MODES OF OPERATION OF THE AES ALGORITHM

ECB Mode of Operation The ECB (Electronic Code Book) mode of operation is the simplest of all. A block scheme of this mode is presented in Fig. 1. As it can be seen from Fig. 1, the plaintext message is divided in blocks (P1, P2, PN), where each block is encrypted separately with the same key (K). The results of the encryption are the encrypted messages C1, C2 and CN respectively. If the size of the message is larger than n blocks, the last block is filled with padding. In this mode, if an error occurs in one of the blocks, it is not propagated to the other blocks, which is why decryption is possible in the blocks that don’t contain an error [2, 6, 7]. According to [6], the encryption in this mode is deterministic, because identical P blocks will produce identical C blocks, which is why identical plaintext blocks or a message with the same beginning are easily recognizable. Also, the ordering of the C blocks can be changed without the receiver noticing. In general, this mode is not recommended for encryption of data that is larger than one block [2, 8]. In [3] it is strictly recommended not to use this mode at all, while [7] states that this mode of operation is wrong and abandoned.

Apparently the end results do come out ‘packaged’ some how and the packets can be moved around if they are the exact same block of text because the outputs all look the same which causes issues with data validation. Not spending much more time on this one. However, another note from the article mentioned in the intro paragraph is that ECB is 128 bit key length, if I’m understanding this right:

Remember to never choose this mode unless you only encrypt data smaller than 128 bit. Unfortunately it is still often misused because it does not require you to provide an initial vector (more about that later) and therefore seems to be easier to handle for a developer.

Anyway, lets move on to the next type of AES encryption mentioned in the first article, CBC mode

This one is a little more complicated and we have XOR data involved and I’m not really sure what that is, so lets investigate. After going through several websites I realized that I understand this at all and went to YouTube. I found this super helpful video that honestly I wouldn’t have found helpful if I didn’t have a baseline understanding of AES.

So now I sort of understand the XOR data, it kind of jumbles the info before it encrypts and then unencrypts the data, spins it and then it should be back. Clearly, you end up with more keys this way. In addition, here is what the PDF has to say about the mode:

In order to provide cryptographic security, every encryption of the same plaintext should result with a different ciphertext [6]. The CBC (Cipher Block Chaining) mode of operation (Fig. 2) provides this by using an initialization vector – IV [4]. The IV has the same size as the block that is encrypted. Fig. 2 presents the encryption process. First, an XOR operation is applied to the plaintext block (P1) with the IV, and then an encryption with the key (K) is performed. Then, the results of the encryption performed on each block (C1, C2, … , CN-1) is used in an XOR operation of the next plaintext block PN which results in CN. In this way, when identical plaintext blocks are encrypted, a different result is obtained. Also, using a different IV for each new encryption, an identical message will always be encrypted differently. It should be emphasized that the same key K is used in each of the encryption blocks. Figure 2: Scheme of the CBC mode of operation [2] An error in one of the plaintext block will propagate in all the following blocks and will be manifested in the process of the description [8]. Specifications in [8] recommend that the Padding method 2 is used in case padding is needed with the CBC mode of operation because it provides protection from some of the known PA (Padding Attacks). There are complex CBC attacks for which an unpredictable value of IV is needed in order to overcome them [2, 6]. In [7] it is emphasized that the CBC mode of operation is safe from CPA (Chosen Plaintext Attack) attacks (attacks in which the attacker chooses a set of plaintexts and is able to obtain respective ciphertexts) only if the IV has a random value, but not if the IV is a nonce (a number that is not repeated). The CBC mode of operation, besides its vulnerability to PA attacks, is also easily susceptible to CCA (Chosen Ciphertext Attack) attacks (where the attacker chooses a set of ciphertexts and is able to obtain respective plaintexts). According to [3], the encryption key has to be changed whenever condition (1) holds: ( 1) / 2 2 + << n q (1) In (1), q is the number of blocks that should be encrypted and n is the number of bits in the encryption blocks. In order to provide protection from CCA attacks in this mode of operation, it is necessary to use ÀÅ (Authenticated Encryption), where, besides the encryption, authentication is also performed [3].

I’m starting to get this one but I don’t know what the key length is which could come up on a test. There is also a basic overview of this one on TechTarget: cipher block chaining (CBC). This also gives us no information but I think its 128 bit based on this information:

If the key and iv are generated with another tool, you must verify that the result is hex-encoded and that the size of the key for 128 is 32 characters, 192 is 48 characters, and 256 is 64 characters. The hex-encoded iv is 32 characters in length. Hex encoding means that each character in the key and iv are converted to its hexadecimal equivalent. For example, the letter “A” is “41” in hexadecimal. Hex encoding eases the storage and transport of the key and iv because the non-encoded versions of these items can contain ASCII control character sequences.

Source: Generating AES keys and password

After further research it looks like CBC can use 128 or 192 or 256, finally an answer in the form of a tool lol AES CBC encryptor

Now that we have covered a ton of basics that maybe we wont have to hit in the next mode, lets move on to CFB

This one looks similar but the data is actually being encrypted and then rotated before spitting out the final cypher. Similar but more complex. I’m going back to the basic link for some info on this:

First, CFB will encrypt the IV, then it will xor with plaintext block to get ciphertext. Then we will encrypt the encryption result to xor the plaintext. Because this mode will not encrypt plaintext directly, it just uses the ciphertext to xor with the plaintext to get the ciphertext. So in this mode, it doesn’t need to pad data. And it could decrypt data in parallel, not encryption. This mode is similar to the CBC, so if there is a broken block, it will affect all following block. This mode can be attacked by replay attack. For example, if you use the other ciphertext to replace the new ciphertext, the user will get the wrong data. But he will not know the data is wrong. It is safe from CPA, but it is easily susceptible to CCA.

Now we know sort of how it works, which to be honest probably wont be on the test but key length/size might be so lets find that out. There is no solid answer but it looks like 128/192/256 as well per a variety of sources. Also, the information from PDF seemed more confusing than helpful on this one

Ok, moving on to the next one, this one is supposed to be the best but has a patent on it in the US and that’s about all I know, so far. In addition I’m pretty sure I will never use this stuff at work as I still don’t use the stuff I learned 5 years ago in my day to day job, unfortunately. However, I honestly like to learn. It’s like going to gym for your brain and its hard to say you are not qualified with a bunch of letters and names next yours that are hard to acquire. Little trophies if you will. Anyway, this ones called OFB

So im going to go with some text right for the site I keep mentioning. Also, if not previously noted the other modes do pad blocks with additional text if they are not specific sizes. This is worth noting.

The OFB (Output FeedBack) mode of operation (Fig. 4) also enables a block encryptor to be used as a stream encryptor. It also doesn’t need padding data. In this mode, it will encrypt the IV in the first time and encrypt the per-result. Then it will use the encryption results to xor the plaintext to get ciphertext. It is different from CFB, it always encrypts the IV. It can not encrypt/decrypt the IV in parallel. Please note that we won’t decrypt the IV encryption results to decrypt data. It will not be affected by the broken block. It is safe from CPA, but it is easily susceptible to CCA and PA. A Mallory can change some bits of ciphertext to damage the plaintext.

So it encryps like ECB first, spins the data and then you have the output. There are two things mentioned in this that I would like to be aware of ‘mallory’ and ‘steam encryptor.’ I cant find a ton of info on this but I think the point being that its good to also sign the encrypted data with some form of hash to ensure a signature verification. On to the next part: Overview: Stream Ciphers vs. Block Ciphers

A stream cipher is an encryption algorithm that encrypts 1 bit or byte of plaintext at a time. It uses an infinite stream of pseudorandom bits as the key. For a stream cipher implementation to remain secure, its pseudorandom generator should be unpredictable and the key should never be reused. Stream ciphers are designed to approximate an idealized cipher, known as the One-Time Pad.

So I think the point being, timestamps are good, wait no…anyway, instead of having a block that has to be specific size it will encrypt the data one character at time. I kind of like what the PDF has to say about this one:

The OFB (Output FeedBack) mode of operation (Fig. 4) also
enables a block encryptor to be used as a stream encryptor. As
shown in Fig. 4, the difference between the CFB and OFB
mode is such that, in the case of an OFB, as an input for the
shift register from the next block, the output from the
encryptor (Encrypt) from the previous block is chosen. At the
same time, the XOR operation with the s-bits of plain text P
uses only s bits from the encryptor. Encryption and
decryption are the same operation [6]. If there is an error in a
block during the encryption, while performing the decryption,
it will influence only a part of the plain text that will result
from that block, i.e. there is a limited propagation of error [2,
3]. Therefore, this mode of operation is often used in
communication through media that carry noise (for example,
satellite communications). According to [6], the IV should be a nonce. The guidelines
given in [8] suggest that the IV should be chosen randomly
and used only once with the given encryption key K. In [7] it
is stated that security does not exist if the IV is a nonce, but
the sequence generated by some counter is acceptable. The
CFB mode of operation is vulnerable to attacks performed by
modification of bits in the encrypted stream [2].</p>

This also notes how often you can use a key before a new one should be generated but given the amount of information we are consuming I have decided to leave that out in hopes that it will not be on the test as I have seen 0 test prep questions’s about key generation.

Moving on to the next one, last one. I think. Wow, I have spent a ton of time on this but I can’t say that I am not having fun. The logical reality of the scale of this is absolutely daunting. This one is CTR

And I like the text from the ‘high go’ site the best for this one as well.

At the CTR (Counter) mode of operation, shown in Fig. 5, as an input block to the encryptor (Encrypt), i.e. as an IV, the value of a counter (Counter, Counter + 1,…, Counter + N – 1) is used. It also is a stream encryptor.The counter has the same size as the used block. As shown in Fig. 5, the XOR operation with the block of plain text is performed on the output block from the encryptor. All encryption blocks use the same encryption key. As this mode, It will not be affected by the broken block. It is very like OFB. But CTR will use the counter to be encrypted every time instead of the IV. So if you could get counter directly, you can encrypt/decrypt data in parallel. A Mallory can change some bits of ciphertext to break the plaintext. In the database encryption, we can use CBC to encrypt all the files.

So it seems like its similar to the previous one but it uses a proxy or counter to reference back to. The PDF text basically says the same thing but a little bit more complicated wording.

Anyway, that’s all for now. Wow, this took forever but I did learn a lot and I feel much better about encryption in general. However, if left with the ‘Mallory’ question and wondering about the data validation that using HMAC with AES takes care of. I am happy to realize that all but ECB use 128/192/256 key sizes which I may intermittently call ‘block sizes’ which are different, sort of. Actually, I guess I didn’t look at key sizes for the last 2 did I. Hum, maybe I could say that now. Ok, it appears to be the same. For sure going to have to go back and read this later and possibly edit some things. For now though, I have shoeshine head for sure but boy was that great haha