 So since this is the most popular and widely used today, it has become the new standard which has replaced DES. DES is too old and it's gone into disuse. It's still supported on most browsers, but people are moving towards AES. The nice thing about it is based on some very interesting and simple field mathematics. How many of you are familiar with field theory? Mathematical field? So this is really based on fields, rings and fields and the nice thing is it's very simple. So simplicity is the ultimate sophistication. It's a pretty powerful, secure kind of scheme. Regular DES was not deemed to be very secure and triple DES is slow. The block size in both cases is 64. The other one is actually 128 because using it two times, actually three times but the key is the same in two cases. A more secure secret key algorithm with a larger block size is desirable. In 2001, so as I was saying, in the 1990s, many people started attacking DES and it became clear to the security community that this is not for the future. It's got another few years and after that some smart guys somewhere in the world is going to come and attack DES and all our cryptography is going to be insecure because of that. So there's a need to replace it with a new standard and so there were many proposals that came up. 15 in the semi-final list, those 15 were reduced to five. All these proposals were vigorously debated in various conferences. These came from people around the world and they were vigorously debated, the good points and the bad points and ultimately five were selected and then from the five only the one winner which is AES. That was in 2001. So that's the one that is supported today for most applications using secret key cryptography. Now you might ask me, on what basis did you choose AES? Why not something else? There were 15 guys who were quite good. So the first thing is security. Is it secure? Is the S-box design very good and secure, for example? And many other things. Cost, computational complexity. If I'm implementing this thing, many implementations will be in software, though some of the latest Intel processors also do it in hardware. But still it's implemented a great deal in software. So how fast is it? How efficient is it to implement in software and also in hardware? Algorithmic and implementation characteristics. So is it flexible enough that I can be done easily on 8-bit microprocessors on 16-bit, on 32-bit, et cetera? Can I do it easily on, say, some of the embedded processors? Can I change the key size and the block size? If I want higher security, can I change the block size to 192 instead of 128? All of these little, little features came in handy and this particular proposal had all the best features, starting, of course, with security, but also performance and flexibility. So the block size and the key size can be varied from 128, 192, and 256. The number of rounds correspondingly is either 10, 12, or 14. And it doesn't have a feastile structure. So the feastile structure is one of my slides which will be made available, but it turns out not to have that. So all the operations are invertible in this case. As mentioned before, each round has these four steps, byte substitution, row shifting, column mixing, and subkey addition. When I say addition, what do I mean? Exclusive or useful to visualize the input block and the intermediate results as a four-by-four array of bytes. So four-by-four array and each byte is eight bits, so that gives you a total of 128 bits. So now the business of table lookup. So we said that substitutions are implemented using a table. So what should this table be? Now I've got to take a quantity which is eight bits, each element of that array, and I've got to substitute by another quantity which is eight bits. For that I need to look up into a table. So what I do is, all this thing basically says, is that you've got this eight-bit quantity split up into two parts. One part is the row index, and the other part is the column index. So I've got eight bits. You take the first four bits, which is an index into the rows. If it's four bits, it can index into two rows to four or 16 rows, and likewise for the columns. So four bits for the row index and four bits for the column index, so that table will be a 16 by 16 table. And the elements of the table, how they are obtained is through some mathematics. It's basically field mathematics. You have to take the inverse of a particular element in that array and so on. So I won't get into those details, but you can read the book for a discussion of that. So this is the substitution once again. Every single eight bits, so you've got 128 bits. Every single eight bits, there are 16 of those guys. You take those eight bits and you substitute for another eight-bit quantity. How did I know what to substitute for? I look into this lookup table. How do I know where to look in this lookup table? I take the first four bits, that's a row index. I take the next four bits, that's a column index. So I've got the row index, I've got the column index. I pluck out that byte and I substitute that byte for the original byte. And I do this 16 times because that's a four by four array. So that's the basic funda in byte substitution. Row shift. So I shift each of these rows. The first row is not shifted, but the second row is shifted by I positions, the ith row in a left way. So left circular shifts. So if I've got this array, I will shift the first row by one position to the left. The second row by two positions, circular shift. Third row by three positions. That's how I implement part of the what? Every cipher should have those three things. Substitution, permutation. So this is nothing else, but a rearranging of those bits and bytes. So it must be a transposition. And in order to make it even more secure, I have another step, which is called column mixing, which uses again field operations. I multiply by a certain field, elements of a certain field. And those elements are this. So I take the state matrix that four by four matrix, which is undergone transformations as I proceed from one step to another. And I pre-multiply it by this matrix. This is a matrix of field elements. So that is not really the number zero, one, zero, two, and so on. Those are field elements in the field of two raised to eight elements. So each element of the field is a byte, which is two hex characters. So each of those things that you see over there are two hex characters or the elements of the field gf two raised to eight. And those of you who are familiar with field theory. So you do this matrix multiplication and you get the output of this third step, which is called column mixing. Very interesting operation. The interesting thing is that avalanche effect business. After a few rounds, an output will depend on all the inputs. This is a very interesting statement, which you should be able to verify. An output will depend on all the inputs. And the final step, as we mentioned before, is round key addition. You just take that four by four matrix, each element, and you exclusive or with another four by four matrix, which contains the round key. The round key is again 128 bits. So that completes one round. Each round, four steps. And how many rounds? 10 rounds. Now one thing that's important in this secret key cryptography is the use of different modes, usage modes. So you must have seen this. How many of you have seen these modes? Okay, yeah, that's an important thing. Can you tell me, before we go to the next slides, what could these modes be used for? Let's talk about some simple things. The rest of the discussion is covered in the rest of the slides or in the book. Can you give me an example of, can you first, the motivation for CBC mode? So electronic code book mode is just this thing. Let's see the picture. Nothing very great. I have the original message. I chunk it up into blocks of size, whatever that is, 128 bits. So the first 128 bits goes with the key and it becomes 128 bits ciphertext. The next thing and so on, all of course with the same key. So we have agreed on a session key, as I've explained over here on the sheet. We have agreed on a session key and I take that session key and I take each block of my message and I encrypt each block. So that's called electronic code book. I don't know why they came up with this term, but it's a historical term, ECB mode. Now, can you think of any disadvantage of this mode? Look carefully at this and tell me how you would attack it. It's the same output. Exactly. If the input is the same, the output will be the same. So for example, if I happen to know the value of P2 and yeah, suppose I find out that C2 is equal to C5. Suppose I can see the ciphertext for example, right? And I find that C2 is equal to C5. If I happen to know P2, I will know P5. Okay, so this is like a known plain text attack where I know the plain text and the ciphertext, one pair and I'm seeing another ciphertext and I'm concluding what is the plain text corresponding to that second pair. So I know the first pair, P1, say P2 and C2 and then I know C5 and I can conclude what is P5. So this is bad news. Can we do something better? And that's something better is what's called CBC mode, cipher block chaining. So instead of all this extra words, let's just look at a figure. Will that same attack be possible here? That known plain text attack, known plain text attack, will it work here also? So a comment is made, yeah, just say a comment on the mic. If two, for two different messages, if initial few blocks are same, they will get encrypted to the same ciphertext blocks. Everybody hears that? What she says is that two messages and there could be such messages like HTTP for example has very similar kinds of things like get something, something, GET and so on. So if that first part is the same in two messages, then the same ciphertext if I know in one, I know the, if I know the plain text in one, I know the plain text in the other if they've got the same thing. Is that what you said? Is that a true statement first? Why is it not true? Sorry? Yes, so that's what these guys had in mind. What they did is they injected some randomness into this algorithm that is through the IV. So your first message, you know, almost certainly will have a different IV because IV is a random number. We'll have a different IV for the first message and the second message. Like for example, I might increment the IV. And now I can't have that same attack that I talked about before that P2, C2 and P5, C5 because the inputs to that E-box in the fifth stage over here, the fifth encryption will be completely garbled because I'm exclusive or exclusive oring the input with the output of the previous stage. So that is the output of the previous stage that is chained back, that is chained forward rather, that is changed forward to the input of the next stage. The same particular output from one stage is chained or transferred to the next stage and operated upon with the plain text of that stage through an exclusive or gate, as you can see. So that serves to randomize the input. So that P5 will now be exclusive ored with what? P5 will be exclusive ored with C4. And because of that, the randomness will increase and when you see that C5, you will not be able to make any sense of it. Bit error during transmission will affect rest of the decryption process. Bit error during transmission will affect decryption of rest of the blocks. Yes. You mean an error? Yeah. Yes, yes. That is one of the disadvantages of this approach. If there is a bit error, the only thing is if there is a bit error, you can probably handle it in another layer, like TCP and so on, ask for a retransmission. But yes, that is true. Can you think of another use of this besides encryption? And it is actually used in some of the wireless protocols. The same figure is used for something slightly different. What is that? Generation of a Mac. Generation of a Mac. So remember what was Mac and what is it used for? What does a Mac stand for? Message authentication code. And what is it used for? Message authentication besides that? This is an extremely important and subtle idea. It is used for message authentication and for integrity protection. So you say integrity protector message by appending a Mac to it. Just like in your normal data communications, you append a CRC. But don't forget, security is much more complicated subject compared to reliability. If you try to use a CRC over here, it will be almost certainly hacked. You have to use something far more complicated. So one example of implementing the Mac is through this thing. How would you do that? Just think for a second. Everybody sees that? I want to compute the Mac. What does that mean? The input to this thing is a message of arbitrary size and the output is some fixed length quantity, just like your CRC, right? Your CRC is 32 bits, for example. This thing would be typically 128 bits. This Mac, it's like a checksum. If you tamper with even one bit in that message, I will not be able to verify correctly the checksum at the other end and I will immediately suspect that you have changed the cost of the T-shirt from 200 to 2000 and so on. The nice thing about this Mac and the very, very important thing is, see, here's what I would do if I'm an attacker. I change that 200 to 2000, correct? And then what? So as not to get the receiver suspicious, I change the checksum. So the checksum is correct for the new data, for the new tampered data. Everybody sees this? I'm sending a message M1, the original guy is sending a message M1 from the sender to the receiver. I'm standing in the middle and I'm trying to take that message M1, tamper with some part of it, but if I tamper with it, that checksum will not tally at the other end, right? He will verify the checksum. Always there is an idea of generating and verifying. Whenever we talk about signatures or Macs or even CRCs, you have to generate a CRC and then you have to check it. When you do a signature, obviously signature, right? You sign, you take that thing to the bank, obviously they're gonna verify it. What else are they gonna do? Verify your signature. So the signature is to be verified at the receiver end. The same thing with the Mac. So what I am saying is I think I'm very smart. So what I do is I change that message, some bits from 200 to 2000, and I change the Mac so that it's correct for the tampered message. And then I send it, so I'm the man in the middle, take the message, tamper with it, tamper with the data, tamper will change the Mac also so that he doesn't suspect that anybody has changed anything. Will it work? Just think about this. Let me ask you a simpler question. The message has only a CRC checksum, like in your ethernet, a CRC checksum. I take this frame, ethernet frame, I tamper with the message, and I change the CRC so that the guy who's verifying the CRC, the intended receiver, doesn't smell a rat. Can I change the CRC in such a way that he doesn't feel that message has been tampered with? Yes or no? Are you sure? I don't know how many of you have seen a circuit or the software to create a CRC. It uses feedback registers, linear feedback shift registers. And it's extremely easy to generate a CRC for any message. So if I have the original message, and this is the CRC, for the new message I can also generate a corresponding CRC, you know, big deal. So he will not know that I've tampered with the message. But when you come to a Mac, you want it to be cryptographically secure. That is why you use something like this. In order for me to compute the new checksum, the new Mac, on the tampered message, what is it that I need? I need the key, the integrity key that is shared between these two guys. If I don't have that integrity key, there is no way on earth, given the kinds of schemes that we have, that you can tamper with the message and change the Mac so that he doesn't get suspicious at the other end. Now one way of doing that is exactly this thing. So what I do is I take the integrity key and I operate on this, each of these blocks of plain text. So I take the first block of plain text, encrypt it, feed it back to the second block, get the output of the second block, feed it back to the next one, and so on and so forth. I ignore all those ciphertexts, C1, C2, after I've done this. I only consider the last one. And that becomes my Mac. I think integrity will be the same, right? Will be same as what? What? We can change the Mac by using the this key, integrity key. So what happens is, if A and B have to securely exchange messages, they have to agree beforehand on the integrity key. Suppose that hacker, that middle-in man, also known as integrity key then? Then of course it's insecure. That is the key thing, right? That is why those keys, when I talked about a security protocol and I said the steps are entity authentication and key exchange. And then the rest of these messages get exchanged. That first step involved negotiating a key, agreeing upon a key. So in the SSL protocol, there are two steps you must have heard of this. SSL handshake protocol and SSL record layer protocol. What is done in the handshake is entity authentication and a derivation of all these keys. How that is done, we'll talk about tomorrow. But this is one of the keys that is agreed upon in that handshake. So that K is very important that you keep it securely. If a man in the middle sees that, then of course he can start tampering with every single message. It's a vector. Yes. So that is also you transmit it and you say I'm using this. That there's nothing secret about the IV. It's just that you should change it to increase the randomness. IV is not secret. No, not necessarily. It's just the key that is secret. The IV is just changed so that you don't have those known plain text attacks and so on. You want to randomize the whole thing. Initialization, generator, and the generator are the same one. Initialization vector, you mean? And zero random, they're different things. The zero random thing is used in the context of stream ciphers. And the IV is used in all of these, including the stream cipher, but also here. So if zero random is generated at the sending type when you're ordering the instruction, so how the zero random generator at the decryption side that will generate the same value? Are you talking about this thing or are you talking about RC4? Team C for RC4. Yes, yes. What about it? At the sending side, when we are doing the encryption, so what we are doing, we are generating the zero random generator and by using that we are generating the key after that doing the encryption. No, you have the key already. The key is known to both sides. They have agreed upon it. Okay. And then they generate the key stream. But whether that zero random generator will generate the same value at both the sides? Yes, absolutely. Because the zero random sequence is a function of the key, session key, and the initialization vector. So in that first part of the security protocol, we agree upon the secret key, the session key. And the IV can be chosen randomly, but both sides have to share it. If initialization vector, if it is made secure, is there any role that it need not be secret? Can you find out an example of where if it is known it can be compromised? In fact, in the case of RC4, as used in WEP, WEP stands for Wide Equivalent Privacy, the protocol for IEEE Auto 2.11. When you use it over there, the IV is known to everybody. It's part of the frame in the clear. I will see it in every round. Yes, so everybody can see it. And as a matter of fact, if I am the recipient, I will need to compute the key stream. So I will need that value because you're changing it with every message you send. Sir, please elaborate on linear cryptanalysis and differential cryptanalysis at some point of the time. Okay, sure, sure. That is going to be a one and a half hour lecture. But I will, if we have time on one of those days, maybe Wednesday or something. It's a very interesting thing. At least linear cryptanalysis is completely discussed in this book. So if you want, you can take a good look at it. And I mean, this is a very interesting topic, cryptanalysis. And let's see whether we have time on the next class on crypto, which is, I think, on Wednesday or something. Latest reduction for what? Sorry? Latest reduction for what? Latest reduction for what? For Pandaki cryptography tax form. And lattice cryptography, I doubt we'll have time for that. I wanted to include, so if you would like to, we can talk about homomorphic encryption and lattice cryptography and so on. But again, the only problem is time constraints. Just introduction, Riva. Okay, okay. So we'll do that. In fact, if you have anything that you would like us to introduce in subsequent lectures, just one second, anything, please let us know. So if, for example, cryptanalysis is one issue or lattice cryptography or elliptic curve cryptography or whatever it is, please let us know so that we can at least make up a half an hour presentation, introduction to those topics. My simple question is, how crypto modes is differed from crypto algorithm? Sorry, crypto modes is differed from crypto algorithm. Crypto algorithm and crypto? Crypto modes is comes under algorithm or not? Oh, I see, you said mode, M-O-D. Yes. Cryptographic modes. Yes. And cryptographic, okay. So the thing is cryptographic algorithm is the basic thing. Now, all those boxes that you see over there implement the cryptographic algorithm. But as you can see, the figures will be very different. There's something called a counter mode. It's all in the slides. There's a counter mode. So the algorithm is the same, but the modes are different. And you use different modes to achieve different things. Because one may be insecure, you use another one, for example. Or one might be performance wise better. For example, there's something called a counter mode. With counter mode, you can do things in parallel. If you've got the first block, but you didn't receive the second and third blocks, you've received the fourth block, you can go ahead and start decrypting the fourth block, even though you have not received. You can't do that over here. If you look at the decryptor, until I've got one, two, three, I can't decrypt the fourth. But with counter mode, I can decrypt the fourth, even though I didn't receive two and three. So there are different trade-offs, wherein all these different modes. I brought up this one in particular, because it helps us to do something else other than encryption. And that something else is integrity protection, using a Mac. Can we use all the algorithms in different modes? Or whether it is a decrypting value for DEs? No, no, no. All the algorithms are orthogonal in that sense. You can use AES, DES, any other secret key block cipher in this thing, in any of the modes. So this is the application I already mentioned about it, to achieve confidentiality, and also to achieve integrity protection. Nothing very great about all this. So the nice thing is you achieve two things with one solution. The Mac gives you both, integrity protection and message authentication. If there's any question, just raise your hand. Secret key, the question is, how can entity authentication be done with a secret key? That's the material for tomorrow's security protocol. So this wonderful thing called a Mac has got some very interesting properties, some of which is related to the cryptographic hash. You change even one bit in the message, and the Mac looks quite different from the original Mac. There's no way for the hacker to guess what is this new Mac. Ask a question about Xbox, Xbox, because it is, we are moved on, so I'm just going back. No, no, no, no problem. The point is like you said, like a lookup table. So do we think that the security or the vulnerability is transformed to lookup tables? You already said that Xbox should be non-linear. And the design of Xbox depends on lookup table. So now the lookup table, now the vulnerability is transformed to the lookup table. So can I say like lookup table should be non-linear to design S-box? See, the lookup table is only an implementation of the S-box. I can implement it with gates if I wanted to. Yeah, can it be different like that is what I say? Who will design the lookup table that is what? Or can it be different for? So you tell me what is your substitution. Forget about the lookup table. That is just an implementation. The key thing, the thing that requires this is the design of that S function. That should be non-linear and those kinds of things. That is very, very critical. The moment you've designed it, you just implement it with any kind of S-box you give me, I can implement with the lookup table. I just have to populate that array which is stored in memory. It's just a matter of putting the values in the right place, right? How do we proof that the S-box is non-linear? How do we prove it? The S-box is non-linear. So one thing is a brute force test. You take any combination or every combination of inputs, outputs and keys, okay? And just see what it evaluates to. So for example, take bits, the input bits, there's an 8x8 box, correct? So you take bit number 3, 4 and 7. Then take outputs 1 and 5 and take some bits of the key. Now keep changing the key value, keep changing the plain text bits, and just see what is the Boolean expression. The Boolean expression is simply an expression involving exclusive ors. And you see whether it gives you always 0 or always 1 or gives you with a higher bias. If it gives it with a high bias towards either 0 or towards 1, then you're in trouble. Excuse me, sir. Who will be having some case studies? A case studies of what exactly? For fingerprints and the areas that is mentioned in the book. For fingerprinting? And areas? Case studies. We don't have them with us. We can see, we can find some. You talk about biometrics. Yeah, so biometrics was not included in this, but we'll see whatever we can do on it. Sir, is commercial AES algorithm that is implemented already or we are using the S-box design is public or private? What do you think it is? That means, can I know that what is the S-box? What do you think it is? I mean, I hope. Anybody? So his question is, is the S-box known to everybody? No. No, no. Why should it be public? It's private. Don't you think that designers would want to keep it secret? All thing is public, but operating is public. Everything is public. Everything is public. As I told you, whatever cryptographic algorithm I or anybody else comes up with in future, we are not going to keep it secret. We are going to tell the whole world and we are going to invite all you guys and your students and everybody to hack into it. And only when you hack into it for one year or three years or whatever, and not only you but everybody in the world, and you don't find any hack for it, then and only then I will raise the flag and say, yes, now this is the most secure thing. I want you to prove me wrong. I want you to find a hack. Otherwise, how do I know it's secure? And if I don't know it's secure, how can it become a standard? If I keep it secret and somebody reverse-engineers it over time and finds a hack over it, then it's all gone. That's exactly what happened in the case of some of these previous algorithms cryptographic algorithms for cell phones and so on. They kept it a secret and then within two, three years everybody figured out what is the hack for it and that's it. Then you can hack into people's conversations and all that. So they had to come up with 3G and so on and so forth. A different algorithm for 3G. And I believe AES is also used in 3G. Thank you, sir. Sorry. Sir, we used D.F. Hellman for the secret key exchange. Yeah. Is there any harm to use for that purpose RSA? For key exchange? Yeah, for the secret key exchange. Is there any harm to use RSA as a secret key exchange algorithm? Not really. There are two different ways in which you can do it. There are many different ways in which, for example, you can do key exchange. So RSA is one. D.F. Hellman is one. You can do D.F. Hellman with a femoral key exchange, with fixed key exchange. In the security and nowhere the RSA is used as a key exchange algorithm anywhere right now. SSL has provision to use RSA for key exchange. They have not given any provision for that. They have used the D.F. Hellman only. There are four different options of which two are D.F. Hellman. One is RSA. At least one is RSA. In fact, that is the most obvious way of doing it, right? If I've got a secret key to give you, a session key, I get your public key and I encrypt the secret with your public key. So can we design an algorithm for using RSA to exchange the key with a symmetric key? That's exactly what I showed you on that paper. I come up with a secret key, a session key. I get your public key from your certificate. I encrypt the session key with your public key. Now only you can decrypt it with your private key. Yes or no? Yes. And now you have it, I have it and nobody else. That's key exchange at the simplest. Sir, a question on, a question on side channel attacks. Yes. So you already said side channel attacks is used for attacking the smart cards like credit confirmations can be taken. Yeah. Yes, but nowadays credit confirmations is more secured by having a OTP. There's one time password sent to the user's mobile. So even though the hackers know the information of the credit card, they will not get the OTP. So what is the solution? OTP is another level of security. Okay. It's not like, I mean, if you break that, then what happens? So, and side channel attacks is not just applicable in that case. If I just use my smart card, for example, I give it to the, the beta. If he has the right gadgetry, which handles the side channel attacks, which can monitor timing. I mean, you can have small gadgets to monitor those things. Then it's all insecure. So it's not, you know, it's not like you can never launch a side channel attacks. Again, it doesn't have to be launched only on smart cards. It can even be on servers. It can be on your browser. There are side channel attacks where intelligence agencies just hear the sound of the keys that you're pressing. And they know what you're typed. Sir, in case of RSA, you said that the encryption process is faster than the decryption. Sorry, sorry. I said the other way about decryption was fast. Sorry, encryption is faster. Encryption is faster than decryption. So if the same operation is done, how the encryption can be faster? Because at both the place, same operation is an exponential. Anybody can answer that. So his question is how it's the same operation true. What is that operation called? What is that operation? Encryption key is smaller. That is why it will be fast. No, one second. Let's just analyze the question. So he says if both the operations for encryption and decryption are the same, then how can you claim that encryption is faster than decryption? So the first question is for the benefit of everybody, what is that operation in the case of RSA? Exponential. Exactly. So it's called modular exponentiation. And you must have seen all this. The time is related to the number of, you raise it to the power. So there is squareings and multiplications. Squareings and multiplications. Am I correct? Now the question is the number of squareings is the same, but the number of the number of squareings will depend on the width of that key. The width of the key, the decryption key will be as big as the modulus, 10, 24 bits. The encryption key will be much smaller. So you have to raise that thing, the encryption key or the decryption key. You have to square it and then again square it again square it and so on and so forth. You have to do it how many times? Depending on the size of that key. How many bits that key occupies? So if it occupies only 10 bits, then I only do 10 squareings. If it occupies 1,000 bits, I do it 1,024 times, which is terrible. That is why decryption is slower. Thank you. The question may be out of the scope. How we can protect the content in the website? If you are creating a website, we have to protect the content. The same problem we faced in our college. We created a website for international conference and the same website is the same layout and same contents are posted in some other website. They created some other website. So somebody has taken your content? Yeah, yeah, content as well as the same layout is taken and it is published. The website, when you saw some change and they published the website, they present the date before the 10 days before our conference date. So his question is somebody is stealing all the content of your website? Yeah, any copyright laws are there, any copyright rules and regulations are there. Can you explain that regarding the next classes? That's a good question. How do I prevent somebody from stealing the content? Yeah, yeah, that's it. So the question is whether that solution involves cryptography or involves something else? It will not be there. Some rules and regulations are there. Later I referred that in our government site. It referred that some rules and regulations are there. Before we are posting the content, we have to get the permission from the government. We have to pay money for that. For each single page, we have to pay 12,000 rupees like that. It is mentioned there. So can you tell that regarding that? Okay, so I don't know the exact rules of the government on this thing. But I can only say this much that there are in different countries there are very stringent rules about this. Your content on your web page is your intellectual property. And in general, and this is a very serious issue, I write a paper in IEEE transactions on computers and I cannot even put that paper on my website. Just imagine it's my own paper that I've written 10 years ago. But I cannot put that on my website. What I can do is I can put a link to IEEE. So you click on the link, you go to IEEE and from there you will have to retrieve that paper. If they don't allow you because you don't have an account or whatever, that's your problem, you will not be able to see that paper. So there are very strict rules that have come up for all these things. And I'm sure you can sue the other party if they have taken exactly your content, if you can prove it is yours. Sir, the provision is an IT Act. Yes, the IT Act. Cyber life, if I want to go to Cyber Law, I need to register that site. Yes. Register this and many procedures are there. Yes. So that word registration... You should have to register yourself. So I think he's answered your question. I think you should register your site and with the content and everything. It's just like registering property. I'm sitting and I'm living in a house and I leave it for one year. Somebody comes and says it's my house. How do I prove it? If I register with the state government, then I show the registration document, then that's proof, right? It's the same thing over here. Okay, let's just continue and wrap this up. We've got about 10 minutes. We'll take more and more questions as we go along and there is a special question answer session on Wednesday. So one of the things that you can do is to write your questions, maybe on Moodle or something, post it. We'll see what are the redundant questions and we'll at least choose a subset of them or at least answer them by email and so on. Okay. So this is a very interesting statement. If it's provably secure, it's probably not. So is this such a thing as proving that this thing is pure, is absolutely secure? Answer is you better guess. So there have been attempts by different people in different universities to prove that this algorithm or this security protocol is perfectly okay. But then there are also all sorts of other problems that arise. That is why you've got SSL that has got 10 different versions. IP Sec has got so many versions. wireless security has got so many versions of wireless security protocols and so on and so forth. It's very hard to prove that something is perfectly secure. You prove it in the next day somebody comes with a bug and shows that it's insecure. I won't talk about this thing in great detail. You've seen it and if we have time we can go through the mathematics of it. But just two or three slides because I wanted to also cover the cryptographic hash and the digital signature. RSA background proposed by Rivesh Shamir Adelman way back in 1977, one of the earliest public key schemes. Diffie Helman was even earlier than this though. I think Diffie Helman was 76. Security based on so every of these crypto algorithms has a security based on some hard mathematical problem. In this case it is the problem of factorizing a very large number say 1024 bits of 2048 bits. That is the product of two very large numbers. How large are those numbers? Those factors themselves are about 512, 512 bits for example. You can't make it too small of this. It's easy to factorize the key operations are key generation. You remember the mathematics for this? Let's very briefly talk about it. P and Q are two prime numbers. P times Q is N, the modulus. E is an encryption key. How did you find E? Relatively prime to phi of N. What is phi of N? P minus 1 times Q minus 1. And then D is the inverse of E modulo phi of N. So that's the basics. That's key generation. You have generated an E. You have generated a D. Encryption. Take a message, chunk it up into blocks. M to the power of E mod phi of N. Yes or no? Not phi of N. The first one was phi of N. The second one is M to the power of E mod N. And then the ciphertext that's equal to C. And at the receiver end C to the power of D mod N. So that's the basics. Refer to the books for more examples and so on and so forth. Now the uses of public key cryptography. So encrypting these servers. So as I said, you don't want to encrypt an entire message. Supposing you're sending a message which is 100 kilobytes. The time for encryption using RSA will be quite substantial and decryption will be even worse. So what you do is you encrypt the session key. And then you decrypt the session key at the other end using that person's private key. And then you use that session key for encrypting and decrypting all subsequent messages between the two of you during that session. Okay, so it's used for encrypting the session key. Anything else besides encryption? Digital signature, right? So what is a digital signature? Very quickly. Message, how do I compute the digital signature? First you take the hash. So this message can be, let's say, five kilobytes. The hash of this thing will be how much? 128 bits or 160, for example. MD5. And then you encrypt it using what? Suppose A wants to sign it. Senders private key. Signers private key. So this is the definition of a digital signature. So here's another application of using RSA. So in the case of the MAC, use a secret key cryptography. In the case of the digital signature, use public key cryptography. Why that difference? No, there's one important word that is related to the digital signature. What is that word? Exactly. So this is one property. I sign this document. I sign this deed transfer real estate deal with my digital signature. And then I deny that I signed it. So how do you verify the signature? Yeah, so just one second. We'll just go back and write this again. So this was the signature. You sign a document, send it to the bank or to some government agency. How do they verify the signature? So what do you send? You send the message and you send the signature. The message can be several kilobytes. This thing is 128 bits or actually not 128 because you're doing the private key operation, say 1,024 bits. Now how do you verify this signature? Signature generation, signature verification. Just like you have encryption, decryption, you have signature generation and signature verification. So what should I do? So I take the signature, so I take the signature and I check whether this is the same thing as, this is the signature, okay? I check whether this is the same thing as, I take the message, everybody sees this. So this S is all this stuff. When I do this D and E, they get nullified, so I've got H of M. And then I verify whether this operation that I do tallies with this operation. The output of this operation is the same as performing an H cryptographic hash on the message. So this is an example of the use of public key cryptography and also of the use of the cryptographic hash. Are there any questions about this? So besides the MAC, this is the next most important thing, but unlike the MAC, this also guarantees the property of non-repudiation. I cannot sign a document and tomorrow deny that I sign this. It also guarantees integrity. Yes, it guarantees authentication, so authenticity, integrity, and in addition, non-repudiation. But the cost is slightly more. The moment I go to public key cryptography, the cost is more. Notice that in the MAC, I didn't need to use public key cryptography. Either I can generate the MAC using only a cryptographic hash or using a DES or any secret key algorithm in CBC mode. I'll just briefly talk about the cryptographic hash because this is such a wonderful thing. Sir, what is the basic difference between MAC and HMAC, sir? What is the difference? So the HMAC is using the MAC twice so that you get more security. Okay, just look at the book. There is a picture of the HMAC which makes it more security. There are some very subtle attacks that cryptographers have found on the simple MAC, so they do it twice with the same key. So some very interesting ideas over here. Can we just go on for another five minutes or seven minutes? Okay. So to produce a fingerprint or digest of a block of data, so you take a large thing and this just like a fingerprint is like a representative of yourself, right? If you use biometrics, the fingerprint represents you sort of. The same thing over here. The cryptographic hash, which is a 128-bit or a 160-bit quantity, in some sense represents that message. So to produce a fingerprint or digest of a block of data, the block of data can be a message. It can be a document, et cetera. For a given hash function, the size of the digest is fixed, though the input can be of arbitrary size. Now some very interesting properties, and you should really think about these properties. We won't have time to discuss them in great detail, but think of why these properties are so important, because you've heard of hash functions in so many contexts, like algorithms, data structures, databases and so on, but this is a completely different animal. Why is this so important? The cryptographic hash. So given an x, it is easy to compute h of x, but given a y, it is computationally infeasible to find an x such that h of x is equal to y. So this is the noninvertibility property or the one-way property. Given an x, I can compute h of x, but given h of x, it's impossible for me to find one value of x that has that same h of x. Weak collision resistance, given an x, it's computationally infeasible to find some z such that h of x is equal to h of z. So this is a weak collision resistance property and a subtle difference between weak collision resistance and strong collision resistance. So I'm saying this is a slightly harder problem for you, but I'm giving you a simpler problem. I'm not giving you an initial x. I'm saying you have the liberty to choose any x you want, and can you find any two x's, x1 and x2 are challenged to you? Find any two x's, x1 and x2, such that the cryptographic hash of x1 equals the cryptographic hash of x2, and this is called strong collision resistance. So the hash designer has to guarantee that these three properties at the very least are satisfied. And as I said before, you want to verify why these properties are so important. So pictorially, you can think of it this way. It's easy for you to go. So this is a mapping. The hash function is basically a mapping from a set of messages. Of course, messages can be of arbitrary length. So the set on the left-hand side is an infinite set, and the set on the right-hand side is, for example, how many elements? Two raised to 128. Because 128 bits, there are two raised to 128 possible hash values. So each of these things on the left will map to one thing and exactly one thing on the right-hand side, though there is no guarantee that you obviously not. You might have something else that maps to that. So understand the difference between this. There could be two things on the left-hand side that both map to the same value on the right-hand side, because the left-hand side is infinite, and the right-hand side is finite. The only problem is you simply cannot find it. It's like saying there is a very good probability that life exists on another planet, and there are billions of other planets and stars. Still, if you try to find it, we can't find it. It's the same thing over here. There are many other guys on the left-hand side that map to the same guy on the right-hand side. Still, if you try to, you cannot find it. So that's the beauty of this cryptographic hash, because of the way it's designed. This is the one-way property, and the other property, for example, over here, weak collision resistance. There is no way, given one of these values, if it's the top one, you can't find another one that maps to the same thing. So this is the property of weak collision resistance. So because of these properties, it's because of this that the digital signature is so secure. Now, think what is the meaning of that statement. Suppose these properties did not exist, then you can forge somebody else's signature, which is very bad news. The whole of e-commerce and banking, internet banking, et cetera, depends on this, on the cryptographic hash and on public key cryptography and secret key cryptography. If you can come up with a scheme that defeats all this, these properties, then we are in trouble. And so some properties to create a digest of a message without even signing it, just create a digest. So there are certain files, for example, you will store the MD5 hash of that file for integrity purposes. So that's one basic application to create a Mac. So the Mac that I showed you before uses secret key cryptography to create it. You can also create a Mac using just a cryptographic hash and using, how do I create a Mac? Without using CBC. So encrypting it, so I take the message, I compute the hash of the message, and then encrypt it using a secret that we share. So that is one way of computing the Mac. So there are two ways using the CBC mode and using the cryptographic hash. The CBC mode doesn't need to use the hash. But the digital signature needs to use the hash, as I've shown over there. So for integrity, authentication, and non-repudiation. So this is the Mac. I take, so actually the Mac can be computed this way. You don't need secret key cryptography. It is H of M concatenated with the secret key. Just look at how beautiful this thing is. And the cryptographic hash isn't very time consuming. So very fast, I can integrity protect the message. What do I do to integrity protect it? I take the message, concatenate it with the secret that we have shared. We've agreed upon the secret now. Concatenate it, and then take the cryptographic hash. So that is the Mac. So one way of computing the Mac, the other way was the CBC mode. Any questions about this? Very important. How do I compute the Mac? Two ways, using the cryptographic hash and the other way, encryption using CBC mode. How do you verify the Mac, just like you verify digital signature? What would you do? In words, you take the message. So what is sent to you is the message in the clear. I'm not even talking about encryption and all that. Send the message in the clear and send the Mac. So I take the message. I have got the secret because the two of us share it. Concatenate the message and the secret, compute the hash, and then check whether it's the same hash that he sent me. If it is, then there has been no tampering, and it's from the right guy. Both, two things in one. You guarantee both integrity and authentication, message authentication. What a beautiful idea. And in the case of digital signature, all three. Integrity, authentication, and non-repudiation. Now verify that the signature is defined by us in the sheet, satisfies all these properties. This is exactly what you want for your manual signature, correct? It should be authentic. You take me, you bring a check that you have signed to the bank. I need to make sure that it is really your signature. It should not be forgible. Some great artist who can mimic your signature has not signed it. So it might be your signature, but this great artist can mimic anybody's signature. How do I guarantee that? You see the difference between point one and point two? Authentic signature means it looks like your signature. Point two means you have signed it, not some artist who can mimic your signature. It should not be possible to repudiate a signature. I'm going to sign a check for you, one lakh, and tomorrow I say I didn't sign it. It should not be reusable. I give you a check of 500 rupees, and then you put it on some other check and put my name on that saying you gave me a check for 10,000. It should not be reused. Take it from here and put on some other check. And it should not be possible to alter the signed document. I gave you a check for 500 and you add two zeros. It should not be possible for you to do that. All of these things can be guaranteed with a digital signature. And verify that what I just said. All of these properties can be guaranteed with a digital signature. So potentially the digital signature is better than a manual signature. Okay, I think we'll stop at this point.