加密AES-256和初始化向量 [英] Encryption with AES-256 and the Initialization Vector
问题描述
[1] Java 256位AES密码加密
[2] http://gmailassistant.sourceforge.net/src/org/freeshell/zs/common/Encryptor.java.html
我最初是从第一个链接跟随erickson的解决方案，但从我可以看出，PBKDF2WithHmacSHA1不支持我的实现。所以，我转向第二个链接来获得我自己的迭代SHA-256哈希创建的想法。
我的问题来自于如何创建IV。一个实现（[1]）使用Cypher类中的方法来导出IV，其中另一个（[2]）将使用散列的第二个16个字节作为IV。很简单，为什么从安全角度来看，差异和哪个更好？我对于IV的推导和使用感到困惑（我明白他们使用了什么，只是不太细微的差异），所以任何澄清也是非常受欢迎的。
我注意到第二个链接使用AES-128而不是AES-256，这将给我建议，我必须去上SHA-512是我想使用这种方法。这似乎是一个不幸的要求，因为用户的密码必须是16个字符以上，以确保远程安全的哈希和这个应用程序注定是手机。
来源可根据要求提供，但仍然不完整。
提前谢谢。
不应该从密码中生成IV。
即使使用相同的密钥和明文，使用，将产生不同的密文。如果IV只是从密码确定性地生成，你每次都会得到相同的密文。在引用的例子中，随机选择了一个盐，所以即使使用相同的密码也会生成一个新的密钥。
只需使用一个随机数发电机选择IV。这就是密码在内部做的。
我想强调，你必须存储IV（如果你使用第一种方法）或盐（如果使用第二种方法）以及密文。如果一切都是从密码派生出来的话，你不会有很好的安全性;每个消息都需要一些随机性。
I have a question relating to the use of an Initialization Vector in AES encryption. I am referencing the following articles / posts to build encryption into my program:
[1] Java 256-bit AES Password-Based Encryption
[2] http://gmailassistant.sourceforge.net/src/org/freeshell/zs/common/Encryptor.java.html
I was originally following erickson's solution from the first link but, from what I can tell, PBKDF2WithHmacSHA1 is not supported on my implementation. So, I turned to the second link to get an idea for my own iterative SHA-256 hash creation.
My question comes in how the IV is created. One implementation ([1]) uses methods from the Cypher class to derive the IV where are the other ([2]) uses the second 16 bytes of the hash as the IV. Quite simply, why the difference and which is better from a security standpoint? I am kinda confused to the derivation and use of IVs as well (I understand what they are used for, just not the subtler differences), so any clarification is also very welcome.
I noticed that the second link uses AES-128 rather than AES-256 which would suggest to me that I would have to go up to SHA-512 is I wanted to use this method. This seems like it would be an unfortunate requirement as the user's password would have to be 16 characters longer to ensure a remotely secure hash and this app is destined for a cell phone.
Source is available on request, though it is still incomplete.
Thank you in advance.
The IV should not be generated from the password alone.
The point of the IV that even with the same key and plaintext is re-used, a different ciphertext will be produced. If the IV is deterministically produced from the password only, you'd get the same ciphertext every time. In the cited example, a salt is randomly chosen, so a new key is generated even with the same password.
Just use a random number generator to choose an IV. That's what the cipher is doing internally.
I want to stress that you have to store either the IV (if you use the first method) or a salt (if you use the second method) together with the ciphertext. You won't have good security if everything is derived from the password; you need some randomness in every message.
这篇关于加密AES-256和初始化向量的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
