我有兴趣提供一个在.Net 中使用的托管 dll，它提供经过身份验证的加密服务。DLL 可能在 WPF 程序或 ASP 应用程序中使用。我有几个与 Microsoft 的加密和流模型有关的问题。
经过身份验证的加密模式（CCM、CWC、EAX、GCM 等）通常会产生两个工件 - 第一个是密文，第二个是身份验证标签。流式加密相当容易，但可能存在一些问题。例如，由于标头的构建方式和经过身份验证的加密模式会产生身份验证标签，因此无法流式传输 CCM。
解密比较棘手，因为它无法流式传输。无法流式传输解密，因为所有密文都必须可用，并且密文必须在解密之前使用身份验证标签进行验证。
如何为分组密码调整经过身份验证的加密模式，以便它可以用于CryptoStream？甚至可能吗？也许是微软不提供它的原因？
微软有推荐吗？例如，将大消息分解成更小的消息或单元（每个都有自己的标签）？还是 MS 建议在输入整个消息和标签之前进行缓冲？
Microsoft 建议在哪里“放置”标签？在流的开头？在流的尽头？
一些有用的参考资料：
2010 年，微软 CLR 安全团队发布了对 System.Security.Cryptography 的扩展，其中包括经过身份验证的对称加密，特别是GCM。为什么他们从那以后没有做任何事情，我不知道。
但是，由于您的问题强调“微软会做什么？”，所以......他们做到了。
您使用的假设并不真正适用于 GCM 等流密码上的经过身份验证的加密：您无法在验证之前解密。这适用于例如 CBC 模式中的 AES，它在应用填充预言时由 MAC 进行身份验证。例如，GCM 模式不执行填充，因为底层流密码是 CTR 模式加密。这反过来意味着不必应用填充，因此填充预言不适用。
当然，在经过身份验证之前对解密数据执行任何业务逻辑是非常不明智的。任何涉及未经验证数据的代码都应该被认为是高风险的，并且应该进行静态分析和审计。如果您想更早地执行任何业务逻辑，那么您确实应该确保在这样做之前对其进行身份验证。把它分成更小的部分肯定是有意义的。
显然，这些只是我的建议。对于 Microsoft 的建议：如果无法使用 Google 或（上帝保佑）Bing 找到它们：询问 Microsoft。这里没有人可以为他们说话。