More. Mike. Pound.

I like how Dr. Pound says “woight” after explaining something.

“ECB, almost never” unless you’re Zoom...

6:44 "If I'm watching a streaming movie, and I've decided the first half is pretty boring, I want to jump through, so you can't do that because you got to chug through the decryption of everything first" - Actually, while *encryption* of CBC is serial, *decryption* of CBC can be parallelized, you don't need any previously plaintext data, just the ciphertext. 8:57 "And we don't want that weird attack where you fiddle about with ciphertext and it effects other message blocks". Counter mode (without a MAC) is even more attackable by fiddling with the cipher text. For CBC, you get one plaintext block modified (bit-flipped) exactly as you wish, and one block garbled, for CTR (as explained in 11:40) you just get all your bits flipped around (just as for any XOR stream cipher), without anything else affected - so it's a an a lot less noticeable attack. So this is not really an argument for counter mode. If you use a MAC (on the ciphertext) with CBC, it's also pretty save against those attacks. (The other arguments for counter mode are better.)

Excellent presentation - Mike always does a great job of explaining his ideas!!

Mike does such a clear and great job explaining cryptographic definitons! I always enjoy the videos of this field!

Nice, I'd love a video with more detail about how this Galois counter mode works, as well as detail about the other AES modes like CFB and OFB.

Writing a university exam about encryption on Monday. This is the perfect for a video like this 👍

Next video on Galois Fields lets go!

In the first f****** minute I learned more of encryption than in hours of lessons at the uni. Thank you Mike, you make it easy for learnes to understand the topics and what it's all about!

I've been working on this today with my RCSOTP (random character set one time pad) program. Then I came on YT and saw this vid !!!! Nice one, good vid, all helps.

exactly what i need for my course on network security! great as always

Liked the video, and I'm looking forward to hearing about the GCM mode of operation next time. Are you going to continue after that with AEAD ciphers?

Please make an extra bits or so on GCM and how it works/ benefits :) Awesome video!

Ah, so it's the counter mode that LoRaWAN uses. I've implemented that protocol myself before. It uses some ECB code to do it. And at the time I was reading up on it what the different modes meant. I was a bit confused why LoRaWAN, generally considered a secure protocol, would use ECB. Then I found out what it was actually doing and thought it was quite smart. Today I've learnt that it actually has a name! Cool :D

I spent a whole day reading my textbook and listening to my professor's video lecture yesterday and couldn't understand what the heck were the functions of the modes because it was all given to me without diagrams. After watching this video, it makes it simpler for me to understand! Holy smokes!

Great video! Esecially considering that it's relevant for my next exam. Also, I'd like to request a playlist for these cryptology videos as I can't seem to find an existing one.

Amazing video! i understand absolutely nothing but your videos have been helping me to sleep since when i get confused, my brain is disoriented and everything seems impossible to do so i am able to do nothing but sleep.

WOW! thanks for the simplified explanations, makes it easy to understand.

For the counter mode once you have your keys this is running exactly like one-pad. The key size is the same as the entire message steam. But you are generating key material on the go.

Ok, that nonce thing caught me off guard cos that's not what it means in British slang...

Fantastic explanations, thank you!

Quote from Github: "I've paid absolutely no attention to safe memory use, cache timings etc. So it's conceivable that the cipher is vulnerable while it's running - possibly after too since it doesn't wipe the key from memory." Python has design issues that makes it hard to stamp those out anyway, though it's feasible to mend _some_ of those problems. In the end, the question remains: Can you trust the hardware your code is running on, and is it sufficient that some parts of the code is still visible to that hardware, or to its operating system. If those things do not pose a problem for you, then cryptography with Python is probably ok for _your_ use case. That isn't to say that it should ever be implemented in a bigger corporation, or on hardware that is exposed to the public.

Can you do a video on how key schedulers work?

Why in CBC can't you continue decrypting from the middle? You just take Cn+1 decrypt it and XOR it with Cn. Was there some simplification in the video?

As far as i understood, the decryption is parallelizable in CBC, as well as random read access. 6:45 Correct me if im wrong

Note that rolling your own code to do this is almost always a bad idea. With Galois/Counter mode the additional complexity of operating in a finite field (GF(2^128) is usually used, with a 128th-degree irreducible polynomial over that field) means that the scope for errors to creep into your code is much bigger. You're much better-off using an open source library (these can be written to make use of some new hardware CPU instruction codes specifically intended to do multiplications over finite fields).

speaking of modes of operation MMC has two operating modes: author mode and user mode. In author mode, you can create and modify a console's design by adding or removing snap-ins and setting console options. In user mode, the console design is frozen, and you cannot change it.

One important detail that I missed in the video is that for CBC mode you need to include the IV (initialization vector) in the ciphertext. The same goes for the nonce in CTR/GCM mode; it has to be transmitted to the receiver so they can actually encrypt the message. You can just send it as plaintext, though.

As always - brilliant explanation ;)

Perfect explanation

The thing is AES CTR is AES ECB but used in a different way like you encrypt NONCE (32bits) + IV (64bits) + COUNTER (32bits) and you then XOR each block of 128bits and then increment COUNTER after each block. So ECB is CTR but used a different way. But yeah I agree that there is no way to detect any bits being changed, unless you use something like HMAC-SHA etc, but that increases your data size.

I am studying for the SSCP exam I am taking in a week from now. I took Security+ and passed, but I am always confused by the block cipher modes. This video helps alot because you really explained it well while putting it into examples on paper for me. Still....while being fascinated by encryption and all the nuances of it, I am just not able to really get it because I haven't worked a day in the field. What would you say I should do to help me expand my knowledge of encryption in a way that I can actually get in real world experience? I want to eventually get a job in cybersecurity and have working knowledge and skills of doing this stuff on my own. I am in college and trying to get off of disability to return to working status. Cybersecurity is the field I have chosen to get in to when I hopefully get back to being able to work again. I am at a huge disadvantage because I haven't been able to work in the IT field for years, so I need to get practice in at home. Thanks in advance.

Watching this videos the question does not leave me alone: is it usual practice of all computer science faculties to use line printers paper for explaining ideas. When I was a student here in Moscow our professor who taught programming course did just the same. And I've been wonder if there is lack of usual A4 paper in our University or there is excess of line printer paper here.

I analyzed software serial numbers "protected" by AES-256 ECB. I think it took less than 15 Minutes to find the original 128-bit key. This was on a PowerPC 750 processor (Mac OS X 10.2), IIRC. Fun times. 😉

6:44 Wait, I think CBC _decryption_ is both parallelizeable and random-access. Just decrypt the current block, and XOR it with the previous one.

Great explanation! Thank you

i have a question about the counter mode encryption. if the nonce+counter is not private, only single use, that means it is theoretically known to the attacker. if we also assume that the method of encryption is known to the attacker because security through obscurity is foolish, then what prevents the attacker from encrypting the nonce+counter themselves and xor'ing this key with the cyphertext to crack the message? surely the encryption system must be asymmetrical (ie rsa) to ensure that only those with a private key can encrypt. am i correct?

So in counter mode, if i don't even need a decryption method, couldn't I just use a a hash function to create the block key from the counter and key? What's the problem with that idea?

So engaging - Thank you!

I love this man

13:47 With an IV of 96 bits, you can encrypt at least 2^96 blocks of information before you need to change your key (More if your messages are longer), which is much more than any data center can contain. The limit that the IV puts of the amount of messages you can encrypt with one key is thus purely theoretical, and other limits are reached much quicker, like the recommendation to only encrypt 4 GiB with one key.

How do you transfer the key or iv or whatever securely when they can't yet open the encryption?

Is the initial vector similar to a salt that you'd use with a hash before you put it through a hashing algorithm?

Cipher block chaining has the weakness that you can manipulate individual bits in a controlled manner. So you switch to counter mode, which has this weakness on steroids. It seems more effective to use Electronic Codebook, but make a trivial modification to input blocks to make repeats less likely. Instead of encrypting the counter, XOR the plaintext with the counter before encrypting.

What about just prepending each message with a simple salt header of unknown size? e.g. message is length 120-127 bytes in length, gets pre-pended with a header that's first byte is a 4 bit header length value, 4 bit random, and then 1-7 bytes of random data. That means all encrypted messages are dissimilar, and can be decrypted independently.

Using counting mode doesn't require implementing decryption at the cipher level. It made me think that using this techinique we can implement a symetric encryption algorithm using a secure hash function such as SHA256 or SHA512 and using the counter initializer as the key. It would work like this: - Apply a random salt to the user supplied password and take the hash of the result (save the salt); - Use this hash as the counter's initial value and increment it for each block; - Take the hash of the counter for each block; - XOR the input message with the resulted hash of each block. My question is: Is this secure?

This is a really great video. Can I suggest that someone puts a request in to change the moniker ‘nonce’....... how has no one noticed this before?!

But where does mike get those jumpers from?

Why not XOR the counter before encryption? It would no longer be vulnerable to bit flip attacks, and would have all the positives, am I wrong?

Amazing video!

12:32 so with counter mode you don't even need to stick to reversible encryption and could use irreversible methods e.g. hashing as well?

Could you explain zero cleare malware and how it works?

I have the exact same arm-armpit tic as Dr. Pound, and each time I watch one of his videos I have to do my best not to inadvertently imitate him 🤣

Helloooo anyone gonna mention that we just got delivered the first 4K Computerphile video ? today can't be a bad day not matter what.

I found a method for remembering less passwords : if you can remember n strings, you can create n - 1 + n - 2 + ... + 1 passwords by combining a diferent pair of strings for each passwords. for exemple if you can remember 4 strings, you have 6 passwords : s0 = cat s1 = dog s2 = tortoise s3 = fly p0 = catdog p1 = cattortoise p2 = catfly p3 = dogtortoise p4 = dogfly p5 = tortoisefly (dont use those strings but you get the idea) and if you have 5 strings, you have 10 passwords, 6 = 15, 7 = 21, 8 = 28, 9 = 37... Each password either countains half of the infomation of half of the other passwords or no information. It is also possible to use a combination of more than tow strings to create more passwords with the same amount of strings. What do you thin about that ?

At 06:44 (the example with a movie encrypted with CBC) it is stated that one cannot easily jump through the movie, because one needs to decrypt all predecessing blocks. This is incorrect. With CBC, encryption indeed cannot be parallelized, however, decryption can be parallelized very easily. One always needs only two succeeding blocks of ciphertext to get the plaintext of the second block (just decrypt the second block and xor it with the still encrypted first one).

So in counter mode. Is there even a reason to use AES? We are not decrypting at all, can't we just do something with the nounce and key and put it to SHA256? I'm assuming SHA256 is faster and even harder to recover the key

Great video!

There is another problem with counter mode based operations and that's the maximum message size. The counter will flip at some point

6:43 Isn't CBC decryption of a block possible with just ciphertext from the previous block (and encryption key ofc)? In that's the case, why can you jump to the middle of that movie without decrypting everything in between?

Mike looks so serious on this thumbnail

Where is the camera that it looking over his shoulder? I feel like i should be able to see it :)

I am confused why the CBC mode can't be parallelized during decryption?

In counter mode why is the xor done after encrypting the counter and not before?

Would be awesome to know what how random in a computer actually works. Can it be broken?

I still don't understand the last part, if the nonce is not secret can't it be used by an attacker since the encryption algorithm is also known?

11:45 But doesn't CBC and ECB also need message authentication? And obviously CTR needs to produces a lot more authentication tags than CBC.

Why do we even need something like AES for counter mode? Couldn't we just have the nonce be the key and use some hash function for the "encryption"?

Please tell us about XTS mode.

My question is how does the receiver know what the nonce is... They will need to know in order to xor it with the block.

Link to the Feistel Cipher video ukposts.info/have/v-deo/fneZnml6fq6dmX0.html

fantastic

quite helpful!

Not gonna lie, I was hoping from the title this was gonna be about the work of Larry Tesler. (I missed the previous video so the context was unknown to me.)

I literally just received a mail saying computerphile just uploaded a video with title "Modes of Operation", I definitely knew it is by Dr. Mike Pound and here I am.

Just dont really understand how the nonce is echanged/syncronized between the parts.

ECB, CBC, CTR, GCM Next level: CBT

Nonce vs block counter could have been a little bit better explained. You mention it very briefly but then example isn’t great. As nonce typically is e.g. 1,2,3,4... the block encrypted must not be nonce, nonce+1, nonce+2 etc because you’d have counter-reuse immediately, breaking counter mode. But eh, it gets a bit dirtier writing e.g. (nonce, 001), (nonce, 002) etc I suppose.

i got questions ,lets assume i've completed python course and made few projects. but others skills do u need in a working environment and what are the best resources to learn those because i never apply for job m afraid if i got job but not ready for it the fear come i learned English at the age 19 after whole new world opened up but m i think m really late to the game

Block 45 Rotation?

What if you just append random salt to every block and discard it after decryption?

How can I use public-key cryptography to verify my identity if I happen to lose one of my online accounts (say twitter)?

Has anybody ever figured out exactly what paper is used on Computerphile?

So GCM once again breaks the seek-ability of CRT :v Because you need the entire message to authenticate, not just arbitrary blocks from the middle?

Mike Pound is cipher-daddy

For a split second I seem to grasp something... but then its gone

More image processing stuff, like sharpening or such

9:04 Hoo-ray!

When the IV isn't a secret anyway, why exactly does it have to be random?

I'm waiting for the GCM video

Be careful is nonce1 = nonce2 + x where x less than the number of total blocks

Mike "The only professor who chose C#" Pound

Someone knight this man

Since we don't need to decrypt, would it be safe if I was to use an hash function instead of an encryption function in conjunction with counter mode? The key would be a string to be concatenated to the nounce and then fed to the hash function

Again pls

Not Mike ~0.45 kg?

Good god he is a god

1:35 Gotta admit I'm a little sad you didn't use 16 characters per line :)

Didn't know that Frodo Baggins was such an expert in cryptography...