Encrypting and Decrypting using CTR and CBC Modes in C# with BouncyCastle

Transcription

1 SE425: Communication and Information Security Recitation 5 Semester April 2018 Encrypting and Decrypting using CTR and CBC Modes in C# with BouncyCastle In this week s recitation we ll learn about using the BouncyCastle (BC) cryptographic library in C#. The library is an open source collection of cryptographic and security algorithms which are in wide use today. For example, every Android phone has a copy of the BC libraries for use in security protocols and authentication on the device. The BC libraries were originally written in Java to extend the functionality of the built in Java javax.crypto libraries, so most of the documentation for them is written for Java. The library were later ported to C#. In contrast to the.net cryptographic services which are quite limited (a few block ciphers, support for CBC and ECB only, RSA public and private keys), BC offers a rich collection of cipher engines which include popular (ex. AES, RC6) and not so popular (ex. SkipJack, Blowfish) block and stream ciphers, key establishment protocols (ex. Diffie-Hellman), three types of public and private key pairs (RSA, elliptical curve, El Gamal), a rich variety of block cipher modes, and much more. There are two APIs for the BC libraries in Java: 1. A cipher by name service in which you request the cipher and mode combination desired (ex. AES_ 128/CBC/NoPadding) from a static Cipher object 2. A polymorphism based class hierarchy in which you build a cipher suite (combination of cipher configuration and mode) modularly using objects. To the best of my knowledge, only the second interface is found in C#, so that s the one we shall use in this recitation. If you don t have them already installed, you can add the BC library to your project by using NuGet in Visual Studio. 1 An AES File Encryptor/Decryptor To make the recitation concrete, we will develop a simple file encryption and decryption tool together. The tool is shown below: 1

2 The tool has three areas: Key and IV management, Encrypt, and Decrypt. The important part of the GUI are as follows: 1.1 Key and IV area Key The encryption and decryption key in hexadecimal format. Generate Key Creates a new key for AES using the key length shown on the right side (numeric up down) IV The IV contents in hexadecimal format. Generate IV Creates a new random IV using the defined AES block size (128 bits) Export Key and IV Stores the key and IV in a text file in a simple format: Key: IV: a29b6d1c048042c15301e43ba52f6128 9ab8821e03d72b83e5a4f86e2719c079 Load Key and IV Loads the key and IV from a text file in the above format. 1.2 Encrypt area Cipher and Mode The cipher and mode that we will use for the encryption. File to Encrypt The file which we are going to process using the cipher and mode shown and the key and IV pair. Encrypt Lets the user choose the output file for the encrypted data and then performs the encryption. 1.3 Decrypt area Cipher and Mode The cipher and mode that we will use for the decryption. File to Decrypt The file which we are going to process using the cipher and mode shown and the key and IV pair. Decrypt Lets the user choose the output file for the decrypted data and then performs the decryption. 2 Provided: Key and IV Functionality Aside from the export and import functionality which is quite straightforward, we ll start with the following features to the key and IV area (it s already in the empty version): 1. Ensure that the key and IV text boxes only contain valid hexadecimal characters (0-9, a-f, A-F). 2. Ensure that the key is only of an supported bit length for AES (remember that each hexadecimal character is 4 bits of data) 3. Ensure that the IV is only of an allowed block length for the cipher. 4. Generate a random key of the requested length. 5. Generate a random IV of the correct length 2

3 Figure 1: Tool showing error message due to a bad key length Figure 2: Tool showing error message due to bad hexadecimal characters in the key and IV For the first three features, we use basic string parsing and character checking. When they key of IV are the wrong length of contain illegal characters, we give a visual signal (coloring the TextBox) and a short text message on the bottom of the tool (in the status bar). The examples in Figures 1 and 2 show how the tool will respond to bad data. For the last two features, we need to write code to generate keys and IVs of the correct length and convert them to hexadecimal characters. The next steps are for you to start working on yourself. 3 Step 1: Counter Mode in AES Counter mode uses a key and an IV for encryption. The IV is used as a starting point for encrypting a counter which goes up by 1 for each block. The resulting encryption of the IV + block number creates a series of encrypted bytes called the key stream. The key stream is then combined with the data to encrypt using XOR to encrypt it. Decryption takes place in the same manner - by encrypting the counter and then using XOR on the cipher text. The counter mode in BouncyCastle is implemented using the class called SicBlockCipher. We use it to 3

4 wrap the core engine that we want (in this case AesEngine) to get the counter mode behavior that we want. Before we can use the SicBlockCipher, we need to initialize it using the init method. The method takes two arguments: A parameters object. Since we re going to use CTR and CBC in the tool, we ll need to provide two things in the parameters object: a key and an IV. To accomplish that, we ll use the following two objects: 1. A KeyParameter object which we construct using the key we want in byte[] format. They key can be gotten from the top TextBox after converting from the hexadecimal string to a byte[]. 2. The IV we want from the second to top TextBox. We also need to convert it from a hexadecimal string to a byte[]. We ll wrap the two objects into a single ParametersWithIV object which we provide to the init method. A boolean parameter whether we want to encrypt (true) or decrypt (false) with the engine. Once the engine has been initialized, we can use it to encrypt and decrypt. 4 Step 2: Padding Issues After a first, naive attempt, we may discover that the SicBlockCipher will only encrypt 16 bytes at a time. That means that if we want to encrypt a message which is much longer (say 1MB), we need to read the data in 16 byte blocks. A second issue which comes up what to do we are given 17 bytes of data. The first 16 will go into the first block. What do we do with a single byte? The answer must be padding to complete the number of bytes which is needed to a multiple of 16. To solve both issues, we will wrap the SicBlockCipher in another class - PaddedBufferedBlockCipher. The buffering makes it possible to process more than 16 bytes in one go and the padding lets us encrypt and decrypt data which is not precisely a multiple of 16 bytes. Once we use buffering, we need to make sure to flush out the buffer when we re done. That means using the dofinal() method on the PaddedBufferedBlockCipher instance. So, we ll use the ProcessBytes method from the PaddedBufferedBlockCipher to encrypt and decrypt. We ll read the input file block by block (using a FileStream), process the block, and output the result to the output file (using a second FileStream). After the last block, we ll run the dofinal method and write its output to the output file. Note If we only wanted to do buffering, not padding, we could use the BufferedBlockCipher class. Stream ciphers in theory don t need padding - they just encrypt whatever you give them using XOR on the key stream. Summary A summary flow chart of the cipher process described in this step and the previous step is shown in Figure 3. The main parallel stages of the process are color coded (preparing the files for input and output, preparing the engine, preparing the key and IV). The main processing loop is shown in greyed block labeled Encryption/Decryption Process. The process is identical whether encrypting or decrypting aside from the parameter passed to the init() method of the PaddedBufferedBlockCipher. 5 Step 3: Adding CBC Mode in AES Once we have things working with Counter mode, we can easily add in CBC mode using the CbcBlockCipher class instead of the SicBlockCipher object. The replacement is straightforward and follows nearly the same steps as shown in Figure 3. 4

5 Figure 3: Counter Mode Processing with BouncyCastle 5