Re: [HACKERS] RFE: Transparent encryption on all fields

2009-04-28 Thread Sam Halliday
> -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Mon, Apr 27, 2009 at 01:28:45AM -0700, Sam Halliday wrote: >> >> >> Tomas Zerolo wrote: >> > >> >> If there were a way to prompt the user for the password to an >> encrypt

Re: [HACKERS] RFE: Transparent encryption on all fields

2009-04-27 Thread Sam Halliday
I think Sam Mason's proposal of hacking pg-pool sounds feasible. Is there any way to create a formal RFE for this? Is anybody interested in implementing this? On 27 Apr 2009, at 13:55, Sam Mason wrote: One possible arrangement would be if each user/encryption key had its own database cluster

Re: [HACKERS] RFE: Transparent encryption on all fields

2009-04-27 Thread Sam Halliday
On 27 Apr 2009, at 13:55, Sam Mason wrote: Allowing multiple users/encryption keys access the same database seems problematic; how would you allow catalogue access and enforce unique or other constraints if the server couldn't look to see what's there. Not sure what you're after here though

Re: [HACKERS] RFE: Transparent encryption on all fields

2009-04-27 Thread Sam Halliday
Tomas Zerolo wrote: > >> If there were a way to prompt the user for the password to an encrypted >> drive on startup for all OS, with an equivalent for headless machines... > > There definitely is. We even need more flexibility: prompt for > credentials at the time of *mounting* a secured par

Re: [HACKERS] RFE: Transparent encryption on all fields

2009-04-27 Thread Sam Halliday
, Apr 27, 2009 at 3:43 AM, Sam Halliday wrote: TrueCrypt is exactly the "encrypted drive" solution. It has problems. They are described in this thread. If there were a way to prompt the user for the password to an encrypted drive on startup for all OS, with an equivalent for

Re: [HACKERS] RFE: Transparent encryption on all fields

2009-04-26 Thread Sam Halliday
TrueCrypt is exactly the "encrypted drive" solution. It has problems. They are described in this thread. Sam Mason wrote: > > There are various tools that allow you to do this without specialised > hardware, TrueCrypt[1] is one I've used in the past and is very easy for > naive users to get the

Re: [HACKERS] RFE: Transparent encryption on all fields

2009-04-26 Thread Sam Halliday
Tomas Zerolo wrote: > > Note that I'm not talking about stealing the hardware, but hijacking, > trojanizing, whatever. That's the real threat, in this > Javascript/Flash/Silverlight infested world. > I'm still talking about theft of machines (particularly laptops) as that is a major threat. On

Re: [HACKERS] RFE: Transparent encryption on all fields

2009-04-26 Thread Sam Halliday
On 26 Apr 2009, at 07:05, to...@tuxteam.de wrote: - a single psql server can autonomously start up and serve connection requests (this cannot be done with encrypted disc) Sure it can -- it will be strongly architecture dependent though. Look at [1] for an example of how this might be done for t

Re: [HACKERS] RFE: Transparent encryption on all fields

2009-04-25 Thread Sam Halliday
Please continue to CC me on this thread as I have disabled receiving messages from this list, although remain subscribed. On 25 Apr 2009, at 05:52, to...@tuxteam.de wrote: Sure, there are challenges, but there are methods to work through all of those challenges. I seem to be less optimistic

[HACKERS] RFE: Transparent encryption on all fields

2009-04-23 Thread Sam Halliday
Dear pgsql hackers, The encryption options http://www.postgresql.org/docs/8.3/static/encryption-options.html fall short for my thread case. Consider the case where all users of a machine are trusted and the machine automatically locks itself down on a period of inactivity, and only local