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

[lejeczek]

@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

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

[shawn l.green]

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


--
Shawn Green
MySQL Senior Principal Technical Support Engineer
Oracle USA, Inc. - Integrated Cloud Applications & Platform Services
Office: Blountville, TN

Become certified in MySQL! Visit https://www.mysql.com/certification/ 
for details.


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

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

[Reindl Harald]

Am 03.03.2016 um 16:40 schrieb lejeczek:

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


think once again what "transparent encryption" means

the most effective backup is anyways running slave connected to the 
master via TLS, stop the slave and rsync away the whole datadir because 
it is fast, efficient and scriptable (with ssh-keys even between networks)




signature.asc
Description: OpenPGP digital signature

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

[lejeczek]

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

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

[shawn l.green]

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


--
Shawn Green
MySQL Senior Principal Technical Support Engineer
Oracle USA, Inc. - Integrated Cloud Applications & Platform Services
Office: Blountville, TN

Become certified in MySQL! Visit https://www.mysql.com/certification/ 
for details.


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

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

[lejeczek]

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?



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

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

[shawn l.green]

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.


--
Shawn Green
MySQL Senior Principal Technical Support Engineer
Oracle USA, Inc. - Integrated Cloud Applications & Platform Services
Office: Blountville, TN

Become certified in MySQL! Visit https://www.mysql.com/certification/ 
for details.


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

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

[Reindl Harald]

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



signature.asc
Description: OpenPGP digital signature

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

[Gary Smith]

On 29/02/2016 19:54, Gary Smith wrote:
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.

Apologies, that should read "unencrypted (aiui) once it's in memory"

Gary

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

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

[Gary Smith]

On 29/02/2016 19:50, Reindl Harald wrote:


cryptsetup/luks can achieve that way better

Only to a degree. 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.


Cheers,

Gary

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

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

[Reindl Harald]

Am 29.02.2016 um 20:30 schrieb shawn l.green:

Hi Reindl,

On 2/29/2016 2:16 PM, Reindl Harald wrote:



Am 29.02.2016 um 20:07 schrieb Jesper Wisborg Krogh:

Hi Lejeczek,

On 1/03/2016 00:31, lejeczek wrote:

hi everybody

a novice type of question - having a php + mysql, can one just encrypt
(internally in mysql) tables and php will be fine?
If not, would it be easy to re-code php to work with this new,
internal encryption?


Starting with MysQL 5.7.11, there is transparent data encryption (TDE)
for InnoDB tables. If you use that, it is as the name suggest
transparent for PHP. See also:
https://dev.mysql.com/doc/refman/5.7/en/innodb-tablespace-encryption.html



i still don't grok a usecase for such encryption because when a
webserver got compromised you have the same access as before, just
solwer with more overhead in general

what is the purpose of encryption on that layer?


Some process requirements state that some data should never be stored on
disk in plain text. This is one way to meet those requirements.


cryptsetup/luks can achieve that way better


Some data has been compromised not by cracking the primary database but
by breaking into a server containing backups of the data. This new
feature allows file-level backups (like those generated by MySQL
Enterprise Backup) to be secure.


well, somewhere must be the key to decrypt the data anyways, otherwise 
mysqld couldn't operate with the data - how do you protect that one 
without run in a chicken-egg problem


in the worst case it introduces the risk that some clueless guys become 
more careless "because my data is encrypted" somewhere else and don't 
grok what and what not is safe



What that feature achieves is that the data will be encrypted at rest,
not just in flight (using SSL).


see above


Clearly, this does not defeat an attacker who is able to compromise or
become an authenticated client who is normally allowed to read that
data. To fix that problem, you must employ application-level encryption
which encodes the data actually stored on the table. Clearly this last
type of encryption breaks the database server's ability to index the
data as the server would have no key to decrypt the content of the
fields to build any normal (clear-content) indexes on it. It would only
be able to index the encrypted (opaque) data. The clients would need to
code their queries with WHERE clauses looking for the exact encrypted
values they wanted to find


and even there you have the same problem: as long your application works 
with however encrypted data it needs to have they key somewhere and when 
i compromise your server i can read that key too




signature.asc
Description: OpenPGP digital signature

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

[shawn l.green]

Hi Reindl,

On 2/29/2016 2:16 PM, Reindl Harald wrote:



Am 29.02.2016 um 20:07 schrieb Jesper Wisborg Krogh:

Hi Lejeczek,

On 1/03/2016 00:31, lejeczek wrote:

hi everybody

a novice type of question - having a php + mysql, can one just encrypt
(internally in mysql) tables and php will be fine?
If not, would it be easy to re-code php to work with this new,
internal encryption?


Starting with MysQL 5.7.11, there is transparent data encryption (TDE)
for InnoDB tables. If you use that, it is as the name suggest
transparent for PHP. See also:
https://dev.mysql.com/doc/refman/5.7/en/innodb-tablespace-encryption.html


i still don't grok a usecase for such encryption because when a
webserver got compromised you have the same access as before, just
solwer with more overhead in general

what is the purpose of encryption on that layer?




Some process requirements state that some data should never be stored on 
disk in plain text. This is one way to meet those requirements.


Some data has been compromised not by cracking the primary database but 
by breaking into a server containing backups of the data. This new 
feature allows file-level backups (like those generated by MySQL 
Enterprise Backup) to be secure.


What that feature achieves is that the data will be encrypted at rest, 
not just in flight (using SSL).


Clearly, this does not defeat an attacker who is able to compromise or 
become an authenticated client who is normally allowed to read that 
data. To fix that problem, you must employ application-level encryption 
which encodes the data actually stored on the table. Clearly this last 
type of encryption breaks the database server's ability to index the 
data as the server would have no key to decrypt the content of the 
fields to build any normal (clear-content) indexes on it. It would only 
be able to index the encrypted (opaque) data. The clients would need to 
code their queries with WHERE clauses looking for the exact encrypted 
values they wanted to find.


--
Shawn Green
MySQL Senior Principal Technical Support Engineer
Oracle USA, Inc. - Integrated Cloud Applications & Platform Services
Office: Blountville, TN

Become certified in MySQL! Visit https://www.mysql.com/certification/ 
for details.


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

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

[Reindl Harald]

Am 29.02.2016 um 20:07 schrieb Jesper Wisborg Krogh:

Hi Lejeczek,

On 1/03/2016 00:31, lejeczek wrote:

hi everybody

a novice type of question - having a php + mysql, can one just encrypt
(internally in mysql) tables and php will be fine?
If not, would it be easy to re-code php to work with this new,
internal encryption?


Starting with MysQL 5.7.11, there is transparent data encryption (TDE)
for InnoDB tables. If you use that, it is as the name suggest
transparent for PHP. See also:
https://dev.mysql.com/doc/refman/5.7/en/innodb-tablespace-encryption.html


i still don't grok a usecase for such encryption because when a 
webserver got compromised you have the same access as before, just 
solwer with more overhead in general


what is the purpose of encryption on that layer?




signature.asc
Description: OpenPGP digital signature

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

[Jesper Wisborg Krogh]

Hi Lejeczek,

On 1/03/2016 00:31, lejeczek wrote:

hi everybody

a novice type of question - having a php + mysql, can one just encrypt 
(internally in mysql) tables and php will be fine?
If not, would it be easy to re-code php to work with this new, 
internal encryption?


Starting with MysQL 5.7.11, there is transparent data encryption (TDE) 
for InnoDB tables. If you use that, it is as the name suggest 
transparent for PHP. See also: 
https://dev.mysql.com/doc/refman/5.7/en/innodb-tablespace-encryption.html


Best regards,
Jesper Krogh
MySQL Support

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

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

[lejeczek]

On 29/02/16 14:38, Steven Siebert wrote:

Simple answer is no. What are you trying to accomplish?

I was hoping that with this new feature (google's) where 
mysql itself, internally uses keys to encrypt/decrypt tables 
or tablespaces I could just secure data, simply.
Chance is I don't quite get the concept, I believe I have 
one table encrypted (trying stings on it suggests) yet I can 
just query it and dump as normal.
I understand it's kind of database-file encryption, 
protection against just grabbing a file and trying to run it 
somewhere else, am I right?
If above is the case the from php perspective nothing should 
be different, it should be transparent, no?


many thanks

S

On Mon, Feb 29, 2016 at 8:31 AM, lejeczek 
> wrote:


hi everybody

a novice type of question - having a php + mysql, can
one just encrypt (internally in mysql) tables and php
will be fine?
If not, would it be easy to re-code php to work with
this new, internal encryption?

thanks.

-- 
MySQL General Mailing List

For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql





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

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

[Steven Siebert]

Simple answer is no. What are you trying to accomplish?

S

On Mon, Feb 29, 2016 at 8:31 AM, lejeczek  wrote:

> hi everybody
>
> a novice type of question - having a php + mysql, can one just encrypt
> (internally in mysql) tables and php will be fine?
> If not, would it be easy to re-code php to work with this new, internal
> encryption?
>
> thanks.
>
> --
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe:http://lists.mysql.com/mysql
>
>