Web lists-archives.com

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
to the data - and even then, you're unlikely to get 3 bars for a
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

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.

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
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