Which of the following is the strongest symmetric cryptographic algorithm?

DES and 3DES

The U.S. government developed Data Encryption Standard (DES) in 1977 as an official cryptography standard; it is still used widely. DES formed the basis of the first automated teller machine (ATM) personal identification number (PIN) code authentication and until recent years existed as the primary authentication encryption method for UNIX machines. DES is a block cipher using a 64-bit block size with a 56-bit key length. In early 1990 it was proven insufficiently secure given current hardware capabilities and that it was possible to exhaust all potential DES key combinations in less than a day. Triple DES (also known as 3DES) emerged to address DESs shortcomings. 3DES uses standard DES encryption cycled over itself three times, with one cycle using a different set of encryption keys. This was a simple yet easy way to effectively increase the key size from 56-bit to 168-bit, thus increasing its security, but it obviously takes three times longer than DES to encrypt the data.

DES is probably nearing the end of its useful life, and 3DES is not as efficient as other algorithms, but they both still dominate as the algorithms of choice. Many programmers feel more comfortable using these algorithms because of their compatibility and wide acceptance.

The .NET Framework provides access to these algorithms through the DESCryptoServiceProvider and TripleDESCryptoServiceProvider classes. Note that both of these classes are managed wrappers that call the unmanaged Win32 CryptoAPI functions. Figures 4.2 and 4.3 demonstrate the use of 3DES encryption.

TIP

Although DES and 3DES do not use managed code, you can get some open-source implementations of these classes that contain fully managed code. Open-source implementations of the .NET Framework include the mono project (www.go-mono.com) and DotGNU Portable .NET (www.southern-storm.com.au/portable_net.html). Note, however, that the native .NET Framework classes that call the CryptoAPI have been FIPS 140-1 certified (see http://csrc.nist.gov/cryptval/140-1/1401vend.htm).

DES does have some keys that you must avoid because they are weak. In fact, there are four keys that produce the same subkeys in every round. This means that if you encrypt data with one of these keys and then encrypt that encrypted data again with the same key, you will end up with the original plaintext message. In addition to these weak keys are 12 semi-weak keys. Semi-weak keys work in pairs, where one key decrypts data encrypted with the first. ASP.NET allows you to check for these with the IsWeakKey and IsSemiWeakKey methods. You can view the actual source code for the IsWeakKey method in Figure 4.4 and the IsSemiWeakKey method in Figure 4.5.

TIP

You can download the source code for the .NET Framework cryptography base classes at www.gotdotnet.com/team/clr/samples/eula_clr_cryptosrc.aspx.

Note that automatically generated keys and those from the GenerateKey method will never produce weak keys, and the chances of randomly selecting one of these are 1 in 18,014,398,509,482,000. Furthermore, the DES and TripleDES classes will throw a CryptographicException if you try to use a weak key.

Rijndael

Given that DES is reaching the end of its useful life and 3DES is really not much more than a temporary fix, many experts are looking to other algorithms. The National Institute of Standards and Technology (NIST) recently chose the Rijndael specification as its official replacement to DES. This specification, referred to as the Advanced Encryption Standard (AES), can be found at http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf. Rijndael supports larger key sizes than DES but has improved performance over 3DES. The Rijndael specification supports key sizes of 128, 192, or 256 bits.

Because of government standardization on this algorithm, it is expected to become a widely used replacement for DES, although ASP.NET still relies heavily on DES and 3DES. However, Rijndael is the default algorithm used with the SymmetricAlgorithm class and is the only symmetric algorithm that fully runs in managed code. Figures 4.6 and 4.7 show an example using Rijndael encryption in ASP.NET. Note that Rijndael encryption does not have any known weak keys and therefore does not support the IsWeakKey method.

The Rijndael cipher is the fastest and supports the largest key size of all the .NET Framework ciphers.

RC2

RC2 is a symmetric block cipher designed by Ronald Rivest of RSA. RSA designed RC2 as a direct replacement for DES, improving on the performance and providing a variable key size. RC2 is commonly used in S/MIME secure email and is said to be two to three times as fast as DES. The complete RC2 specification is available at www.ietf.org/rfc/rfc2268.txt. Figure 4.8 and Figure 4.9 show examples using RC2 encryption. Like Rijndael, RC2 does not have any known weak keys and therefore does not support the IsWeakKey method.

RC2 is a widely used algorithm that allows a variety of key lengths, but you should be aware that security experts consider RC2 with smaller keys to be insecure. You should always use a 128-bit key, the maximum length available.

Selecting an Algorithm

Selecting a symmetric encryption algorithm is essentially a matter of key length, compatibility, performance, experience, and personal preference. It is extremely difficult to prove that an encryption algorithm is the most secure, although the failure to demonstrate vulnerabilities over time is usually good enough proof. Ultimately, the strength of the algorithm is based on the size of the key, but there is no guarantee that any particular algorithm is without flaws.

WARNING

At the time of this writing, there are no known flaws with these algorithms, other than limitations on key length. However, we do know that some government agencies spend a great amount of money and effort looking for flaws in these algorithms. If such an agency were ever to discover (or already has discovered) a flaw, you can bet that would become one of their most closely guarded secrets. In fact, they would likely go to great lengths to give the impression that they have no clue of any flaws with the algorithms.

In a situation in which security is a much higher priority than performance, you could avoid exposure by layering multiple algorithms as shown in Figures 4.10 and 4.11. Because CryptoStreams allow chaining, it is a simple process to provide multiple layers of encryption.

Establishing Keys and Initialization Vectors

A number of parameters determine the outcome of the ciphertext. To decrypt the ciphertext, you must use the same algorithm and the same parameters. Two of the parameters you should intentionally change each time are the key and the initialization vector (IV). The key is the secret vital to ensuring the integrity of the data and the IV ensures randomness and uniqueness of the ciphertext blocks.

If you encrypt data with the same key each time, you will always end up with the same ciphertext. Knowing this, an attacker can eventually gain enough data to decode many messages. To prevent this, the symmetric encryption algorithms use the IV to initialize the process, ensuring a unique ciphertext message. The message recipient must know both the key and the IV to decrypt the message, but only the key must remain secret.

WARNING

When creating a key and IV, never derive one from the other, because knowing the IV could allow the attacker to determine the key. Also be sure to avoid a fixed IV for all encryption. The best solution is to use the random IV that the algorithm automatically creates when it's initialized.

There are some difficulties when it comes to exchanging keys, especially when it comes to sharing a key without any prior shared secrets. The whole reason for the encryption is that you do not trust the transmission medium. Therefore, you must somehow transmit the key over an insecure connection, but if you already have a secure connection, why would you need further encryption? Suppose, for example, that you want to send someone an encrypted message. The recipient will not be able to read your message unless you give her the proper key. It makes no sense to send the key along with the message, so you instead call the recipient on the phone to convey the key. But since you already trust the phone line enough to share the key, you might as well go ahead and share the whole message. This is a major shortcoming of symmetric cryptography but is an issue we can overcome with key exchange algorithms and by using asymmetric cryptography. For an ASP.NET application, this is not as great an issue, because you can easily use SSL to establish a secure session.

Most often you will use symmetric encryption for saving sensitive settings or user data. The problem with this is that your ASP.NET application must know the key and therefore must save the key for its own use. This is a problem because if an attacker takes over the application, the attacker will gain access to the application's keys. For example, ASP.NET uses the machine.config file to store the encryption keys for many encryption operations, such as encrypting a forms authentication ticket. If an attacker were able to read this file, that attacker could forge his own authentication tickets. To help this situation, you can use DPAPI, as explained later in this chapter. You should also design your application so that it allows you to regularly change your keys.

Sometimes you might want the user to be able to encrypt information that even you cannot access. The user provides the key and then gains access to the encrypted data. However, it normally is not practical to expect a user to memorize or type a large encryption key. If users have issues remembering a password of six or eight characters, how will they remember a 128-bit key? The solution is to allow the user to enter a password that you use to derive an appropriate key.

The PasswordDeriveBytes.CryptDeriveKey method can produce an appropriate key based on a password, salt, algorithm, and number of iterations. This method creates a hash of the password using the supplied salt and uses that hash to create another hash, repeating this process for as many iterations specified. The result is a long string suitable to use as a key. Figures 4.12 and 4.13 demonstrate the code to use CryptDeriveKey, and Figure 4.14 shows an example key derived from a user's password.

WARNING

Note that although you can use CryptDeriveKey to turn a short password into a strong key, keep in mind that the key is only as strong as the password itself. By using CryptDeriveKey, you are effectively reducing the key strength to that of the password, not the other way around. However, using a large number of iterations definitely will slow a brute-force attack because the attacker would have to perform those iterations for each password attempt. For a password-cracking tool, every millisecond makes a huge difference.

When using CBC or CFB modes, you must set an initialization vector. The IV works like a salt to further transform the data so that two plaintext messages encrypted with unique IVs will produce unique ciphertext data. This makes it more difficult to perform a dictionary attack on the ciphertext. Generally you want to use a random number for the IV, which SymmetricAlgorithm automatically generates when the class is created. You must read this property and store the IV so that you can later decrypt the ciphertext. If you create your own IV, you need to create one that is the same length as the key. Note that the IV is not a secret and you do not need to take special measures to protect it. Figures 4.15 and 4.16 show examples of how you can append the IV and the ciphertext so that you can store them together. They also show how you can extract the IV and decrypt the ciphertext.

Symmetric cryptography does have its limitations and weaknesses, but it also plays an important role in protecting data. The .NET Framework provides good support for well-established symmetric ciphers, and you should always encrypt sensitive data. Establish a solid framework for encryption early in your application design.

Security Policies

▪

Use strong symmetric ciphers to ensure the privacy of data.

Never rely on XOR, ROT-13, base-64 encoding, or any homegrown encryption or obfuscation algorithm.

Avoid using DES unless absolutely necessary for backward compatibility; consider 3DES as a compatible alternative.

Use Rijndael/AES encryption for the best security and performance.

If using RC2 encryption, use 128-bit keys whenever possible.

When security is a high priority and performance a low priority, consider layering encryption algorithms.

When creating a key and IV, do not derive one from the other.

Use CryptDeriveKey to create an encryption key from a user password.

Symmetric

One method of cryptography is symmetric cryptography (also known as secret key cryptography or private key cryptography). Symmetric cryptography is best suited for bulk encryption because it is much faster than asymmetric cryptography. With symmetric cryptography:

Both parties share the same key (which is kept secret). Before communications begin, both parties must exchange the shared secret key. Each pair of communicating entities requires a unique shared key. The key is not shared with other communication partners.

NOTE: Other names: Secret key, Conventional Key, Session Key, File Encryption Key, etc.

Pros:

Speed/file size

Symmetric-key algorithms are generally much less computationally intensive which provides a smaller file size that allows for faster transmissions and less storage space.

Cons:

Key management

One disadvantage of symmetric-key algorithms is the requirement of a shared secret key, with one copy at each end. See drawing below.

To ensure secure communications between everyone in a population of n people a total of n (n − 1)/2 keys are needed. Example: key for 10 individuals 10(10-1)/2 = 45 keys.

The process of selecting, distributing, and storing keys is known as key management; it is difficult to achieve reliably and securely.

Hash functions

Hash functions represent a third cryptography type alongside symmetric and asymmetric cryptography, what we might call keyless cryptography. Hash functions, also referred to as message digests, do not use a key, but instead create a largely unique and fixed-length hash value, commonly referred to as a hash, based on the original message, something along the same lines as a fingerprint. Any slight change to the message will change the hash.

Hashes cannot be used to discover the contents of the original message, or any of its other characteristics, but can be used to determine whether the message has changed. In this way, hashes provide confidentiality, but not integrity. Hashes can be used on programs (to determine if someone modified an application you want to download), open text messages or operating system files. Hashes are very useful when distributing files or sending communications, as the hash can be sent with the message so that the receiver can verify its integrity. The receiver simply hashes the message again using the same algorithm, then compares the two hashes. If the hashes match, the message has not changed. If they do not match, the message has been altered.

Although it is theoretically possible to engineer a matching hash for two different sets of data, called a collision, this is a very difficult task indeed, and generally requires that the hashing algorithm be broken in order to accomplish. Some algorithms, such as Message-Digest algorithm 5 (MD5), have been attacked in this fashion, although producing a collision is still nontrivial. When such cases occur, the compromised algorithm usually falls out of common use. Hashing algorithms such as SHA-2 and the soon-to-arrive SHA-3 have replaced MD5 in cases where stringent hash security is required.

Many other hash algorithms exist and are used in a variety of situations, such as MD2, MD4, and RACE.

17.2.1 Sigfox

The Sigfox security design is based mainly on symmetric cryptography. Moreover, some security features, such as encryption, are on-demand and not provided by default. This section compiles results of documentations analysis, best practices, and even reverse engineering to generate the complete picture of the main security features of Sigfox technology [4–6].

Credential and their provisioning. The Sigfox technology uses three main credentials: device identification (ID, 4 bytes(B)), porting authorization code (PAC, 16 B), and key (sometimes referred also as network access key, NAK, 16 B). There are three different ways how credentials are delivered, namely via (1) Sigfox Central Registration Authority (CRA), (2) secure element (SE) providers, and (3) the Sigfox build platform (used exclusively for the products in development). The procedures for (1) and (2) are shown in detail in Figs. 17–2 and 17–3, respectively. Since (3) is not intended to be used for any commercial devices, we do not address it here.

The principal difference between (1) and (2) is the location, where the security credentials are stored. In the former case, the credentials are kept in local memory (e.g., in radio transceiver or a location accessible by the processor of the IoT device). In the latter case, the credentials are stored in a specialized chip, such as STSAFE-A1SX [7].

The ID acts as the unique identifier of an ED in the Sigfox network. The 4 B ED ID results in the address space of 232, that is, 4,294,967,296 unique addresses. The Sigfox report from May 2018 [8] estimates the number of deployed Sigfox devices to reach 3 million, which is below 0.1% of the total maximum limit. Note that the device ID is typically neither encrypted nor protected.

The NAK is the key used to encrypt all the communication, which is known only to the manufacturers/CRA/SE providers. The PAC is a one-time code used to confirm ED ownership in the process of its registration as a part of its assignment to a particular device group. The PAC is regenerated after each registration and delivered to the group owner and must be kept confidential, since knowing it, one can virtually “hijack” the ED by connecting it to a third-party device group.

In addition to ID, NAK and PAC, two other keys are specified in the Sigfox documentation—the authentication key (Ka, 16 B) and the encryption key (Ke, 16 B). By default, Ka is the same as the NAK. The difference between the two is that the NAK is used mostly in the registration processes, while Ka is employed in the cryptography processes. The Ke key is used to encrypt the frames exchanged between the devices and the Sigfox core network, if encryption service is activated. The Ke is derived by applying Advanced Encryption Standard AESECB-128 to the NAK.

Identity protection. The Sigfox solution for identity protection is based on combination of unique ID and PAC. ID is typically transferred via air in nonencrypted form. Therefore, the ED identity is protected primarily by PAC. The ID of the ED is static and does not change through the lifetime of the device. The PAC changes only when a device is registered to a new group. Note that there is neither temporary mobile subscriber identity (TMSI) service/protocol nor any equivalent managing identity protection.

Authentication (device, network, message, and subscriber). Each Sigfox device has a unique identifier ID, which is not protected. Modification of ID is not supported either. To register an ED at the Sigfox cloud service, one has to possess the device ID and a valid PAC.

The network is identified by unique private NAK, which is known only to the manufacturers/CRA/SE and has to be put in the device for it to communicate with the network. Note that no mechanism for changing the NAK, should it ever be compromised, is available. The authentication of each message is provided via AESCBC-128(Ka, Data).

The cloud authenticates the subscriber via an email and a password, which must have at least eight characters containing at least one lower case (26 valid characters), one upper case (26 valid characters), one digit (10 valid characters), and one symbol (32 valid characters). Since the login is not protected against multiple tries, the brute-force attack is possible. Considering, for example, attacker having the maximal distributed power equal to that of distributed.net (1049.20 gigakeys(GKs)/s) [9], the attack would need at maximum 948/1049.20 GKs=96.83 minutes to break the weakest possible password. Increasing the password to 10 characters would increase the time to break the password to over 1.6 years, while brute-force breaking of a 12-character password would require over 14,000 years.

Data integrity. The data integrity is ensured by the 2 (in uplink)/1 (in downlink) bytes of cyclic redundancy check (CRC) produced by the polynomial function. For the uplink the polynomial function is x16+x12+x5+1, result is XOR-ed with 0xFFFF. For the downlink the polynomial function is x8+x5+x3+x+1 and the result is put in CRC field.

Data confidentiality. By default, the Sigfox radio messages between an ED and a GW are not encrypted. The secured IP connection is established only between a GW and an network server (NS) through virtual private network/secure sockets layer (VPN/SSL) (over Eth/DSL/4G/long-term evolution (LTE) depending on the availability and Sigfox infrastructure) and between the NS and a subscriber via HTTPs protocol. However, Sigfox introduced new service in Q4/2017 for the EDs to provide E2M security. This service is available at extra cost on request. Moreover, the service must be supported by both the local Sigfox operator and by the ED. This service implies the use of AESCTR-128 encryption with Ke derived from NAK (Ka). The requirement for Advanced Encryption Standard (AES) is to support encryption of up to 264 blocks of data (approximately 9.22·1018 messages) before the key exchange need arises. Given the typical limit of 140 Sigfox messages per day, the need for key exchange would arise in 1.80 x 1014 years. However, should the key get compromised, no mechanism for changing it is available.

E2M security and end-to-end security. The E2M security is provided via integrity, authentication, and encryption function, as discussed above. The E2E security is not provided and needs to be implemented by the application developer.

Forward secrecy. Sigfox communication protocol does not use any forward secrecy or single-session protection.

Replay protection. To fight a packet replay attack, the message counter value is encrypted and sent in each message. The counter field is 12 bit wide and can encode 4095 values. For an ED sending 140 messages per day, the counter would repeat in approximately 29.25 days. Except the counter, two timestamps are used. The former (T M0) is added to each received message by the GW. The latter (T M1) is generated once Sigfox NS receives the message. The two timestamps are used to compute the NS-GW delivery latency to protect the message against replay attack between the GW and the NS. However, the “stop-and-replay” attack (i.e., jamming the EDs, changing the message, and resending in selected time) is still feasible.

Reliable delivery. Some Sigfox operators claim to achieve the 99% reliability [10]. This is achieved by combining the message repetition and random carrier selection. Moreover, Sigfox also employs cooperative reception, allowing multiple base stations (on average—three) receive each message, to make a transmission more reliable. As a result, the Sigfox solution implements time, frequency, and spatial diversity.

Prioritization. Sigfox technology does not offer any packet prioritization mechanism.

Updatability. The limited downlink capabilities (typically only four messages of 8 bytes per day) offer minimal capabilities for any update. Moreover, the update procedures are out of the scope of the Sigfox specification and must be handled through the application layer.

Network monitoring and filtering. Each GW implements preliminary uplink message validation and CRC check. However, this is the NS, which handles the final message processing (computes and validates the data authenticity, checks the sequence number and timestamps, removes the duplicates) and billing.

Algorithm negotiation. Sigfox EDs use predefined algorithms, and there is no algorithm negotiation mechanism.

Class break resistance. There is no secret/private key sharing between different EDs. All EDs use unique device ID and keys. Nevertheless, the same cryptography algorithms are used by each device.

Certified equipment. Sigfox is a proprietary solution, which operates in the unlicensed bands. However, there are strict policy and regulations in place for deploying new EDs and GWs. The Sigfox control authority must always certify an ED or any other device entering the network. The Sigfox EDs are openly available on the market. The network infrastructure (e.g., GWs) is provided by Sigfox only to the selected partners.

IP network Sigfox implements non-IP data delivery (NIDD) over the air. The radio frames are further encapsulated in the IP packet by the GW and delivered to NS via VPN/SSL, which should provide sufficient security in this part of the network.

3.1.4.1 Symmetric cryptography

In symmetric cryptography, two entities, traditionally known as Alice and Bob, share a key. When Alice wishes to encode a message to send to Bob, she uses a symmetric algorithm, using the secret key and the message as parameters. When Bob receives the message, he applies the corresponding decryption algorithm, using the same key as a parameter. The principle of symmetric encryption is illustrated in Figure 3.2, where E is the encryption function and E− 1 the corresponding decryption function. 3 Data Encryption Standard (DES) and Advanced Encryption Standard (AES) are two of the best-known and most robust symmetric encryption algorithms.

Despite the existence of robust algorithms and strong performances in terms of calculations, symmetric cryptography presents two main limitations:

the number of keys to manage: a different symmetric key is needed for each pair of correspondents. Thus, the number of keys required increases in line with the square of the number of individuals;

the exchange of the secret key: we know that Alice and Bob share a key, but the way in which this key is exchanged is not specified. Security at this stage is a significant issue; asymmetric cryptography offers one possible solution.

Cryptography

Three types of encryption as currently used in security controls:

Symmetric: One method of cryptography is symmetric cryptography (also known as secret key cryptography or private key cryptography). Symmetric cryptography is best suited for bulk encryption because it is much faster than asymmetric cryptography. With symmetric cryptography:

Both parties share the same key (which is kept secret). Before communications begin, both parties must exchange the shared secret key. Each pair of communicating entities requires a unique shared key. The key is not shared with other communication partners.

Note: Other names – secret key, conventional key, session key, file encryption key, etc.

Pros:

Speed/file size:

Symmetric-key algorithms are generally much less computationally intensive which provides a smaller file size that allows for faster transmissions and less storage space.

Cons:

Key management:

One disadvantage of symmetric-key algorithms is the requirement of a shared secret key, with one copy at each end. See drawing below.

In order to ensure secure communications between everyone in a population of n people a total of n(n − 1)/2 keys are needed. Example: key for 10 individuals, 10(10 − 1)/2 = 45 keys.

The process of selecting, distributing, and storing keys is known as key management; it is difficult to achieve reliably and securely.

Symmetric algorithms:

MethodsCharacteristicsData Encryption Standard (DES)•

Created in 1972 and recertified in 1993

Uses a 64-bit block size and a 56-bit key

Can be easily broken

Applies DES three times. Uses a 168-bit key

Replaced with AES

Uses the Rijndael block cipher (rhine-doll) which is resistant to all known attacks

Uses a variable-length block and key length (128-, 192-, or 256-bit keys)

Variable block size, variable key size (up to 448 bits)

Uses 128-bit blocks and variable key lengths (128-, 192-, or 256 bits)

Two implementations: 64-bit block size with 128-bit key, 128-bit block size with 256-bit key. Used by Pretty Good Privacy (PGP) email encryption

Two implementations: 64-bit block size with 128-bit key, 128-bit block size with 256-bit key. Used by PGP email encryption

Includes various implementations:

RC2 with 64-bit blocks and a variable key length (any size)

RC4 with 40- and 128-bit keys

RC5 with variable blocks and keys (any size)

RC6 an improvement on RC5

Asymmetric: Asymmetric cryptography is a second form of cryptography. It is scalable for use in very large and ever expanding environments where data is frequently exchanged between different communication partners. With asymmetric cryptography:

Each user has two keys: a public key and a private key.

Both keys are mathematically related (both keys together are called the key pair).

The public key is made available to anyone. The private key is kept secret.

Both keys are required to perform an operation. For example, data encrypted with the private key is unencrypted with the public key. Data encrypted with the public key is unencrypted with the private key.

Encrypting data with the private key creates a digital signature. This ensures the message has come from the stated sender (because only the sender had access to the private key to be able to create the signature).

A digital envelope is signing a message with a recipient’s public key. A digital envelope, which serves as a means of AC by ensuring that only the intended recipient can open the message (because only the receiver will have the private key necessary to unlock the envelope; this is also known as receiver authentication).

If the private key is ever discovered, a new key pair must be generated.

Asymmetric cryptography is often used to exchange the secret key to prepare for using symmetric cryptography to encrypt data. In the case of a key exchange, one party creates the secret key and encrypts it with the public key of the recipient. The recipient would then decrypt it with their private key. The remaining communication would be done with the secret key being the encryption key. Asymmetric encryption is used in key exchange, email security, web security, and other encryption systems that require key exchange over the public network.

Pros:

Key management:

Two keys (public and private), private key cannot be derived for the public so the public key can be freely distributed without confidentially being compromised

Offers digital signatures, integrity checks, and nonrepudiation

Cons:

Speed/file size:

Because symmetric-key algorithms are generally much less computationally intensive than asymmetric-key algorithms.

In practice, asymmetric-key algorithm are typically hundreds to thousands times slower than a symmetric-key algorithm.

Asymmetric algorithms:

MethodCharacteristicsRivest–Shamir–Adleman (RSA)•

Uses a specific one-way function based on the difficulty of factoring N, a product of 2 large prime numbers (200 digits)

Known as a key exchange algorithm

Uses two system parameters (p and g)

p is a prime number

g is an integer smaller than p generated by both parties

Extends Diffie–Hellman for use in encryption and digital signatures

Used in conjunction with other methods to reduce the key size

An EC key of 160 bits is equivalent to 1024-bit RSA key, which means less computational power and memory requirements

Suitable for hardware applications (e.g., smart cards and wireless devices)

Used to digital sign documents

Performs integrity check by use of SHA hashing

3.

Hashing: A hash is a function that takes a variable-length string (message), and compresses and transforms it into a fixed-length value.

The hashing algorithm (formula or method) is public.

Hashing uses a secret value to protect the method.

Hashing is used to create checksums or message digests (e.g., an investigator can create a checksum to secure a removable media device that is to be used as evidence).

The hash ensures data integrity (i.e., the data have not been altered). The receiving device computes a checksum and compares it to the checksum included with the file. If they do not match, the data has been altered.

Examples include message digest (MD2, MD4, MD5) and Secure Hashing Algorithm (SHA).

SHA, Race Integrity Primitives Evaluation Message Digest (RIPEMD), and Hash of Variable Length (HAVAL).

NameClassHash lengthMD5512-Bit blocksDigest size(s): 128 bits
Rounds: 4SHA-1512-Bit blocksDigest size(s): 160 bits
Rounds: 80SHA-2
SHA-224/256512-Bit blocksDigest size(s): 256 bits
Rounds: 64SHA-2
SHA-384/5121024-Bit blocksDigest size(s): 512 bits
Rounds: 80RIPEMD-160Digest size(s): 128,160, 256, and 320 bitsHAVALDigest size(s): 128, 160, 192, 224, and 256 bits
Rounds: 3, 4, or 5

Hash Functions

It is important to know that the slight technical differences that support hashing are significant enough to draw a distinction between symmetric or asymmetric cryptography and hash functions. Hashing only supports integrity and not confidentiality services. A hash function is a one-way cryptographic algorithm. The use of a one-way cryptographic algorithm means that the ciphertext cannot be decrypted to reveal the original plaintext. The algorithm is made of two parts. The first element is the original content and is called the message. After encryption, the output, or second element, is called the message digest. The message digest is a unique identifier and based on the message. It is often viewed as a digital fingerprint. If the original message were altered in anyway, then it would not match the original message digest. Table 4.1 compares the types of encryption algorithms as well as provides a common example.

Table 4.1. Common Encryption Algorithms

Encryption TypeStrengthsWeaknessExampleSymmetric•

Faster than asymmetric systems

Difficult to break when large key size is used

Requires secure mechanism to deliver keys

Key management is difficult due to high volume of keys

Cannot perform nonrepudiation

AES

3DES

Stronger key distribution

Improved scalability

Provides integrity, authenticity, and nonrepudiation functions

Slower than symmetric systems

Mathematically intense work factor

RSA

DSA

One-way efficiency

Provides file/message integrity

Does not support confidentiality

SHA 1

MD5

Summary

This chapter looked into the meaning of cryptography and some of its origins, including the Caesar Cipher. More modern branches of cryptography are symmetric and asymmetric cryptography, which are also known as secret key and public key cryptography, respectively.

The most common symmetric algorithms in use today include DES, AES, and IDEA. Since DES is showing its age, we looked at how NIST managed the development of AES as a replacement, and how Rijndael was selected from five finalists to become the AES algorithm. From the European perspective, we saw how IDEA came to be developed in the early 1990s and examined its advantages over DES.

The early development of asymmetric cryptography was begun in the mid-1970s by Diffie and Hellman, who developed the Diffie-Hellman key exchange algorithm as a means of securely exchanging information over a public network. After Diffie-Hellman, the RSA algorithm was developed, heralding a new era of public key cryptography systems such as PGP. Fundamental differences between public key and symmetric cryptography include public key cryptography's reliance on the factoring problem for extremely large integers.

Brute force is an effective method of breaking most forms of cryptography, provided you have the time to wait for keyspace exhaustion, which could take anywhere from several minutes to billions of years. Cracking passwords is the most widely used application of brute force; programs such as L0phtcrack and John the Ripper are used exclusively for this purpose.

Even secure algorithms can be implemented insecurely, or in ways not intended by the algorithm's developers. Man-in-the-middle attacks could cripple the security of a Diffie-Hellman key exchange, and even DES-encrypted LANMAN password hashes can be broken quite easily. Using easily broken passwords or passphrases as secret keys in symmetric algorithms can have unpleasant effects, and improperly stored private and secret keys can negate the security provided by encryption altogether.

Information is sometimes concealed using weak or reversible algorithms. We saw in this chapter how weak ciphers are subject to frequency analysis attacks that use language characteristics to decipher the message. Related attacks include relative length analysis and similar plaintext analysis. We saw how vendors sometimes conceal information using XOR and Base64 encoding and looked at some sample code for each of these types of reversible ciphers. We also saw how, on occasion, information is compressed as a means of obscuring it.

This chapter provides an introduction to encryption as a resistance strategy. The focus is on symmetric encryption. Steganography and asymmetric encryption are covered in enough detail to demonstrate what symmetric cryptography is not, even though both could be subjects of books in their own right. Likewise, information theory is introduced at the appropriate level to support the discussion on cryptography. The chapter assumes no previous knowledge, and attempts to provide a basis for understanding by beginning with definitions for primitive cryptographic terms and discussing what encryption can and cannot do.

To give the reader a feel for how cryptography works, historic examples are introduced and the workings of the ciphers are described in some detail. Although these ciphers are not of practical importance, they are simple enough that the reader can grasp their workings without the extensive math background needed for modern ciphers. The historic ciphers covered include several substitution and transposition ciphers, starting with the simple Caesar cipher.

Modern encryption is discussed in the context of its primary uses: block ciphers, stream ciphers, disk encryption, and file encryption. Asymmetric encryption is introduced mostly for its utility in key management and distribution of symmetric keys. Host identification, more properly a topic for Chapter 7, is included in this chapter as a motivating example and technical example of these concepts; particularly to this end, the working of the transport layer security (TLS) stack is described.

AN.ON

AN.ON [30] is an anonymity service which was developed and operated since the late nineties at the Technical University of Dresden. As it aims at providing a network of mixes for low-latency traffic routing, symmetric cryptography is replacing asymmetric cryptography where possible (asymmetric cryptography is only used to exchange symmetric session keys between mixes and users). Moreover, low latency requires that message delays are reduced, and in fact, AN.ON mixes implement practically no message delay. The downside of reducing delays is that the size of the message buffer in the mixes and thus the anonymity set decreases. In order to increase the size of anonymity sets, AN.ON provides standard routes through the mix network, the so-called mix cascades. A mix cascade typically contains a sequence of two or three mixes and every message sent to the cascade runs through the mixes in the same order as any other message sent to the same cascade. Predefined and stable mix cascades have a number of advantages over dynamic routing:

Mixes can be audited and certified with regard to their performance, their geographical position, the legislation in which they operate, and the operator (the company or the governmental institution operating the mix infrastructure).

Cascades can be designed to cross different nations, different legislations, and different operators in order to enjoy the protection of the most liberal regulation; they can also be designed to provide a certain performance.

Security measures focus on a small number of mixes while the costs can be distributed to a large number of users.

The disadvantages of implementing mix cascades include:

Each mix is a possible bottleneck and thus needs to provide a stable and high bandwidth installation, as one mix going offline stops all cascades in which it was involved.

Setting up and operating mixes is expensive due to the considerable organizational overhead for establishing mix cascades and due to the high performance requirements.

What is the strongest symmetric cryptographic algorithm?

Which is the strongest encryption algorithm?

What is the strongest asymmetric algorithm?

Which is better RSA or AES?