Encryption and Hashing Application
Encryption techniques have been around for thousands of years. Still, the advent of computing devices has meant that ever more complex encryption mechanisms are required to resist brute force attacks of encoded information. Modern encryption mechanisms revolve around using cryptographic keys and mathematical-based algorithms to encode data resistant to decoding without access to the keys. The terminology we will use is that the original uncoded information is referred to as plaintext, and the output of the encryption process is referred to as ciphertext.
Hashing is a technique using a defined algorithm to generates a value based on the contents of information that can be used to indicate if the information is subsequently changed. This can be used to protect messages in transit between a sender and recipient or data at rest in a storage device. Hash values are not secret. They can be recreated by anyone that knows which hashing algorithm to use. Hashing is used alongside encryption techniques to provide data integrity and non-repudiation checks.
This article will explain both encryption and hashing, along with digital signatures that utilize hashing principles. We will look at different forms of encryption and hashing, along with some standard algorithms.
Encryption and hashing between them can offer multiple benefits:
- Encryption prevents eavesdroppers on an insecure communications channel such as the internet from reading information passing over that channel.
- Encryption prevents malicious actors from accessing or modifying sensitive information on network-connected shared or personal storage devices.
- Encryption and hashing prevent malicious actors from intercepting and altering information passing across an insecure communications channel.
- Hashing prevents malicious actors from modifying sensitive information on network-connected shared or personal storage devices.
- Encryption and hashing provide a level of proof that the sender of the information is who they say they are by authenticating their identity.
- Encryption and hashing provide an assurance to the recipient that the information’s sender cannot subsequently alter or deny sending that information.
There are two primary forms of encryption in common usage, symmetric and asymmetric encryption.
- Symmetric encryption is an encoding technique where the encryption and decryption processes use a single shared key. Cryptographic keys are, in essence, an alphanumeric string with a set number of characters. These characters can be manually chosen or randomly generated. Symmetric encryption is also known as secret key encryption. The security of communications is dependent on the protection of the encryption key.
- Asymmetric encryption is an encoding technique where the encryption process uses an openly shared public key. The decryption process uses a second secret key known only to the recipient. Asymmetric encryption is also known as public-key encryption.
We will now look at these two types of encryption in more detail.
Symmetric encryption relies on using a mathematically based algorithm that can encrypt and decrypt data using the same secret key, hence the symmetry from which the name is derived. The main advantage of symmetric encryption is that using a single key is simpler to implement and requires less processing than other more secure encryption forms.
The use of a single shared key necessitates implementing a secure method of sharing the key between the sender and receiver. Symmetric encryption relies on the sender and recipient having access to the same cryptographic key while ensuring that no other third-party such as an eavesdropper or interceptor has access to that key. This technique will only be secure if the sender and recipient can securely share the key and guarantee that no other party can access that key.
Traditional approaches relied on the physical transfer of keys between the two parties. Electronic exchange techniques such as the Diffie–Hellman key exchange have been developed to enable the secure exchange of cryptographic keys over a public network. One limitation of the Diffie–Hellman key exchange is that it does not prevent a malicious actor from pretending to be the intended recipient. This would allow the attacker to complete the key exchange using their own public and private keys.
Symmetric encryption is straightforward to implement. The sender takes plaintext, uses the secret key to encode the plaintext into ciphertext using an encryption algorithm, and then sends the ciphertext over a communications channel. The recipient receives the ciphertext and uses the secret key to decode the ciphertext back into plaintext using the same encryption algorithm to access its information.
The Encryption Algorithm
A cipher function takes the plaintext and breaks it up into pre-set blocks of data. The encryption algorithm then takes each block and performs a mathematically based calculation using the plaintext block and the secret key to create a ciphertext block. The size of the blocks will depend on the particular encryption algorithm selected. This technique is known as a block cipher for evident reasons.
The implemented symmetric encryption will then concatenate the ciphertext blocks and transmit them as an encrypted message in its simplest form. However, a weakness with symmetric encryption is that it is deterministic in nature, so that if two or more plaintext blocks are the same, then the corresponding ciphertext blocks will also be the same. This opens up the encrypted message to analysis to look for patterns and deduce the secret key by guessing what information those repeated blocks may contain. Typically, messages contain header information or standard blocks of text, such as a disclaimer or copyright statement that an attacker can use to reverse engineer the secret key from the ciphertext blocks. While session keys can minimize the risks of messages containing sufficient repeated text to allow deduction of the private key, it still remains an avoidable risk to the communications’ security.
Simple block encryption
One solution is to use a plaintext block’s contents to generate a seed value used to alter the next plaintext block’s encryption. Any subsequently repeated plaintext blocks will not generate the same corresponding ciphertext blocks. By adding a dependency on previous data into the encryption algorithm, effectively chaining the blocks together, any attempt to analyze the encrypted data to deduce the secret key will become considerably more complex. The initial seed value does not need to be secure; the sender can share this data with the recipient in plaintext as part of the message stream. Using a randomly generated seed data block that changes with each message offers the best protection against attacks based on the analysis of the encrypted data.
A downside to this approach is that the message’s corruption in transit will prevent decryption of the message from where the corruption occurred to the end of the message. With the simple block encryption approach, only the block affected by the corruption would be lost. This can place a significant bandwidth overhead if the transmission route is subject to interference.
Cipher block chaining
When generating the final data block, padding data will generally be required unless the plaintext size happens by chance to be an exact multiple block size. A common technique is for the padding to be the numerical value of the padding’s size to ensure that the decryption process correctly recognizes what part of the block is padding. This ensures that the decryption algorithm does not incorrectly identify message data as padding data.
Decoding the ciphertext simply requires breaking the received message into the correct pre-set blocks of encrypted data and performing a reversal of the mathematically based calculation with the secret key to recreate the plaintext blocks. These blocks are then joined back together to recreate the original plaintext.
One downside of using a block cipher technique is that it does not provide a practical solution where plaintext is generated on a random or pseudo-random basis in real-time and requires encryption and transmission on an as-required basis. Collating the plaintext data into the pre-set blocks can add significant latency to the data and needs data to be stored in a vulnerable unencrypted state while waiting for sufficient data to form a block to be available. The solution is to use a cipher feedback technique where data is encrypted as soon as it is available.
This technique basically starts with a randomly generated seed data block. Then as real data becomes available, it is added to the end of the block, and the corresponding number of bits are removed from the start of the data block. The data block can then be encrypted and transmitted as for the block encryption mode. As new data becomes available, the process is repeated, with the bits in the data block being shifted to the left as new data is added to the right-hand end. This technique can accommodate the transmission of data of any size. However, the smaller the size of data added each time a new message is transmitted, the greater the processing overhead due to performing the encryption algorithm processing each time.
Asymmetric encryption is an encoding technique where the information sender encrypts the data using the recipient’s public key. Hence, it is also known as public-key encryption. The encrypted data can then only be decoded by the recipient using a second private key known only to them. This allows the encrypted data to be sent over any open channel where interception by a third party will not compromise the data as long as the encryption method is sufficiently strong to resist attack. The strength will be dependent both on the encryption algorithm used and the length of the keys. Asymmetric encryption relies on using a mathematically based algorithm that can encrypt information using one key but requires a second, different key to decrypt the information. The key used for encryption cannot be used for decryption, hence the asymmetry from which the name is derived. The two keys are mathematically related, the public and private keys being generated as a pair. However, the relationship’s nature is such that an attacker cannot derive the private key from the public key.
All parties involved in the communications have a private key known only to them and a public key known to everyone. The sender takes plaintext, uses the recipient’s public key to encode the plaintext into ciphertext, and then sends the ciphertext over a communications channel. The recipient receives the ciphertext, uses their private key to decode the ciphertext back into plaintext to access the information it contains.
The advantage of asymmetric encryption is that it does not require the secure sharing of keys. The public encryption key can be openly shared and will not enable the decryption of the data. The private decryption key is only required by the receiving party and so will never be shared. The main disadvantage of asymmetric encryption is the encryption and decryption processes are relatively slow and can cause significant latency issues. Another disadvantage of asymmetric encryption is that once a private key is discovered, the confidentiality of all communications past and present using that key is compromised. However, it is straightforward for the individual to generate a new public/private key pair and then publish the new public key for any subsequent communications. This is far simpler than sharing a new symmetric encryption key.
Asymmetric Key Generation
Typically, the public and private keys are long, relatively prime numbers generated from a pair of shorter prime numbers. In a simplified example based on the key generation for the RSA algorithm, two initial prime numbers A and B, are selected. The public key comprises two parts. The first part of the public key C1 is simply calculated from A*B. The second part of the public key C2 is selected using the criteria that C2 and the result of (A-1)*(B-1) are both relatively prime. That is, the two numbers share no common factors. For comprehensively secure asymmetric encryption, these two numbers should themselves be prime numbers, but processing limitations make this impractical given the size of the numbers involved. Typically, the RSA algorithm uses either 512-bit or 1024-bit keys.
Once a value for C2 is chosen, the private key D can then be calculated from C2-1 MOD ((A-1)*(B-1)). The public key C (C1 and C2) can then be published, and the private key D stored securely on the device that will perform the decryption process. The original numbers A and B are no longer required, but they must never be disclosed or retained as their compromise would allow an attacker to deduce the private key D’s value. Given the mathematical relationship between keys, it will take less processing power to derive a private key corresponding to a known public key. This is the reason why key lengths for asymmetric encryption are significantly longer than for symmetric encryption. A more complete explanation of the RSA algorithm can be found here.
Typically, a 512-bit asymmetric encryption key offers a similar resistance to brute force attack as a 64-bit symmetric encryption key. The asymmetric encryption key would need to be over 2,304 bits in length to achieve an equivalent resistance as a 128-bit symmetric encryption key. However, the main vulnerability for asymmetric encryption keys is weaknesses in the algorithm used to create the key pair that would allow the private key to be derived from the public key using a mathematical calculation rather than a brute force attack. Therefore, asymmetric encryption protection relies on the integrity of the algorithm and the absence of any weaknesses. Microsoft has produced a more detailed guide for the symmetric and asymmetric key generation here.
The Encryption Algorithm
As for symmetric encryption, a cipher function using a block cipher technique takes the plaintext and breaks it up into pre-set blocks of data. The encryption algorithm then takes each block and performs a mathematically based calculation using the plaintext block and the recipient’s public key to create a ciphertext block. The size of the blocks will depend on the particular encryption algorithm selected, specifically the key length. In the case of the RSA algorithm, the block size in bytes is simply the integer result of dividing the key length in bits less one by eight. That is, for a 512-bit key length, the block size is INT ((512 – 1) / 8) bytes.
In the case of RSA, the encryption algorithm is simply calculated from:
ciphertext = plaintext C2 MOD C1
where C1 and C2 are the two parts of the public key
The ciphertext block is the remainder when the plaintext block is converted to a numerical value, raised to the power of the second part of the recipient’s public key, and then divided by the first part of the recipient’s public key. A key difference between asymmetric and symmetric encryption is that the ciphertext block’s length is the same as the length of the plaintext block for symmetric encryption. For asymmetric encryption, the ciphertext block’s length is the same as the length of the encryption key modulus and so will be longer than the plaintext block from which it is calculated.
The implemented asymmetric encryption will then concatenate the ciphertext blocks together and transmit them as an encrypted message. Padding is added to the plaintext to ensure the message is an exact multiple of the block size.
The security of asymmetric encryption is such that it is unnecessary to introduce dependencies between a ciphertext block and the preceding block. The advantage is that a ciphertext block corrupted in transmission will not prevent decryption of subsequent ciphertext blocks, making this technique more resilient than symmetric encryption that uses a cipher block chaining technique.
In this RSA example, the ciphertext can be decrypted by the recipient simply using the following calculation:
Plaintext = ciphertext D MOD C1
where C1 is the first part of the public key and D is the recipient’s private key
The security of the encrypted information is directly dependent on the sender and recipient’s ability to share the secret key and keep it secure while in their possession.
Without access to the secret key, an eavesdropper or interceptor can only access the information if they can steal or deduce the key. One attack option is to try every possible key until the correct one is found, known as a brute force attack. Modern processing facilities can undertake millions of operations per second, but using a secret key of 64 bits or greater would make the average time required sufficiently long enough to guarantee security.
For example, a 32-bit key has 232 possible values, which equals 4,294,967,296. If an attacker has access to sophisticated processing facilities that can test 1000 keys per second, it will take around 50 days to try every key. The law of probabilities states that, on average, it would take 25 days to find the correct key. By changing to use a 64-bit key, this figure changes to an average of around 290,000,000 years.
Another attack option is to guess the secret key based on the assumption that it was logically derived rather than randomly generated characters. Also known as a dictionary attack, the private key’s security is now down to its complexity. A key based on words found in a dictionary would be simple to break within a reasonable period to render communications insecure.
The mathematical encryption algorithms themselves may also contain weaknesses and flaws that an attacker could exploit to either deduce the keys used or directly decode the encrypted information without the need for the key. All popular encryption algorithms are subject to extensive cryptoanalysis by users seeking to identify and resolve issues and attackers seeking to find a previously unidentified flaw. Attackers, in this case, will be highly organized and sophisticated nation-state actors such as intelligence agencies. Finding and exploiting a flaw in an encryption algorithm used worldwide offers a significant incentive to invest vast sums of time and large budgets.
For example, the original Wired Equivalent Privacy (WEP) algorithm used for Wi-Fi communications should not be used due to the number of flaws that have been identified that render this algorithm insecure. The nature of the weaknesses meant that an attacker could deduce the encryption key within a few minutes by simply monitoring the encrypted traffic.
The simplest method of compromising encryption is to steal a copy of any cryptographic keys from one or more of the parties involved in the secure communications exchanges. Malware introduced onto a computer used for encryption processing can steal key information from the repository where keys are stored, from dynamic memory during the encryption process, or by monitoring the user as they enter into the computer. This requires significantly less knowledge, resources, and time than attempting to undertake crypto-analysis on message data or perform a brute force attack. Users undertaking encryption to protect sensitive information should be carrying out regular checks of devices, including anti-virus scans and log file reviews for suspicious security events.
Application and Algorithm Weaknesses
The last attack option is to use known flaws or weaknesses in the encryption algorithm to deduce the secret key based upon analysis of the encrypted data. The majority of software applications contain weaknesses, flaws, and vulnerabilities that can be exploited once identified. This is no different for applications used to implement encryption and decryption processes.
Several popular encryption algorithms have been found to contain defects, either in the underlying mathematical algorithms or in the software that implements the algorithms. Using knowledge of which algorithm has been used, it may be possible to deduce the secret key within a reasonable period. Common faults include errors in the key generation that restrict the total possible number of keys that can be generated for a given key length. This reduces the time necessary to undertake a brute force attack should the attacker be aware of the flaw and restrict the guessing process to use only that subset of keys that the key generation algorithm will allow. Such defects are rare but not impossible. The Sweet32 attack identified cipher design weaknesses that could be exploited, an interesting article on how this was achieved can be found here.
We have seen how symmetric encryption is vulnerable to unauthorized decoding by either analyzing the encrypted data to deduce the secret key or through an attack on the sender or recipient to steal the private key. Using the same key for all communications between the sender and recipient means all communications will be compromised if the key is compromised. A standard solution is to create a new secret key for every communications session established between the sender and recipient. This ensures that only those communications undertaken during the session will be at risk of unauthorized access when that key was in use if a key is compromised. This concept is known as perfect forward secrecy. The compromised key only allows the attacker to see communications using that key. This solution then emphasizes that the method of sharing the key at the start of each session must be sufficiently secure.
Practical Implementation of Encryption
The mathematical algorithms for asymmetric encryption and decryption are different and significantly more complex than the mathematical algorithms required for symmetric encryption/decryption. As a result, asymmetric encryption requires more processing power to achieve the same protection level as symmetric encryption. Also, where a sender needs to send a message to multiple recipients, using asymmetric encryption would require the sender to separately encode the data sent to each recipient using their public keys. With large numbers of recipients, this places an enormous processing overhead on the sender.
In practice, secure information communications protocols utilize both asymmetric and symmetric encryption. They combine the advantages of each to deliver an optimum balance of security and throughput. While symmetric encryption with lower processing and latency overheads is used for information encryption, asymmetric encryption is used to securely share the secret symmetric encryption key used for the communications session. This delivers the required secure key sharing for all parties involved in the communications. Where there are many recipients, the sender is only required to separately encode the secret key for the symmetric encryption sent to each recipient using their public keys. The symmetric encryption is then common for all recipients.
Where encryption is used for protecting information at rest in local storage, such as whole disk encryption, there is no requirement to share the encryption key. In this case, the key, typically based on a memorable password, is known only to the storage device user. Here, symmetric encryption is utilized to provide adequate protection with minimum access latency. For example, the Bitlocker application, which Microsoft has integrated into the currently supported versions of the Windows operating system, uses the AES symmetric encryption algorithm with options for an efficient 128-bit key or a more secure but slower 256-bit key.
The Dark Side of Encryption
Encryption algorithms are not only used to protect the confidentiality of information. Ransomware uses symmetric encryption to encode information on an infected device, preventing that device’s authorized user from accessing the data. Typically, the malware that implements the ransomware function will employ a key stored on a remote server under the attacker’s control responsible for distributing the malware. Following a ransom payment, the attacker may provide the victim with the key to decode and recover their information. If the victim is lucky and the attacker is lax, the encryption key may be hard-coded as part of the malware. Analysis of the software can uncover the key without resorting to paying the ransom. Suppose the victim is unlucky and the attacker is callous. In that case, the encryption key may be randomly generated and not stored, meaning that there will be no practical method of decoding the data, even if the ransom is paid.
Analysis of the ‘Ransom Warrior‘ ransomware identified that there were 1,000 keys hardcoded in the software. When allowed to execute, this malware then chose one of these keys at random. This allowed security researchers to develop a decoding utility that simply tried each of the uncovered keys in turn until the correct key was found.
Analysis of the ‘WannaCry‘ ransomware identified that the prime numbers used to generate the encryption key were not cleared from memory after the encryption key was generated, allowing the key to be recreated by inspection of the device’s memory.
Of course, the simple solution to recover from a ransomware attack is to restore the infected device’s contents from a backup taken from before the infection occurred. Even if the malware is proficiently written to retain and store the encryption key on the attacker’s remote server, there is no guarantee that they will release that key after the ransom is paid.
Hashing functions are used to create a unique fingerprint of a message that can be used to identify if that message is subsequently altered. This provides assurance of the integrity of the information contained in the message, preventing an attacker from intercepting the message, changing the content, and then forwarding the message to the recipient. Hashing functions work by using a mathematical algorithm that takes the message’s contents and generates a hash code representing the content.
Hashing functions can be used for encrypted communications to provide additional assurance. Still, they are equally helpful for unencrypted communications where the information shared is not sensitive, but it must be correct. An example is downloading software, either in the form of a complete application or an update, particularly security patches. It is imperative that the downloaded software is not intercepted and altered in transit by an attacker looking to introduce malware into the software. Malware successfully introduced into a security patch is a sure-fire method of infecting a target computer. It avoids the majority of security controls intended to block such an attack vector. By adding a hash code to the function that is published by the original software provider, the downloaded software can be verified that it has not been altered by regenerating a hash code for the downloaded software and cross-checking against the original hash code.
A hashing function takes the message and breaks it up into pre-set blocks of data. The hashing algorithm then takes each block and performs a mathematically based calculation using the message block to create a hash code. The size of the blocks will depend on the particular hashing algorithm selected. Like symmetric encryption techniques, the hashing function adds a dependency on previous data into the hashing algorithm, chaining the blocks together to generate a single hash code for the entire chain. This technique ensures that any message block changes will cascade through to the final calculated hash code. The hashing algorithm will define the initial seed value to ensure that different users generate identical hash codes for the same message. When generating the final message block, padding data will usually be required unless the message size happens by chance to be an exact multiple block size.
Hashing function schematic
One limitation of hashing algorithms is that depending on the hash code’s size limit, the greater the original message’s length, the more likely it will be that the hash code may not be unique. For very long messages in the order of 264 bits or more, an attacker can alter the message to generate the same hash code relatively simply. This is because there are potentially infinite different messages but only 2L possible hash codes, where L is the length in bits of the hash code. The question then becomes how quickly an attacker can subtly change their altered message until they create a message with an identical hash code to the original message. A common approach to guard against this possibility is to use a secret key shared between the sender and recipient as the first message block passed to the hashing algorithm.
There may also be a situation where the original message’s creator may seek to create an altered version with the same hash code for nefarious purposes, such as changing a contract’s terms after acceptance by the recipient. Creating two different messages and adjusting their content until they produce identical hash codes will take significantly less time than attempting to change the altered message to match the original fixed message. This can be demonstrated using the analogy of the birthday paradox. Given a group of people in a room, the probability of any two people sharing the same birthday is significantly greater than the likelihood of one person sharing the same birthday as a fixed date.
A simple solution would be for the recipient to request two hash codes be produced using two different hashing algorithms. This renders the likelihood of an altered message producing both hash codes correctly improbable. An alternative is the use of a digital signature.
A digital signature is a technique based on the hashing function that can authenticate a message to provide assurance that it was sent by the person claiming to have sent it and assuring its integrity. The signature is generated using a hashing algorithm that takes the message’s contents and the private key of the asymmetric encryption key pair belonging to the sender. This fulfills two functions. It assures the message’s integrity as any change to the message content would invalidate the digital signature. It also confirms the identity of the sender as long as their private key remains secure. This technique prevents an attacker from attempting to deceive the recipient by intercepting and changing a message while in transit from the sender to the recipient. It also prevents an attacker from trying to trick the recipient into thinking a message sent by the attacker is from the sender. As previously covered in the section on asymmetric encryption, all parties involved in the communications have a private key known only to them and a public key known to everyone.
The sender takes plaintext and uses the recipient’s public key to encode the plaintext into ciphertext. The sender then uses a hashing algorithm to create a hash code for the ciphertext and uses their private key to create a digital signature based on the hash code. The ciphertext and digital signature are then sent to the recipient over the communications channel. The recipient receives the ciphertext and digital signature and uses the sender’s public key to verify that the received digital signature and ciphertext are valid by recreating the hash code for the received ciphertext. The recipient can then use their private key to decode the ciphertext back into plaintext to access the information it contains. In this process, both the sender and recipient must have a public and private key pair. Microsoft has produced a more detailed guide for cryptographic digital signatures here.
Digital signatures are based on a hash code of the ciphertext rather than the message itself. This is significantly more efficient than using asymmetric encryption techniques to digitally sign the entire ciphertext message. Digital signatures can be used to authenticate multiple parties’ agreement to the contents of a message if it represents a contract or similar legal agreement. A copy of the message is shared with all parties who each digitally sign the message by generating a hash code and using their private key to create their signature. These signatures can then be shared between all parties, where they can be validated using the public keys for the parties. This provides assurance that the digitally signed message is identical for all parties and that each has identified themselves using their private key. This prevents any attempt by any party to either alter the agreed message or deny signing the message.
This solution’s security depends on all parties keeping their private keys secure and using a hashing algorithm that is sufficiently secure that the message cannot be altered so that the hash code for the message does not change. Given that the typical application of digital signatures is for contractual agreements that may be valid for many years, the asymmetric key generation algorithm and hashing algorithm must be sufficiently robust to resist brute force attack or cryptanalysis techniques duration of the contract.
Symmetric Encryption Algorithms
The DES (Data Encryption Standard) algorithm is one of the oldest algorithms still in fairly common usage. It was created by IBM to protect US federal information and entered usage in the 1970s. It went on to be used in versions 1.0 and 1.1 of the TLS (Transport Layer Security) protocol. DES uses a 56-bit encryption key, operating on 64-bit data blocks and producing 64-bit ciphertext blocks. The relatively short key length means that DES is no longer considered sufficiently secure and has been superseded by the 3DES algorithm and, in most applications, replaced by the AES algorithm.
The 3DES (Triple Data Encryption Standard) algorithm is an updated version of DES that entered usage in the 1990s. It works by effectively encrypting each data block three times using the DES algorithm with three 64-bit keys to make brute force cracking more difficult relative to the DES algorithm. While the three 56-bit keys, in theory, represent a total 168-bit key length, commonalities in the repeated algorithms reduce this effectiveness to being broadly equivalent to a 112-bit key. Following the identification of vulnerabilities in the 3DAS algorithm, its use is being decrepitated. While still used in hardware encryption products, it is no longer used for version 1.3 of the TLS protocol, and its use is expected to formally end in the 2020s.
The AES (Advanced Encryption System) algorithm has been the standard symmetric encryption algorithm in everyday use worldwide since the early 2000s. The main difference from DES is that the algorithm can accommodate a range of key lengths. The most common key length is 128 bits that deliver the most efficient encryption speeds, but 192-bit and 256-bit keys are commonly used to provide more robust security. The block sizes for the plaintext and ciphertext will depend on the key size. The complexity of the mathematical operations undertaken by the algorithm also increases with key length. This enables the balance of processing overhead and security protection to be tuned to the specific application the algorithm is used for.
The Blowfish algorithm is an open-source replacement for DES developed by Bruce Schneier, using the same 64-bit block size. It uses the simple block encryption technique to deliver very fast encryption speeds, which, along with its license-free availability, have made its use popular in eCommerce applications.
The Twofish algorithm has been developed by Bruce Schneier to replace the Blowfish algorithm. The main difference is that it accommodates keys of up to 256 bits in length while maintaining very fast encryption speeds.
Asymmetric Encryption Algorithms
The RSA algorithm is named after its developers, Ron Rivest, Adi Shamir, and Leonard Adleman. The RSA algorithm was created in the 1970s and is one of the oldest asymmetric encryption algorithms and is still in common usage. Its longevity is due to the principle of using two large random prime numbers to generate keys. The RSA algorithm can accommodate a range of key lengths, including 768-bit, 1024-bit, 2048-bit, 4096-bit, and onwards. A study in 2010 concluded that breaking a 768-bit RSA key would require more than half a million hours of processing time. The current standard key length is 2048 bits. RSA can be found in a broad range of applications, including SSL/TLS certificates, message encryption, and crypto-currencies.
Stream Cipher Encryption Algorithms
The RC4 (Rivest Cipher version 4) algorithm is named after its developer Ron Rivest, a member of the team behind RSA. The RC4 algorithm was created in the 1980s, designed to operate on a data stream on a byte by byte basis. It has gained almost universal use for stream cipher applications due to its rapid encryption speeds. It is used in Secure Socket Layer (SSL), Transport Layer Security (TSL), and IEEE 802.11 wireless networks. The RC4 algorithm is flexible in that it can use either a 64-bit or a 128-bit key length.
The MD5 (Message Digest version 5) algorithm was developed by Ron Rivest, a member of the team behind RSA. This algorithm produces a 128-bit message digest (another name for a hash code) by applying a block algorithm technique, dividing the message into 512-bit blocks and then mathematically operating on 32-bit sub-blocks. Will originally intended to provide checksums for application integrity checks, it became popular for hashing functions. However, the hash code length means that this algorithm can be susceptible to hash collision weakness where two different messages can produce the same hash code. This has led to the replacement of MD5 with the faster and more secure SHA.
The SHA-1 (Secure Hash Algorithm version 1) is based on the MD5 algorithm but generates a 160-bit hash code to reduce hash collision weakness. It was developed in the 1990s by the US National Security Agency (NSA) but was replaced in the 2010s following the identification of implementation weaknesses that made it vulnerable to attack.
The SHA-2 (Secure Hash Algorithm version 2) has been developed by the US NSA as the replacement for SHA-1 and covers a family of hashing function algorithms of varying hash code length. The most commonly used variants are SHA-256, SHA-384, and SHA-512. The number in the hashing function name equates to the size in bits of the generated hash code.
The SHA-3 (Secure Hash Algorithm version 3) family has been developed outside of the US NSA and is intended to address flaws identified in the implementation of the SHA-2 algorithm. The variants all produce the same hash code length options as the SHA-2 family but using different internal algorithms to generate the hash codes. While not yet in common usage, depreciation of SHA-2 is expected when exploits for the known flaws become available.
The processing power available to nation-states and organized criminal syndicates continues to grow. There will be a point where the time required to brute force the encryption techniques available is sufficiently quick to render these techniques insecure. Traditionally encryption techniques have evolved by using ever-longer keys and more robust algorithms, but this brings an additional processing overhead that adversely affects latency.
Going forward, quantum cryptography, or quantum key distribution (QKD), is seen as a potential breakthrough solution that could deliver unbreakable encryption. It relies on a fundamental principle of quantum mechanics in that observing an elementary particle’s state will change that particle’s state. This means, in essence, that it is impossible to eavesdrop on a message without detection. For further reading, QuantumXC explains Quantum Cryptography on their website, and they have an interesting article published in Forbes.
Another interesting development is the concept of Honey Encryption, where an attacker attempting to brute force deduce a password is presented with a believable but false decoy password. Any attempt to use that decoy password can initiate an action such as raise the alarm, block logical access, or other control measures that impede the brute force attack. McAfee has produced a blog post that provides more information here. A more detailed explanation can be found in this research paper covering Honey Encryption, Security Beyond the Brute-Force Bound.
Cisco basic explanation of encryption algorithms: What Is Encryption? Explanation and Types - Cisco
Cloudflare basic explanation of encryption algorithms: What is encryption? | Types of encryption | Cloudflare UK
Electronic Frontier Foundation overview of how asymmetric encryption works
UK’s Information Commissioner’s Office practical guidance for implementing encryption and links to further reading Encryption scenarios | ICO