Java AESGCMNoPadding-cipher.getIV（）给我什么？

Java AES / GCM / NoPadding-cipher.getIV（）给我什么？

Q1：cipher.getIV（）返回的IV以这种方式使用对我安全吗？

是的，至少是针对Oracle提供的实施。它使用默认

SecureRandom

实现单独生成。由于它的大小为12个字节（GCM的默认值），因此您具有96位的随机性。计数器重复的机会很小。您可以在Oracle
JDK所基于的OpenJDK（GPL版）中查找源。

但是，我仍然建议您生成自己的12个随机字节，因为其他提供程序的行为可能有所不同。

---

Q2：IV是否总是12个字节长？

这很有可能是因为它是GCM的默认值，但其他长度对于GCM 也
有效。但是，对于12字节以外的任何其他大小，该算法将不得不执行其他计算。由于弱点，强烈建议将其保留为12字节/ 96位，并且API
可能会限制您选择IV大小 。

---

Q3：身份验证标签是否总是16个字节（128位）长？

不可以，它的字节大小可以从64位到128位以8位为增量的任意大小。如果较小，则仅由身份验证标签的最左侧字节组成。您可以将标签的另一个大小

GCMParameterSpec

用作

init

呼叫的第三个参数。

请注意，GCM的强度在很大程度上取决于标签的大小。我建议将其保留为128位。最少应包含96位， 特别是 如果您要生成大量密文时。

---

问题4：使用＃2和＃3，并且没有填充，这是否意味着我的加密消息始终为12 + src.length + 16个字节长？
（因此，我可以安全地将它们压缩到一个字节数组中，我知道该长度正确吗？）

往上看。对于Oracle提供程序，情况就是如此。使用

GCMParameterSpec

来确保这一点。

---

Q5：在给定用户知道的恒定src数据的情况下，对用户显示无数的src数据加密是否安全？

几乎没有限制 ，是的。经过约2 ^ 48次加密后，我将开始担心。通常，您应该 设计 密钥更改。

---

Q6：如果每次的src数据都不相同（例如，包括System.currentTimeMillis（）或随机数），对用户显示无数的src数据加密是否安全？

请参阅问题5的答案

---

问题7：如果在加密之前用随机数填充src数据会有所帮助吗？ 在前面和后面说8个随机字节，还是只说一端？还是完全没有帮助/会使我的加密变得更糟？

不，完全没有帮助。GCM在下面使用CTR模式，因此只需使用密钥流进行加密即可。它 不会 充当IV。如果您需要几乎无数个密文（高于2 ^
48！），那么我建议您使用该随机数和密钥作为密钥派生函数或KDF。HKDF目前是最好的，但您可能需要使用Bouncy Castle或自己实施。