android - Android、AES-GCM 或纯 AES 上的数据加密？

Question

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

已经确定加密算法必须是AES， key 为256位。但是，我想就我们应该使用哪种 AES 实现和/或“模式”做出明智的决定。我读过一些叫做 GCM 模式的东西，我们已经用它做了一些测试(使用 BouncyCaSTLe/SpongyCaSTLe)，但我并不完全清楚 AES-GCM 到底是做什么用的，以及与普通模式相比它“买”了我们什么AES - 以及是否需要权衡取舍。

以下是我们的疑虑/要求/问题列表:

• 填充:我们需要加密的数据并不总是 128 位的倍数，因此 AES 实现/模式应该添加填充，但仅在必要时添加。我的印象是，普通的 AES 实现(例如 javax.crypto.Cipher 提供的)不会这样做，但初步测试表明它会这样做。所以我猜填充要求本身并不是诉诸 GCM 之类的东西而不是“普通”AES 的理由。对吗？

• 身份验证:我们需要一种万无一失的方法来检测数据是否已损坏。然而，理想情况下，我们还希望检测何时使用不正确的 key 尝试解密。因此，我们希望能够区分这两种情况。我最终首先考虑 GCM 的原因是因为这个 Stackoverflow question ，其中一位响应者似乎暗示可以使用 AES-GCM 进行这种区分，尽管他没有提供详细的解释(更不用说代码了)。

• 最小化开销:我们需要限制存储和传输加密数据的开销。因此，我们希望知道特定 AES 实现/模式的选择是否以及在多大程度上影响开销量。

• 加密/解密性能:虽然这不是主要问题，但我们想知道特定 AES 实现/模式的选择在多大程度上影响加密和解密性能，无论是在CPU 时间和内存占用。

提前感谢您提供任何建议、说明和/或代码示例。

编辑: delnan 很有帮助地指出没有“普通 AES”这样的东西。所以澄清一下，我的意思是使用 Java 的内置 AES 支持。
像这样:Cipher localCipher = Cipher.getInstance("AES");

Answer 1

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

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

到目前为止，正常的操作模式是 ECB(Java 的默认模式)、CBC、CTR、OFB 和其他一些模式。他们都只提供加密。但是，如果没有完整性， secret 性本身很少有用；必须以一种特别的方式将这种经典模式与完整性检查结合起来。由于密码学很难正确设置，因此此类组合通常不安全，速度比必要的慢，甚至两者兼而有之。

Authenticated Encryption 模式(最近)由密码学家创建来解决该问题。 GCM 是最成功的之一:它已被 NIST 选择，它非常高效，它是免费的，并且它可以携带额外的经过验证的数据(即保持清晰的数据，但您可以验证其真实性)。有关其他模式的说明，请参阅 this excellent article of Matthew Green .

解决您的问题:

• 填充:默认情况下，Java 使用 PKCS#7 填充。这行得通，但它通常容易受到 padding oracle attacks 的攻击最好用 MAC 打败它们. GCM 已经嵌入了一个 MAC(称为 GMAC)。

• 身份验证:AES-GCM 只接受一个 AES key 作为输入，而不是密码。它会告诉您 AES key 是否错误或有效负载已被篡改，但这些情况被视为一个。相反，您应该考虑使用适当的 key 派生算法，例如 PBKDF2或 bcrypt从密码中导出 AES key 。我不认为总是可以判断密码是否不正确或负载是否已被修改，因为验证前者所需的数据总是可能被破坏。您可以加密一个已知的小字符串(使用 ECB AES)，将其一起发送，并使用它来验证密码是否正确。

• 最小化开销:归根结底，如果您需要身份验证，所有模式都会导致相同的开销(大约 10-20 字节)。除非您使用非常小的有效负载，否则可以忽略这一点。

• 性能:GCM 非常好，因为它是一种在线 模式(不需要缓冲整个负载，因此内存较少)，它是可并行化的，并且每个明文 block 需要一次 AES 运算和一次伽罗瓦乘法。像 ECB 这样的经典模式速度更快(每个 block 仅一个 AES 操作)，但是 - 同样 - 您还必须考虑完整性逻辑，这最终可能比 GMAC 慢。

话虽如此，但必须意识到 GCM 安全性依赖于良好的随机数生成来创建 IV。