Script Only Stack Behaviors and Nesting

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

Script Only Stack Behaviors and Nesting

Niggemann, Bernd via use-livecode
Hi all.

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. All the substacks have quite a bit of shared behavior, so I created a button with the common code for all the stacks, then set the behavior of each stack to the long ID of that button. So far so good. It works famously.

But I also took the non-common code for each stack, and saved each one as a .livecode script only stack but have yet to set the behavior of the substacks to them. I will eventually do the same for the common code behavior mentioned above.

Now I want to nest the behaviors in such a way so that each stack can avail itself of both behaviors. So the first question is, Which behavior should be the first behavior I set the stack to, or does it matter? The next is, how do I nest behaviors of script only stacks? I know I can set the behavior of one button to the behavior of another whose behavior is that of another etc. But how do I do that with script only stack files?

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
Reply | Threaded
Open this post in threaded view
|

Re: Script Only Stack Behaviors and Nesting

Niggemann, Bernd via use-livecode
Hi all. I nailed this down, and it is indeed as someone surmised, that even though the script editor variable watcher indicated that script local variables had the correct values, it was showing me the BEHAVIOR's script local variable values, and NOT those for the STACK, which were in fact still empty (not initialized).

This is likely going to bite others in the butt in the future, who use the same script local variables in their behaviors as they do in their parent script. Who knows, maybe I'm going to be the only one in the history of LC to try this, but I just thought I'd toss that out there, in case anyone else gets obscure bugs where a statement ought to work and doesn't.

Bob S


> On Jun 27, 2018, at 15:50 , Bob Sneidar via use-livecode <[hidden email]> wrote:
>
> Hi all.
>
> 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. All the substacks have quite a bit of shared behavior, so I created a button with the common code for all the stacks, then set the behavior of each stack to the long ID of that button. So far so good. It works famously.
>
> But I also took the non-common code for each stack, and saved each one as a .livecode script only stack but have yet to set the behavior of the substacks to them. I will eventually do the same for the common code behavior mentioned above.
>
> Now I want to nest the behaviors in such a way so that each stack can avail itself of both behaviors. So the first question is, Which behavior should be the first behavior I set the stack to, or does it matter? The next is, how do I nest behaviors of script only stacks? I know I can set the behavior of one button to the behavior of another whose behavior is that of another etc. But how do I do that with script only stack files?
>
> 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


_______________________________________________
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

Niggemann, Bernd via use-livecode
Whoops! Wrong thread.

Bob S


> On Jul 2, 2018, at 10:05 , Bob Sneidar via use-livecode <[hidden email]> wrote:
>
> Hi all. I nailed this down, and it is indeed as someone surmised, that even though the script editor variable watcher indicated that script local variables had the correct values, it was showing me the BEHAVIOR's script local variable values, and NOT those for the STACK, which were in fact still empty (not initialized).
>
> This is likely going to bite others in the butt in the future, who use the same script local variables in their behaviors as they do in their parent script. Who knows, maybe I'm going to be the only one in the history of LC to try this, but I just thought I'd toss that out there, in case anyone else gets obscure bugs where a statement ought to work and doesn't.
>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Script Only Stack Behaviors and Nesting

Niggemann, Bernd via use-livecode
In reply to this post by Niggemann, Bernd via use-livecode
Okay, so apparently I cannot use script local variables in a behavior. Setting the variables in a handler in a behavior script does not retain the values when that handler exits, like they do in a normal object script. Should they?

The workaround for me is to simply get the custom property of each stack (an array in each stack containing all the values I need) and then reference the array values directly instead of trying to set script local values. The downside to this is I have to get the array in every handler in the behavior script. Not a big deal, but I was trying to be efficient by only having to initialize the values once upon every openStack.

Bob S


> On Jul 2, 2018, at 10:05 , Bob Sneidar via use-livecode <[hidden email]> wrote:
>
> Hi all. I nailed this down, and it is indeed as someone surmised, that even though the script editor variable watcher indicated that script local variables had the correct values, it was showing me the BEHAVIOR's script local variable values, and NOT those for the STACK, which were in fact still empty (not initialized).
>
> This is likely going to bite others in the butt in the future, who use the same script local variables in their behaviors as they do in their parent script. Who knows, maybe I'm going to be the only one in the history of LC to try this, but I just thought I'd toss that out there, in case anyone else gets obscure bugs where a statement ought to work and doesn't.
>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Script Only Stack Behaviors and Nesting

Niggemann, Bernd via use-livecode
They do retain independent values, one set of script locals for each
instance. For example, if you have two buttons that use the same
behavior, button 1 will retain its script local values and button 2 will
retain its own (different) set of values.

On 7/2/18 1:42 PM, Bob Sneidar via use-livecode wrote:

> Okay, so apparently I cannot use script local variables in a behavior. Setting the variables in a handler in a behavior script does not retain the values when that handler exits, like they do in a normal object script. Should they?
>
> The workaround for me is to simply get the custom property of each stack (an array in each stack containing all the values I need) and then reference the array values directly instead of trying to set script local values. The downside to this is I have to get the array in every handler in the behavior script. Not a big deal, but I was trying to be efficient by only having to initialize the values once upon every openStack.
>
> Bob S
>
>
>> On Jul 2, 2018, at 10:05 , Bob Sneidar via use-livecode <[hidden email]> wrote:
>>
>> Hi all. I nailed this down, and it is indeed as someone surmised, that even though the script editor variable watcher indicated that script local variables had the correct values, it was showing me the BEHAVIOR's script local variable values, and NOT those for the STACK, which were in fact still empty (not initialized).
>>
>> This is likely going to bite others in the butt in the future, who use the same script local variables in their behaviors as they do in their parent script. Who knows, maybe I'm going to be the only one in the history of LC to try this, but I just thought I'd toss that out there, in case anyone else gets obscure bugs where a statement ought to work and doesn't.
>>
>> 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
>


--
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: Script Only Stack Behaviors and Nesting

Niggemann, Bernd via use-livecode
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".

If you want the script locals of the behavior object to be shared for
every other object that uses the behavior, you need global variables.
Behaviors act like they are the actual script of an object. Setting a
script local for button 1 wouldn't share that value with button 2.

On 7/2/18 2:17 PM, J. Landman Gay via use-livecode wrote:

> They do retain independent values, one set of script locals for each
> instance. For example, if you have two buttons that use the same
> behavior, button 1 will retain its script local values and button 2 will
> retain its own (different) set of values.
>
> On 7/2/18 1:42 PM, Bob Sneidar via use-livecode wrote:
>> Okay, so apparently I cannot use script local variables in a behavior.
>> Setting the variables in a handler in a behavior script does not
>> retain the values when that handler exits, like they do in a normal
>> object script. Should they?
>>
>> The workaround for me is to simply get the custom property of each
>> stack (an array in each stack containing all the values I need) and
>> then reference the array values directly instead of trying to set
>> script local values. The downside to this is I have to get the array
>> in every handler in the behavior script. Not a big deal, but I was
>> trying to be efficient by only having to initialize the values once
>> upon every openStack.
>>
>> Bob S
>>
>>
>>> On Jul 2, 2018, at 10:05 , Bob Sneidar via use-livecode
>>> <[hidden email]> wrote:
>>>
>>> Hi all. I nailed this down, and it is indeed as someone surmised,
>>> that even though the script editor variable watcher indicated that
>>> script local variables had the correct values, it was showing me the
>>> BEHAVIOR's script local variable values, and NOT those for the STACK,
>>> which were in fact still empty (not initialized).
>>>
>>> This is likely going to bite others in the butt in the future, who
>>> use the same script local variables in their behaviors as they do in
>>> their parent script. Who knows, maybe I'm going to be the only one in
>>> the history of LC to try this, but I just thought I'd toss that out
>>> there, in case anyone else gets obscure bugs where a statement ought
>>> to work and doesn't.
>>>
>>> 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
>>
>
>


--
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: Script Only Stack Behaviors and Nesting

Niggemann, Bernd via use-livecode
In reply to this post by Niggemann, Bernd via use-livecode
Yes, but I am not talking about the child object's script. That works fine. What doesn't work are script locals in the behavior itself.

Bob S


> On Jul 2, 2018, at 12:17 , J. Landman Gay via use-livecode <[hidden email]> wrote:
>
> They do retain independent values, one set of script locals for each instance. For example, if you have two buttons that use the same behavior, button 1 will retain its script local values and button 2 will retain its own (different) set of values.
>
> On 7/2/18 1:42 PM, Bob Sneidar via use-livecode wrote:
>> Okay, so apparently I cannot use script local variables in a behavior. Setting the variables in a handler in a behavior script does not retain the values when that handler exits, like they do in a normal object script. Should they?
>> The workaround for me is to simply get the custom property of each stack (an array in each stack containing all the values I need) and then reference the array values directly instead of trying to set script local values. The downside to this is I have to get the array in every handler in the behavior script. Not a big deal, but I was trying to be efficient by only having to initialize the values once upon every openStack.
>> 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
Reply | Threaded
Open this post in threaded view
|

Re: Script Only Stack Behaviors and Nesting

Niggemann, Bernd via use-livecode
In reply to this post by Niggemann, Bernd via use-livecode
oic. Well getting the stacks custom property and referencing that is working for me. It's curious then if you can use the sLocal of this me, could you also use the sLocal of button x or stack y?? That would be very cool! That would mean you could get and set the script locals of another object.

Bob S


> 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".
>
> If you want the script locals of the behavior object to be shared for every other object that uses the behavior, you need global variables. Behaviors act like they are the actual script of an object. Setting a script local for button 1 wouldn't share that value with button 2.
>
> On 7/2/18 2:17 PM, J. Landman Gay via use-livecode wrote:
>> They do retain independent values, one set of script locals for each instance. For example, if you have two buttons that use the same behavior, button 1 will retain its script local values and button 2 will retain its own (different) set of values.
>> On 7/2/18 1:42 PM, Bob Sneidar via use-livecode wrote:
>>> Okay, so apparently I cannot use script local variables in a behavior. Setting the variables in a handler in a behavior script does not retain the values when that handler exits, like they do in a normal object script. Should they?
>>>
>>> The workaround for me is to simply get the custom property of each stack (an array in each stack containing all the values I need) and then reference the array values directly instead of trying to set script local values. The downside to this is I have to get the array in every handler in the behavior script. Not a big deal, but I was trying to be efficient by only having to initialize the values once upon every openStack.
>>>
>>> Bob S
>>>
>>>
>>>> On Jul 2, 2018, at 10:05 , Bob Sneidar via use-livecode <[hidden email]> wrote:
>>>>
>>>> Hi all. I nailed this down, and it is indeed as someone surmised, that even though the script editor variable watcher indicated that script local variables had the correct values, it was showing me the BEHAVIOR's script local variable values, and NOT those for the STACK, which were in fact still empty (not initialized).
>>>>
>>>> This is likely going to bite others in the butt in the future, who use the same script local variables in their behaviors as they do in their parent script. Who knows, maybe I'm going to be the only one in the history of LC to try this, but I just thought I'd toss that out there, in case anyone else gets obscure bugs where a statement ought to work and doesn't.
>>>>
>>>> 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
>>>
>
>
> --
> 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


_______________________________________________
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

Niggemann, Bernd via use-livecode


> On 3 Jul 2018, at 9:16 am, Bob Sneidar via use-livecode <[hidden email]> wrote:
>
> That would be very cool! That would mean you could get and set the script locals of another object.

No it really wouldn’t. It would make them worse than globals… eek.

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

Niggemann, Bernd via use-livecode
In reply to this post by Niggemann, Bernd via use-livecode
On 07/02/2018 04:16 PM, Bob Sneidar via use-livecode wrote:
> oic. Well getting the stacks custom property and referencing that is working for me. It's curious then if you can use the sLocal of this me, could you also use the sLocal of button x or stack y?? That would be very cool! That would mean you could get and set the script locals of another object.

Ick

--
  Mark Wieder
  [hidden email]

_______________________________________________
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

Niggemann, Bernd via use-livecode
Curious if this would be useful.  It occurred to me that one could use
getters and setters in the behavior if one wanted a "central" location for
data for objects using that behavior.

Not as easy as just using an actual property set, but might end up being
faster?

To test I put the following into a button to use as a behavior..
local sOhBehaveLocalA

on mouseup
   -- sets a value in the local of the behavior object
   -- based on the long id of the object using the behavior
   set the setter[(the long id of me)] of (the behavior of me) to
random(4000)

   -- grabs the whole array from the behavior object
   put the getter of (the behavior of me) into tArray

   -- shows the value assigned to the array entry for the
   -- object using the behavior keyed by long id
   put tArray[the long id of me] & cr

   --cycles through all keys in the array returned by getter
   -- and shows values for all objects tracked by the getter/setter in the
behavior object
   put the keys of tArray into tKeys
   repeat for each line tLine in tKeys
      put tLine & ":" & tArray[tLine] & cr after msg
   end repeat

end mouseup

Then assigned the behavior to several buttons and it works well enough.
LIke I said, i'm not sure there is actually a point to this since there are
so many other ways the same objective could be reached, but thought I'd
toss it out there.  (sorry for the ugly code and silly example) I think I
read somewhere that setting a variable is faster than setting a property,
but.. /shrug

On Mon, Jul 2, 2018 at 6:27 PM Mark Wieder via use-livecode <
[hidden email]> wrote:

> On 07/02/2018 04:16 PM, Bob Sneidar via use-livecode wrote:
> > oic. Well getting the stacks custom property and referencing that is
> working for me. It's curious then if you can use the sLocal of this me,
> could you also use the sLocal of button x or stack y?? That would be very
> cool! That would mean you could get and set the script locals of another
> object.
>
> Ick
>
> --
>   Mark Wieder
>   [hidden email]
>
> _______________________________________________
> 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
|

AES-256 Encryption Best Practices

Niggemann, Bernd via use-livecode
In reply to this post by Niggemann, Bernd via use-livecode
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
Reply | Threaded
Open this post in threaded view
|

Re: AES-256 Encryption Best Practices

Niggemann, Bernd via use-livecode
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

Niggemann, Bernd via use-livecode
In reply to this post by Niggemann, Bernd via use-livecode
i will be looking at this thank you William.

On Mon, Jul 2, 2018 at 11: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

Niggemann, Bernd via use-livecode
In reply to this post by Niggemann, Bernd via use-livecode
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

Niggemann, Bernd via use-livecode
I found a reference to the HMAC encryption. I’m thinking that the use of a random iv guards against the kind of attack it was designed to avoid. I’m thinking AES is more modern, making HMAC less useful.

I may be wrong, but it’s worth looking into, I think.

Best,
Bill

William Prothero
http://earthlearningsolutions.org

> On Jul 2, 2018, at 10:56 PM, William Prothero via use-livecode <[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: Script Only Stack Behaviors and Nesting

Niggemann, Bernd via use-livecode
In reply to this post by Niggemann, Bernd via use-livecode
Not if you had to reference them the way Jacque says you can reference a behavior's script locals ie. the sLocal of THIS ME. I have a lot of objects (my SearchBar is a good example) where I store information in scrip locals (the old dgData and hilited record of a datagrid before performing a hot search so I can revert if canceled for instance) and it would be convenient to be able to reference them from another object sometimes. Of course I can use properties.

Bob S


> On Jul 2, 2018, at 17:02 , Monte Goulding via use-livecode <[hidden email]> wrote:
>
>> On 3 Jul 2018, at 9:16 am, Bob Sneidar via use-livecode <[hidden email]> wrote:
>>
>> That would be very cool! That would mean you could get and set the script locals of another object.
>
> No it really wouldn’t. It would make them worse than globals… eek.
>
> 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

Niggemann, Bernd via use-livecode
Can’t we already do that with a custom getprop/setprop?
On Jul 3, 2018, 10:53 AM -0400, Bob Sneidar via use-livecode <[hidden email]>, wrote:

> Not if you had to reference them the way Jacque says you can reference a behavior's script locals ie. the sLocal of THIS ME. I have a lot of objects (my SearchBar is a good example) where I store information in scrip locals (the old dgData and hilited record of a datagrid before performing a hot search so I can revert if canceled for instance) and it would be convenient to be able to reference them from another object sometimes. Of course I can use properties.
>
> Bob S
>
>
> > On Jul 2, 2018, at 17:02 , Monte Goulding via use-livecode <[hidden email]> wrote:
> >
> > > On 3 Jul 2018, at 9:16 am, Bob Sneidar via use-livecode <[hidden email]> wrote:
> > >
> > > That would be very cool! That would mean you could get and set the script locals of another object.
> >
> > No it really wouldn’t. It would make them worse than globals… eek.
> >
> > 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
_______________________________________________
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

Niggemann, Bernd via use-livecode
In reply to this post by Niggemann, Bernd via use-livecode
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

Niggemann, Bernd via use-livecode
In reply to this post by Niggemann, Bernd via use-livecode
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


> On Jul 3, 2018, at 12:57 AM, Brian Milby via use-livecode <[hidden email]> wrote:
>
> 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.

_______________________________________________
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