 In contrast to stream ciphers, we have block ciphers which encrypt messages in fixed-sized chunks, and these chunks are encrypted independently. So in fact, if you have two chunks in your plaintext which have identical content, the ciphertext for those chunks encrypted with the same key will be identical. Now, whereas a stream cipher always uses a pseudo-randomly generated key stream, this is not the case in most block ciphers. Most block ciphers are based on the techniques of substitution and transposition, although pseudo-random generation does play a role in some block ciphers, and so in some cases the distinction between block ciphers and stream ciphers can become a bit blurry. Some people try to make a distinction, falsely I think, based on just the names of stream versus block, that a stream handles the encryption byte by byte unit by unit character by character, whereas a block takes things in set chunks of like say 512 bits at a time, but I don't think that's actually a very meaningful distinction because after all, the choice of byte-sized units or character-sized units is just another arbitrary unit size for a block. So by this way of thinking, a stream cipher could just be a block cipher that uses very small blocks. For that reason, I think the more meaningful distinction is that stream ciphers use pseudo-random generation, whereas with block ciphers that may be an element of the encryption, but it's not the whole thing. Probably the three most widely used block ciphers are the three standards, first the old DES, meaning data encryption standard, which used 56-bit keys, and then the update of that triple DES, which as the name implies uses triple-sized keys, 168-bit keys, and then there's AES, which was introduced in the last decade, and uses 128, 192, or 256-bit keys. DES with its 56-bit keys, these days is really quite inadequate for reasons we'll discuss later. In short, a 56-bit key is really just too small. So a lot of institutions in the past that used DES like banks these days, most of them are using triple DES, which is significantly more secure but allows those institutions to carry on with some other old infrastructure, their old hardware and software. For anyone without any legacy concerns, you would almost certainly go with AES over triple DES. We'll discuss the details of AES in a moment, but recall that I said with a block cipher, two identical blocks in the plain text are going to come out encrypted the same when you crypto them with the same key. As you might imagine, that's really quite problematic because it leaves a huge clue to any attacker of, hey, these parts of the cipher text represent identical parts of the plain text. Much worse, you've effectively given the attacker many small independent messages that have all been encrypted with the same key, and like we said earlier, that leaves your cipher text vulnerable to cryptanalysis techniques. To correct for these faults, we only use block ciphers with what are called modes of operations. There are several of these, including five we'll look at, starting with electronic codebook or ECB, cipher block chaining or CBC, cipher feedback or CFB output feedback or OFB and counter, abbreviated as CTR. All of these, with the exception of ECB electronic codebook, allow for the secure use of a block cipher with a single key on a message longer than a single block. The strangely named electronic codebook mode is not secure because it's the mode in which we do nothing special. We just simply encrypt each block straight with the key, and that's it. So ECB in a sense is the do nothing mode. But in CBC cipher block chaining, we start off with, in addition to our random key, an additional random piece of data called an initialization vector, which is a block-sized chunk of random data. Like the key itself, the IV will be necessary for anyone to decrypt our message. The difference, though, is that initialization vectors generally don't need to be kept secret. In fact, we very often just tack it on to either the front or the end of our cipher text. In any case, the way CBC cipher block chaining works is that we start by XORing the first block of plain text with the initialization vector. That's what the circle with the cross is indicating in XOR operation. The product of that XOR is then what gets encrypted with the key for our first block. And then that first block of cipher text produced from this, that is what we use to XOR with the next block of plain text. And then that result of the XOR is what we encrypt for the second block. And again, we get a second block of cipher text. And then again, that second block of cipher text is XORed with the third block of plain text. And then that XOR of the plain text and the cipher text is what gets encrypted for the third block of cipher text. So every block of cipher text is used as an input to XOR with the next block of plain text. So effectively what happens in cipher block chaining is that our plain text is getting modified before encryption. First is modified in the first block with the IV and then each successive block is modified by the cipher text of the previous block. Effectively then, blocks of our plain text which are identical don't get encrypted as identical. They first get XORed with the preceding cipher text. Now note that in cipher block chaining, encryption of each block depends upon first having encrypted the previous block. So the encryption has to be done sequentially. The same is not true when decrypting cipher block chaining. The inverse of what we did when we encrypted is to first decrypt the individual block of cipher text and what we decrypt then simply has to be XORed with the preceding block of cipher text to get out the block of plain text with the special case of the first block where we XORed with the initialization vector. So actually note with cipher block chaining if you lose your initialization vector or for some reason it gets scrambled or whatever you can still decrypt your message except for that first block. In the CFB mode, cipher feedback mode we again use initialization vector so this time we actually start off by just encrypting the initialization vector itself. The result of that then we XOR with our plain text to get our first block of cipher text and then it's actually that first block of cipher text which we encrypt in our second block and then the result of that we XOR with the second block of plain text to get our second block of cipher text. And then again we take that second block of cipher text, encrypt it, XOR it with the third block of plain text to get our third block of cipher text. So very strangely here in this mode we're not actually running our plain text through the block cipher but of course what will come out of the block cipher will have high entropy, it will be very random. So just like in a one-time pad or stream cipher where we have our random data which we XOR with our plain text to get our cipher text we're kind of doing the same thing in this mode. The block cipher in this mode is sort of being used as a pseudo-random number generator which is one reason I said that the line between block ciphers and stream ciphers isn't always stringently defined. Now to reverse this process to decrypt we get each block of plain text by taking the cipher text of the previous block and actually encrypting it, not decrypting it, encrypting it and then XORing that with the cipher text for that block. So for example to get our last block of plain text we take the previous block of cipher text, encrypt that and XOR that with our last block of cipher text. And note of course the special case of our first block where we don't encrypt with the previous block because there is no previous block we encrypt the initialization vector and that is what we XOR against the first block of cipher text to get the first block of plain text. So the cipher feedback mode has the fairly cool property of using just an encryption cipher without any corresponding decryption cipher and again like in cipher block chaining whereas encryption must be done sequentially decryption can be done in parallel you can do each block independently because decryption of each block only requires the cipher text of the previous block which we already have because we're decrypting rather than encrypting. When we encrypt we also need the previous block of cipher text but of course we don't have the previous block of cipher text until that block itself has been encrypted so the encryption must be done sequentially. One last small advantage of cipher feedback over cipher block chaining is that because we're not actually running our plain text through the block cipher we're just using the block cipher to generate pseudo random data to XOR against our plain text what this means is that we don't have to pad out our last block with cipher block chaining if our data isn't evenly divisible by the block size then that last block has to be padded out and so that requires some scheme of denoting in our cipher text how long the plain text actually is and how much is just padding with CBC with cipher block chaining our cipher text can be precisely as long as our plain text we don't have to pad it out. The output feedback mode is very similar to the cipher feedback mode with the one difference that what we use as input to the block cipher is not the preceding block of cipher text but the preceding output from the block cipher hence the name of output feedback rather than cipher feedback understand that cipher is sometimes confusingly used as a synonym for cipher text so in cipher feedback cipher refers to the cipher text anyway the basic principle here is the same we're effectively generating a pseudo random stream of data which we are then x-oriented against our plain text to produce our blocks of cipher text the advantage of output feedback though is that we can actually generate that entire pseudo random stream before we even involve the plain text at all this means we can actually do the bulk of the work ahead of time before we even have a plain text we can just randomly pick keys and initialization vectors and generate a whole bunch of pseudo random data to use later on and that's extremely helpful performance wise in certain scenarios like say for a bank that has to do lots of encryption all the time with the output feedback mode the hard work of the encryption can be offloaded to one part of the system that just churns out key streams all day and when another part of the system actually needs to do some encryption it can just grab one of those key streams and do its encryption simply with an XOR and note again that in this mode and in the cipher feedback mode the distinction between a stream cipher and a block cipher becomes extremely blurry and last thing about output feedback is it has a nice advantage that the decryption process is precisely the same as the encryption process we just swap in the cipher text in place of the plain text the counter or CTR mode is another stream like mode of operation this time though the initialization vector for fairly obscure reasons of technical terminology is generally not called the IV it's called the knots yet it's the same idea it's a random block sized piece of data and just like an output feedback and cipher feedback our goal here is to generate a pseudorandom key stream based upon this random input and our key and as usual we get our first block of the key stream by simply running it through the block cipher to get our successive blocks of the key stream though this time in counter mode we simply modify the knots according to some simple function most commonly a function that simply increments the knots against the name counter now for some time there was some concern about this counter mode that using a simple function like just incrementing our knots would make our key stream too predictable these days however it's generally accepted because it's recognized that the true randomness of the key stream should be provided by the block cipher and any good block cipher should have radically different output when you make just a small change in the input which is what happens when we increment our knots so here for example when our knots starts in hex c59bcf35 something something something and then ends in a zero the output of that run through our block cipher should be totally unrelated to what we get when we run c59bc535 something something something 1 through the same block cipher with the same key if that's not the case then that's a weakness of the block cipher itself and we have deeper problems than a problem with our mode of operation so a simple incrementing function is most commonly used in this mode though alternatively you can use any function as long as that function produces output that doesn't repeat or at least doesn't repeat for a very long time the goal here of course is that the input to the cipher in each block is unique so there's no two blocks that get the same input to the cipher note that the counter mode shares with output feedback the property that the key stream can be generated entirely ahead of time but note that it also has the advantage that the key stream can be generated in parallel it doesn't have to be generated in sequence so now looking at an actual block cipher itself AES the advanced encryption standard as I mentioned is today's predominantly used symmetric encryption algorithm however the algorithm itself and the standard is actually called which is a portmanteau a word combination of the names of the two creators of the algorithm two Belgians Joan Damon and Vincent Reiman I believe that's how it's pronounced R-I-J-M-E-N this Rijendal algorithm was actually selected in a contest there was a years long selection process in which several candidates were scrutinized and in the end Rijendal is the one that was selected in 2001 and it was selected not just for the integrity of its encryption but also partly because it offers pretty good performance which is fairly important in an encryption standard particularly for high volume use cases like say what a bank does you want the encryption and decryption to take as little time and computing resources as possible while the Rijendal algorithm itself will allow for block sizes and key sizes of 128 up to 256 in increments of 32 so 128, 160, 192, 224 and 256 those are all valid block and key sizes in the AAS specification the blocks are always 128 bit and the key is a choice of 128, 192 and 256 bits now of course the size of the key determines how many possible keys there are given the size of 128 bits that means that there are two to the 128th power possible keys which is a hell of a lot and then likewise a key size of 192 bits gets you 2 to the 192nd power number of possible keys and 256 bits gets you 2 to the 256th power possible keys and those of course are even more fantastically astronomical numbers now given today's existing computers it is presumed that 128 bits is actually perfectly adequate it is not really foreseen that even if we see the same kind of performance increases in computers in the next say 30, 40 years that we've seen in the past 30, 40 years it's not foreseen that enough computing power will be there to do a brute force attack on Rijendal encryption using 128 bits because 2 to the 128th is really just a hell of a lot of possibilities so if an attacker wants to brute force their way to find your key that is by just going through all possibilities until they hit the right key they just aren't today computers fast enough to really do that in a practical amount of time practical here meaning within a person's lifetime on the other hand there may be some disruptive developments in computer technology coming down the line namely what are called quantum computers if quantum computers become a reality then there are algorithms which would cut down the effective key size in half so something encrypted with 128 bit key would be as susceptible to brute force attack as a 64 bit key so this is the main reason why the standard also allows for 192 bit keys and 256 bit keys if you're dealing in highly sensitive data like say military secrets you probably don't want those secrets decrypted even a few decades from now if quantum computing becomes a reality for less sensitive usage just say like for personal usage or consumer usage 128 bit keys are generally considered perfectly fine it's just a fact that most stuff most people encrypt isn't really all that important for an attacker to keep around for decades on the off chance that one day they'll be able to with great effort decrypt it in any case the way original works both when encrypting and decrypting is to first take the key and from it by a series of computations produce what's called the key schedule this key schedule is effectively really just a longer key it's taking the short key and producing from it a longer key including portions which will be used like a substitution table so once we have this key schedule the actual encryption and decryption is done in a series of rounds for 128 bit keys there are 10 rounds for 192 there are 12 and for 256 bit keys there are 14 in each round we are taking the input and transforming it in a series of operations just like we saw in the simpler ciphers where we used substitution, transposition and also combination with a key usually with an XOR operation in risen doll in each round we use one or more of these four operations which we call sub bytes, shift rows, mix columns and add round key described briefly in the sub bytes operation we are doing a substitution of each byte with another in a lookup table a lookup table which is a part of the key schedule the shift rows operation is a transposition operation where we take rows of the state the state here referring to the current state of the bytes of our data we take each row and we shift them cyclically a certain number of steps which is specified by the key schedule in the mix columns operation a different kind of transposition is formed one using what's called a linear transformation and I won't go into the details and then finally in the add round key operation each byte of the state is combined with the so-called round key which is a part of the key schedule using a bitwise XOR just like in stream ciphers or in a one-time pad now whether we have 10, 12 or 14 rounds to perform based on the size of the key in the first round we have five operations first add round key then sub bytes and shift rows then mix columns and then one more add round key in all subsequent rounds we drop that first add round key operation just doing the sub bytes shift rows, mix columns and add round key operation except then in the last round we also drop that mix columns operation and tack on an additional sub bytes shift rows and add round key operation so the basic principle here again is that if a little bit of substitution and transposition is good well to get even more security to get even more parent randomness do a lot of substitution and transposition and mix them up in different orders now why it's better to do these operations in this particular order is a matter of mathematical analysis the real trick in designing encryption algorithms is generally not so much in coming up with some combination of the basic techniques like substitution and transposition but rather the difficulty isn't improving that the particular substitutions and transpositions and XORing that you're doing is actually effective that it is actually increasing the randomness of the output rather than doing no good or possibly even being counterproductive it's actually quite possible to do additional operations of transposition and substitution that actually detract from the strength of your encryption so that's a good reason why you don't try and roll your own encryption algorithm creating an algorithm isn't hard but creating one that stands up to real scrutiny definitely is