Re: can I just encrypt tables? what about the app?
- Date: Sun, 6 Mar 2016 09:55:02 +0000
- From: lejeczek <peljasz@xxxxxxxxxxx>
- Subject: Re: can I just encrypt tables? what about the app?
@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:
how to backup in a way that this in-database-encryption
will be taken
On 3/1/2016 6:26 PM, lejeczek wrote:
On 29/02/16 21:35, shawn l.green wrote:
taking your last line and making and assumption or two,
notion of double
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
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
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
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
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
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
Correct. As long as the key and the lock are on the
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
read the data. It's purpose is to make it
impractically hard for any
unauthorized parties to read it.
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
scramble the data, but how long your key is. In the
early days of
computers, keys were short because processing power was
today's world, you must use longer keys just to stay
ahead of Moore's
For example, DES with a 56-bit key (2^56 possible
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
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
upgrading their certificates soon.
does any of present backup solutions can do it?
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.
cold backups (copying off the files after stopping the
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.
(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