在加密期间，为MACing添加AAD似乎只是使用AEADParameters。但是我不清楚以后在哪里可以获取此AAD。
我认为processAADBytes最有可能是我想要的。 processAADBytes说
如果实现支持，这将是一个在线操作
并且不会保留相关数据。
我对此感到困惑。我对此方法有2种潜在的解释：
这是在加密过程中（除AEADParameters之外）传递AAD的另一种方法，并且AAD不会与密文一起存储。
这是一种在解密过程中验证AAD的方法。需要将AAD（来自其他地方）馈入此处以进行MAC验证。
我曾期望找到类似getAAD()的方法。因此，我猜想此密码根本不存储带有密文的AAD，而只是对我们声称是AAD的数据提供MAC验证？
最佳答案
这是在加密过程中传递AAD的另一种方法（除了AEADParameters），并且AAD不会与密文一起存储。
没错，通常AEADParameters的处理方式与processAADBytes中的数据相同。不一定总是在* 1前面提供AAD，它可能包含很多数据（即使通常没有）。这意味着processAADBytes比AEADParameters更加灵活，因为它允许流式传输并且不需要同时缓冲所有AAD。
另一方面，AEADParameters对于向后兼容以及可能更有效/更清洁的设计可能很有用。
这是一种在解密过程中验证AAD的方法。需要将AAD（来自其他地方）馈入此处以进行MAC验证。
好吧，是的，通常是这样，但是您也可以在这里使用AEADParameters。
因此，两者都是正确的。是的，您需要确保消息的接收者可以接收（和/或能够生成）AAD。
* 1 EAX允许随时提供AAD，如果在加密/解密开始后确实提供了AAD，则GCM需要进行其他计算（模幂！）。 CCM要求所有AAD都在前期。如果可以，则应在加密/解密之前提供所有AAD。