Examples of encryption for database access

Thu Jun 28 22:43:15 EDT 2018

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 <brian at 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, prothero at 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 <brian at 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, prothero at earthlearningsolutions.org <prothero at 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 <brian at 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 at 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
>>>>>>> ahsoftware at gmail.com
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> use-livecode mailing list
>>>>>>> use-livecode at lists.runrev.com
>>>>>>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>>>>>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> use-livecode mailing list
>>>>>> use-livecode at lists.runrev.com
>>>>>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>>>>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>>> 
>> 