为什么使用CryptoStream代替TransformBlock? [英] Why use CryptoStream instead of TransformBlock?

问题描述

文档从未真正提及为什么应该使用 CryptoStream 代替 TransformBlock 和 TransformFinalBlock ，而是自动调用所需的任何内容.

Docs never really mention why CryptoStream should be used instead of TransformBlock and TransformFinalBlock other than that it calls whichever is needed automatically.

因此，为什么要在此答案中使用代码( https://stackoverflow.com/a/2006922/7343355)代替:

Thus, why would one use the code in this answer (https://stackoverflow.com/a/2006922/7343355) instead of this:

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

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

Even though TransformFinalBlock should be used after TransformBlockand only on the last block, somehow this code passed all the unit tests and always gives me the correct result. Are there any cases where this could fail? Does this have something to do with me using ECB cipher mode to test this and would fail under other modes?

推荐答案

通常首选 CryptoStream 的原因是，它更通用.它用于对称加密，通常可能涉及大量数据.由于诸如限制存储器使用之类的实际原因，将整个要加密的事物和加密的输出同时全部存储在存储器中可能是不切实际的.

The reason why CryptoStream is generally preferred is that it's more generally applicable. It's used for symmetric encryption which can often involve large amounts of data. For practical reasons, such as limiting memory usage, it may not be practical to have the entire thing to be encrypted and the encrypted output all in memory at the same time.

这样，您可能已经在使用流，例如 NetworkStream 或 FileStream . CryptoStream 自然可以与其他流完美地组合在一起，因此您通常会最终构建一条 pipeline (或者可能使用 CopyTo 或CopyToAsync 弥合读取"端和写入"端之间的鸿沟.

As such, you'll likely already be working with streams, such as NetworkStream or FileStream. CryptoStream naturally composes well with these other streams so that you'll often end up building a pipeline (or possibly two with CopyTo or CopyToAsync bridging the gap between the "read" side and the "write" side).

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

If you're in a position where the entirety of what is to be encrypted is small and already in memory, and so you'll also be able to cope with the whole encrypted output being in memory, then sure, you can just use TransformFinalBlock instead. And you'll save yourself a few object allocations (but we've already said memory usage isn't a problem if we're here...), at the expense of now having to write your crypto code in one of two completely different ways depending on each use case.

元位

不幸的是，我们遇到问题的玩具示例(类似……"或实际的MCVE)看起来像它们适合第二种情况.但是大多数回答此类问题的人会认为代码将需要处理与第一种情况更为相似的情况，因此即使 TransformFinalBlock CryptoStream 的解决方案.>可以解决问题中的代码 .

Unfortunately, the toy examples we get in questions (either "something like..." or actual MCVEs) will look like they fit the second case. But most people answering such questions will assume that the code will need to cope with situations more akin to the first, and so they'll still offer CryptoStream based solutions even if the TransformFinalBlock one would work for the code in the question.

这篇关于为什么使用CryptoStream代替TransformBlock?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！