Key Derivation

The public and private key pairs in RSA are based on prime numbers, and their security comes from the difficulty in factorizing prime numbers. What this means is that if you have a large prime number, it is tough to determine what two prime numbers are multiplied together to make the larger number.

Let’s look at a simple example.

If you were to pick two prime numbers, let’s say 23 and 17, and I asked you to multiply these numbers, you could work it out quite comfortably in your head or with a calculator. The answer is 391. But if I were to ask you which two prime numbers do you multiply to make 5963, it would be a harder mathematical problem to solve. The answer is 67 × 89 = 5963.

Now imagine numbers that are considerably larger, for example, a 2048-bit number or 256-byte number. The strength of RSA keys is because going from one large number back to the original primes that made that number initially is a tough problem to solve, which is where the strength of RSA comes into effect.

Now let’s equate this example back to private and public keys. Alice wishes to send an important message to Bob, so she uses Bob’s public key to encrypt the message. In the simple example we just looked at, the public key is 5963. Alice then encrypts the message and sends it to Bob, where he uses his private key to decrypt the message. In our example, the private key consists of the two prime numbers: 67 and 89.

This is a very simplified example. The reality is more complicated and goes outside the scope of this book because there are many more components to an RSA key than just the prime numbers, but it is beneficial for you to have this simplified mental model of an RSA key.

In Figure 7-3, the internals of a public and private key in .NET are shown in the debugger. The class we use to hold an RSA key is called RSAParameters.

The relevant parts to note are that in the private key, P and Q are both populated; they are the two prime numbers. In the public key, P and Q are not present because they are secret to anyone who uses the public key; but the modulus is populated, which is the result of multiplying the two prime numbers.

Encryption and Decryption

Unlike symmetric encryption algorithms such as AES, where the encryption and decryption process are algorithmic (the plaintext is split it into smaller blocks and run through several rounds of obfuscation with the key), RSA takes a more mathematical approach and is based on modular arithmetic.

In mathematics, modular arithmetic is an integer-based system, where numbers “wrap around” when reaching a certain value. This wrap around value is called the modulus. A favorite example for describing the use of modular arithmetic is defining a 12-hour clock, where a 24-hour day is divided into two 12-hour blocks.

If the time is 7:00 a.m., then it will be 3:00 p.m. eight hours later.

A standard addition would suggest that the time should be 15.00 (7 + 8 = 15), but because we are dealing with a day that is split into two 12-hour blocks, it is not the correct answer because the clock will wrap around every 12 hours.

As another example, if we have the clock set to at 12:00 (noon) and 21 hours pass, then the correct time will be 9:00 a.m. the next day, rather than 33:00; this is because the hour number will start over again once it reaches 12; this is referred to as arithmetic modulo 12.

Because the encryption process is mathematical and based on Modulus arithmetic, there are limits to the amount of data you can encrypt in one go. As a rule, you cannot encrypt data larger than the size of the key. So, if you are encrypting using a 2048-bit key, which is 256 bytes in length, then you cannot encrypt more than 256 bytes. The more data you encrypt, the slower the encryption process is even though RSA makes the key sharing problem easier, it is quite an inefficient encryption system.

In-Memory Keys

Valid lengths for the key size parameter that you pass into the constructor are 1024 bits, 2048 bits, and 4096 bits. In the preceding example code, we are creating a public and a private key and keeping them in objects in memory. We look at what the PersistKeyInCsp property means in a moment, but for this example, it is set to false. To export the key material, you call the ExportParameters method on the RSA object instance of RSACryptoServiceProvider. To export the public key, you pass false into ExportParameters; to export the private key, you pass in true.

If you are using .NET Core, then this method of creating keys using RSACryptoServiceProvider works cross-platform across Windows, macOS, and Linux, which is the only supported way of creating the RSA keys programmatically across all three platforms. The next two techniques for XML keys and CSP keys only work on Windows.

XML-Based Keys

Next, in this example, we use the WriteAllText static method on the File class to save out the XML text of the public and private keys to disk. To export the actual key material, we use the ToXmlString method on the RSACryptoServiceParameter instance.

It is important to stress though, that just because you can export RSA keys as XML files, you should question your need to do this. If you need to do this for development tools or other tooling, then that’s fine. If you intend to export RSA keys and store them in a folder on a server somewhere for a production system, then this is not a good idea at all. Files are tough to protect. Your servers are susceptible to being accessed by people who shouldn’t, and they could copy, delete, or tamper with keys. There are much better ways to use keys: use the cryptographic service provider (Windows only), load keys from the certificate store (also Windows only), or use a protected key vault, such as Azure Key Vault, which is covered later in the book.

Cryptographic Service Provider

To generate an RSA asymmetric key and store it within a key container you need first to instantiate the CspParameters class and pass in the name that you want to call the key container to the CspParameters.KeyContainerName field. Using the Flags property, you have a choice of storing the key in either a local user key container or a machine-level key container.

In our example, we are using a machine-level key store. The ProviderName field represents a specific name used for a key container on the system. The default Windows provider is the Microsoft Strong Cryptographic Provider. If you are using any specific key management hardware that is compatible with the Windows CSP, then the name you provide in that string relates to the hardware whose drivers should be installed on the system.

Key containers that are at the user level are stored inside the Windows user profile for that user. The key container can then be used to encrypt and decrypt data for any applications that run using that user identity. Having key containers at the user level is useful if you require that the RSA keys are removed with the user profile is deleted. However, because you must be logged in with the specific user account that makes use of the user-level RSA key container to encrypt or decrypt protected configuration sections, they are inconvenient to use.

In addition to the user-level RSA key containers, there are machine-level containers that can be available to every user that logs into a computer. Machine-level key containers are useful because you can use them to both encrypt and decrypt data while logged in with any user account, including admin accounts. Although machine-level RSA key containers are available to all users, they can be secured with NTFS access control lists (ACLs) so that only required users can access them.

To remove a key from a key container, you first need to instantiate another instance of the CspParameters class and pass the name of the key container to the CspParameters.KeyContainerName property. Then you create a new instance of a class RSACryptoServiceProvider and pass the previously created CspParameters object to its constructor. Next, set the PersistKeyInCSP property of the RSACryptoServiceProvider class to false. Finally, you need to call the Clear method on the instance of RSACryptoServiceProvider. Calling this method releases all resources of the RSA instance and clears the key container.

Encryption and Decryption

Once you have your keys set up, the encryption process is very straightforward. If you look at the code snippet, you pass in your data to encrypt as a byte array and then create a new instance of RSACryptoServiceProvider. You import the public key to encrypt with using the ImportParamters method, and you have to make sure PersistKeyInCSP is set to false. Then you call the Encrypt method on the RSACryptoServiceProvider object.

The second parameter on the encrypt method is for optimal asymmetric encryption padding (OEAP), which is a padding scheme that is used within RSA. OEAP is a form of the Feistel network that is designed to add an element of randomness to the encryption process, which helps prevent the partial decryption of ciphertext by ensuring that an attacker cannot recover any portion of the plaintext.

Once you have called Encrypt, you get a byte array back containing your encrypted data. The encryption process is similar if you are using a key container.

The code looks virtually identical to the Encrypt method, apart from where we load the private key instead of the public key, and we call Decrypt instead of Encrypt. Remember that with RSA, we encrypt using our recipient’s public key, which they are free to share with us, and they decrypt the message using their private key, which only they know.

First, we create an instance of our class that contains the Encrypt and Decrypt methods. Then we call the code to assign a new key. In this example, the public and private keys are stored as members’ variables. Then we call the Encrypt method, but first, our data to encrypt, which is a string, is first converted into a byte array using Encoding.UTF8.GetBytes. Once the Encrypt method returns, we have our encrypted data (which used the public key for encryption) as a byte array.

Then the example code decrypts the data by passing in the encrypted byte array to Decrypt. This time the decryption happens using the private key to recover the plaintext, which is also sent back as a byte array. Then the sample code prints the original message, converts the encrypted ciphertext into a base64 string for display, and turns the decrypted plaintext back into a string. You can see the results of this in the screenshot in Figure 7-4.

When encrypting and decrypting, instead of calling ImportParameters to load the keys, we call FromXmlString and pass in the results of loading the key from disk. Again, loading keys from disk like this is very risky, and I don’t recommend storing RSA keys as files, but you can do it if needed. Remember that using XML-based keys only works on the Windows version of .NET Framework and .NET Core. This operation is not supported on macOS and Linux as of .NET Core 2.1.

In both the Encrypt and Decrypt methods, we construct a new CspParameters object and load in the container name into the KeyContainerName property. Then when we construct the RSSCryptoServiceProvider class, we pass in the CspParameters instance as the seconds’ constructor parameter, which loads the relevant key, and there is no need to import or load the keys manually.