thank you for this .....I'm willing to post it too....was just thinking if the goal is to nail down a best practice ..... then there may be a few suggestions from a few people and maybe a few revisits, so keeping up with the mailing list or your personal site is not ideal for something that is being worked on in community. unfortunately i cannot add anything to the code except test it myself when the time comes. great job everyone this can be very helpful to a lot of livecode developers.
On Tue, Jul 3, 2018 at 3:07 PM, Brian Milby via use-livecode < use-livecode@lists.runrev.com> wrote: > 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. > > Thanks, > Brian > On Jul 3, 2018, 2:39 PM -0400, William Prothero <waproth...@gmail.com>, > wrote: > > Brian, > > 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, > > Bill > > > > William Prothero > > http://earthlearningsolutions.org > > > > > On Jul 3, 2018, at 9:31 AM, Brian Milby <br...@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. > > > > > > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
