问维护请求之间的敏感密钥

EN

对你的问题的简短回答是，不知道IV使得AES，或真正的任何分组密码在一个正确的操作模式下，更不可能蛮力，因为基本上使IV成为密钥的扩展。对于AES-256,256位密钥加上128位IV基本上要求攻击者正确猜测384位序列，需要进行最坏的2^384次尝试。从长远来看，如果一台电子级的计算机运行在100%的热效率，如果我们的太阳在剩余寿命中产生的每一个光子，在太阳变成黑矮星之前，只能尝试大约2218个键。

但是，双方都需要IV，以便在任何使用IV的模式下进行加密/解密，因此，与有关加密方案的其他细节一样，除了协商过程中各方共享的实际密钥(如算法、模式、块大小、密钥大小)外，IV也被视为公共信息。隐藏它是可能的，就像密钥可以安全地交换一样(离线，公钥密码)，但这是不必要的。

在回答了这个问题后，我必须说，你还没有提供很多信息，这使得我们不可能回答更广泛的“这个方案安全吗”的问题。例如，用户的密码如何与密钥相关(您是在使用KDF还是其他“密钥拉伸”方案？)用于AES加密的操作模式是什么(有些模式比其他模式更安全，而有些模式实际上已被破坏)。编辑: CBC模式不是一个糟糕的选择(还有更糟的)，但必须注意确保您的代码不能用作“填充oracle"；一个”黑匣子“将告诉攻击者在解密时某个特定的密文消息是否被正确填充。它可以用于在不知道密钥的情况下从已知的密文中反向工程明文消息。由于这仅仅是一个服务器端进程，因此没有客户端代码可用于解密，因此攻击者需要深入到相当远的地方，才能将服务器代码转换为填充oracle，但绝不假设；如果您有一个好的实现可供您使用，我将选择一种经过身份验证的模式，如GCM或CCM，这将抵抗填充-oracle攻击。

我还会说，这个方案似乎只在服务器端；如果密钥和IV只存储在服务器上，那么所有的加密和解密都必须发生在服务器上，这意味着除非您使用其他东西(如SSL )向客户端发送数据，否则这一特定部分的安全性是毫无意义的。

是的，IV设置用于生成密码文本的流的初始状态。如果没有IV，您将得到一个不同的流，并且解密将失败。根据操作模式的不同，其失败的程度可能会有所不同。不过，我不知道你为什么会问你为什么要在没有IV的情况下破解它，听起来你在说解密。虽然需要静脉注射，但这并不是秘密。可以让IV知道，它只是通过比较使用相同密钥加密的类似消息来防止攻击。关键是要保持秘密。

如果密钥被泄露，在大多数操作模式中，都会有极大地削弱加密的攻击。虽然IV是秘密的稍微增加了安全性，但披露它并不会对加密的安全性造成灾难性的影响。然而，密钥的保密是至关重要的，因为如果密钥已知，则IV的保密很可能无法保护消息。

大多数关于会话劫持之类的担忧是有效的，但不会立即危及服务器上的数据。我的建议是在用户密钥最初使用另一个时间会话密钥获得后对其进行加密，将密钥分成三个部分(或用3个不同的会话密钥对其进行加密)，然后将IV (或适当的IV)的一部分和密钥的一部分(或3个密钥中的一个)作为令牌。然后，当提供所有三条信息时，可以对实际密钥进行解密，但任何已泄露的密钥都不会在会话之外受益，真正的解密密钥只有在提供了会话密钥的3段作为密码的替代后才能用于服务器。

使用三个单独的会话密钥将提供更多的安全性，但也需要更多的处理能力。一个简单的拆分仍然会提供一些额外的保护，这取决于密码的操作方式，而且成本更低。

最重要的是，您永远不希望向攻击者(或客户端)公开实际的解密密钥或有关数据解密密钥的任何信息，并且不希望它在DB (处于静止状态)中不受保护。这意味着您需要以一种受只有客户端知道的信息保护的方式来存储数据密钥，并将信息分成三部分来折衷，稍微增加了难度。