Great lecture, after a lot of searching this was finally the explanation I needed. The fact that professor had to beg the students for attention is so sad.
It's lots of theory thrown at you in an hour so I believe they are bored. Yes it's sad but just few of them in that class are probably very passionate about it. The rest maybe just needs to pass this class.
At the beginning of the lecture, I had a doubt that this teacher could give me answers about my long-term questions about MAC (authentication and non-repudiation) and I must say that he gave me straight and simple anwers twenty minutes later: Thank you for this M Paar ! I enjoy the way you provide an example on the most important stuff.
What a great lecture. I cannot help to be upset at the people chatting in the background. How come they do not realize how interesting, informative, and useful this is, explained so easily and straightforward. Thank you for posting your videos!
Thanks for your great lecture, I have a question about MAC secret prefix MACs, if we have the message length information in the key K , would it still need to use HMAC for security concern ?
In its pure form, MACs are NOT encryption schemes, they just protect the message against manipulations. And there are applications where one does not care about sending the message in clear. Of course, in practice, the message is very often both encrypted and protected by a MAC. cheers, christof
Professor Paar, MAC is a wonderful concept incorporating the integrity and authenticity features of the security services. One thing I am struggling to understand is that if both encryption and MAC were used all these work well when both parties use the same algorithm for encryption and decryption. For example how does Alice know that Bob used MAC on sha1 with AES128 encryption so that she can decrypt using the same alogirthms at her end to verify the messages? The only thing Alice would see on the channel is the plain text and the MAC. Thanks, Satya
Would imagine that Alice would know what to use to decrypt based on protocols that are in place. There would probably be a rule in place that if data is transmitted using this protocol then it's AES128 encrypted or some other encryption. If there wasn't a rule for this then Alice might be able to examine the key length or another attribute that would give away how Bob encrypted it. Not sure if this answers your question or not..
Thank you for answering my question. Yes, I think it makes sense. There should be some rules that would be defined either in a header or any other mechanism for these protocols to work
I think I've come across a fallacy. When explaining 2.2 secret suffix MACs, professor Paar compares the brute force attack on key (128 bits) versus collision search (160 bits), he says the complexity should be 2^80 instead of 2^160 due to Birthday Paradox resulting 2^(n+1)/2 complexity. In the case of Birthday Paradox (Collision attack), we need Oscar to be able to freely choose X1 and X2 which is not the case here. Here, X1 is fixed and Oscar needs to find X2 that satisfies h(X2) = h(X1). In this case (2nd preimage attack), the complexity is computed as 2^n = 2^160. Is this correct or did I miss something?
@@Ricardo-pz4zq I think it's just a minor error in the lecture due to which they cannot rerecord the whole lecture. The correct answer (IMO) is in my original comment too. Hope this helps!
In a previous video Professor Paar mentioned that it's not so unrealistic that an attacker could ask Bob to sign a message. In that case the birthday paradox does apply, if an attacker can find two messages m1,m2 and ask Bob for a MAC tag of m1, he can reuse that tag on m2 and forge a valid tag. So I guess in this worst case, the security of the MAC is brought down to 2^(n+1)/2 bits. But as it is explained, yeah I think you're right (or if Oscar could monitor the traffic indefinitely then birthday paradox would also apply eventually).
At 26:50 you write down the basic idea of the hashed MAC. I'm not understanding this at all. From MACk(x) we get m but h(k,x) is what we want or what we're going to get...or is x=m or...? I am hoping the subsequent lecture clears things up but as a suggestion, could you rephrase your "basic idea"? That statement doesn't shout out to me "this is generally what we're after" (and it's supposed to be "basic"). Seems like we'd want h(k,m) at some level, and not h(k,x) (because we already have m) but again, I need to continue watching. Thanks for these! Without a doubt an amazing body of work!
If I understand your confusion, it may be helpful to point out his usage of 'x' and 'm' here. In his past videos, 'm' is message. Here it's MAC. 'x' is the message in this video. At the start of this video, he's describing what a MAC offers. Then he goes into why it's not enough for specific security reasons, hence we need to hash 'x' (the message) with 'k' (the key), in order to get a checksum 'm' - for mac - (or hash digest) that can be compared to what 'm' is supposed to be.
The instructor says that SHA-1 has a 512 bit output, as far as I know SHA-1 has a maximum output size of 160 bits, not 512. I'm still learning cryptography, so if I'm mistaken feel free to correct me :) just don't want people learning wrong information.
Sha 512 has 512 output.I guess u might have become an expert till now but just want to tell that there are different versions of Sha and they produce different output sizes.eg Sha 160 produces 160 bit hash code while Sha 254 if I'm correction produces 254 bit digest
Great lecture, after a lot of searching this was finally the explanation I needed. The fact that professor had to beg the students for attention is so sad.
It's lots of theory thrown at you in an hour so I believe they are bored. Yes it's sad but just few of them in that class are probably very passionate about it. The rest maybe just needs to pass this class.
At the beginning of the lecture, I had a doubt that this teacher could give me answers about my long-term questions about MAC (authentication and non-repudiation) and I must say that he gave me straight and simple anwers twenty minutes later: Thank you for this M Paar ! I enjoy the way you provide an example on the most important stuff.
I love when he says "surprise surprise"..
Love your lectures/videos. Thanks for posting.
Thank you very much for publishing all this material. It is incredibly helpful!
25:40 MACs from Hash Functions
59:25 HMAC construction
This is what I was looking for, thank you.
Great lecture. After watching several videos this finally made things clear. Thanks.
What a great lecture. I cannot help to be upset at the people chatting in the background. How come they do not realize how interesting, informative, and useful this is, explained so easily and straightforward. Thank you for posting your videos!
Finally a good explanation that uses real-world examples, thank you
This man is an Amerian hero
Thanks for your great lecture, I have a question about MAC secret prefix MACs, if we have the message length information in the key K , would it still need to use HMAC for security concern ?
Great lecture!!!!!!!!!!!!!!!!
thank you sooo much sir
in 43:00, shouldn't we check m prime with m of Oscar not plain m ??
Great class
Thankuu !!!!
Where have you been this whole time!
1:03:26 - But.. that's what I am doing right now :o
Any programming explanation of these lessons. Or any resources to learn programming for these lecture. Any helps
10.54 why do we transmit the clear text ( x ) over a public line?
In its pure form, MACs are NOT encryption schemes, they just protect the message against manipulations. And there are applications where one does not care about sending the message in clear. Of course, in practice, the message is very often both encrypted and protected by a MAC. cheers, christof
Professor Paar,
MAC is a wonderful concept incorporating the integrity and authenticity features of the security services. One thing I am struggling to understand is that if both encryption and MAC were used all these work well when both parties use the same algorithm for encryption and decryption. For example how does Alice know that Bob used MAC on sha1 with AES128 encryption so that she can decrypt using the same alogirthms at her end to verify the messages? The only thing Alice would see on the channel is the plain text and the MAC.
Thanks,
Satya
Would imagine that Alice would know what to use to decrypt based on protocols that are in place. There would probably be a rule in place that if data is transmitted using this protocol then it's AES128 encrypted or some other encryption. If there wasn't a rule for this then Alice might be able to examine the key length or another attribute that would give away how Bob encrypted it. Not sure if this answers your question or not..
Thank you for answering my question. Yes, I think it makes sense. There should be some rules that would be defined either in a header or any other mechanism for these protocols to work
I think I've come across a fallacy. When explaining 2.2 secret suffix MACs, professor Paar compares the brute force attack on key (128 bits) versus collision search (160 bits), he says the complexity should be 2^80 instead of 2^160 due to Birthday Paradox resulting 2^(n+1)/2 complexity. In the case of Birthday Paradox (Collision attack), we need Oscar to be able to freely choose X1 and X2 which is not the case here. Here, X1 is fixed and Oscar needs to find X2 that satisfies h(X2) = h(X1). In this case (2nd preimage attack), the complexity is computed as 2^n = 2^160. Is this correct or did I miss something?
I had the same doubt. Did you figure it out if you missed something or not?
@@richardtomy7730 What if Bob sent only one message?
@@Ricardo-pz4zq I think it's just a minor error in the lecture due to which they cannot rerecord the whole lecture. The correct answer (IMO) is in my original comment too. Hope this helps!
I have the same question. Let's see if @introductiontocryptography4223 can clarify it. Thanks very much for the great lectures and the textbook.
In a previous video Professor Paar mentioned that it's not so unrealistic that an attacker could ask Bob to sign a message. In that case the birthday paradox does apply, if an attacker can find two messages m1,m2 and ask Bob for a MAC tag of m1, he can reuse that tag on m2 and forge a valid tag. So I guess in this worst case, the security of the MAC is brought down to 2^(n+1)/2 bits. But as it is explained, yeah I think you're right (or if Oscar could monitor the traffic indefinitely then birthday paradox would also apply eventually).
At 26:50 you write down the basic idea of the hashed MAC. I'm not understanding this at all. From MACk(x) we get m but h(k,x) is what we want or what we're going to get...or is x=m or...? I am hoping the subsequent lecture clears things up but as a suggestion, could you rephrase your "basic idea"? That statement doesn't shout out to me "this is generally what we're after" (and it's supposed to be "basic"). Seems like we'd want h(k,m) at some level, and not h(k,x) (because we already have m) but again, I need to continue watching. Thanks for these! Without a doubt an amazing body of work!
If I understand your confusion, it may be helpful to point out his usage of 'x' and 'm' here. In his past videos, 'm' is message. Here it's MAC. 'x' is the message in this video.
At the start of this video, he's describing what a MAC offers. Then he goes into why it's not enough for specific security reasons, hence we need to hash 'x' (the message) with 'k' (the key), in order to get a checksum 'm' - for mac - (or hash digest) that can be compared to what 'm' is supposed to be.
At 33:10 the block size of SHA-1 is mentioned as 512 bits, that should be SHA-2.
input is 512bits
Thank you for your lectures. Just one thing: Please never use red chalk on a green blackboard.
The instructor says that SHA-1 has a 512 bit output, as far as I know SHA-1 has a maximum output size of 160 bits, not 512. I'm still learning cryptography, so if I'm mistaken feel free to correct me :) just don't want people learning wrong information.
+Kyle At what point does he say this? Perhaps he or you confused the block input length with the output length?
Yes SHA-1 has 160 bit output
Sha 512 has 512 output.I guess u might have become an expert till now but just want to tell that there are different versions of Sha and they produce different output sizes.eg Sha 160 produces 160 bit hash code while Sha 254 if I'm correction produces 254 bit digest
He's talking about input block size, which is indeed 512 bits for SHA-1.