.NET 加密类的线程安全性？

Question

我的高级目标是创建一个静态实用程序类来封装我的 .NET 应用程序的加密。 在内部我想尽量减少不必要的对象创建。

我的问题是：在 .NET Framework 中实现对称加密的类的线程安全性是什么？特别是 System.Security.Cryptography.RijndaelManaged 和 它生成的 ICryptoTransform 类型。

例如，在我的类构造函数中，我可以简单地执行以下操作吗？

static MyUtility()
{
    using (RijndaelManaged rm = new RijndaelManaged())
    {
        MyUtility.EncryptorTransform = rm.CreateEncryptor(MyUtility.MyKey, MyUtility.MyIV);
        MyUtility.DecryptorTransform = rm.CreateDecryptor(MyUtility.MyKey, MyUtility.MyIV);
    }
}

回避这个类中存在 Key 和 IV 是否安全的问题，这个示例块提出了许多其他问题：

1. 我可以不断重用 EncryptorTransform 和 DecryptorTransform 吗？超过？ *.CanReuseTransform 和 *.CanTransformMultipleBlocks 属性暗示“是”，但是有什么我应该注意的警告吗？

2. 由于RijndaelManaged实现了IDisposable，我倾向于将其放在using块中，特别是因为它可能与外部操作系统级库相关联。 由于我保留了 ICryptoTransform 对象，因此有任何警告吗？

3. 可能是最重要的问题，在高度多线程环境中，我是否会遇到在线程之间共享 ICryptoTransform 对象的问题？

4. 如果问题 3 的答案是它不是线程安全的，那么当我使用 ICryptoTransform 对象时，我是否会因锁定而导致性能严重下降？ （取决于我认为的负载。）

5. 每次简单地实例化新的 RijndaelManaged 性能会不会更高？ 或者存储一个 RijndaelManaged 并每次生成 new RijndaelManaged().CreateEncryptor(...)？

我希望有人知道这些在幕后是如何工作的，或者对类似实现中的问题有经验。 我发现，许多此类性能和线程相关问题通常只有在负载达到相当大的情况时才会显现出来。

谢谢！

Answer 1

1）是的。

2）一旦废弃，就无法再使用。 在此之前，您可以共享/使用它（但请参见下文）

3-4) 来自 MSDN：

则不保证任何实例成员都是线程安全的。

“此类型的任何公共静态（在 Visual Basic 中共享）成员都是线程安全的。”如果您想保留这一点， ，并在线程之间共享它，您需要实现锁定并将其视为锁定资源。 否则，我建议根据需要制作单独的版本，并在完成后将其丢弃。

5）我建议根据需要创建这些，然后在以后发现性能问题时尝试优化它。 不要担心创建新版本对性能的影响，直到您在分析后发现这是一个问题。

Answer 2

人们可以简单地使用基于并发堆栈的缓存来解决并发问题：

static ConcurrentStack<ICryptoTransform> decryptors = new ConcurrentStack<ICryptoTransform>();

void Encrypt()
{
   // Pop decryptor from cache...
   ICryptoTransform decryptor;
   if (!decryptors.TryPop(out decryptor))
   {
       // ... or create a new one since cache is depleted
       AesManaged aes = new AesManaged();
       aes.Key = key;
       aes.IV = iv;
       decryptor = aes.CreateDecryptor(aes.Key, aes.IV);
    }

    try
    {
       //// use decryptor
    }
    finally
    {
       decryptors.Push(decryptor);
    }
 }

Answer 3

1. 绝对不，我有麻烦。 我已经使用它两年了，突然我的一些最重要的代码在解密时开始抛出错误。
   微软补丁的结果？ 迈克菲？ 点网框架更新？ （框架 4.7.2）

当我最终弄清楚时，我将 CreateEncryptor 和 CreateDecryptor 移动到实际调用中的 using 中以进行加密和解密。 问题已解决。

Answer 4

我一直在努力解决这个与线程安全相关的问题，但我刚刚发现它是不同的。 这个“解决方案”与OP问题并不真正相关，但这篇文章是我在寻找问题解决方案时发现的最接近的文章，因此我将在这里发布，也许它会对其他人有所帮助。

当像这样使用 CryptoStream 时：

 using (MemoryStream memoryStream = new MemoryStream())
 using (CryptoStream cryptoStream = new CryptoStream(memoryStream, decryptor, CryptoStreamMode.Write))
 {
    cryptoStream.Write(cipherData, 0, cipherData.Length);
    cryptoStream.FlushFinalBlock();
    result = memoryStream.ToArray();
 }

如果 cipherData 不正确（例如，内容是纯文本且未加密），则可能会导致 FlushFinalBlock() 出现期望，例如：

"The input data is not a complete block." (System.Security.Cryptography.CryptographicException)

因此，某些内容将保持未完成状态，并导致下一次使用此函数（使用相同的解密器）返回的结果带有先前使用的剩余部分，从而导致稍后处理结果时出现意外错误。

正如 @Doug Hill 建议的那样，在每次调用时创建一个新的 CreateEncryptor()/CreateDecryptor() 将会修复它，因为这是函数每次调用之间的链接，但会以性能为代价。

在 @Andreas 的基本代码的帮助下，我创建了这个解决方案，仅在引发异常时才会处理这些 ICryptoTransform 对象，因为我不知道如何清除/重置它以再次重用。 它并不完美，但应该可以提高性能。

private Aes _aes;
private static ConcurrentStack<ICryptoTransform> decryptors = new ConcurrentStack<ICryptoTransform>();

public void Initialize()
{
    _aes = Aes.Create();
    // ...
}

public byte[] Decode(byte[] cipherData)
{
    var decryptor = DecryptorPop();
    
    try
    {
        byte[] result = null;
        using (MemoryStream memoryStream = new MemoryStream())
        using (CryptoStream cryptoStream = new CryptoStream(memoryStream, decryptor, CryptoStreamMode.Write))
        {
            cryptoStream.Write(cipherData, 0, cipherData.Length);
            cryptoStream.FlushFinalBlock();
            result = memoryStream.ToArray();
        }
        return result;
    }
    catch (Exception ex)
    {
        // since I do not know how to fix the decryptor I will just dispose it
        decryptor.Dispose();
        decryptor = null;

        // throw the same exception again if you want to catch it outside
        System.Runtime.ExceptionServices.ExceptionDispatchInfo.Capture(ex).Throw();
    }
    finally
    {
        DecryptorPush(decryptor);
    }

    return null;
}

private ICryptoTransform DecryptorPop()
{
    ICryptoTransform decryptor;
    if (!decryptors.TryPop(out decryptor))
    {
        decryptor = _aes.CreateDecryptor();
    }

    return decryptor;
}

private void DecryptorPush(ICryptoTransform decryptor)
{
    if(decryptor == null) return;

    decryptors.Push(decryptor);
}

Answer 5

重用从调用 AesManaged.CreateDecryptor 返回的 ICryptoTransform 实例意味着您使用相同的密钥和初始化向量来解密先前使用相同密钥加密的多条消息和初始化向量。

这是一个非常非常糟糕的主意。

IV 永远不应该被重复使用，并且密钥只能通过使用保护实际会话或消息密钥的主密钥来间接重复使用，该主密钥对于每条消息都应该是唯一的。 因此，唯一重复使用的密钥是主密钥，它仅用于加密其他密钥，而不用于加密数据。 密钥或 IV 之间也不应该有任何关系，即不要从密钥派生 IV，或从主密钥派生会话密钥等。

因此，要回答最初的和后续的问题，该问题归结为“如何为了安全地重用“解密器”对象”，答案很简单：不要这样做，因为那样你就重复使用了密钥和 IV，并且两者都不应该重复使用。

计划总是充满危险，一般来说我建议根本不要这样做。 只需看看各大公司和组织（微软的 Office 加密、IEEE WiFi 加密仅举两例）出错的次数，甚至多次。

这不是线程安全与否等问题，而是首先为什么要加密的问题。 如果您没有正确执行此操作，最好不要执行所有操作，因为这样至少可以清楚地看出消息不受保护。 做得不正确只不过是混淆视听。