Application of symmetric and asymmetric encryption algorithms

Ruslan Rakhmetov, Security Vision

As we mentioned in a previous article, encryption is used to protect the confidentiality of information by converting it using cryptographic algorithms (symmetric and asymmetric), and hashing and digitally signing messages are used to protect integrity and authenticity. In this article, we will look at the practical application of symmetric and asymmetric encryption algorithms using various examples.

The first practical use of encryption dates back to the 6th century BC. In the Old Testament, the world's first Atbash cipher was used to conceal certain names and geographical names, which, according to modern classification, is a simple substitution cipher and a special case of substitution cipher. In such a cipher, each letter of the source text corresponds to one letter of the ciphertext. In particular, in the Atbash cipher, the first letter of the alphabet is replaced by the last letter (A -> Z), the second by the penultimate letter (B -> Y), etc. The Caesar cipher appeared around 100 BC and was used by Gaius Julius Caesar for secret correspondence. In this substitution cipher, each letter of the plaintext was shifted by a fixed number of positions to the left or right in the alphabet to obtain the final ciphertext (for example, 3 positions to the right: A -> D, B -> E, etc.The evolution of the Caesar cipher in the 15th century AD was the Vigener cipher, which used various character shift values, a keyword, and an alphabet table (the Vigener square). In addition to the substitution cipher, permutation ciphers were also used in ancient times, in which the letters of the plaintext are reversed. For example, in ancient Greece in the 5th century BC, the world's first Scytale encryption device was used, which consisted of a wooden block of a pre-determined diameter and a ribbon of parchment wrapped around it, on which the source text was written along the bar. and to hide (encrypt) the message, it was enough to unwind the tape.

Having gone from exclusively military and government applications, cryptography became available to ordinary people: in 1991, American programmer Philip Zimmerman developed the Pretty Good Privacy (PGP) program, which used asymmetric cryptography to encrypt and sign protected data (drives, files, and e-mail messages). The source code of this program was published in a book published by the Massachusetts Institute of Technology (MIT), despite the protests of the US government, which banned the export of certain types of cryptographic systems, equating them to weapons. In 1996, the developers of the Netscape Navigator browser created the SSL 3.0 protocol, which is the progenitor of modern TLS protocols for protecting information transmitted over the Internet. In the future, various encryption tools using symmetric and asymmetric encryption algorithms have been continuously improved, and today users regularly encounter the application of cryptography to protect network communications and stored data, correspondence in e-mail and messengers.

1. Application of symmetric and asymmetric encryption algorithms to protect network traffic.

Currently, more than 95% of all Internet traffic is encrypted, while by the end of 2023, the TLS protocol of the latest version 1.3 prevailed among all encrypted traffic. The TLS 1.3 protocol (Transport Layer Security) is used to encrypt data transmitted over the network, to authenticate the server and client, and to control the integrity and authenticity of the transmitted data. As part of traffic encryption, both symmetric and asymmetric algorithms are used at once: symmetric encryption works faster, but requires secure transmission of a secret key, for which asymmetric encryption is already used - the server's public key is contained in a publicly available certificate signed by one of the trusted certification centers (hereinafter referred to as the CC). If two-way authentication is required, the certificate is also issued to the client who connects to the site. A certificate can be issued for a specific domain or for a group of subdomains (Wildcard certificate), and the certificate fields must comply with the X.509 standard and include information about the certificate's publisher (which CC issued it), the validity period (which is continuously decreasing), the public key and the algorithm used to create it (recall, that asymmetric encryption involves the use of two keys - public and private, which is kept secret by the owner). In addition, the certificate (more precisely, the hash amount from the certificate) of the X.509 standard must be signed by the issuing user. The list of trusted users is stored in the operating system and in some browsers (for example, Mozilla Firefox supports its own list of trusted users, independent of the OS). The purpose of the certificate is not only to transfer the server's public key to the client, but also to verify that the address of the protected site corresponds to what is indicated in the browser's address bar to counter DNS spoofing attacks, in which attackers can replace the DNS server's response and display to the user the contents of the site, which is located on a domain controlled by them and is used, for example, to steal credentials. That is why it is important to always use HTTPS connections, check the site address in the browser's address bar and carefully heed browser warnings about an untrusted/invalid certificate for the site, as well as, if possible, use secure DNS analogues such as DNS-over-HTTPS (DoH), DNS-over-TLS (DoT), DNS-over-QUIC (DoQ), DNSSEC, DNSCrypt.

So, the TLS protocol uses a hybrid encryption scheme: asymmetric algorithms are used to establish an initial secure connection and to encrypt the transmitted symmetric encryption key, which is then used to protect traffic. The main components of the TLS 1.3 protocol are:

1) Hashing function. Older TLS protocols (1.2, 1.1) used the HMAC (Hash-based Message Authentication Code, hash-based authentication code, or hash-based authentication code) algorithm to verify the integrity and authenticity of encrypted messages. The TLS version 1.3 protocol uses HKDF (HMAC-based Key Derivation Function) to create symmetric encryption session keys, which are generated from shared secret data obtained from the Diffie-Hellman Elliptic Curve Protocol (ECDH, Elliptic-curve Diffie–Hellman) during procedures for starting a secure exchange (called Handshake, handshake). In addition to generating session keys, the hash function in TLS 1.3 is used to calculate the hash of all messages within the Handshake stage (Transcript Hash, transcript hash), as well as when creating certificate signatures - the hash amount is calculated from the text form of the certificate and then it is signed. Currently, the SHA256 and SHA384 hash functions are used, which are considered collision-free.

2) Digital signature. The server (and client's certificate in the case of mutual authentication - mutual TLS, mTLS) must be signed with a digital signature calculated using the ECDSA (Elliptic Curve Digital Signature Algorithm) or EdDSA (Edwards-curve Digital Signature Algorithm, digital signature on elliptical Edwards curves) algorithms. In addition, the hash of the Transcript Hash of the Handshake stage is digitally signed by the server to verify the authenticity of the connection being established.

3) The encryption algorithm. The TLS 1.3 protocol uses authenticated Encryption with Associated Data (AEAD), in which the message is encrypted and authenticated. For this, block ciphers are used that operate in certain modes, for example, AES-GCM (symmetric AES encryption in Galois/Counter Mode, counter with Galois authentication), or ChaCha20-Poly1305 (symmetric stream encryption algorithm ChaCha20 with Poly1305 function to generate a message authentication code). In modern infrastructures, the algorithm that is best suited for the devices used is chosen. For example, many modern desktop and server processors have hardware support for AES, and the ChaCha20 algorithm has proven itself well for portable devices with low power consumption.

The list of symmetric and asymmetric encryption algorithms used by the site (Cipher Suites) can be viewed through the developer Tools (in Chromium-based browsers) or in the connection properties next to the address bar (in Mozilla Firefox browser), as well as using network traffic sniffers. In addition, you can check the list of cipher suites and TLS protocol versions supported by the site on special resources. For example, the TLS_AES_128_GCM_SHA256 cipher suite indicates that the site uses the AES algorithm with a key length of 128 bits in GCM mode and the SHA256 hash function, and the TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 cipher suite indicates that the site uses an algorithm for generating ephemeral (temporary) keys using the Diffie-Hellman protocol on elliptical curves, digitally signing the site's certificate using elliptical curves, the symmetric algorithm ChaCha20 stream encryption with Poly1305 function for generating message authentication code and SHA256 hash function. The list of possible cipher suites is regulated and listed in the IANA registry, and the visualization of the TLS connection can be viewed on various resources.

2. Use encryption to protect the stored data.

Encryption tools are also used to protect files, partitions, and entire disks. For example, you can use BestCrypt, PGP Whole Disk Encryption (PGPDisk), and Veracrypt programs to encrypt disks and files. The principle of operation of such solutions is simple: the programs use symmetric block encryption algorithms (for example, AES, Serpent, Twofish, Camellia) with an encryption key, access to which is protected by a user password. There are also solutions built into various operating systems: BitLocker for Windows, LUKS (Linux Unified Key Setup) for Linux, FileVault for macOS - these solutions support storing disk encryption keys in dedicated hardware modules (TPM chip for BitLocker and LUKS, T2 Security Chip or Secure Enclave coprocessor for FileVault). A special feature of BitLocker for Windows non-corporate versions, for example, Windows Home 10/11, is that the BitLocker recovery key is saved in the Microsoft cloud by default, and in corporate versions you can limit yourself to saving the recovery key locally (as a printout or in a file on a USB stick). In all cases of using TPM, you should set an additional strong password to unlock access to the encrypted disk (TPM+PIN mode), as well as ensure the secure storage of BitLocker and LUKS recovery keys.

3. The use of encryption to protect correspondence in e-mail and messengers.

To protect correspondence, both the communication channel and the messages themselves should be protected from access by third parties.

3.1. To protect mail traffic, you can use TLS-based protocols of the Implicit TLS family (SMTPS, IMAPS, POP3S, described in RFC 8314) or the STARTTLS protocol (Explicit TLS or Opportunistic TLS, described in RFC 3207, it is subject to a STRIPTLS attack on the used opportunistic encryption). A more modern way to protect mail traffic during transmission would be to use the MTA-STS (Mail Transport Agent Strict Transport Security, described in RFC 8461) and TLS-RPT (SMTP TLS Reporting, described in RFC 8460) mechanisms, which respectively enforce the use of TLS (versions 1.2 and 1.3) to protect SMTP mail traffic and the exchange of error reports on setting up an encrypted connection between mail servers. You can use special services to verify the encryption protocols supported by the mail server. Corporate collaboration systems typically use the TLS protocol to protect traffic by default, and popular messengers use various protocols to protect connections - for example, Telegram uses its own MTProto cryptographic protocol to protect messages between clients and servers, and WhatsApp uses the XMPP (Extensible Messaging and Presence Protocol) protocol with TLS, described above in RFC 7590.

3.2. In addition to encrypting mail and messenger traffic, it is important to protect the messages themselves from access by third parties on servers that process correspondence (mail servers and messenger servers that store messages until they are delivered to the recipient if he temporarily does not have the Internet, for example). To protect the contents of messages from unauthorized access, end-to-end encryption (E2EE) technology is used, in which only the recipients and sender can read the message, but not the server owner or whoever managed to break into the communication channel and intercept the messages. For example, in a corporate environment, PGP and S/MIME (Secure/Multipurpose Internet Mail Extensions) technologies are used to protect e-mail messages, which, by analogy with TLS, use a hybrid encryption scheme: asymmetric algorithms are used to encrypt the transmitted symmetric encryption key, which is used to quickly encrypt messages and transmitted files. If there are several recipients of a message encrypted with a symmetric algorithm, then the secret key is encrypted for each recipient individually using their public keys.

Some popular messengers (WhatsApp, Signal, Session, Element, Telegram in the "secret chat" mode) end-to-end encryption technology is also used, and if the user connects an additional device (for example, opens a web messenger session on a PC), then the main device (smartphone) establishes a direct encrypted connection to the PC and duplicates the information decrypted on the smartphone there, which does not violate the E2EE principle - messages are decrypted only on one device that securely stores encryption keys and does not transfer them anywhere else. Various classic Internet messengers, such as Jabber and Pidgin, use the OTR (Off-the-Record Messaging) plugin, which provides message encryption and authentication of participants in the correspondence. Another protocol, Tox, is also actively used to provide end-to-end E2EE encryption of messages and video communications.