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))
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 ...
+Amit K he mentioned that in a few lectures back...he said that in modern transmissions of data..the first few bytes of data are known because of the protocols and type of messages that are handled in this data communication protocols.
I was just thinking this when I was watching the video. He doesn't mention that this requires at least one know plaintext, cipher text to break the keys.
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
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.
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 ?
Excellent thought. Such approaches are actually used in practice. A limiting factor, though, is that the pre-computed table only works if we know the plaintext x1 that is used by "Alice". That might be the case if file headers or protocol headers are used in the begining of the encryption.
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.
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 ?
Good question. For a brute-force attack, the attacker has to know at least one block of plaintext for checking whether the key is the correct one. regards, christof
@@introductiontocryptography4223 I have actually 2 questions. How can he compute enc(p) for all possible keys not knowing the plaintext? And in RSA, why are there multiple private keys d, one is the general one and the other are ciphertext dependant and have the form of d(the real one) + n*p , where n is a positive integer ( not tested which are possible ) and p is a number - some periodicity of the keys. At the end I would like to thank you for these amazing lectures. I am a high school student getting into crypto ctfs and these lectures are very clear ( super easy to understand everything, watching on 2* speed ).
Question 1: If you do an exhaustive key search (aka brute-force attack), you also have to know a SHORT piece of the plaintext. In practice, that is often the format information at the beginning of an encrypted file or an email. If you now run a key test, you can always check whether you recover the correct plaintext. Question 2: What you describe is a variant of RSA. In "schoolbook RSA", you only have one private key d. enjoy learning crypto, christof
I was searching for the same question. Now clear. Thanks a lot for your lectures. I will just say that you are the best teacher I have ever found in my whole life. Thank you so much
Great explanation. I get the point of the critique of double encryption. However, I wouldn't say it is only "marginally" more secure than DES. Not only does the attacker have to perform 2^57 encrypt/decrypt steps and to obtain something like an exabyte (million terabytes) of storage, he also has to perform 2^56 lookups on a table that takes an exabyte of storage. The NSA and several other intelligence agencies certainly could do that, even Google could probably do that, but it seems like would be prohibitive to any but the most well-funded of evil entities. I suppose I think like an ordinary engineer rather than a cryptographic computer scientist when thinking about "marginal" improvements.
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?
If the problem with DES is that takes a key which is too short in length, is there a way to effectively scale DES like using the same network and principles but with more rounds, more s-boxes etc. so it can be fed a larger key?
Excellent question. I think I forgot to mention this explicitly in the lecture: We assume that the attacker knows x1. Later on it also becomes clear that he sometimes also needs to know x2 and x3. In practice this is often the case since header information (e.g., header of a file or protocol) are encrypted and the attacker knows those data.
Actually, "naïve" isn't really an English word. I think it was actually a French word that was just adopted into the language--similarly to "déjà vu," "cliché," and "fiancé."
1:19:50 i think you made a mistake ?? you said we have 2^16 CANDIDATE keys -> its false : the probabilty having a false key is 2^-48 on the 2^16 extra keys ( the average number of extra right keys is the numbrer of overhead keys * probability having the right ciphertext with one key ( assume equiprobable) = 2^16*(1/2^64) = 2^-48). then if you are not lucky you can used a second pair pt/ct. thanks again i like your lectures.
I'm not really sold on the idea that storing 1.08 exabytes of intermediate ciphertext and keys is at all reasonable for an attack, but I suppose it isn't impossible.
so the zr value is the plain text value you get after trying to match your yi against a second set of keys untill you find a corresponding set of cipher text from phase 1 of the attack?
I think if u mean ZR so u hit the right hand side of the table and I mean the right keys ,Finally If u get Zr and Zl , U get Kr and Kl . These keys are just keys ,I think the next step is to find out the plain text by matching the the R & L keys from the table
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!
In DES decryption, we use k(16) of encryption in the first round of decryption. When we encrypt the plain-text twice using the same key, how are we getting the plain-text? Won't we be using k(1) in round 1 of second encryption?
+simran aggarwal Yes, with double encryption with the same key you use k1 both times in the 1st round. In order to decrypt such a message, you need to have ro run DES decryption TWICE. In both decryption operations you use k16 in the first round. BTW, note that double enryption with the same key does not give you much additional security. If using DES, one should rund 3DES with 2 or 3 different keys. Regards, christof
Hello Professor, I have one question in this lecture. For double and triple encryption, meet in the middle attack, phase 1 is to encrypt X1 for all possible keys. But how does an attacker know whats X1?
Good question. I should have written the following on the black board explicitly: For brute-force attacks (and MITM is a brute-force attack) we always assume that the attacker knows at least one block of plaintext, i.e., he knows X1. As we see later in the lecture, sometimes he needs to know X1 and X2, or X1 and X2 and X3. In practice, that's often not so complicated, e.g., if files with known headers are encrypted. Please note that the block sizes are quite small. For DES, one block has only 8 bytes/characters (= 64 bits), and even for AES it is only 16 bytes/characters. Headers of files or protocols are almost always much longer. cheers, christof
No, that would require you to have an hash table that is a data structure supported by RAM usually. What you refer to, is a database. They have search mechanisms, mostly rely on b-trees or more complex data structures.
would somone please care to explain this to me: I do not understand how when the attacker tries to bread double DES how does he tell if he hit the correct keys. suppose the attacker tries a bunch of keys of the left store it in a table then tries the keys on the right there is a match from what he tried on the right side to what is found on the left side ( as mentioned...) might that just mean that the attacker just has attempted the same key twice how does that let him know he hit the correct key?
Why would using the same key twice give you a match when encrypting plaintext X to Z and decrypting ciphertext Y to Z? There is no reason for this to happen. X and Y aren't related by a single layer of DES, but with two layers.
Christof, your English is very good! With this naïve thing and so forth. But please, if you don't want to pronounce the "th" correctly, use "t"- and "d"-sounds. Like 'this' -> 'dis' and 'thing -> 'ting'. Because the word 'sink' has its own meaning... Besides, I love you, mr Paar, and the way you gives the material.
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))
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 ...
+Amit K he mentioned that in a few lectures back...he said that in modern transmissions of data..the first few bytes of data are known because of the protocols and type of messages that are handled in this data communication protocols.
Specifically x1 is header information
I was just thinking about that when he was explaining it. It just didnt seem like a complete explanation and now I know the missing part.
I was just thinking this when I was watching the video. He doesn't mention that this requires at least one know plaintext, cipher text to break the keys.
I feel like I've learned so much so quickly watching your lectures. Thank you
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
Another brilliant explanation, feel like Im finally getting this, thanks Professor!
Double encrption 2:00
Triple encrption 44:00
Brute force attacks 58:30
bro's german is very understandable , but huge respect sir , super , Es hat mir viel Spaß gemacht, aber der Vortrag ist okay
Thank you Professor! This is the type of lecture values outstand than reading the textbook by myself!!
I am waiting video lectures from other lessons.Thank you dear Cristof Paar for your free of charge lectures.
Hats off, Prof Paar! Excellent lectures.
These videos are very well done and refreshing....from las vegas
Excellent point just 1 min before the end, about block cipher, being used as a stream cipher ! So obvious ... once you said it.
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.
Came here for learning about 3DES, stayed for learning German :)
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 ?
Excellent thought. Such approaches are actually used in practice. A limiting factor, though, is that the pre-computed table only works if we know the plaintext x1 that is used by "Alice". That might be the case if file headers or protocol headers are used in the begining of the encryption.
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.
Note that the number of phase II 2E56 - 1 because you cannot use the key that was used to encrypt oherwise the X1 would be equal to Y1.
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 ?
Good question. For a brute-force attack, the attacker has to know at least one block of plaintext for checking whether the key is the correct one. regards, christof
@@introductiontocryptography4223 I have actually 2 questions. How can he compute enc(p) for all possible keys not knowing the plaintext? And in RSA, why are there multiple private keys d, one is the general one and the other are ciphertext dependant and have the form of d(the real one) + n*p , where n is a positive integer ( not tested which are possible ) and p is a number - some periodicity of the keys. At the end I would like to thank you for these amazing lectures. I am a high school student getting into crypto ctfs and these lectures are very clear ( super easy to understand everything, watching on 2* speed ).
Question 1: If you do an exhaustive key search (aka brute-force attack), you also have to know a SHORT piece of the plaintext. In practice, that is often the format information at the beginning of an encrypted file or an email. If you now run a key test, you can always check whether you recover the correct plaintext.
Question 2: What you describe is a variant of RSA. In "schoolbook RSA", you only have one private key d.
enjoy learning crypto, christof
I was searching for the same question. Now clear. Thanks a lot for your lectures. I will just say that you are the best teacher I have ever found in my whole life. Thank you so much
Great explanation. I get the point of the critique of double encryption. However, I wouldn't say it is only "marginally" more secure than DES. Not only does the attacker have to perform 2^57 encrypt/decrypt steps and to obtain something like an exabyte (million terabytes) of storage, he also has to perform 2^56 lookups on a table that takes an exabyte of storage. The NSA and several other intelligence agencies certainly could do that, even Google could probably do that, but it seems like would be prohibitive to any but the most well-funded of evil entities.
I suppose I think like an ordinary engineer rather than a cryptographic computer scientist when thinking about "marginal" improvements.
You are the best teacher. Thank you :D
I think we need to have a serious discussion about watching youtube Prof Paar
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?
Double Enc Attack we are talking about exabytes of storage which is A LOT!
If the problem with DES is that takes a key which is too short in length, is there a way to effectively scale DES like using the same network and principles but with more rounds, more s-boxes etc. so it can be fed a larger key?
1:11:00 at 2^32 you have probability of 50% to have collision in keys (Birthday Pardx)
I have a huge confusion, at 18:50, the attacker is attacking from the left but how did he/she get the plaintext block "x1"
Excellent question. I think I forgot to mention this explicitly in the lecture: We assume that the attacker knows x1. Later on it also becomes clear that he sometimes also needs to know x2 and x3.
In practice this is often the case since header information (e.g., header of a file or protocol) are encrypted and the attacker knows those data.
@@introductiontocryptography4223 thank you sir, i got it now
Actually, "naïve" isn't really an English word. I think it was actually a French word that was just adopted into the language--similarly to "déjà vu," "cliché," and "fiancé."
Thanks a lot.
1:19:50 i think you made a mistake ?? you said we have 2^16 CANDIDATE keys -> its false : the probabilty having a false key is 2^-48 on the 2^16 extra keys ( the average number of extra right keys is the numbrer of overhead keys * probability having the right ciphertext with one key ( assume equiprobable) = 2^16*(1/2^64) = 2^-48). then if you are not lucky you can used a second pair pt/ct. thanks again i like your lectures.
Thank you alot.
I'm not really sold on the idea that storing 1.08 exabytes of intermediate ciphertext and keys is at all reasonable for an attack, but I suppose it isn't impossible.
56:42 - Chapter number TWOOOOO!!!
so the zr value is the plain text value you get after trying to match your yi against a second set of keys untill you find a corresponding set of cipher text from phase 1 of the attack?
I think if u mean ZR so u hit the right hand side of the table and I mean the right keys ,Finally If u get Zr and Zl , U get Kr and Kl .
These keys are just keys ,I think the next step is to find out the plain text by matching the the R & L keys from the table
48:47 how it's become 2^112 ,
from 2^56+2^112?
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!
I think it would be incorrect to subtract 1 as you might go below zero, but negative number of expected false negative keys makes no sense.
i think u know how to break 3DES after watching this video Sir !!
Why not just use much longer keys?
In DES decryption, we use k(16) of encryption in the first round of decryption. When we encrypt the plain-text twice using the same key, how are we getting the plain-text? Won't we be using k(1) in round 1 of second encryption?
+simran aggarwal Yes, with double encryption with the same key you use k1 both times in the 1st round. In order to decrypt such a message, you need to have ro run DES decryption TWICE. In both decryption operations you use k16 in the first round.
BTW, note that double enryption with the same key does not give you much additional security. If using DES, one should rund 3DES with 2 or 3 different keys.
Regards, christof
Thank you so much Sir.
Danke schön Professor Paar, are there any videos/book that you would recommend that would help me understand linear cryptanalysis? Thanks!
There is only one book AFAIK, but it is excellent and I recommend it. It's "The Block Cipher Companion" by Knudsen and Robshaw. regards, christof
Danke schön, All the best
Hello Professor,
I have one question in this lecture. For double and triple encryption, meet in the middle attack, phase 1 is to encrypt X1 for all possible keys. But how does an attacker know whats X1?
Good question. I should have written the following on the black board explicitly: For brute-force attacks (and MITM is a brute-force attack) we always assume that the attacker knows at least one block of plaintext, i.e., he knows X1. As we see later in the lecture, sometimes he needs to know X1 and X2, or X1 and X2 and X3. In practice, that's often not so complicated, e.g., if files with known headers are encrypted.
Please note that the block sizes are quite small. For DES, one block has only 8 bytes/characters (= 64 bits), and even for AES it is only 16 bytes/characters. Headers of files or protocols are almost always much longer.
cheers, christof
@@introductiontocryptography4223 Thanks so much for this explanation, Mr. Christof Paar. Actually, I was looking for an explanation of this part.
Prof. Paar, can we just reduce the complexity of lookup table by O(1) using hash functions?
thanks
No, that would require you to have an hash table that is a data structure supported by RAM usually. What you refer to, is a database. They have search mechanisms, mostly rely on b-trees or more complex data structures.
would somone please care to explain this to me: I do not understand how when the attacker tries to bread double DES how does he tell if he hit the correct keys. suppose the attacker tries a bunch of keys of the left store it in a table then tries the keys on the right there is a match from what he tried on the right side to what is found on the left side ( as mentioned...) might that just mean that the attacker just has attempted the same key twice how does that let him know he hit the correct key?
( tries to break..... sorry for the typo)
Why would using the same key twice give you a match when encrypting plaintext X to Z and decrypting ciphertext Y to Z? There is no reason for this to happen. X and Y aren't related by a single layer of DES, but with two layers.
Meet In the Middle few times :)
why the 2 ^256 i get the 256 but why 2?
256 digits where the digits can be either 1 or 0 , hecce 2 possibilities therefore 2 raised to 256
Christof, your English is very good! With this naïve thing and so forth. But please, if you don't want to pronounce the "th" correctly, use "t"- and "d"-sounds. Like 'this' -> 'dis' and 'thing -> 'ting'. Because the word 'sink' has its own meaning... Besides, I love you, mr Paar, and the way you gives the material.
Go to sleep but don't talk 😍😍