Centuries ago, Nostradamus foresaw when Murat Kantarcioglu <kanmurat@cs.purdue.edu> would write:
> For our research project, I need to implement an encryption support
> for Postgressql. At this current phase, I need to at least support
> page level encryption In other words, each page that belongs to a
> certain sensitive table will be stored encrypted on the harddisk.
> Since we are trying to have a new design that can start the decryption
> before even we see the data, I need to have some kind of thread
> support.
>
> My questions are in order to support page level encryption(i,e
> encrypt each page before writing back to disk and decrypt each page
> after we read from disk.) which parts of the code should be changed?
> Our more simply, is /src/backend/storage/smgr/md.c the only code
> that does the disk access?
>
> Since our design requires thread support (we will do some of the
> decryption, before we see the data, therefore during disk access, we
> need to continue decryption) Can you suggest me a good thread lib
> you think will work fine with postgresql ?
>
> Thanks for your help.
You'd better step back to your threat model, and figure out what
encryption will actually get you.
I don't see any reason to think that you can actually gain _anything_
from page level encryption.
If you think you do, then you ought to either:
a) Show how you gain it using something like Linux's capability to use encrypted loopback filesystems, which would
notrequire touching PostgreSQL at all, or
b) Demonstrate what are the attacks that page level encryption would protect against, and how.
The problem with any such mechanisms is essentially the same, namely
that the encryption key has got to sit in memory in either the
database server process or in the kernel's memory.
As such, the key is vulnerable to anyone with root access that can
access /proc or its equivalent and get at process memory.
The only way for the encryption key NOT to be vulnerable in this
fashion is if the encryption key is communicated neither to the
database server nor to the OS kernel.
I'd suggest you avail yourself of the book _Translucent Databases_ by
Peter Weyner; it involves a model where the database engine is not
entrusted with cryptography at all.
Instead, cryptography is all done within the client.
--
(reverse (concatenate 'string "gro.gultn" "@" "enworbbc"))
http://www.ntlug.org/~cbbrowne/unix.html
In case you weren't aware, "ad homineum" is not latin for "the user of
this technique is a fine debater." -- Thomas F. Burdick
