Re: can I just encrypt tables? what about the app?

On 02/03/16 00:51, shawn l.green wrote:
>
>
> On 3/1/2016 6:26 PM, lejeczek wrote:
>>
>>
>> On 29/02/16 21:35, shawn l.green wrote:
>>>
>>>
>>> On 2/29/2016 3:13 PM, Reindl Harald wrote:
>>>>
>>>>
>>>> Am 29.02.2016 um 20:54 schrieb Gary Smith:
>>>>> On 29/02/2016 19:50, Reindl Harald wrote:
>>>>>>
>>>>>> cryptsetup/luks can achieve that way better
>>>>>>
>>>>> Only to a degree.
>>>>
>>>> no - not only to a degree - when the question is "not 
>>>> store anything
>>>> unencrypted on the disk" the is no degree, but or if
>>>>
>>>>> Once the disk is unencrypted, you've got access to the
>>>>> filesystem. If you've got physical access to the 
>>>>> machine, then anything
>>>>> which gives you console access gives you (potentially) 
>>>>> access to the
>>>>> underlying database files. If you can get those, it's 
>>>>> trivial to get
>>>>> access to the dataset that they contain.
>>>>>
>>>>> However, if TDE is employed, then you've got another 
>>>>> significant
>>>>> obstacle to overcome: The data is only encrypted 
>>>>> (aiui) once it's in
>>>>> memory. At this point, you're needing to do attacks on 
>>>>> RAM to get
>>>>> access
>>>>> to the data - and even then, you're unlikely to get 3 
>>>>> bars for a
>>>>> jackpot
>>>>> payout of the whole database schema, assuming a decent 
>>>>> sized database.
>>>>
>>>> in theory
>>>>
>>>> in reality you don't need to hack around in the RAM - 
>>>> mysqld needs to
>>>> have access to key for operate with the data and so you 
>>>> need to find
>>>> only that piece
>>>>
>>>> the same for encryption on the application side before 
>>>> send data to the
>>>> db-layer - see the start and subject of that thread how 
>>>> far people are
>>>> away from understanding how and on what layer things 
>>>> are encrypted and
>>>> what excatly is protected in which context....
>>>>
>>>> there is no "turn this on and you are safe" without 
>>>> deeper understanding
>>>>
>>>
>>> Correct. As long as the key and the lock are on the same 
>>> machine,
>>> there will be some way of opening that lock. It's just a 
>>> matter of how
>>> hard can you make it to find that key. No data is 
>>> perfectly safe. No
>>> crypto is unbreakable. Ever.
>>>
>>> Maybe the key only exists in memory while the daemon 
>>> runs? You can
>>> hack the memory to find the key.
>>>
>>> Maybe the key is retrieved from another key service 
>>> daemon. If you
>>> have the credentials to impersonate a valid retriever, 
>>> you are in the
>>> money.
>>>
>>> The purpose of any encryption system is not to make it 
>>> impossible to
>>> read the data. It's purpose is to make it impractically 
>>> hard for any
>>> unauthorized parties to read it.
>> taking your last line and making and assumption or two, 
>> notion of double
>> encryption arises - will it work?
>>
>>
>
> A system called "Triple DES" does exactly what you propose 
> and appears to be in wide usage.
> https://en.wikipedia.org/wiki/Triple_DES
>
> The key to avoiding brute force attacks is not how many 
> times you scramble the data, but how long your key is. In 
> the early days of computers, keys were short because 
> processing power was less. In today's world, you must use 
> longer keys just to stay ahead of Moore's Law.
>
> Quoting from
> http://www.welivesecurity.com/2016/02/17/how-is-cryptography-incorporated-into-pos-terminals/ 
>
>> For example, DES with a 56-bit key (2^56 possible 
>> combinations) can be broken in less than a day, since 
>> average computers can perform a billion operations per 
>> second. However, the addition of more bits to the string 
>> will exponentially increase the time required to crack it.
>
>
> Most SSL keys (for example, those used to encrypt the 
> information exchanged when you visit "secure" web sites) 
> should all have keys that are 2048 bits or longer. If they 
> don't already, I'll bet they are upgrading their 
> certificates soon.
> http://news.netcraft.com/archives/2012/09/10/minimum-rsa-public-key-lengths-guidelines-or-rules.html 
>
>
>
how to backup in a way that this in-database-encryption will 
be taken advantage of?
does any of present backup solutions can do it?
many thanks.


-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:    http://lists.mysql.com/mysql