On Mon, Jul 13, 2009 at 01:22:30PM +0900, Itagaki Takahiro wrote:
Sam Mason s...@samason.me.uk wrote:
As others have said, handling encryption client side would seem to offer
many more benefits (transparently within libpq offering easy adoption).
Libpq is not the only driver. Do we need to
On Tue, Jul 07, 2009 at 05:35:28PM +0900, Itagaki Takahiro wrote:
Our manual says we can use pgcrypto functions or encrypted filesystems
for data encryption.
http://www.postgresql.org/docs/8.4/static/encryption-options.html
However, they are not always the best approaches in some cases.
Sam Mason s...@samason.me.uk wrote:
As others have said, handling encryption client side would seem to offer
many more benefits (transparently within libpq offering easy adoption).
Libpq is not the only driver. Do we need to develop transparent decryption
for each drivers? (libpq, JDBC,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, Jul 13, 2009 at 01:22:30PM +0900, Itagaki Takahiro wrote:
Sam Mason s...@samason.me.uk wrote:
As others have said, handling encryption client side would seem to offer
many more benefits (transparently within libpq offering easy
gsst...@mit.edu (Greg Stark) writes:
However I have a different concern which hasn't been raised yet.
Encrypting lots of small chunks of data with the same key is a very
dangerous thing to do and it's very tricky to get right.
Yeah, that's exactly the sort of thing that would be Most Useful
a...@esilo.com (Andrew Chernow) writes:
Would the IV be regenerated every time the plaintext is updated, to
avoid using it twice? For instace: update t set text = 'abc' where id
= 1 . ISTM that the IV for OLD.text should be thrown away.
Where would the key come from? Where would it be
Our manual says we can use pgcrypto functions or encrypted filesystems
for data encryption.
http://www.postgresql.org/docs/8.4/static/encryption-options.html
However, they are not always the best approaches in some cases.
For pgcrypto functions, user's SQL must contain keyword strings
and they
Itagaki Takahiro wrote:
Our manual says we can use pgcrypto functions or encrypted filesystems
for data encryption.
http://www.postgresql.org/docs/8.4/static/encryption-options.html
However, they are not always the best approaches in some cases.
For pgcrypto functions, user's SQL must
On Tue, Jul 7, 2009 at 10:09 AM, Heikki
Linnakangasheikki.linnakan...@enterprisedb.com wrote:
What kind of attacks would this protect against? Seems a bit pointless
to me if the password is being sent to the server anyway. If the
attacker has superuser access to the server, he can harvest the
Greg Stark wrote:
On Tue, Jul 7, 2009 at 10:09 AM, Heikki
Linnakangasheikki.linnakan...@enterprisedb.com wrote:
What kind of attacks would this protect against? Seems a bit pointless
to me if the password is being sent to the server anyway. If the
attacker has superuser access to the server,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Jul 07, 2009 at 05:35:28PM +0900, Itagaki Takahiro wrote:
Our manual says we can use pgcrypto functions or encrypted filesystems
for data encryption.
http://www.postgresql.org/docs/8.4/static/encryption-options.html
As other posters have
In response to Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp:
Our manual says we can use pgcrypto functions or encrypted filesystems
for data encryption.
http://www.postgresql.org/docs/8.4/static/encryption-options.html
However, they are not always the best approaches in some cases.
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Itagaki Takahiro wrote:
CREATE TYPE encrypted_text (
INPUT = pgp_sym_encrypt_text(textin($1), passward(), options()),
OUTPUT = textout(pgp_sym_decrypt_text($1, passward(), options())),
LIKE bytea
);
passward() and options()
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
Greg Stark wrote:
It would still protect against offline attacks such as against backup files.
True, but filesystem-level encryption handles that scenario with less pain.
Yes, I intended offline attacks, and also agree that
On Wed, Jul 8, 2009 at 1:49 AM, Itagaki
Takahiroitagaki.takah...@oss.ntt.co.jp wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
Greg Stark wrote:
It would still protect against offline attacks such as against backup
files.
True, but filesystem-level encryption handles
Encrypting lots of small chunks of data with the same key is a very
dangerous thing to do and it's very tricky to get right.
Using an initialization vector (IV) is the way to go, recommend using CBC or CFB
mode. Although, an IV is never supposed to be used more than once with the same
key;
Andrew Chernow wrote:
Encrypting lots of small chunks of data with the same key is a very
dangerous thing to do and it's very tricky to get right.
Using an initialization vector (IV) is the way to go, recommend using
CBC or CFB mode. Although, an IV is never supposed to be used more
Andrew Dunstan wrote:
Andrew Chernow wrote:
Encrypting lots of small chunks of data with the same key is a very
dangerous thing to do and it's very tricky to get right.
Using an initialization vector (IV) is the way to go, recommend using
CBC or CFB mode. Although, an IV is never
to...@tuxteam.de wrote:
As other posters have put it, I'd be very sceptical of server-side
decryption. If the server has all the necessary bits to decrypt the
data, all bets are off.
Server can access both encrypted data and its password, but we can put
them in different disk drives. We
On Wed, Jul 8, 2009 at 6:43 AM, Itagaki
Takahiroitagaki.takah...@oss.ntt.co.jp wrote:
to...@tuxteam.de wrote:
As other posters have put it, I'd be very sceptical of server-side
decryption. If the server has all the necessary bits to decrypt the
data, all bets are off.
Server can access
20 matches
Mail list logo
