Thanks, Brian, Actually, I think I know how to do it now, with iv sent along with the data. I’ll post what I come up with.
Thanks so much for your input. Bill William Prothero http://earthlearningsolutions.org > On Jun 28, 2018, at 7:38 PM, Brian Milby <br...@milby7.com> wrote: > > I can write an LC example, but not sure how quickly I could do the equivalent > in PHP. Some of the Mark Smith code can be used for inspiration. I’ll put > something on GitHub and post a link here. > > If the server doesn’t need access to the contents, then storing the data > encrypted does reduce the location of the key by one. Depending on how > paranoid you want to get, you can add all kinds of layers. > > Here is another good answer on secrecy of the IV: > https://crypto.stackexchange.com/questions/8592/iv-security-clarification > > Not sure how much would be gained using a different key for each direction - > both keys would be needed in both places anyway. The random IV ensures each > cipher text is unique even if the plain text is the same. > > Transmitting the IV is not a security risk assuming that they are random > (which they should be). >> On Jun 28, 2018, 7:40 PM -0400, proth...@earthlearningsolutions.org , wrote: >> Brianand Mark >> Tnx so much for your patience. >> >> What I get so far, where I am sending data to a php script that stores the >> data in a mysql db, is that the key and iv vector cannot be sent along with >> the encrypted data, because those values make it easier to hack the >> encrypted text. As Mark suggests, I can store the iv and key in the >> .htaccess file. >> >> Reading stackoverflow and other various googled links, I get even more >> confused by the postings, then the corrective comments, then corrections of >> the corrections. So, is there a “best practices” source that I can trust >> fully? If not, I’m going to go with the above. >> >> Another suggestion was to use a different key and iv for the return message. >> Also one source said the db should store the encrypted data, not the >> decrypted data. It never ends. For my use I’m ok with what I already know, >> but it would really be nice to have the best known useage. >> >> In general, i’m paranoid about security. It oughta be easier. >> >> Best, >> Bill >> >> William Prothero >> http://ed.earthednet.org >> >>> On Jun 28, 2018, at 4:02 PM, Brian Milby <br...@milby7.com> wrote: >>> >>> See the second example on the Wikipedia page in the properties section. It >>> talks about how a predictable IV can be an issue. >>>> On Jun 28, 2018, 6:43 PM -0400, proth...@earthlearningsolutions.org >>>> <proth...@earthlearningsolutions.org>, wrote: >>>> Brian, >>>> If the iv is appended to the encrypted data, the the hacker will have it. >>>> >>>> Your message says “If the first encrypted block for the same data is >>>> always the same, the attacker can use that to test guesses if they can >>>> control what is being encrypted. Same issue if they can predict the IV. “ >>>> >>>> Now I’m a bit confused. Plse clarify?? >>>> >>>> Best, >>>> Bill >>>> >>>> William Prothero >>>> http://earthlearningsolutions.org >>>> >>>>> On Jun 28, 2018, at 1:49 PM, Brian Milby <br...@milby7.com> wrote: >>>>> >>>>> Random IV means that an attacker can not generate a dictionary in >>>>> advance. Knowing it at the same time is not an issue since they cypher is >>>>> not cracked. The other reason is that the IV seeds the AES encryption so >>>>> that the first block does not give anything away. If the first encrypted >>>>> block for the same data is always the same, the attacker can use that to >>>>> test guesses if they can control what is being encrypted. Same issue if >>>>> they can predict the IV. See the Wikipedia entry I linked to for a better >>>>> discussion. >>>>> >>>>> IV is fixed at the block size of the cipher. So for AES it is 16 bytes. >>>>>> On Jun 28, 2018, 4:33 PM -0400, prothero--- via use-livecode , wrote: >>>>>> Mark, >>>>>> Pardon me for being dense. But if you send an iv with the data, can’t a >>>>>> hacker obtain and use that iv to support hacking the encrypted data? >>>>>> >>>>>> What I understand, possibly erroneous, is that a Dictionary attack >>>>>> involves trying all possible combinations of a key. A 32 char key would >>>>>> have 2**(32*8) combinations. The iv vector increases the possible >>>>>> combinations to [2**(32*8)]*[2**(16*8)] and makes dictionary attacks >>>>>> much less practical.. Now I’m wondering whether I’m understanding what >>>>>> the iv does. If the iv for data with an unknown key, is known, can’t >>>>>> that iv be used to reduce the number of possible combinations of keys >>>>>> back to the 2**(16*32) value, making the use of an iv irrelevant? >>>>>> >>>>>> I am going to google this to see if I can get more info, but please >>>>>> chime in if I am on the wrong track. >>>>>> >>>>>> Best, >>>>>> Bill >>>>>> >>>>>> Bill >>>>>> >>>>>> William Prothero >>>>>> http://earthlearningsolutions.org >>>>>> >>>>>>> On Jun 28, 2018, at 12:30 PM, Mark Wieder via use-livecode >>>>>>> <use-livecode@lists.runrev.com> wrote: >>>>>>> >>>>>>>> On 06/28/2018 09:17 AM, William Prothero via use-livecode wrote: >>>>>>>> >>>>>>>> I understand Mark’s comment about putting the key and IV vector in the >>>>>>>> .htaccess file. I will do this as soon as I figure out if I’ve >>>>>>>> destroyed my server by deleting all files in the /etc/httpd directory >>>>>>>> by mistake (I was trying to set an environment variable in that >>>>>>>> directory and ….. arg…l). However, if IV is a random vector, I don’t >>>>>>>> understand how the php code that accesses the mySQL db would decode >>>>>>>> the commands and data. The setup would be different for password >>>>>>>> verification because it doesn’t need to be decoded to be verified. >>>>>>>> However, for access to a mySQL server, it needs to be decoded on the >>>>>>>> server. My understanding was that the function of the IV was to >>>>>>>> increase the number of possible keys to make a dictionary attack less >>>>>>>> feasible. Also, my php docs say the IV should be 16 bits. I haven’t >>>>>>>> tried more, but I do get an error message complaining about IV not >>>>>>>> being 16 bits. >>>>>>> >>>>>>> There's no requirement for the initialization vector to be private, >>>>>>> just that it is unique among all messages using the same encryption >>>>>>> key. It can be posted to the server along with the encrypted data. Thus >>>>>>> you can use a new randomized iv for each post, and the php code on the >>>>>>> server would take the posted iv and use it with the already-known >>>>>>> encryption key to decrypt the data. >>>>>>> >>>>>>> Ignore my comment about 16 bits. You're supplying an iv of 16 *bytes*, >>>>>>> which is 128 bytes. That's standard for normal use. If you want to get >>>>>>> serious about it, you could double the length. >>>>>>> >>>>>>> -- >>>>>>> Mark Wieder >>>>>>> ahsoftw...@gmail.com >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>> >> _______________________________________________ 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
