AES-256 Encryption Best Practices

[Tom Glod]

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 at 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 <waprothero at 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 <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.
> > > > >
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>