I put it here:
http://pro.datisstom.nl/tests/bench.tar.bz2
The encryption isn't really a *real* security measure, except for when
somebody is stupid enough to install phpMyAdmin or anything equivalent
and try to get personal data. The problem is the password needs to be
anywhere on the application-server and if you're in, you're in. But it's
a request and I'm happy to oblige. Even if it only stops them for 1
minute (which could be enough).
Regards,
John
--
/ Humanique
/ Webstrategie en ontwikkeling
/ http://www.humanique.com/
-
Humanique zoekt een ervaren Web-ontwikkelaar (PHP).
Bekijk de vacature op http://www.humanique.com/
-
Jeremy Cole wrote:
Hi John,
Your attachment for the php code got stripped somewhere. Can you post
it somewhere (http preferable)? In either case it's going to result in
a full table scan, so they are actually both a bad strategy long term,
but they should in theory perform as you would expect, with with
encryption being slightly slower.
Have you tried with longer strings?
What is your customer's fear with having the data in plain text?
Presumably in order to use this in your application, you will have the
AES password stored in your application, and it will end up in logs
(such as the slow query log) quite frequently. I would think your data
can be safer and your security more effective by setting some policies
which are less intrusive into the actual workings of the data, such as
encrypting backups and setting system-level policies.
Regards,
Jeremy
John Kraal wrote:
Dear you,
I've been working on encrypting some data for a customer. They want
their personal/sensitive information encrypted in the database, but they
want to be able to search it too, through the application. So we've been
thinking a bit, and just started trying and benchmarking some solutions
we thought up.
The next one really got my attention, I created a table with 4 fields:
1. id (primary/auto_increment, not really interesting)
2. "field", with encrypted data
3. md5sum (it has no special use, we benched it though.)
4. "line", always containing three words (the same three as encrypted)
When we started querying the table for random words (from lipsum.com),
it seems that searching in the encrypted fields was _lots_ faster.
Results below:
1.000 queries per field:
~$ php -q searchtest.php
Control test (plain/text LIKE %..%): 1.409699s
Decrypt test (AES_DECRYPT() LIKE %..%): 1.226069s
done
1.000.000 queries per field:
~$ php -q searchtest.php
Control test (plain/text LIKE %..%): 155.059671s
Decrypt test (AES_DECRYPT() LIKE %..%): 137.003216s
done
Actually, the only thing I could think of to say was: "Well, at least
it's consistent".
I've attached all the files I used for this test. Edit db.inc.php (add
some more lipsum if you want), execute fill.php, and then have fun
with bench.php.
Does any of you know why this is, how come, etc? I'm just very curious.
Regards,
John Kraal
------------------------------------------------------------------------
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
