More. Mike. Pound.

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

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

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

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.)

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

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!

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 👍

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!

Next video on Galois Fields lets go!

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.

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?

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

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

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

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

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

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.

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.

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.

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.

Fantastic explanations, 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?

As always - brilliant explanation ;)

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.

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).

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

Can you do a video on how key schedulers work?

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.

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

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?

So engaging - Thank you!

But where does mike get those jumpers from?

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. 😉

Great explanation! Thank you

Amazing video!

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.

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.

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

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?

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

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.

Great video!

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

Perfect explanation

I love this man

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?

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 🤣

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?

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.

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

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.

Please tell us about XTS mode.

Could you explain zero cleare malware and how it works?

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?

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.

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?

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

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 ?

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 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.

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.

Mike looks so serious on this thumbnail

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

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).

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?!

quite helpful!

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.

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.

fantastic

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

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

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

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

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"?

Link to the Feistel Cipher video kzfaq.info/get/bejne/fK2YnZZ0rN7QaH0.html

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

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.)

Block 45 Rotation?

Mike Pound is cipher-daddy

ECB, CBC, CTR, GCM Next level: CBT

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

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

I'm waiting for the GCM video

9:04 Hoo-ray!

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?

More image processing stuff, like sharpening or such

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

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.

Good god he is a god

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

Someone knight this man

Mike "The only professor who chose C#" Pound

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

Again pls

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

Slowing the speed to .75 is extremely helpful

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