Re: Two way encryption in PG???

From: Mathijs Brands <mathijs(at)ilse(dot)nl>
To: clayton cottingham <drfrog(at)smartt(dot)com>
Cc: Boulat Khakimov <boulat(at)inet-interactif(dot)com>, pgsql-sql(at)postgresql(dot)org
Subject: Re: Two way encryption in PG???
Date: 2001-03-05 23:06:25
Message-ID: 20010306000625.H22983@ilse.nl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

On Mon, Mar 05, 2001 at 08:40:53AM -0800, clayton cottingham allegedly wrote:
> Boulat Khakimov wrote:
> >
> > David Olbersen wrote:
> > >
> > > On Sun, 4 Mar 2001, Boulat Khakimov wrote:
> > >
> > > ->How do I encrypt/decrypt something in PG?
> > >
> > > Perhaps it'd be better to one-way encrypt something? Granted I don't know the
> > > details of your project, but allowing a way to "decrypt" something is rather
> > > insecure.
> > >
> > > -- Dave
> >
> > Now, one way CC encryption doesnt really make any sense, does it :)
> >
> > Two-way encryption algorithms like blowfish are very hard to break, too
> > bad they are
> > not build in to PG.
> >
>
> this could be easily done with
> PL/perl couldnt it?

It's still not clear to me why someone would want to. Having the database
server do two-way encryption doesn't really provide you with any extra
protection. Also, it puts extra strain on the database server.

If you want to store encrypted data on the server, have the application do
the encryption. That also would provide for a much more scaleable solution,
since it doesn't put any extra load on the database server. Doing the
encryption on the application end should be pretty easy.

I know there are some database(like) systems that can do this kind of stuff,
but the only advantage I can see at the moment is that when someone
physically steals your database server (or the disks), they can't read your
data. This only works when the key is NOT, again, NOT stored on disk in any
form; query the sysadmin (or someone similar) when starting the db server
instead.

Btw. don't even think about asymmetric (public key) cyphers, such as RSA.
They are MUCH too slow, both in setup and processing (throughput) time.

Cheers,

Mathijs
--
It's not that perl programmers are idiots, it's that the language
rewards idiotic behavior in a way that no other language or tool has
ever done.
Erik Naggum

In response to

Browse pgsql-sql by date

  From Date Subject
Next Message Mathijs Brands 2001-03-05 23:08:50 Re: Optimizing Query
Previous Message Michael Fork 2001-03-05 22:53:38 Re: Optimizing Query