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