So far I have dealt with the implementation of *integrity* services and *authentication of* transmitted data. It is high time to deal with secrecy, that is, securing them in such a way that they cannot be read by unauthorized persons. This is the purpose of the service called *confidentiality*, and the algorithms that implement it are called *ciphers* ( *cipher*). In the following post I will introduce one of their types. These will be *symmetric block ciphers*.

## Encryption and decryption

The process of *encryption* converts a message called *plaintext* or *open* *text* ( *plaintext*, *cleartext*) into *encrypted text* also referred to as *cryptogram* ( *encrypted text*, *ciphertext*). The reverse operation is *decryption (decrypt*). The parameter of both functions is a *key* ( *key*), which ensures the secrecy of the transmitted information. These processes are shown in the figure below. Instead of the $$E^{-1}K$$ designation,*$$DK$$ is also used*.

Confidentiality is not a service that only appeared with modern computers. One of the classic ciphers is the Caesar cipher. It consists in substituting for each letter of the encrypted message a letter three characters away from it in the alphabet. Thus, the message *ABC* after encryption will obtain the form *DEF*. This cipher can be generalized by fixing the key *K* to the number of offsets. For the English alphabet, we will then obtain a *shifting cipher* with 26 possible keys. This is a special case of a mono-alphabetic cipher, in which the key is a certain permutation of the alphabet, that is, an assignment of letters to other letters. We use such an assignment for each character of the encrypted message. If we would prepare several such transformations and apply them cyclically for successive characters we would get a polyalphabetic cipher. All these ciphers form a group of base ciphers. For the sake of order, I still need to mention pivot ciphers, in which encryption involves changing the order (position) of characters in the plaintext and not their value.

Caesar's cipher uses a single key and is called *a cipher* for historical reasons. The correct term in this case would be *encryption* and not *encryption*. Encryption is a change in the form of writing according to a specific and known algorithm, in which there is no key needed to read the message. One variation of the shifting cipher, using a shift of 13, which is *half of* the English alphabet (thus the same algorithm is used for encryption and decryption) is known as ROT13 and is sometimes used, for example, on newsgroups to obscure content or as the subject of various jokes. The algorithm is built into many email applications and text editors. In the Vim editor, the transformation can be performed using the shortcut `g?`

## When a cipher is a cipher

Not every function that transforms a message is a cipher. In particular, to be a so-called *block c* ipher it must meet at least the following conditions:

- any data of a certain size (e.g.,
*n*bits) must convert to a block of the same length (hence the name block ciphers, the number*n*is called block length), - the cipher works using keys of length
*k*bits, this length can be different from the block length, - there must be $$E^{-1}K*(EK*(M))=M$$, that is, what we encrypt should be decryptable with the same key.

The listed properties do not exhaust all the characteristics of a good cipher. It must be difficult to break, which means that a person who does not have the key should not be able to obtain the plaintext from the cryptogram. The requirements for ciphers are even stronger: a person in possession of the plaintext and the cryptogram should not be able to recover the key to decrypt other captured cryptograms. All these rules also assume the openness of the encryption algorithm.

Imagine the following experiment. We sit in front of a black box into which we enter some data, and it responds to us with data of the same length. In other words, we enter a block of data to transform and in response we also get a block of data. There may be an encryption cipher with some *K* key, unknown to us, or a random number generator. We don't know what is in the box, and our task is to guess whether we are dealing with a random number generator or a cipher. If we find a method to recognize what the device is doing based on the results we get, a cipher subjected to this test will not find applications in cryptography. Of course, we cannot feed the same block into the black box twice - then the task would be easy to solve. There is one more important conclusion from the described experiment. A properly used cipher can have applications as a *random number generator*.

Good ciphers should provide *confusion* and *diffusion*. The creator of these concepts is Claude Elwood Shannon, who worked on information theory. Confusion aims to hide the relationship between the plaintext message, the ciphertext and the key. Diffusion refers to the dispersion of the bits of the key and the plaintext message throughout the cryptogram.

For the above reasons, the previously mentioned classical ciphers from the point of view of cryptography are now a curiosity and **should not be used** in systems that are supposed to ensure confidentiality.

Keys of length *k* bits can be $$2^k$$. The set of all keys is called the key *space*. Since there are a finite number of them we can always launch a *brute force* *attack*, which involves checking consecutive keys. For this reason, the key space should be large enough to make such an attack impossible in practice. Then the time or resources involved to find the key will be uneconomical to carry out such an attack. Suppose a key is 56 bits long and we can check 100 million keys in a second. It would take almost 23 years to search the entire key space. If we extend the key by only 1 bit, the time doubles to almost 46 years.

## Symmetric ciphers

When the encryption and decryption operation is performed with the same key we talk about *symmetric encryption*, and such a key is called *a* *secret* key. The diagram of secure communication using such an encryption is shown in the figure below.

A necessary condition for the correct implementation of the confidentiality service is the secure transmission of the secret key. How can this be done? Of course, by realizing the confidentiality service, that is, to pass the key encrypted ... with another key. Implementing such a procedure, we will fall into a recurrence, which eventually must be broken. It is necessary to exchange the first key in a trusted channel, that is, in one that is not exposed to successful attacks by a cryptanalyst. I will write about such techniques soon.

As I already mentioned block symmetric ciphers encrypt entire n-bit blocks. If the block we want to encrypt is too short it is necessary to use *padding*. The message can be padded with zeros, for example. In this case, the other party may have trouble determining what is the message and what is the padding because there may be zeros in the message itself. Another type of complement, which will be unambiguous to the recipient, is to complement the message with bytes of the value of the number of bytes complemented. In any case, the recipient must know what technique we used to apply an analogous algorithm and separate the message from its complement.

## Several algorithms

One of the first modern cryptographic algorithms is the DES*(Data Encryption Standard*) algorithm, also called DEA*(Data Encryption Algorithm*). It was developed in the mid-1970s by IBM on behalf of the US. It works on blocks of 64 bits in length. The key of the DES algorithm is the same length, but in the algorithm itself the youngest bits of each key byte are skipped leading to an effective key of 56 bits. The DES algorithm has never been broken, but it has too short a key and for this reason should not be used today. A method of lengthening the key in the DES algorithm is to use it three times with different keys. Triple DES involves encrypting a message with the *K1* key, then decrypting the result with the *K2* key and re-encrypting it with the *K3* key. This can be written as $$3DES{K1*| K2 | K3}(M)=DES{K3}*(DES^{-1}{K2}*(DES{K1}(*M)))$$. This extends the key to 192 bits (effectively 168 bits). 3DES is often used with a set of keys in which the first and third keys have the same value. In this case, the key will be 128 bits long (effectively 112 bits). DES and 3DES are presented in the FIPS 46-3 standard.

In 1997, NIST announced a competition for an algorithm that would become the new encryption standard and replace the DES algorithm. The finalists were the Rijndael, MARS, RC6, Serpent and Twofish ciphers. The AES*(Advanced Encryption Standard*) designation went to the first of these. AES encrypts 128-bit blocks using a key length of 128, 192 or 256 bits. Rijndael's initial specification also allowed 192- and 256-bit blocks, but these were removed from AES. The operation of the algorithm can be seen in this animation, the formal specification is presented in the FIPS 197 document. Currently, AES is the recommended way to encrypt data by NIST.

The algorithm worth mentioning is Blowfish, and not only because of its graceful name in Polish, which indicates a *blowfish*. It is quite popular in *open source* software, whose developers, for various reasons, do not want to use solutions recommended by government organizations. Blowfish encrypts 64-bit blocks using a key length ranging from 32 to 448 bits. Bruce Schneier, the algorithm's author, now recommends using its successor, the Twofish algorithm.

Encryption and decryption in Java can be implemented using the `Cipher`

factory. The name of the selected encryption algorithm, the type of complement and the so-called encryption mode (I will discuss them in the next post) are passed as a string. Like other algorithms, we will find them in the Standard Algorithm Name Documentation or in the documentation of the cryptographic service provider used.

The result of the following program will be to calculate the cryptogram for a single block (encryption) and transform it into the initial message (decryption) using the AES algorithm, without complement (we are encrypting the whole block, so it is unnecessary), in the *electronic codebook* mode (for the moment, we can assume that this mode is to *encrypt each block independently of each other*).

`1import javax.crypto.Cipher; 2import javax.crypto.spec.SecretKeySpec; 3 4public class CipherTest { 5 public static void main(String[] args) throws Exception { 6 byte[] plain = "abcdefghijklmnop".getBytes(); 7 byte[] key = "klucz--128-bitow".getBytes(); 8 9 SecretKeySpec secretKey = new SecretKeySpec(key, "AES"); 10 Cipher cipher = Cipher.getInstance("AES/ECB/NoPadding"); 11 12 // szyfrowanie 13 cipher.init(Cipher.ENCRYPT_MODE, secretKey); 14 byte encrypted[] = cipher.doFinal(plain); 15 16 // deszyfrowanie 17 cipher.init(Cipher.DECRYPT_MODE, secretKey); 18 byte decrypted[] = cipher.doFinal(encrypted); 19 } 20}`

An interesting effect of the program will be observed by extending the key to 256 bits. In users of the *HotSpot* VM, most often the `java.security.InvalidKeyException`

*Illegal key size or default parameters* exception will appear. This is not the fault of the key, for the AES algorithm a key of this length is correct. The limitation on the strength of cryptographic algorithms is a requirement in some countries and for this reason it is installed by default with the VM distribution. Once you download and install the *Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files* package for the appropriate Java version, this restriction will be lifted and the program will start working.

I encourage you to experiment on your own with other ciphers and block completions. Note that we store the secret key in the application's source code, which is not the best idea. Further problems arise in the process. If the user were to remember the 128-bit key and use it like a password then this is impractical in a real solution. The solution will be to convert user passwords into cryptographic keys.

## Summary

Encryption algorithms enable the *confidentiality* service. What happens if an attacker intercepts and disrupts the transmitted cryptogram? He will not be able to know the transmitted message (if a secure cipher is used, of course), but the recipient will decrypt the disturbed cryptogram. What he will receive will not be the original message. However, how is the recipient supposed to know this? From the point of view of cryptanalysis, such an attack will lead to the recipient accepting a fake message. Why was it successfully carried out? Cbavrjnż avr mncrjavbab *vagrtenyabśpv*. Qb ernyvmnpwv grtb pryh zbżan jlxbemlfgnć zrpunavmzl, xgóer whż cemrqfgnjvłrz. N j xbyrwalz jcvfvr bzójvę gelol fmlsebjnavn qyn fmlseój oybxbjlpu.