AES-256 Encryption Best Practices
brian at milby7.com
Tue Jul 3 15:07:32 EDT 2018
I think the IV vulnerability that I’m talking about is more theoretical than an actual concern. From what I’ve read the attacker needs to be able to control/influence what is being encrypted for knowledge of the next IV to help (so they can use a known plain text to test their key hypothesis).
And yes, the IV does make each encrypted message different even for the same plain text.
I didn’t fully work out the IV vulnerability but it did make sense how it would work.
On Jul 3, 2018, 2:39 PM -0400, William Prothero <waprothero at gmail.com>, wrote:
> Thank you for your wisdom on this issue. I’m very interested in your recommendations and they are inspiring me to do more Internet research.
> Just asking...
> You said that the attacker could figure out the next iv. Since I append the iv to the front of the encrypted data, the attacker will always know the iv, correct? As I understand, the iv is used to obfuscate the encrypted data so it is more difficult for the attacker to decrypt the AES encrypted data. A random iv is used so the attacker can’t get the key by entering specific patterns of data and using the results.
> Darn, this is complicated! I can see why there are so many opinions. I read that some folks recommend that the iv be secret and others don’t. When I look at the online discussions on stackoverflow, every comment is responded to with a different suggestion, and I have no idea whether the commenter knows what he/she is talking about. There is also out of date information to contend with. I also remember the horrible bug found in ssh encryption. AES was developed and released November, 2001 and a lot of the discussions are older.
> I think the basic thing we hope for is that the attacker doesn’t have the key, and we need to do everything possible to keep it from determining the key. The attacker can still decrypt with a brute force method that tries all possible keys, but that’s probably rare in most cases, but possible.
> I will modify the php to generate a new iv for the return data and look into the way I set the randomseed using the milliseconds.
> Thanks again,
> William Prothero
> > On Jul 3, 2018, at 9:31 AM, Brian Milby <brian at milby7.com> wrote:
> > I just put the PHP on my server and it was able to handle the randombytes IV without issue.
> > The demo does not generate a new IV for the returned data which it really should in production.
> > From a security perspective, you assume that an attacker has access to the code. From the encrypted message, an attacker could figure out your next IV.
> > > >
More information about the use-livecode