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

@harald, sure.
@shawn, you say FTWRL is very important, tools that backup 
to text files for now - do those follow this principle? 
mysqldump eg. does it do FTWRL ? (I'm reading man pages but 
either I've gone blind or it's not there)

On 03/03/16 16:02, shawn l.green wrote:
>
>
> On 3/3/2016 10:40 AM, lejeczek wrote:
>> 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.
>>
>
> As the new encryption layer we are discussing (TDE) is 
> between the storage engine and the physical file (the data 
> in the file is encrypted), then any technique for doing 
> safe file-level backups will preserve the encryption.
>
> Examples:
>   cold backups (copying off the files after stopping the 
> daemon)
>   FTWRL + wait for background threads to complete their 
> queues + file system snapshot
>   MySQL Enterprise Backup (coming soon for TDE tables; we 
> are still working out some early bugs between TDE and MEB)
>
> Any technique that reads the decrypted data and 
> transcribes it to text would not be a backup technique 
> that preserves that encryption.
> Example: mysqldump
>
>
> (NOTE: "FTWRL" is a shorthand for the command FLUSH TABLES 
> WITH READ LOCK. It can save a lot of typing. )
>


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