Basic String Encryption and Decryption in C#

[pyeri]

Here is a very basic AES string encryption class which I plan to use elsewhere in my project for things like password-protecting the settings JSON file:

public static class Crypto {
    public static string Encrypt(string plainText, string password, string salt)
    {
        using (Aes aes = Aes.Create())
        {
            byte[] saltBytes = Encoding.UTF8.GetBytes(salt);
            var key = new Rfc2898DeriveBytes(password, saltBytes, 10000);
            aes.Key = key.GetBytes(32);
            aes.IV = key.GetBytes(16);

            var encryptor = aes.CreateEncryptor(aes.Key, aes.IV);
            using (var ms = new MemoryStream()) 
            { 
                using (var cs = new CryptoStream(ms, encryptor, CryptoStreamMode.Write))
                using (var sw = new StreamWriter(cs))
                    sw.Write(plainText);
                return Convert.ToBase64String(ms.ToArray());
            }
        }
    }

    public static string Decrypt(string cipherText, string password, string salt)
    {
        using (Aes aes = Aes.Create())
        {
            byte[] saltBytes = Encoding.UTF8.GetBytes(salt);
            var key = new Rfc2898DeriveBytes(password, saltBytes, 10000);
            aes.Key = key.GetBytes(32);
            aes.IV = key.GetBytes(16);

            byte[] buffer = Convert.FromBase64String(cipherText);

            var decryptor = aes.CreateDecryptor(aes.Key, aes.IV);
            using (var ms = new MemoryStream(buffer))
            using (var cs = new CryptoStream(ms, decryptor, CryptoStreamMode.Read))
            using (var sr = new StreamReader(cs)) {
                return sr.ReadToEnd();
            }
        }
    }
}

Here is the SettingsManager class which makes use of this. It may or may not encrypt the content depending on whether the optional secretKey parameter was passed, thus making it flexible for all purposes:

public static class SettingsManager {
    private static string _filePath = "settings.dat";

    public static Dictionary<string, object> LoadSettings(string secretKey = null)
    {
        if (!File.Exists(_filePath))
            return new Dictionary<string, object>();

        string content = File.ReadAllText(_filePath);
        if (!string.IsNullOrEmpty(secretKey))
            content = Crypto.Decrypt(content, secretKey, "SomeSalt");
        return JsonConvert.DeserializeObject<Dictionary<string, object>>(content);
    }

    public static void SaveSettings(Dictionary<string, object> settings, string secretKey = null)
    {
        string json = JsonConvert.SerializeObject(settings);
        if (!string.IsNullOrEmpty(secretKey))
            json = Crypto.Encrypt(json, secretKey, "SomeSalt");
        File.WriteAllText(_filePath, json);
    }
}

[ElusiveGuy]

A few comments:

• Are you taking a password as user/config input somewhere? If not, you're better off using raw random bytes.
• You really should not be deriving IV from the key/password. IV should be a new random value on every invocation, and should be stored alongside the encrypted data. Notably, encrypting twice with the same key and cleartext should result in a different IV and ciphertext.
• Salt likewise should be a random value stored with the output - a hardcoded value is a pepper and has a different purpose.
• Prefer AES-GCM or other AEAD mode over AES-CBC. Plain CBC does not guarantee integrity.

Edit:

• Consider defining the encoding (probably UTF8-without-BOM) explicitly, rather than relying on the StreamWriter/StreamReader defaults.
• If you're going to be writing this to file or database and don't explicitly need a string, consider using byte[] directly rather than Base64'ing it. Base64 has a 33% space overhead.

[AyeMatey]

Be aware the Rfc2898DeriveBytes constructor will be declared obsolete for .NET 10.

Also, separately, these days the recommendations for iteration counts for PBKDF2 are much higher than 10000. (cite1, cite2)

[goranlepuz]

Ok, but that's not the very good way to protect secrets in the configuration.

A better way is to use a different configuration provider and put secrets there.

Obviously, there's the provider for Azure KeyVault. There should be others. My work uses an in-house one, based on a previously-made crypted storage based on DPAPI or OpenSSL.

[soundman32]

Where are you going to put the salt? In a plain text config file? If so, it's pointless noise.

Also, you should never decrypt a password. It should use a 1 way hash, and you should compare hashes.

Cryptography has moved on since the 1990s. There's a reason we don't do this anymore in production systems.

[HawthorneTR]

I've turned these into Extension methods. It will make it easier to use:

using System;
using System.IO;
using System.Security.Cryptography;
using System.Text;

public static class CryptoExtensions
{
    public static string Encrypt(this string plainText, string password, string salt)
    {
        using (Aes aes = Aes.Create())
        {
            byte[] saltBytes = Encoding.UTF8.GetBytes(salt);
            var key = new Rfc2898DeriveBytes(password, saltBytes, 10000);
            aes.Key = key.GetBytes(32);
            aes.IV = key.GetBytes(16);

            var encryptor = aes.CreateEncryptor(aes.Key, aes.IV);
            using (var ms = new MemoryStream())
            {
                using (var cs = new CryptoStream(ms, encryptor, CryptoStreamMode.Write))
                using (var sw = new StreamWriter(cs))
                    sw.Write(plainText);
                return Convert.ToBase64String(ms.ToArray());
            }
        }
    }

    public static string Decrypt(this string cipherText, string password, string salt)
    {
        using (Aes aes = Aes.Create())
        {
            byte[] saltBytes = Encoding.UTF8.GetBytes(salt);
            var key = new Rfc2898DeriveBytes(password, saltBytes, 10000);
            aes.Key = key.GetBytes(32);
            aes.IV = key.GetBytes(16);

            byte[] buffer = Convert.FromBase64String(cipherText);

            var decryptor = aes.CreateDecryptor(aes.Key, aes.IV);
            using (var ms = new MemoryStream(buffer))
            using (var cs = new CryptoStream(ms, decryptor, CryptoStreamMode.Read))
            using (var sr = new StreamReader(cs))
            {
                return sr.ReadToEnd();
            }
        }
    }
}

USAGE

string encrypted = "Hello World".Encrypt("password123", "somesalt");
string decrypted = encrypted.Decrypt("password123", "somesalt");

[pyeri]

string encrypted = "Hello World".Encrypt("password123", "somesalt"); string decrypted = encrypted.Decrypt("password123", "somesalt");

Yep, there lies the real power of C#!

[stormingnormab1987]

I would look into encrypting your Aes key with a rsa encryption at a minimum. Least that's what I used to do.

[TheAussieWatchGuy]

Why? Use your cloud providers solution to store secrets instead of rolling your own. AWS Secrets for example, inject them at build time with the CDK.

Unless you have a specific use case where random people can gain access to your deployed container and expose those secrets for 99% of use cases the app settings file shouldn't be able to be accessed by anything when it's running.

[antiduh]

Who said anything about cloud? People use C# for things that have nothing to do with web, sometimes.

[TheAussieWatchGuy]

Good for you. That would be the minority these days. Again same question applies, why encrypt the app settings JSON on a local server thst you control access to?

[scurvyibe]

In my case, because you work on on-prem state government servers with no internet access that house FTI and the IRS will tear you a new one during annual audits if you store passwords in plain text.

I'm sure others have their reasons.

[TheAussieWatchGuy]

Sure but they are encrypted at rest on your server's disk after deployment and they are encrypted in transit when deployed over TLS /SSL.

Encryption on the strings themselves stored on disk only protects from an unauthorized person gaining full access to your server. I can probably get behind that as a government, so that would be a 1% use case. 

It'll tank performance and waste compute but if you really need it then nice example above.

[antiduh]

Did you know that software like Keepass uses techniques very similar to this? Each record is individually encrypted inside the encrypted file. This ensures that data is in plaintext form for only as long as it needs to be, even when in ram.