相关疑难解决方法(0)

我知道独特的IV在加密时非常重要,可以防止频率分析等攻击.问题:对于AES CBC加密,最重要的是IV？有一个非常明确的答案解释了IV的重要性.

以明文形式发送IV会有任何安全漏洞吗？或者是否需要使用用于发送对称密钥的相同公钥/私钥进行加密？

如果需要加密发送IV,那么为什么不每次都生成一个新的对称密钥并将IV视为密钥的一部分？是否生成对称密钥太昂贵了？还是最小化传输的数据量？

Secret与Non-secret Initialization Vector的最佳答案如下:

典型的密钥建立协议将导致双方计算一个数据,但只有他们都知道.利用Diffie-Hellman(或其任何椭圆曲线变体),所述共享数据片段具有固定长度并且它们不能控制其值(它们两者都获得相同的看似随机的比特序列).

两个实体如何在没有共享信息的情况下导出"相同的看似随机的比特序列"？假设共享信息是加密发送的吗？并且,如果共享信息是加密发送的,为什么不直接发送加密的IV？

因为应用程序需要安全地传输对称密钥,所以将IV与密钥本身分开似乎是一种优化.或者我错过了什么？

我确信这个问题没有一个答案,只是想找出一个通用的方法.

使用Java 1.4.2,我需要生成一个密钥和IV,以便在对称算法中使用.这些值将通过安全通道与收件人预先共享.

我可以使用KeyGenerator.keyGenerate()生成密钥.但除非我错过它,否则没有生成随机IV的功能.

我应该做一些完全随意的事情,比如从内存中拉出16个随机字节 或者是否有一种生成足够随机初始化向量的首选方法？

我绝不是一名加密专家,我一直在阅读围绕Stack Overflow和维基百科的一些问题,但在定义IV及其用法方面,没有什么是真正"明确的".

我发现的要点:

• IV加在明文消息之前,以加强加密
• IV真的是随机的
• 每条消息都有自己独特的IV
• 有时使用时间戳和加密哈希值而不是随机值,但由于可以预测时间戳,因此这些值被认为是不安全的
• WEP(在802.11中)的弱点之一是IV将在特定数量的加密后重置,从而重复IV

我确信还有很多其他要点,有人能想到我错过的任何其他特征吗？

我正在开发一个与位于 VPS 上的数据库通信的应用程序。我需要在我的数据库中存储使用 AES-256 加密的信息。

如果我是对的，当我加密时，会生成一个 IV 参数，并且每个加密都不同。但是当我解密时，我没有这个参数，因为我只有密钥和数据库中的加密文本。

我能做些什么来解决这个问题？

我有一个函数,使用AES加密我从用户输入的关键文本.并根据要求解密.什么是维护AES加密的密钥和IV的理想方法(截至目前在应用程序中硬编码).我每次都在数据库中保存加密数据.页面加载从数据库中检索加密值.单击按钮即可解密此值.有没有最好的我可以更好地使用键和IV.