Script Only Stack Behaviors and Nesting

classic Classic list List threaded Threaded
35 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: AES-256 Encryption Best Practices

Pi Digital via use-livecode
Brian,
Good suggestion.

Easy-peasy. Php has a nice function to generate random iv vectors, so I’ll put it in.  Thanks for the suggestion!

Best,
Bill

William Prothero
http://earthlearningsolutions.org

> On Jul 3, 2018, at 9:31 AM, Brian Milby <[hidden email]> 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.
>> On Jul 3, 2018, 1:56 AM -0400, William Prothero <[hidden email]>, wrote:
>> Brian, thanks for the feedback.
>>
>> I started by using random bytes, which was ok, but the php base64encode would only encode characters. So, I couldn’t get the return message to decode in LC correctly. I forget, it could have been the LC decode step, but the upshot was that I decided to go with valid ascii characters for iv because of this.
>>
>> I don’t understand the problem with using the milliseconds to generate the random seed, though. The least significant digits of the milliseconds only depends on the random time the user first initiates the query. I assumed the milliseconds counts up to some maximum integer number, then repeats. Hmm, maybe I need to investigate how the counting goes. I had assumed it was just an integer number that counted until it overflowed, then started again from zero. I can investigate this.
>>
>> What would the H(MAC) consist of? I haven’t heard of it.
>>
>> Best,
>> Bill
>>
>> William Prothero
>> http://earthlearningsolutions.org
>>
>> On Jul 2, 2018, at 9:57 PM, Brian Milby <[hidden email]> wrote:
>>
>>> I would suggest using "randombytes" instead of "random" on desktop/server (according to dictionary is isn't available in mobile, but I have not actually verified).  That uses the openssl library to generate random numbers.  The problem with using an IV based on a pseudorandom number generator seeded from something derived from the time means that it is potentially predictable.
>>>
>>> I was playing around with a function to generate an IV that is guaranteed to not repeat.  The middle 4 bytes are the seconds, so it reduces the randomness by 4 bytes.  I'm not sure how much of an issue that would be.  It does avoid the birthday problem (which should not really be an issue with a good random number generator I would guess).  Maintaining your own counter would be another option.  Ensuring uniqueness and unpredictability is the goal.
>>>
>>> One other thing that I was reading is that we should also include a (H)MAC after the encryption to ensure that the payload is not tampered with.  We would then only decrypt if the message had not been changed (and the IV would be included in the MAC calculation).
>>>
>>> Below is the code that I was experimenting with:
>>>
>>> function generateIV pLength
>>>    local tSeconds, tBytes
>>>    
>>>    put randomBytes(6) into tBytes
>>>    put the seconds into tSeconds
>>>    repeat until tSeconds < 256
>>>       put numToByte(tSeconds mod 256) after tBytes
>>>       put tSeconds div 256 into tSeconds
>>>    end repeat
>>>    put numToByte(tSeconds) after tBytes
>>>    
>>>    if pLength is empty then put 16 into pLength
>>>    subtract length(tBytes) from pLength
>>>    if pLength < 0 then
>>>       delete byte 1 to (- pLength) of tBytes
>>>    else
>>>       put randomBytes(pLength) after tBytes
>>>    end if
>>>    return tBytes
>>> end generateIV
>>>
>>>> On Mon, Jul 2, 2018 at 10:37 PM, William Prothero via use-livecode <[hidden email]> wrote:
>>>> Folks:
>>>> I’ve been working on a sample stack to demonstrate encryption, best practices (as far as I can determine).
>>>> The online lessons are not adequate for a robust solution to this vital security issue. I’ve posted a demo stack at: http://earthlearningsolutions.org/google-static-maps-demo/ <http://earthlearningsolutions.org/google-static-maps-demo/>  This stack has benefited from feedback and ideas from folks on this list. Feedback is welcome.
>>>>
>>>> This stack generates a random iv vector and uses AES-256 encryption to encode an array containing commands for interaction with a mySQL server. The server side php script that decodes the data and encodes the returned response is included.
>>>>
>>>> On thing I am still unsure about is the best way to generate a random string of characters that I use for the random IV (initialization vector) that is used for the encryption. I’ve included some code below, which is used to encrypt and decrypt the data sent and returned from the server. The encode and decode scripts are put into the launcher, or stack that is created when a standalone or mobile version is built.
>>>>
>>>> Here are the handlers. The encryption key will be more secure if it is obfuscated by putting it in as a property of a control or hidden in some way. I am wondering if the generation of the random seed is optimum.
>>>>
>>>> Feedback welcome.
>>>>
>>>> local theRandomSeed
>>>>
>>>> function randomChrs n
>>>>    if theRandomSeed = "" then
>>>>       setRandomSeed
>>>>    end if
>>>>    put "" into tChars
>>>>    repeat with i=1 to n
>>>>       put random(256) into nChar
>>>>       put numToNativeChar(nChar) after tChars
>>>>    end repeat
>>>>    return tChars
>>>> end randomChrs
>>>>
>>>> on setRandomSeed
>>>>    put (the milliseconds) into tMS
>>>>    put trunc(tMs/10000000) into tDiv
>>>>    put tMS mod tDiv into theRandomSeed
>>>>    set the randomseed to theRandomSeed
>>>> end setRandomSeed
>>>>
>>>> function theRandomIV
>>>>    if theRandomSeed = "" then
>>>>       setRandomSeed
>>>>    end if
>>>>    put randomChrs(16) into tIVBytes
>>>>    return tIVBytes
>>>> end theRandomIV
>>>>
>>>> --This handler encodes the data. First it generates a random
>>>> --initialization vector (iv), then encrypts the data and puts
>>>> --adds iv to the encoded data.
>>>> --tArray is an array that controls the action of the php script.
>>>> function theEncoded tArray
>>>>    put  theRandomIV() into tIV
>>>>    put base64Encode(tIV) into tB64IV
>>>>    put ArrayToJSON(tArray,"string”,”") into tJson
>>>>    put "AFBDDFCFBDBBDDCCFFACGHDFFFFEEDCC" into tEncryptionKey
>>>>    put "AES-256-CTR" into tCipher
>>>>    encrypt tJson using tCipher with key tEncryptionKey and iV tIV
>>>>    put base64encode(it) into tDataToSend
>>>>    --comment out next statement if iv not included in data
>>>>    put tB64IV&tDataToSend into tDataToSend
>>>>    return tDataToSend
>>>> end theEncoded
>>>>
>>>> --This decodes the data that is returned by the php on the
>>>> --remote server.
>>>> --The iv is expected as the first 24 bytes of the returned data.
>>>> function theDecoded tData
>>>>    put byte 1 to 24 of tData into tIVB64
>>>>    put base64decode(tIVB64) into tIV
>>>>    put the number of bytes in tData into n
>>>>    put byte 25 to n of tData into tRetB64Data
>>>>    put base64decode(tRetB64Data) into tRetData
>>>>    put "AES-256-CTR" into tCipher
>>>>    put "AFBDDFCFBDBBDDCCFFACGHDFFFFEEDCC" into tEncryptionKey
>>>>    decrypt tRetData using tCipher with key tEncryptionKey and iV tIV
>>>>    put it into tReturn
>>>>    return tReturn
>>>> end theDecoded
>>>> -- End of handlers that should be in the main stack
>>>>
>>>> _______________________________________________
>>>> use-livecode mailing list
>>>> [hidden email]
>>>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: AES-256 Encryption Best Practices

Pi Digital via use-livecode
any chance this could go on github?

On Tue, Jul 3, 2018 at 2:02 PM, William Prothero via use-livecode <
[hidden email]> wrote:

> Brian,
> Good suggestion.
>
> Easy-peasy. Php has a nice function to generate random iv vectors, so I’ll
> put it in.  Thanks for the suggestion!
>
> Best,
> Bill
>
> William Prothero
> http://earthlearningsolutions.org
>
> > On Jul 3, 2018, at 9:31 AM, Brian Milby <[hidden email]> 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.
> >> On Jul 3, 2018, 1:56 AM -0400, William Prothero <[hidden email]>,
> wrote:
> >> Brian, thanks for the feedback.
> >>
> >> I started by using random bytes, which was ok, but the php base64encode
> would only encode characters. So, I couldn’t get the return message to
> decode in LC correctly. I forget, it could have been the LC decode step,
> but the upshot was that I decided to go with valid ascii characters for iv
> because of this.
> >>
> >> I don’t understand the problem with using the milliseconds to generate
> the random seed, though. The least significant digits of the milliseconds
> only depends on the random time the user first initiates the query. I
> assumed the milliseconds counts up to some maximum integer number, then
> repeats. Hmm, maybe I need to investigate how the counting goes. I had
> assumed it was just an integer number that counted until it overflowed,
> then started again from zero. I can investigate this.
> >>
> >> What would the H(MAC) consist of? I haven’t heard of it.
> >>
> >> Best,
> >> Bill
> >>
> >> William Prothero
> >> http://earthlearningsolutions.org
> >>
> >> On Jul 2, 2018, at 9:57 PM, Brian Milby <[hidden email]> wrote:
> >>
> >>> I would suggest using "randombytes" instead of "random" on
> desktop/server (according to dictionary is isn't available in mobile, but I
> have not actually verified).  That uses the openssl library to generate
> random numbers.  The problem with using an IV based on a pseudorandom
> number generator seeded from something derived from the time means that it
> is potentially predictable.
> >>>
> >>> I was playing around with a function to generate an IV that is
> guaranteed to not repeat.  The middle 4 bytes are the seconds, so it
> reduces the randomness by 4 bytes.  I'm not sure how much of an issue that
> would be.  It does avoid the birthday problem (which should not really be
> an issue with a good random number generator I would guess).  Maintaining
> your own counter would be another option.  Ensuring uniqueness and
> unpredictability is the goal.
> >>>
> >>> One other thing that I was reading is that we should also include a
> (H)MAC after the encryption to ensure that the payload is not tampered
> with.  We would then only decrypt if the message had not been changed (and
> the IV would be included in the MAC calculation).
> >>>
> >>> Below is the code that I was experimenting with:
> >>>
> >>> function generateIV pLength
> >>>    local tSeconds, tBytes
> >>>
> >>>    put randomBytes(6) into tBytes
> >>>    put the seconds into tSeconds
> >>>    repeat until tSeconds < 256
> >>>       put numToByte(tSeconds mod 256) after tBytes
> >>>       put tSeconds div 256 into tSeconds
> >>>    end repeat
> >>>    put numToByte(tSeconds) after tBytes
> >>>
> >>>    if pLength is empty then put 16 into pLength
> >>>    subtract length(tBytes) from pLength
> >>>    if pLength < 0 then
> >>>       delete byte 1 to (- pLength) of tBytes
> >>>    else
> >>>       put randomBytes(pLength) after tBytes
> >>>    end if
> >>>    return tBytes
> >>> end generateIV
> >>>
> >>>> On Mon, Jul 2, 2018 at 10:37 PM, William Prothero via use-livecode <
> [hidden email]> wrote:
> >>>> Folks:
> >>>> I’ve been working on a sample stack to demonstrate encryption, best
> practices (as far as I can determine).
> >>>> The online lessons are not adequate for a robust solution to this
> vital security issue. I’ve posted a demo stack at:
> http://earthlearningsolutions.org/google-static-maps-demo/ <http://
> earthlearningsolutions.org/google-static-maps-demo/>  This stack has
> benefited from feedback and ideas from folks on this list. Feedback is
> welcome.
> >>>>
> >>>> This stack generates a random iv vector and uses AES-256 encryption
> to encode an array containing commands for interaction with a mySQL server.
> The server side php script that decodes the data and encodes the returned
> response is included.
> >>>>
> >>>> On thing I am still unsure about is the best way to generate a random
> string of characters that I use for the random IV (initialization vector)
> that is used for the encryption. I’ve included some code below, which is
> used to encrypt and decrypt the data sent and returned from the server. The
> encode and decode scripts are put into the launcher, or stack that is
> created when a standalone or mobile version is built.
> >>>>
> >>>> Here are the handlers. The encryption key will be more secure if it
> is obfuscated by putting it in as a property of a control or hidden in some
> way. I am wondering if the generation of the random seed is optimum.
> >>>>
> >>>> Feedback welcome.
> >>>>
> >>>> local theRandomSeed
> >>>>
> >>>> function randomChrs n
> >>>>    if theRandomSeed = "" then
> >>>>       setRandomSeed
> >>>>    end if
> >>>>    put "" into tChars
> >>>>    repeat with i=1 to n
> >>>>       put random(256) into nChar
> >>>>       put numToNativeChar(nChar) after tChars
> >>>>    end repeat
> >>>>    return tChars
> >>>> end randomChrs
> >>>>
> >>>> on setRandomSeed
> >>>>    put (the milliseconds) into tMS
> >>>>    put trunc(tMs/10000000) into tDiv
> >>>>    put tMS mod tDiv into theRandomSeed
> >>>>    set the randomseed to theRandomSeed
> >>>> end setRandomSeed
> >>>>
> >>>> function theRandomIV
> >>>>    if theRandomSeed = "" then
> >>>>       setRandomSeed
> >>>>    end if
> >>>>    put randomChrs(16) into tIVBytes
> >>>>    return tIVBytes
> >>>> end theRandomIV
> >>>>
> >>>> --This handler encodes the data. First it generates a random
> >>>> --initialization vector (iv), then encrypts the data and puts
> >>>> --adds iv to the encoded data.
> >>>> --tArray is an array that controls the action of the php script.
> >>>> function theEncoded tArray
> >>>>    put  theRandomIV() into tIV
> >>>>    put base64Encode(tIV) into tB64IV
> >>>>    put ArrayToJSON(tArray,"string”,”") into tJson
> >>>>    put "AFBDDFCFBDBBDDCCFFACGHDFFFFEEDCC" into tEncryptionKey
> >>>>    put "AES-256-CTR" into tCipher
> >>>>    encrypt tJson using tCipher with key tEncryptionKey and iV tIV
> >>>>    put base64encode(it) into tDataToSend
> >>>>    --comment out next statement if iv not included in data
> >>>>    put tB64IV&tDataToSend into tDataToSend
> >>>>    return tDataToSend
> >>>> end theEncoded
> >>>>
> >>>> --This decodes the data that is returned by the php on the
> >>>> --remote server.
> >>>> --The iv is expected as the first 24 bytes of the returned data.
> >>>> function theDecoded tData
> >>>>    put byte 1 to 24 of tData into tIVB64
> >>>>    put base64decode(tIVB64) into tIV
> >>>>    put the number of bytes in tData into n
> >>>>    put byte 25 to n of tData into tRetB64Data
> >>>>    put base64decode(tRetB64Data) into tRetData
> >>>>    put "AES-256-CTR" into tCipher
> >>>>    put "AFBDDFCFBDBBDDCCFFACGHDFFFFEEDCC" into tEncryptionKey
> >>>>    decrypt tRetData using tCipher with key tEncryptionKey and iV tIV
> >>>>    put it into tReturn
> >>>>    return tReturn
> >>>> end theDecoded
> >>>> -- End of handlers that should be in the main stack
> >>>>
> >>>> _______________________________________________
> >>>> use-livecode mailing list
> >>>> [hidden email]
> >>>> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> >>>> http://lists.runrev.com/mailman/listinfo/use-livecode
> >>>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: AES-256 Encryption Best Practices

Pi Digital via use-livecode
I’ll volunteer to add it to my community repo if desired.

Thanks,
Brian
On Jul 3, 2018, 2:17 PM -0400, Tom Glod via use-livecode <[hidden email]>, wrote:
> any chance this could go on github?
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: AES-256 Encryption Best Practices

Pi Digital via use-livecode
In reply to this post by Pi Digital via use-livecode
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 <[hidden email]> 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: AES-256 Encryption Best Practices

Pi Digital via use-livecode
In reply to this post by Pi Digital via use-livecode
I haven’t spent the time to get familiar with github, but after I modify the php to use a random iv for the return data, I’m happy with any way to disseminate it for others.

I’ll post a new link, when I’m done. Probably later today. I will also remove the link to my server. Then, I invite you to post it to github.

Best,
Bill

William Prothero
http://earthlearningsolutions.org

> On Jul 3, 2018, at 11:20 AM, Brian Milby via use-livecode <[hidden email]> wrote:
>
> I’ll volunteer to add it to my community repo if desired.
>
> Thanks,
> Brian
>> On Jul 3, 2018, 2:17 PM -0400, Tom Glod via use-livecode <[hidden email]>, wrote:
>> any chance this could go on github?
>>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: AES-256 Encryption Best Practices

Pi Digital via use-livecode
In reply to this post by Pi Digital via use-livecode
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 <[hidden email]>, 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 <[hidden email]> 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: AES-256 Encryption Best Practices

Pi Digital via use-livecode
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 <
[hidden email]> 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 <[hidden email]>,
> 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 <[hidden email]> 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
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: AES-256 Encryption Best Practices

Pi Digital via use-livecode
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 <
[hidden email]> 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 <
> [hidden email]> 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 <[hidden email]>,
> > 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 <[hidden email]> 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
> > [hidden email]
> > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> >
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: AES-256 Encryption Best Practices

Pi Digital via use-livecode
Thanks Brian. Thanks everyone. This is great a big time saver for me.

On Tue, Jul 3, 2018 at 4:00 PM, Brian Milby via use-livecode <
[hidden email]> wrote:

> 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 <
> [hidden email]> 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 <
> > [hidden email]> 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 <[hidden email]
> >,
> > > 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 <[hidden email]> 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
> > > [hidden email]
> > > Please visit this url to subscribe, unsubscribe and manage your
> > > subscription preferences:
> > > http://lists.runrev.com/mailman/listinfo/use-livecode
> > >
> > _______________________________________________
> > use-livecode mailing list
> > [hidden email]
> > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> >
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Script Only Stack Behaviors and Nesting

Pi Digital via use-livecode
In reply to this post by Pi Digital via use-livecode


> On 4 Jul 2018, at 12:52 am, Bob Sneidar via use-livecode <[hidden email]> wrote:
>
> Jacque says you can reference a behavior's script locals ie. the sLocal of THIS ME

Well you can’t actually do that so maybe Jacque is being misquoted?

Cheers

Monte
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Script Only Stack Behaviors and Nesting

Pi Digital via use-livecode
In reply to this post by Pi Digital via use-livecode
Just a side note, that for "parent" behaviors which have been "nested" as the behavior of multiple "children" ... we are "blinded sided" to this, as the designation is in the first comment of the script with doesn't appear in the IDE, SE

The only other place to see it is in the PB in 9+, that is obscure and is shows a "dot" nothing more.

If you are using text editor, no problem. But I have taken a convention for every child behavior, to make the first comment on the script declare:

-> ## this script has a parent: behavior_ListenUI  

So I can see it in IDE script editor

Coming to the "script local" problem. Jacque was misquoted. She  said scripts that are not attached to an object (there is no "this me"....) globals are required.

One solution is to use a single global as an array..

Global sConfigA # with keys needed

This doesn’t solve the problem of "who set that value" when tracing; but I found it convenient to have a single global to check out at any point this I want to use it. And the keys are like "custom properties" of global array.

 Still, if could lead to "untraceable" code if I  used that one array for too much.

Would be nice to solve it somehow. I found myself using  a "setter" command  from  parent script creating a child local script local.  And then a function to called that back...into parent.  Then a few days, later, thinking

"I need that local value in this other child..... geez - this backwards! Parent has to check "down the message path"?....The parent script wants to have everything!  UhOH! I'm on the edge of snake pit here. Maybe I should not go down that road?"

So I put plans for all the cool stuff I could do in "parent script" (of other children which actually have object) aside for now.  Mostly use for UI stuff, like keep a mouseup handler, and if wanted it called from the child, just pass it in the child

On mouseUp
  pass mouseUp
# goes to parent behavior_ListenUI
# because it has to have an object in the UI
# it will *not* be passed in the message path...unless you do this.
End mouseup

BR

"I too am still trying to figure it out"

 Bob Sneidar wrote:

    I'm getting heavily into behaviors and script only stacks now (in preparation for Levure Framework) because my project has become complex enough to make it almost inevitable. I have perhaps 20 or so substacks in a mainstack.

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: AES-256 Encryption Best Practices

Pi Digital via use-livecode
In reply to this post by Pi Digital via use-livecode
 The problem is that with a known IV and the code, the next IV can be
predicted if using the random function. If the generator was reseeded every
time an IV was generated, that would remove the advance prediction issue. I
didn't mean that the first IV could be guessed.  Exploitation would be
difficult and I believe even requires the attacker to be able to inject
plain text to be encrypted.

On Jul 3, 2018, 1:24 PM -0400, Rick Harrison via use-livecode <
[hidden email]>, wrote:

Hi Brian,

I think it would be pretty hard to do based on the time.
One would have to do the calculation in advance and
hope that the program caught the server at exactly
the correct millisecond. As you also pointed out the
hacker would also have to have access to the code.

If you generate your own random seed with a counter
it should not count by 1’s. The step count ideally should
be random as well.

Good discussion!

Thanks,

Rick
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Script Only Stack Behaviors and Nesting

Pi Digital via use-livecode
In reply to this post by Pi Digital via use-livecode
On 7/3/18 5:48 PM, Monte Goulding via use-livecode wrote:
>
>
>> On 4 Jul 2018, at 12:52 am, Bob Sneidar via use-livecode <[hidden email]> wrote:
>>
>> Jacque says you can reference a behavior's script locals ie. the sLocal of THIS ME
>
> Well you can’t actually do that so maybe Jacque is being misquoted?

I think I misquoted myself. "Me" is an object, and an object can't have
a script local, so you were being generous in not saying outright I was
wrong. My brain did a little twist, and the example I gave used property
syntax, which a "me" can have.

--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: AES-256 Encryption Best Practices

Pi Digital via use-livecode
In reply to this post by Pi Digital via use-livecode
Brian:
Ahhh, ok, I get it. It’s easy to re-seed every time it’s called, using the milliseconds. That assumes that the user of the program initiates the action at a random time.

I’ll change the code so it re-seeds every time.

Best,
Bill

> On Jul 3, 2018, at 7:02 PM, Brian Milby via use-livecode <[hidden email]> wrote:
>
> The problem is that with a known IV and the code, the next IV can be
> predicted if using the random function. If the generator was reseeded every
> time an IV was generated, that would remove the advance prediction issue. I
> didn't mean that the first IV could be guessed.  Exploitation would be
> difficult and I believe even requires the attacker to be able to inject
> plain text to be encrypted.
>
> On Jul 3, 2018, 1:24 PM -0400, Rick Harrison via use-livecode <
> [hidden email]>, wrote:
>
> Hi Brian,
>
> I think it would be pretty hard to do based on the time.
> One would have to do the calculation in advance and
> hope that the program caught the server at exactly
> the correct millisecond. As you also pointed out the
> hacker would also have to have access to the code.
>
> If you generate your own random seed with a counter
> it should not count by 1’s. The step count ideally should
> be random as well.
>
> Good discussion!
>
> Thanks,
>
> Rick
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Script Only Stack Behaviors and Nesting

Pi Digital via use-livecode
In reply to this post by Pi Digital via use-livecode
Not misquoted, but misunderstood.

> On Jul 2, 2018, at 12:33 , J. Landman Gay via use-livecode <[hidden email]> wrote:
>
> Actually, do you mean you want to set the script locals for the behavior object itself? You can do that, but it will only apply to that particular control. The magic word is "this me" : "set the sLocal of this me to xxx".

Bob S


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
12