 So, we will be showing here a short presentation demonstrating various uses of open SSL toolkit, mainly it will be related to the presentation which we just saw. But before that we will take a look at a few Linux commands which are relevant to network security. So, the first command is the IF config, this command is used for viewing the settings of the interfaces of the machine. So, here you can see that the name of the interface is ETH3, there is a MAC address of the interface, it shows the IPv4 address, broadcast address of that network, network mask there is also IPv6 address over there and there are a few more counters below that which shows how many packets are transmitted and received and such things, below that there is also a loopback address, but which is just a self interface and after the IF config we will take the look at the ARP command. So, what ARP basically does is it shows you the ARP cache of the machine, ARP cache is basically mapping between IP addresses and MAC addresses in the local network. So, here we can see that in the ARP cache we have addresses of four other machines. So, I will just pick one of these machines and try to check whether it is alive or not, for that we will use the PIN command. So, what Swapnil is showing you is a bunch of Linux commands, the first one was IF config, IF stands for interface, it shows you what are the different IP addresses on the different interfaces and the MAC address and so on, subnet masks at each interface. The second command was the ARP, ARP stands for address resolution protocol, so with the ARP you can actually inspect the ARP cache at a machine and after that he is trying to use a PIN command. So, these are all basic Linux commands which you will try out in the lab today during the afternoon session. So, here we have PIN this machine 10.129.1.53, so it is giving us replies right now. So, the PIN uses an ICMP echo protocol over here and the machine which is there at the destination replies us with ICMP reply. So, unless until we stop this PIN command it will keep on trying the echo equation reply. So, for that we can give it a minus C options which tells the PIN program to stop after a few PINs. For example, I have given here minus C3, so it will try it only three times. If in case the machine was not alive we will get here as 100 percent packet loss, but here we are getting that three packets have been received, so it means the machine is up and running. After this PIN command, we will have a look at the NSLOOKUP command. This is used to resolve the domain names of machines. For example, here I have used NSLOOKUP space IITB dot AC dot IN, it will try to resolve this into an IP address. So, here we have gotten reply 10 dot 200 dot 100 dot 1. There is another utility in Linux which is called host. It also does the same thing, here again we have got the same reply. And this is finally, we will see the trace root command over here. What it does it? It shows you all the hops in between our machine and the destination machine. Then here also it uses the ICMP echo protocol to find these intermediate routers, but there is a field called TTL in it in the IP which it varies, so that the intermediate routers give the reply. Now, we take a look at the secret key typography and for that we will take an example as the AES encryption standard. So, here we will again use the open SSL toolkit. Next I will show that I have a message file over here. This message file contains some text and each text I mean each line of this text has 15 characters and there is a new line character at the end of each line. It means that there are 16 characters in each line and this is repeating sequence of three lines. So, we will encrypt this text using the AES. 256 is the key length of AES, minus E option stands for encryption, this is the input file which is the message and the output file will be named as ciphertextECB1.bin, it is a binary file. Note that here we have given the AES to use the ECB mode, it is the electronic code or book mode. So, here I will give some password over here to encrypt the file. So, these are the contents of the ciphertext. We can see here that the ciphertext is also getting repeated every 16 bytes. This is usually not a good thing because if somebody knows ciphertext before and then he can know the plaintext using that and maybe even the key. What do we notice out there? We had a bunch of zeroes, ones and twos, one full row of zeroes, one full row of ones, one full row of twos and the sync kept repeating. Now just look at the corresponding ciphertext. There is an M sort of thing on the first row, F and all that on the second row, six AES and the M thing that row keeps repeating with a periodicity of three. So, every three rows the thing repeats. Now, why does it repeat? This is like a known plaintext attack. If I know the plaintext on the first row, I can conclude what is the plaintext in the fourth row and so on and so forth. Now, suppose instead of having 15 characters, actually if you recall, in the original when you saw the plaintext, there were 15 zeroes and there was one new line character. The new line character was not visible on the screen but that is a total of 16 characters and 16 characters corresponds to each character's 8 bits. So, 16, 8, 128 bits is the block size. Now, suppose I make the plaintext just 14 bits, each of those lines, suppose I made just 14 bits, sorry, 14 characters, then what would happen? Would this thing repeat or not? So, that's a question I'll again state the question. The original plaintext that you saw with Swapnel had put inside a file, that plaintext was 15 zeroes followed by a new line character followed by the next line 111 repeated 15 times followed by 222 repeated and so on and then 00 all over again. Now, there were 15 zeroes, 15 ones, 15 twos. Now, suppose I had only 14 zeroes instead of 15 zeroes on the first line and similarly 14 ones and 14 twos and so on, would I see a repetition of the ciphertext? That's the question. Here, you see a repeat of the ciphertext but if I had only 14 instead of 15, would you see a repeat? That's the question and the rest of it is why or why not? Okay, so we will see now when the each line contains less than 16 characters, what happens? So, we have another file over here, it's named as, first we will see that if we encrypt the same file using the cipherblock chain mode, does the repetition occur in the ciphertext? So, here we have given the AES 256 CBC option, so we will encrypt this file and we will use the output. Here, you can see that there is no repetition anymore over here while before in the electron codebook mode, there was a repetition in the file. So, I hope all the participants can appreciate this. In the case of CBC mode, you don't see a repeat. Each line is 15 characters as before with the new line character which is another character, so 16 characters. 16 multiplied by 8 bits per character, 128 bits is the block size. But what you see is that those lines do not repeat as in the case of ECB mode, so you can verify this in the lab today. So, we saw that in CBC mode, there will not be any repetition in the ciphertext. So, now we will see that file in which there are less than 16 characters per line. This file is having 14 visible characters and so there will be a one new line character trend of each line, it means it has 15 characters per line and the sequence is repeating after each 45 characters. So, if I encrypt this file using the ECB mode again, we should not be able to see the repetition in the ciphertext. Again, I am using the same password over here. So, these are the contents of the encrypted file when I use the ECB mode on the message file which has 15 characters per line. There is no repetition over here. Note that this file contains 15 characters per line and a new line character and there is some modification in this file. Here I am having a 3 instead of 2 whereas in the original file it was all 2s. So, now we will see that if some byte in a message file is changed, then what are the changes we see in the cipher? I will encrypt both of these files using the ECB mode, electronic code book mode. We are seeing the repetition as before again, this is the same ciphertext as before. Now, we will encrypt the modified file. Here you will see that there is some repetition, but at one point the text changes. This is the point where we made the modification, this entire block has changed because of that. So, when we in ECB mode when we change one byte, the block in which that byte falls, only that block will change, rest of the things will remain the same. This is the original block and this is the modified block because of just one character. Now, we will perform the same test using the CBC mode. Again here there is the same thing one byte is modified. So, since this is CBC mode of course there will be no repetition in this file, but we will compare it with another ciphertext which has the modified plaintext. We will compare both this ciphertext now. You can see that these five blocks over here will look different in the another ciphertext. So, what happens is that just because of one byte the changes propagate forward in the ciphertext. This is because the chaining in the CBC mode. Next we will take a look at the public key cryptography using the RSA in open SSL. First we have to generate a public key private key pair to do that this is the command. This has generated a private key now. So, this private key is in the base 64 format. From this private key we will extract the public key using this command. So, this public key is also in base 64 format. So, but we cannot view whatever parameters are used in the RSA. To do that we have to use this minus text option in open SSL. So, I am opening the private key using the minus text option. It will show all the parameters it has used. So, the next set of experiments over here is to try to find the different parameters of RSA and to look at what the ciphertext is obtained when you do encryption. So, if we go back to the original project. So, these are the different things that you see. This is 512 bit RSA. You see the modulus over there in hexadecimal. So, you can actually compare and just check how many bits are there in the modulus. Are there really 512 bits or something else? Then the public exponent. Typically the exponents are small values. So, you might be surprised about this that the public exponent that is the encryption key is a small value. Around 65,537. And you can see it in binary just next to it. And then the private key. The private key is typically about as large as the modulus. Almost always. And then the two prime numbers. The two prime numbers P and Q which are about half the size, half the number of bits of the modulus. So, you can inspect all these parameters and try and make some sense of it. In particular, look at the number of bits. It says it is 512 bit RSA. Make sure that you have enough hex characters in those roles to give you actually 512 bits. Notice that the public exponent and don't be surprised that the public exponent is so small. There's no loss of security by making it small. Look at the private key. See that it is almost as big as the modulus. In fact, it is pretty much the same size. And then look at the two prime numbers and see if they are half the size of the modulus. Because the modulus is P times Q. So, this is some message file which we'll try to encrypt using the RSA. So, we have to give the public key as input here. So, this is the safer text. And we will do the reverse operation now. In reverse operation, we have to use the private key. We'll save it in another file and we will view the contents. It's the same. Using the RSA unit, we can encrypt and decrypt using the AES in the open SSL. Now, we'll take a look at various hashes and hashback, hash-based message authentication and signatures. So, again, I'm having the same text file over here. I will try to find the MD5 hash of this file. So, it is showing the hash in the hex format. We can output this in binary format also. We'll change something in the message file and see what happens to the hash. I will change just one character over here. I will change the i to j. You will notice that almost half the number of total bits will be changed in this. In hash, whenever we change, in the message, if we change even a small bit, the entire hash will change. And on an average, half the bits will be changed. Now, we will see the hash base. So, one of the important things that Swapnir just demoed was if you take some message and you compute the hash and you change even a single bit in that message, roughly half, I'm not saying exactly, but roughly half the bits in the hash value will change. That will be diffused all through the hash value. It's not like if I change only the first part of the message, the first part of the hash will change. That the change will be all over the hash value. So, Swapnir, can we just see the two hash values and where the bits are changed? Like over here, in the modified hash, all ones are here in this byte, but here only three ones are there. Similarly, over here, we can see that the bits are changed. If we count these ones over here and the number of bits toggled over here, it will be roughly is equal to 64. So, roughly half the bits are flipped in the hash value and where exactly they are flipped, we don't know. It could be diffused over the entire hash value. Now, we will take a look at the hash-based message authentication. The hash-based message authentication also takes input key along with the message. The HMAC option over here lets us input a key. This is some random password I am putting here. So, we will be using this HMAC in binary. Now, we will see that if we change the key little bit, what happens to the hash? Here also on an average, half the number of bits will change. So, this is a property of hash. If in any input, if you change a little bit, the hash will change entirely and roughly half the bits will change. This HMAC is used for a message authentication. In this, the board sender and receiver will be having the same key and to verify the hash and to create the hash. There is another way to do this using the signature, but it has different advantage in hash. In HMAC, if someone uses HMAC and sends a message and later he can say that I did not send the message. But in signature, there is a property of non-repedition. So, here I am using the same public key, private key pair which I created in RSA. This is the message file of which we will create a signature. This is a signature in the hex format. And now we will verify whether this signature is correct or not. Notice that when we created the signature, we use the private key which is known only to the sender of the message. And the signature can be verified by anyone using the public key. So, I have given as input the signature over here and the message file. So, it is saying that verified OK. And what if the message file was changed a little bit while transmitting? If I change something in the message file now and verify it using the same signature. It has to show that the signature is incorrect. It says verification failure. So, this is what I was talking about. The demos that will be done in conjunction with the lectures. It is this demo that will be part of the lab today. So, whatever commands you have seen in open SSL that Swapnel has typed and demonstrated to you, the same thing you have to type in the lab. So, 70 percent of the lab will be basically typing those commands and appreciating the different things that we are trying to illustrate by those commands. So, for example, if you change just one bit in the message, then the hash value approximately half the bits change and there is no locality in this change. So, if you change one bit in the start of the message, any bits in the hash value could possibly change. The goal was also to tell you about RSA. What does the, what do the two primes look like p and q? How many bits are there in the two primes? What does the modulus look like? What does the phi of n function look like? What does the encryption key look like? That it is a very small encryption key of just a few digits, while the decryption key is almost as large as the size of the modulus. It was also to show you what is the effect of using CBC rather than ECB. That the known plaintext attack will be thwarted if you use CBC rather than ECB. Also the repeating plaintext, which was a deliberate choice of plaintext. If you, if we showed you a repeating plaintext, which had a periodicity of 128 bits and a periodicity of less than 128 bits, say 120 bits and then the plaintext does not repeat or you cannot see it repeating because the size of the block is precisely 128 bits. So, these are the things that we are trying to illustrate with this open SSL lab, which you will do be doing today. Now, we understand at this end that you might have problems viewing the video. So, when you came here, when the coordinators came over here, the screen was pretty clear and so on, but when you are doing it at the remote end, there might be problems. We are going to try and address these problems in the coming days. For the time being, however, you can take a look at the video. The video, hopefully you have already downloaded. The organizers will tell you how to download the video. Download the video as soon as you can and during the afternoon session, maybe the coordinators can replay part of the video so that the participants feel comfortable in these very important experiments with Linux where we looked at IP config, where we looked at Ping and ARP and so on and so forth and now in this crypto lab, we did not have the crypto lab in the 5-day workshop. I thought it would be very enlightening for the participants to not just derive equations, but also to understand what these keys are and what is the effect of encryption and what does it actually look like, what does the plaintext, ciphertext look like. And you can choose a key and change a bit of the key and change a bit of the plaintext, etc. and see what is the effect on the ciphertext. So, I hope that these problems with viewing will be sorted out. We would like your feedback as soon as possible. You can tell us, especially there are problems that linger on with the viewing because there are many demos, every session will have a demo and we want to make sure that you can see the demo as clearly as possible. So, please tell us what is going on and let us, if you have any suggestions also please inform us. There are some questions that have come which I would like to address. So, we have still about 10 minutes to go. So, one question was regarding the values of E and D. How did you obtain E and D in the case of RSA? So, in the case of RSA you choose these two primes, the software that is actually generating the key. Say it is a Java API to generate an RSA key pair. They will choose a large prime number of say for example, 128 bits. If you are talking about 512 bit RSA, they will choose P and Q to be about 1 and 28 bits. So, that is the first thing that will be done. The software will choose prime numbers. Now, how do you know that something you have chosen is prime? There are well known algorithms to do this actually that I mentioned in various books. I think I have a little mention about how to generate prime numbers. So, you generate P and you generate Q. The product is the modulus N. Now, the question that came up from one of the remote sites is how did you obtain E and D? So, the first thing is you just choose an E and D that is relatively prime to phi of N. Now, how do I know that something is relatively prime to something else? I will perform the GCD test. So, there is an algorithm called the Euclidean algorithm. Again that is explained in the text. The Euclidean algorithm to find out the GCD of two arbitrary integers, positive integers. If I want GCD of M and N, the Euclidean algorithm will enable me to find GCD of M and N. So, I choose an E and I make sure that I do this algorithm for E, E and phi of N and I make sure that this thing is equal to 1. So, that is the way I choose E and I try to choose a small number. So, obviously, I cannot choose an even number because phi of N is going to be even. It is an odd number, this is an odd number, this is an even number, even number, this is a number that will be divisible by 4. So, phi of N is going to be an even number. So, E will be typically an odd number. So, typical choices are something like 3 and I think what we had in the demo 65537 I believe. So, you choose an E and then there is the extended Euclidean algorithm which will enable you to find D as the inverse of E modulo phi of N. So, these are standard algorithms and in the textbook this is actually shown the different steps of the algorithm. So, you can program this or you get the program from somewhere and just verify that the D that you choose is relatively prime to phi of N. So, that was the question about how did you get E and D? I need an explanation for the calculation of E and D. So, how did I obtain E? I just chose an E which is and then I verified say I choose an odd number and I verified that that E was relatively prime to phi of N. I choose it small because I want encryption to be fast as fast as possible. There is no harm in choosing a small value for E, there is no security issue we are choosing a small value of E. So, choose a random number which is odd and make sure that this test is satisfied. Then go ahead and compute D as the inverse of E modulo phi of N. The inverse is computed using the extended Euclidean algorithm. To compute the GCD you use the Euclidean algorithm, to compute the inverse use the extended Euclidean algorithm. Both of those are shown in the text. Ok, so I hope that answers the question about an explanation for the computation of E and D. There was another question about the S box. What is the functionality of the S box? So, it turns out S box is the one non-linear component in the secret key cipher and it has to be chosen very correctly. Now, what does it mean to choose it correctly? It means that it should be immune to things like a crypt analysis various crypt analytic attacks. And one attack is linear crypt analysis, another is differential crypt analysis. You can study the details of linear crypt analysis in the text. So, this non-linear text box is necessary so that you do not succumb to a linear crypt analytic attack. And what do I mean by that? You are unable to find a linear combination of bits in the plain text, in the cipher text and in the key. So, it should not be possible to say for example, your plain text is p 0 to p 127. I should not be able to find a linear combination say p 1 0 5 exclusive or with p 98 exclusive or with p 31 exclusive or with cipher text bit number 25. Suppose, I can find expressions of the following that hold all the time. This is a linear expression which is these variables are operated upon by this exclusive or gate. So, if I can find expressions of this type then I can get clues as to what could be bits of the certain bits of the key. And then the this cipher is vulnerable to these kinds of attacks linear crypt analysis for example. That is why the design of this S S box has to be it has to be very very careful when you are designing this. And again details of this are in the chapter on secret key cryptography in the text. The last part of that chapter deals with linear crypt analysis with a very detailed example of an attack on the S box in a secret key cipher. So, ciphers such as DES and AS will make sure that these kinds of things will not occur. So, basically what it is is that if I have got this as the S box and there are inputs to this. Let us say 3 inputs 3 outputs and a simple toy S box in the case of AS there are 8 inputs and 8 outputs. Then if I take any combination of inputs and outputs say this bit this bit this bit this bit and this this this and something like that. I cannot find a linear relationship between them. I should make sure that regardless of what are the inputs and what are the outputs. Something like say these inputs are I 0 I 1 I 2 I write up to I 7 the case of AS there are 8 inputs and 8 outputs. O 0 write up to O 7 then I should not be able to find expressions of the form. For example, I 1 exclusive or I 5 exclusive or O 0 exclusive or O 6 for example, such things these things will never be true all the time. But it should be the case that even 80 percent of the time I should not find this thing to be true regardless of what kind of input I give over here. Suppose I give some in 7 bit input to this thing I get a 7 bit 7 bit output and then if I look at the different values of the input I gave and the corresponding outputs. It should not be true that this thing holds all the time. So, 50 percent of the time if it holds that means this is 0 and 50 percent of the time it is 1 then I am very happy. There should be no bias towards 0 or 1 it is called a bias. So, it is these kinds of things that I will use to design my S box I will try to make sure there is no bias towards 0 or towards 1 for any combination of inputs and outputs. And once again some detailed examples of these are given in the textbook. So, I guess that this is an attempt to answer the question about the S box and the design of the S box.