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