17 minute read
Notice a tyop typo? Please submit an issue or open a PR.
Both RSA and Diffie-Hellman - the most widely-used public-key algorithms - are based on number theory and use modular arithmetic - modular addition, multiplication, and exponentiation. Before we dive into the details of the algorithms themselves, let's review the basics of modular arithmetic.
Given a modulus , is equal to the remainder of . For example, , because divides evenly whereas because yields a remainder of .
In modular addition, a number has an inverse such that . For example, for and , because . Every number has an inverse under modular addition.
The presence of an additive inverse means that modular addition is reversible. That is, given , and . This reversibility is very convenient for encryption because we want the decryption process ideally to be the reverse of the encryption process.
Suppose we have plaintext , key and encryption algorithm . Thus, ciphertext . We can decrypt using the inverse of : . Since , .
In modular addition, a number has an inverse such that . In this case, and . Therefore, because .
Given a modulus , is equal to the remainder of . For example, , because divides evenly whereas because yields a remainder of 2.
In modular multiplication, a number , has an inverse such that . For example, for and , because .
Not all numbers have multiplicative inverses for a given . For , for example, 2, 5, 6, and 8 do not have multiplicative inverses.
In modular multiplication, a number has an inverse such that . In this case, and . Therefore, because .
Given a modulus , only the numbers that are relatively prime to have multiplicative inverses in .
Two numbers and are relatively prime to one another if they share no common factor other than 1. For example, 3 and 10 are relatively prime, whereas 2 and 10 - which share 2 as a common factor - are not.
Given , we can calculate how many integers are relatively prime to using the totient function . If is prime, , because every number smaller than is relatively prime to because itself is prime. If and and are prime, then . If and and are relatively prime, .
If and and are prime, then . For , and , .
In modular exponentiation, . If , then .
We know that . For , and , . We can calculate as follows: . Thus, . If we divide 27 by 8, we are left with a remainder of 3, so . , which yields a remainder of 13 when divided by 30.
RSA - named after its three creators - is the most widely used public-key algorithm. RSA supports both public-key encryption and digital signature.
RSA bases the strength of its security on the hypothesis that factoring a massive number into two primes is computationally infeasible problem to solve on a reasonable timescale using modern computers.
RSA supports variable key lengths, and in practice, most people use a 1024-, 2048-, or 4096-bit key. The plaintext block size can also be variable, but the value of the block - represented as a binary integer - must be smaller than the value of the key. The length of the ciphertext block is the same is the key length.
Here is a summary of RSA, including the key generation, encryption, and decryption steps.
The first step is key generation. First, we select two primes and that are at least 512 bits in size. Next, we compute , and . Then, we select an integer that is smaller than and relatively prime to . Finally, we calculate : the multiplicative inverse of , .
The public key is . The private key is .
Suppose Bob wishes to send a message to Alice that only she can read. Bob can encrypt using Alice's public key, by computing . On receipt of ciphertext , Alice can use her private key, , and compute to recover .
RSA guarantees that only Alice can decrypt because only she has the private key that pairs with the public key used to encrypt the message.
Digital signature creation and verification work in a similar fashion as encryption and decryption.
To create a signature for a message , Alice uses her private key, to compute . Bob can verify Alice's signature by using her public key, to compute , which is equivalent to the original message .
Remember from the rules of modular exponentiation that, for a base , a power , a modulus , . If , then .
Also recall that, for a given public key, and its private key , . Thus, .
To encrypt a message , we compute . To decrypt , we compute . We can substitute the first expression in for in the second to get . The right-hand side of the equation simplifies to , which is equivalent to , which equals since .
Here is an example of RSA in action.
The key generation step proceeds as follows. First, we select two prime numbers, and . From these values, we can compute and , as and , respectively. We select 7 as our public key , as 7 and 160 are relatively prime. The private key is the multiplicative inverse of , . The multiplicative inverse of is 23, which is our private key .
To encrypt a plaintext , we compute ciphertext . To decrypt , we perform , which returns .
and . and must be multiplicative inverses , so for , , since . Finally, public key is equal to , and private key, is equal to .
Encrypting message involves computing , which is equivalent to . Decrypting ciphertext involves computing , which is equivalent to .
RSA bases its security on the hypothesis that factoring a very large number - at least 512 bits, but often in the range of 1024-4096 bits - takes an inordinately long amount of time using modern computers.
If someone finds an efficient way to factor a large number into primes, then the security of RSA is effectively broken. Given public key, , an efficient factorization of into and allows an attacker to compute and the multiplicative inverse of , . This inverse is , the private key.
An attacker can read confidential messages and forge digital signatures against any public key if they can compute a private key in a reasonable amount of time.
One issue with RSA is that the algorithm is deterministic. For a given key, the same plaintext message always encrypts to the same ciphertext. Additionally, for specific plaintext values such as 0, 1, or -1, the ciphertext is always equivalent to the plaintext, regardless of the key used.
Another issue is that RSA is malleable. An attacker can induce predictable transformations in plaintext by modifying ciphertext in specific ways.
For example, suppose Bob sends Alice an encrypted message using Alice's public key, . The attacker intercepts and performs the transformation . When Alice receives this ciphertext, the decrypted result is .
In practice, the standard is to prepend with padding, a step which addresses the issues described above.
Always use standard libraries, as they have been reviewed and tested by experts in the field.
In the Diffie-Hellman key exchange algorithm, there are two publicly known numbers and . is a large prime number - at least 300 digits long - and is a small primitive root of .
Suppose two users and wish to exchange a key using Diffie-Hellman. selects a random integer and computes . Likewise, selects a random integer and then computes . Each side keeps its value private and sends their value to the other side.
Upon receiving from , computes the key . Similarly, computes the key upon receiving from . The expressions used to compute by each party are equivalent; that is, . As a result of this exchange, both sides now share a secret encryption key.
The values of and are private while , , , and are public. If an attacker wants to compute the shared key, they must first compute either or . The attacker can compute , for example, by computing , where is the discrete logarithm. If can retrieve , they can compute the shared key using and .
The security of Diffie-Hellman lies in the fact that it is infeasible to compute discrete logarithms for large primes such as using modern computers.
Let's walk through the Diffie-Hellman key exchange using and .
First, user selects a random number, , which they keep secret, and they compute . Similarly, user selects a random number , which they also keep secret, and they compute . Next, sends 40 to and sends 248 to .
Upon receiving , computes . Similarly, computes . Through this exchange, both and have computed the same secret value, which they can now use to encrypt their communications.
We assume that an attacker can access , , , and . Because the numbers in this example are quite small, an attacker can feasibly compute the discrete log to retrieve either or . However, as we said before, this computation becomes infeasible for the large values of used in practice.
Alice sends to Bob, which is equivalent to . Bob sends to Alice, which is equivalent to .
In Diffie-Hellman, neither party ever transmits the shared secret encryption key , nor the locally generated secrets and . Since we assume that attackers can intercept any transmitted value, the lack of transmission of secret values adds to the security of the scheme.
We assume that an attacker can access , , , and , since these values are transmitted. The value of local secret is equal to the discrete logarithm . The security assumption in Diffie-Hellman is that finding the discrete logarithm is infeasible given a very large, prime .
Of course, if this conjecture is not valid, then an adversary knowing , , and can easily compute . With in hand, they can compute and effectively eavesdrop on communication between and .
Suppose that Alice tells Bob to use Diffie-Hellman. The first thing that Bob has to do is compute from his local secret , and this computation involves a very CPU-intensive exponentiation calculation.
If Alice is a malicious attacker, and Bob is a server, then Alice can request multiple simultaneous Diffie-Hellman sessions with Bob. These requests would cause Bob to waste many CPU cycles on exponentiation, which can result in denial of service.
Additionally, the sole purpose of Diffie-Hellman is key exchange. Unlike RSA, it does not offer encryption and cannot produce digital signatures.
The biggest threat to the Diffie-Hellman key exchange is the bucket brigade attack, which is a type of man-in-the-middle attack.
In this attack, Trudy intercepts the message that Alice sends to Bob, and instead sends her own to Bob, fooling Bob to accept this as . Likewise, Trudy intercepts that Bob sends to Alice and instead sends her own to Alice, fooling Alice to believe that is actually .
The result is that the shared key that Alice computes is the shared key between Alice and Trudy. Similarly, the shared key that Bob computes is the shared key between him and Trudy. In other words, Trudy plays Bob to Alice and Alice to Bob.
This man-in-the-middle attack is possible because the Diffie-Hellman key exchange protocol does not authenticate Alice or Bob. There is no way for Alice to know that the message that she has received is from Bob, and vice versa.
There are several ways to fix this problem. For example, everyone can publish their public key to a trusted, public repository instead of sending it and risking interception and forgery.
Alternatively, if Alice has already published her RSA public key, she can sign when she sends it to Bob. Bob can verify that is really from Alice using her RSA public key.
The Digital Signature Standard (DSS) is based on the secure hash function SHA-1. This algorithm is only used for digital signature, not encryption or key exchange.
While RSA is the most widely used public-key algorithm for encryption and digital signature, a competing system known as Elliptic-Curve Cryptography (ECC), has recently begun to challenge RSA. The main advantage of ECC over RSA is that it offers the same security with a far smaller bit size.
On the other hand, RSA has been subject to a lot of cryptanalysis work over the years. For ECC, the cryptanalysis work is still just beginning; therefore, we are not as confident in ECC as we are in RSA.
OMSCS Notes is made with in NYC by Matt Schlenker.