On ons, jul 03, 2002 at 11:00:19 +0200, Anders Gustafsson wrote:
> On Wed, Jul 03, 2002 at 08:06:52PM +0200, Tobias Bengtsson wrote:
> > I want to do transparent encryption. Like being able to choose an encryption
> > scheme of a table or database when created so that the data on disk is
> > always encrypted.
> Why don't you just put the tables on an encrypted filesystem? Afraid
> root will be able to read them? Somewhere the data will be in
> plaintext, root will always be able to get it if she wants. (think
> about ptracing mysqld)
well.. your right, but its not that easy.
The data could be decrypted client-side, then you can't ptrace mysqld, sure
you could ptrace the client, which could be on another machine, so you will
have to crack that too..
As always, your security could be tight as a virgin, it will break sometime anyway.
But if you have an encrypted filesystem on a server somewhere and it goes
down you can't automatically mount it without saving the password on disk,
am I right? Encrypted filesystems probably don't exists on all the platforms
mysql runs on.
> > I need this as my application doesn't communicate
> > directly with the database. I do it via an application called tilde
> > (http://tilde.tildesoftware.net), sure I can patch tilde (me and some
> > others wrote it), but its not a good solution as I'm sure others need or at
> > least want the same thing.
> So you want it totally transperent? Without any need at all for
> changes in the client.
Well.. I realise thats hard or impossible, but I'd rather be looking through
clean windows than rusty chickenwire..uhh.. or something like that :)
> > In the users interface it could be implemented as CREATE:ing the table with
> > some extra flags, choose encryption algorithm, nums of bits etc.
> > And when you're asking querys we'll need a new API to be able to send
> > passphrases too.
> Whoah! This is really transperant, no needs to make changes in the
> client :)
well.. Sure the last sentence was a stupid idea..
but altering the table description or creating the database in a
different way is quite transparent compared to rewrite all applications in
the world who ask SQL-querys.. I know there are several applications that
don't even deal with creation of tables.. and creation of databases? not
> > parameter on the mysql_real_connect()-api (the best thing is probably to
> > create a new API, called something like mysql_connect_wparams(), taking an
> > info-struct containing things like port, host, username, password, database,
> > ssl-option etc..)
mysql_connect_wparams() is still a good idea though, for future extensions,
not necessarily encryption. Anyone agree?
> > or maybe just use the database-password as passphrase for
> > the choosen encryption-scheme.. how strong is the PASSWORD()-funtion? is it
> > just some crypt(3)-variant or good shit? come with some ideas!
> What about different users (hopefully with different passwords) using
> the same database?
I didn't think too long about this.. I actually just wanted to start a
discussion, which I obviously did :)
> In what way, other than protecting the database ondisk-files from
> beeing stolen and read, will your proposed change increase the
> security? If you are able to steal the ondisk-files you are also able
> to ptrace mysqld and aquire the data that way. To me it seems as a
> good way of making oneself just feel secure when infact it almost
> doesn't buy you anything.
sure, you will feel more secure, you ARE more secure, because the number of
crackers 'elite' enough to perform this attack is less. People caring about
security will read the manual, and this will ofcourse be stated in the manual.
> > PS. Please CC replies on the internals list to me, as I'm only on the
> > general discussion list
hm. Is everybody thinking this is a bad idea?
`Given enough eyeballs, all bugs are shallow.'
69D6 E76A FC83 E9CA 0747 7A21 3CA3 2ABC 7A33 0551
Registered linux user number 75150