我有兴趣提供在.Net中使用的托管dll，它提供经过身份验证的加密服务。 DLL可能在WPF程序或ASP应用程序中使用。我有几个与微软的加密和流模型有关的问题。
经过身份验证的加密模式（CCM，CWC，EAX，GCM等）通常会产生两个工件 - 第一个是密文，第二个是身份验证标记。它很容易流加密，但可能会有一些问题。例如，由于标头的构建方式和经过身份验证的加密模式会生成身份验证标记，因此无法对CCM进行流式处理。
解密比较简单，因为它无法流式传输。无法对解密进行流式传输，因为所有密文都必须可用，并且在解密之前必须使用身份验证标记验证密文。
如何为块密码调整经过身份验证的加密模式，以便可以在CryptoStream中使用？它甚至可能吗？也许是微软不提供它的原因？
Microsoft有推荐吗？例如，将大型邮件拆分为较小的邮件或单元（每个邮件或单元都有自己的标签）？或者MS是否建议在输入整个消息和标签之前进行缓冲？
Microsoft建议“放置”标记？在流的开头？在流的最后？
一些有用的参考资料：
答案 0 :(得分：5)
2010年，Microsoft CLR安全团队发布了extension to the System.Security.Cryptography，其中包括经过身份验证的对称加密GCM。从那时起他们为什么没有做任何事情，我不知道。
但是，既然你的问题强调“微软会做什么？”，那就是......他们这样做了。
答案 1 :(得分：2)
您使用的假设并不真正适用于GCM等流密码上经过身份验证的加密方法：您无法在验证前解密。这对于例如在CBC模式下的AES，当填充oracles时，由MAC验证。例如，GCM模式不执行填充，因为基础流密码是CTR模式加密。这意味着不必应用填充，因此填充神谕不适用。
当然，在验证之前用解密数据执行任何业务逻辑是非常不明智的。任何涉及未经验证的数据的代码都应被视为高风险，并应对其进行静态分析和审核。如果您想更早地执行任何业务逻辑，那么您应该确保在执行此操作之前对其进行身份验证。将它拆分成较小的部分肯定是有道理的。
显然这些只是我的建议。对于Microsoft的建议：如果使用Google或（上帝禁止）Bing找不到它们：请问微软。这里没有人可以为他们说话。