Lecture 10: Multiple Encryption and Brute-Force Attacks by Christof Paar

[brod]

I think It's important to point out that the reason The Meet-In-The-Middle attack works efficiently is because we are assuming that searching the table is O(1) complexity or at most O(log(n))

[neiloza]

I feel like I've learned so much so quickly watching your lectures. Thank you

[eliatkinson]

Another brilliant explanation, feel like Im finally getting this, thanks Professor!

[amitk]

I think it's important to mention that double encryption breaks down specifically against known plaintext attacks. I haven't noticed that it was mentioned where "x1" comes from. You only have it if  you have a known plaintext-ciphertext pair ...

[yahuiz]

Thank you Professor! This is the type of lecture values outstand than reading the textbook by myself!!

[pervanadurdyeva]

I am waiting video lectures from other lessons.Thank you dear Cristof Paar for your free of charge lectures.

[Sakshamlal-gkil]

bro's german is very understandable, but huge respect sir, super, Es hat mir viel Spaß gemacht, aber der Vortrag ist okay

[buddhamanify]

These videos are very well done and refreshing....from las vegas

[beckychiang]

Hats off, Prof Paar! Excellent lectures.

[BrunoVernay]

Excellent point just 1 min before the end, about block cipher, being used as a stream cipher ! So obvious ... once you said it.

[mr.shanegao]

Double encrption 2:00
Triple encrption 44:00
Brute force attacks 58:30

[dog_with_a_tail]

42:00 The better way to store would be a hashmap, where the look up is O(1), which still takes some time, but is nowhere near O(logn) of such a big table

[Richard.Andersson]

It is worth noting that the formula in the end to calculate expected number of keys that will be false positives is not correct. It is just a simplified approximation that only works when you have a large discrepancy between the value of H and the sum of t*n.
For example if you assume t = 1, H = 64 and t = 64 you get a result of 1, which is obviously incorrect as the probability of having a false positive should be about 0.64. You get correct values in that case by using the formula: 1-(1-2^-n)^(2^H-1), note that you need a calculator with variable precision arithmetic to handle the huge exponents and the high precisions in the intermediate steps.

[nikolailoboda]

Search in hashtable is not log(n) it's 1.does not matter whether it RAM/HDD/Punch cards . The worst part is that mr. Paar does not seem to be confused by the fact that in his lecture n*log(n)=2n.

Long explanation:
let's fill our hdd of size 2^64 sectors, so that each sector contain a pointer(an offset) to another sector containing key, that was used for encryption followed by pointer to a next key in case of collision or 0 otherwise. Write complexity is o(1) at best, o(n) at worst (if your cypher gives you same value disregard of the key that suck) so it's o(1). reading is the same. if you've cyphertext you can find correct sector and it's also o(1).
Using 2^64 instead of 2^56 space is not nice, but there are more elaborate workarounds for this I'm too lazy to describe here.

[hamdidjeridane]

so in 18:00, given we have K possible X1 predictable plaintext values (since we use files headers for example and they are somehow limited), So we don't actually need to perform this every time for every attack attempt right ? we can accelerate the attack by calculating them beforehand and make standalone look-up tables and whenever the attacker intercepts a ciphertext Y1 they can just find collisions. Or am I missing something ?

[mayankpratapsingh]

Hello sir, I have a question which may be stupid. Suppose Oscar tries all 2^56 keys on the cipher text . And for every key he will get some plain text . How will he know the actual plain text ?

[dr-Jonas-Birch]

Is it still possible to take your course at uni? JB

[nathansherrard]

Prof. Paar, wonderful lectures to date (even though I don't speak German, ha)

One nitpick question - in your Theorem 5.2.1, which describes the expected # of false keys, should there be an extra "minus 1" at the end, to account for the one true positive key?

Or to ask with an example, if in AES we have both an input block size of 128 bits, and a key length of 128 bits, and one PT/CT pair, do we on average expect 2^(128-1*128) = 2^0 = 1 false positives, or NO (2^0 - 1) false positives?

Thanks!

[arkmidis]

Came here for learning about 3DES, stayed for learning German :)

[ceyhunugur]

In the triple des, you can also do the meet in the middle attack because we know all the intermediate values. So using intermediate values first we can try to find first two keys, when we find them then we can pass to find the third key. Can we do that? Is my question clear?