Android，AES-GCM还是普通AES上的数据加密？

Question

我的团队需要开发一个解决方案，在用Java编写的Android应用程序的上下文中加密二进制数据(存储为byte[])。加密的数据将以各种方式传输和存储，在此期间不能排除数据损坏的可能。最终，另一个Android应用程序(同样是用Java编写的)将不得不解密数据。

已经确定加密算法必须是AES，密钥为256位。然而，我想对我们应该使用的AES实现和/或“模式”做出一个明智的决定。我读过一些叫做GCM模式的文章，我们用它做了一些测试(使用Bouncy城堡/Spongy城堡)，但我并不完全清楚AES-GCM到底是为了什么，和普通AES相比，它“买”了我们什么，以及是否有任何交易需要考虑。

以下是我们所关注的问题/要求/问题的清单：

• 填充:我们需要加密的数据并不总是128位的倍数，所以实现/模式应该添加填充，但只有在必要时才需要。我的印象是，普通的AES实现(如javax.crypto.Cipher提供的)不会这样做，但最初的测试表明是这样的。因此，我猜想填充需求本身并不是求助于类似GCM的理由，而不是“普通”的AES。对吗？
• Authentication:我们需要一种万无一失的方法来检测是否发生了数据损坏。但是，理想情况下，我们还希望检测使用不正确密钥尝试解密的时间。因此，我们希望能够区分这两种情况。我最终考虑GCM的原因首先是由于这个堆栈过流问题，其中一个响应者似乎暗示使用AES-GCM进行这种区分是可能的，尽管他没有提供详细的解释(更不用说代码了)。
• 最小化开销：我们需要限制加密数据的存储和传输开销。因此，我们希望了解对特定AES实现/模式的选择是否以及在多大程度上影响开销的数量。
• 加密/解密性能：虽然不是主要关注的问题，但我们想知道选择特定的实现/模式会在多大程度上影响加密和解密性能，无论是在CPU时间还是内存占用方面。

预先感谢您的任何建议、澄清和/或代码示例。

编辑： delnan很有帮助地指出，没有“普通AES”这样的东西。因此，为了澄清，我的意思是使用Java的内置AES支持。

就像这样：Cipher localCipher = Cipher.getInstance("AES");

Answer 1

2012年的答案是GCM，除非你有严重的兼容性问题。

GCM是一种经过验证的加密模式。它一次性为您提供机密性(加密)、完整性和身份验证(MAC)。

到目前为止，正常的操作模式是欧洲央行(这是Java的默认模式)、CBC、CTR、OFB和其他几种模式。他们都只提供加密。保密本身很少有用，但没有完整性；一个人必须结合这样的经典模式和完整性检查以一种临时的方式。由于密码学很难正确，这种组合常常是不安全的，速度慢于必要，甚至两者兼而有之。

通过身份验证的加密模式(最近)已经由密码家创建，以解决这个问题。GCM是最成功的方法之一:它已经被NIST选中，它是高效的，它是免费的，并且它可以携带额外的认证数据(即保持清晰的数据，但您可以验证其真实性)。有关其他模式的说明，请参见这篇关于马修·格林的优秀文章。

来谈谈你的关切：

• 填充:默认情况下，使用PKCS#7填充。这是可行的，但它通常容易受到填充甲骨文攻击的攻击，而MAC则是最好的选择。GCM已经嵌入了一个MAC (称为GMAC)。
• Authentication: AES-GCM只使用一个AES密钥作为输入，而不是密码。它将告诉您，如果AES密钥是错误的，或有效载荷已被篡改，但这类条件被视为一个。相反，您应该考虑使用适当的密钥派生算法(如PBKDF2或bcrypt )从密码派生AES密钥。我不认为总是能够判断密码是否不正确，或者是否修改了有效负载，因为验证密码所需的数据总是会被破坏。您可以加密一个已知的小字符串(使用欧洲央行AES)，发送它，并使用它来验证密码是否正确。
• 最小化开销：在一天结束时，如果您想要身份验证，所有模式都会导致相同的开销(大约10-20字节)。除非您正在处理非常小的有效载荷，否则可以忽略这一点。
• Performance: GCM非常好，因为它是一种在线模式(不需要缓冲整个有效负载，因此内存更少)，它是可并行的，它需要每个明文块一个AES操作和一个Galois乘法。欧洲央行这样的经典模式速度更快(每个区块只运行一个AES操作)，但--同样--你也必须考虑到完整性逻辑，这最终可能会比GMAC慢。

尽管如此，人们必须意识到，GCM安全依赖于良好的随机数生成来创建IV。