Re: 3des key lengths and key management - Mailing list pgsql-general

From Greg Stark
Subject Re: 3des key lengths and key management
Date
Msg-id 407d949e0907231147v1cea3f78y3077400e66b4402a@mail.gmail.com
Whole thread Raw
In response to 3des key lengths and key management  (bulk <bulk@bohlman.org>)
List pgsql-general
On Thu, Jul 23, 2009 at 6:11 PM, bulk<bulk@bohlman.org> wrote:
> 1)   What are the default 3des key lengths when you load postgresql
> enterprise db on a redhat ES x86_64 box?

Traditionally 3des can use either 112-bit or 56-bit keys. I think the
openssl interface actually lets you set the third key separately now
but I'm not sure that adds any security.

> 2)   If possible how can you change the keys?  and replace them with keys
> with lengths to 2048 bit or above?
> 3)  If 2 is not possible then what other encryption type can we use that
> will meet his 2048 bit key length requirement?

He's completely confused. Symmetric key encryption like DES/3DES/AES
use key sizes much smaller than this. 3DES is still considered
reasonably secure with 112 bit keys, though the real state of the art
today is AES which uses key sizes of 128, 192, or 256.

He or she is thinking of asymmetric encryption like RSA. For those
algorithms key sizes are often in the range 1024, 2048, or even higher
-- 2048 isn't actually considered very high any more. But those keys
are generally used differently. They're used to sign or protect hashes
or keys which are then generated or used with symmetric encryption
algorithms. They're far too slow to use for the actual encryption
itself.



> 4) Is is possible to compile C or Java code that will allow me to be the
> only one whom knows the pass-key but allow other users to encrypt/decrypt
> data?

Well you need the pass-key to do the encryption or decryption. With
asymmetric algorithms you can separate those two functions so the
group which can encrypt is separate from the group which can decrypt.

You can create a function to do the encryption and another function to
do decryption, make it SECURITY DEFINER, and grant access to only
certain users. But then anyone who has a dump of your database will
have the key which kind of defeats the purpose of using encryption.


--
greg
http://mit.edu/~gsstark/resume.pdf

pgsql-general by date:

Previous
From: Greg Smith
Date:
Subject: Re: commercial adaptation of postgres
Next
From: Emanuel Calvo Franco
Date:
Subject: uuid contrib don't compile in OpenSolaris