Question

除了能自动调用所需的内容外，文档从未真正提及为什么应使用CryptoStream代替TransformBlock和TransformFinalBlock。

因此，为什么要使用此答案中的代码（https://stackoverflow.com/a/2006922/7343355）来代替：

using (var encryptor = aes.CreateEncryptor())
{
    result = encryptor.TransformFinalBlock(data, 0, data.Length); // Data length is greater than the blocksize
}

即使TransformFinalBlock应该在TransformBlock之后且仅在最后一个块中使用，但该代码还是通过了所有单元测试，并始终为我提供正确的结果。是否有可能失败的情况？使用ECB密码模式进行测试是否与我有关，并且在其他模式下会失败？

Answer 1

通常首选CryptoStream 的原因是它更通用。它用于对称加密，通常可能涉及大量数据。出于实际原因（例如限制内存使用），将整个要加密的内容和加密的输出全部同时存储在内存中可能是不切实际的。

这样，您可能已经在使用流，例如NetworkStream或FileStream。 CryptoStream与其他流自然融合得很好，因此您常常会最终构建一条 pipeline （或者可能会用CopyTo或CopyToAsync来弥合两者之间的差距“读取”端和“写入”端）。

如果，您处于一个要加密的整体很小并且已经在内存中的位置，因此您也可以应对整个加密输出内存，那么可以肯定，您可以只使用TransformFinalBlock。并且您将为自己节省一些对象分配（但是我们已经说过，如果我们在这里，内存使用就不成问题了……），但要付出的代价是现在必须用两个完全之一来编写密码取决于每个用例的不同方式。

元位

不幸的是，我们遇到问题的玩具示例（“类似……的东西”或实际的MCVE）看起来像它们适合第二种情况。但是大多数回答此类问题的人都会认为代码将需要处理更类似于第一种情况的情况，因此即使CryptoStream可以解决问题，他们仍然会提供基于TransformFinalBlock的解决方案。问题中的代码。

为什么使用CryptoStream代替TransformBlock？

1 个答案: