javaaes初始向量_加密–如何为AESCTRNoPadding选择合适
的IV（初始化向量）？
CTR安全性要求您不要使⽤相同密钥的两个消息加密来重复使⽤IV。实际上甚⾄更严格：CTR模式通过加密计数器的连续值(IV只是该计数器的初始值)⼯作，只有当相同的计数器值不使⽤两次时才能实现适当的安全性；这意味着⽤IV加密值实际上“消耗”⼀系列连续的IV值，这些序列不能与另⼀个加密⼀起使⽤。
如何为文件夹加密这样做的简单⽅法是使⽤加密安全的随机数⽣成器，并为每个消息创建⼀个新的16字节随机IV。我强调“加密安全”，因为这是进⼝;⼀个基本的随机数发⽣器是不够的。使⽤Java，使⽤java.util.SecureRandom。使⽤Win32，调⽤CryptGenRandom()。通过随机选择，可能的128位IV的空间⾜够⼤，使得碰撞极不可能。实际上，这就是为什么AES使⽤128位块(因此意味着128位IV)。
将解密消息的实体必须知道IV，所以您必须将其与加密消息⼀起存储。这是⼀个额外的16个字节。我明⽩，这个开销是你想要避免的，虽然16个字节不是⼀个cookie。 cookie的有效最⼤长度取决于Web浏览器，但是4000个字符似乎在“⽆处不在”中⼯作。⼀个16字节的IV，⽤字符编码(例如使⽤Base64)将使⽤约22个字符，即远远⼩于最⼤cookie⼤⼩的1％：也许你负担得起？
现在我们可以变得更时髦，并尝试通过欺骗减少IV长度：
>使⽤散列函数⽣成IV：服务器端，使⽤从0开始的计数器，并且每当需要新的IV时递增。要得到IV，你⽤适当的散列函数对计数器进⾏散列，例如SHA-256，并保留哈希值的前16个字节。散列函数的“随机化属性”将⾜以使IV对于CTR要求⾜够随机。这需要⼀个加密安全的哈希函数，因此SHA-256(避免MD5)。然后，您只需将计数器值存储在cookie中，计数器将短于16个字节(例如，如果您的客户数量不超过4亿，计数器将以4个字节为准)。然⽽，有⼀个隐藏的成本：服务器(我认为服务器在你的系统中执⾏加密)必须确保它不会重复使⽤计数器值，所以它必须以⼀种持续存在的⽅式存储“当前计数器”服务器重新启动，如果您扩展到⼏个前端也不会失败。这似乎并不容易。
>使⽤外部唯⼀值：可能，cookie可以是提供⾜够数据以⽣成每个加密唯⼀的值的上下⽂的⼀部分。例如，如果请求还包含(清除)“⽤户ID”，则可以将⽤户ID⽤作IV源。该设置与上述相似：您获取所有数据，将其填⼊SHA-256，SHA-256输出的前16个字节是您需要的IV。这只有在给定的加密消息的数据没有变化的情况下才能起作⽤，如果它真的是唯⼀的。这是⼀个罕见的情况：例如，只有在永远不需要为同⼀⽤户重新加密新消息的情况下，“⽤户ID”才是有⽤的，如果永远不会有⽤户ID被重⽤的可能性(例如，⼀个旧⽤户退出，⼀个新⽤户来，并选择现在的免费⽤户ID)。
使⽤密码安全PRNG⽣成的随机16字节IV仍然是“安全”的⽅式，⽽我推荐的。如果您在cookie中发现空间紧张，则这意味着您正在接近4 kB限制，此时可能需要使⽤压缩(在加密之前的数据上，加密后压缩⾮常不太可能运⾏)。使⽤zlib(在Java中，您可以通过java.util.zip访问zlib)。
警告：在上述所有⽅⾯，我不是说cookie加密是否有助于提供您尝试实现的任何安全特性。通常，当需要加密时，实际上需要加密和完整性，然后应该使⽤组合加密和完整性模式。 Lookup GCM和CCM.此外，Cookie加密主要适⽤于⼀个⽬的，这是为了避免存储服务器端⼀点⽤户特定数据的成本。如果你想加密⼀个cookie的其他东西，例如验证⼀个有效的⽤户，那么你做错了：加密不是正确的⼯具。
版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。
发表评论