On Mon, 8 Mar 2004, Silvana Di Martino wrote:
> Alle 17:40, domenica 7 marzo 2004, Stephan Szabo ha scritto:
> > Who has access to the unencrypted versions of the data? Are there people
> > who will have access to the database who might have access to some of the
> > encrypted data but not all or someone who has access to the database but
> > none of the encrypted data? If so, then you presumably need a system
> > where the decryption will only work for the appropriate people and that
> > needs to be built in.
> Yes: each "authorized operator" must be able to access data belonging to him,
> only, even if the database contains data belonging to many different
> operators. Moreover, SysAdmin (that are not "authorized operator") must not
> be able to access any data, even if they are able to access the database (as
> a whole) for maintenance. So, decryption must work for authorized operator
That's what I figured, but given a system where the password is given on
startup to the database, you would need another layer for the security,
have you though about how that would work? A not terrible option would be
to compose the key from something given by the user (perhaps at session
start with a query) with something already stored, but I don't know if the
law would allow that.
Also, there's a question about multiple databases in one instance that
might want separate encryption esp where the authorized users might be
non-overlapping sets. It might be better to allow a human to use a query
to initialize the passwords.
> > Also, what manipulation do you want to do with these values in the
> > database? Are you going to need to subtract two encrypted dates or
> > determine that one is greater than the other?
> Yes: we will need to perform basic operations on encrypted dates, times and so
> on. Of course, it would be great to be able to delegate the on-the-fly
> decryption/encryption work to the encryption system.
> > What about substring or
> > ordering for encrypted strings? Does this have to be automatic or is
> > explicit description of the fact that you want to decrypt them and then do
> > something sufficient?
> Same as above: we would need to perform substring-wise operations and ordering
> on encrypted strings. The encryption/decryption mechanism should be
As above, automatic runs into questions about who can do it and maint
issues, like if encryption happens on insert and the admin cannot see the
decrypted form, the admin cannot backup the database using something like
pg_dump. This is probably best solved by doing whatever is necessary to
make the admin authorized.
It should be reasonably easy to make types that took input and encrypted
it and had say appropriate output function that checked and decrypted
along with implicit casts that do the same thing. It'd be CPU consuming,
but workable. Here you run into the question of how it's configured
In response to
pgsql-admin by date
|Next:||From: Corey Edwards||Date: 2004-03-08 16:54:06|
|Subject: Re: Postgres and multiprocessor?|
|Previous:||From: Bruno Wolff III||Date: 2004-03-08 14:47:32|
|Subject: Re: pgcrypto and database encryption|