C# 为什么使用CryptoStream而不是TransformBlock？

文档从未真正提到为什么应该使用

CryptoStream

而不是

TransformBlock

和

TransformFinalBlock

，除非它会自动调用所需的值

因此，为什么要使用这个答案（）中的代码而不是这个：

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

---

尽管

TransformFinalBlock

应该在

TransformBlock

之后使用，并且只在最后一个块上使用，但不知何故，这段代码通过了所有单元测试，并且总是给出正确的结果。有没有可能失败的案例？这是否与我使用

ECB

密码模式来测试这一点有关，并且在其他模式下会失败？

通常首选

加密流的原因是它更普遍适用。它用于对称加密，通常涉及大量数据。出于实际原因，例如限制内存使用，将要加密的整个内容和加密的输出同时放在内存中可能不太实际

因此，您可能已经在使用流，例如
NetworkStream
或
FileStream
CryptoStream
自然地与这些其他流很好地组合在一起，因此您通常会构建一个管道（或者可能是两个管道，通过
CopyTo
或
CopyToAsync
弥合“读取”端和“写入”端之间的差距）

如果要加密的内容很小，并且已经在内存中，因此您也可以处理内存中的整个加密输出，那么当然，您可以使用
TransformFinalBlock
。您将为自己节省一些对象分配（但我们已经说过，如果我们在这里，内存使用不是问题…），代价是现在必须根据每个用例以两种完全不同的方式之一编写密码


元位

不幸的是，我们在问题中得到的玩具示例（要么是“类似…”的东西，要么是实际的MCVE）看起来似乎适合第二种情况。但大多数回答这些问题的人都会认为代码需要处理与第一个问题更相似的情况，因此，他们仍然会提供基于
CryptoStream
的解决方案，即使
TransformFinalBlock
可以用于问题中的代码。
因此，如果我们有完整的数据……那么我们可以直接使用TransformFinalBlock（）而不是CryptoStream。