AES-256 Encryption Best Practices

Brian Milby brian at milby7.com
Tue Jul 3 22:00:44 CEST 2018


Initial code is posted here:
https://github.com/bwmilby/lc-community/tree/master/AES_Demo

I'll update it later today with an updated version of the PHP that uses a
different IV for the return data.

The good thing about how I've posted it is that PRs can be submitted and
integrated with edits to just the code (and I'll merge them into the stack
itself).  If you do submit a PR, do not include the stack itself.  Hold off
until v2 is posted though (I'm integrating an updated stack).

After I post v2, I'm going to update the README with links to these threads
for reference.

On Tue, Jul 3, 2018 at 2:27 PM, Tom Glod via use-livecode <
use-livecode at lists.runrev.com> wrote:

> 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
> >
> _______________________________________________
> 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
>


More information about the use-livecode mailing list