Re: [GENERAL] 3des key lengths and key management
On Jul 23, 2009, at 12:11 PM, Steve Atkins wrote: They asked me to open up my firewall to them, pointing at a fake server, just so they'd have something to audit, after failing our audit "because we only allowed access to the application from inside our firewall." I'm glad it wasn't just me. We failed our audit because our firewall correctly detected their probes as an intrusion, and shut them down. It would be as if your home failed a security audit because no one could get through the external fence, so "we couldn't verify that the door was locked." -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] 3des key lengths and key management
On Jul 23, 2009, at 12:11 PM, Steve Atkins wrote: 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? Yes, that's asymmetric cryptography, using something like DSA. Oops. Missed the "decrypt" bit there. It's sort of possible, but only by relying on other access controls to allow other users to run your code, but not access it in other ways. Within the database a security definer function would let you do that. But anyone with superuser access to the machine, or to the database, or who had access to backups or database dumps would be able to get the key. You can build systems of increasing complexity to get marginally more protection, but it's really not a path you want to be going down just for PCI compliance. Cheers, Steve -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] 3des key lengths and key management
On Jul 23, 2009, at 10:11 AM, bulk wrote: I am working for a small company that is going through a PCI DSS audit. securitymetrics.com? (They seem to be the low bidder, with everything that implies. They asked me to open up my firewall to them, pointing at a fake server, just so they'd have something to audit, after failing our audit "because we only allowed access to the application from inside our firewall.".) The auditor wants to know how long the key lengths are for the fields that we have encrypted with pgcrypto 3des. I am by no means an expert in cryptology, so I am struggling with what to tell him?I've done a day or so of googling and the best I can tell is the 3des uses 3x56bit keys and encrypts the date 3 times with each of the keys. If he really said that 3des can use 2048 bit keys, tell him he's an idiot. He did not seem to like that answer. He seems to believe that 3des can use 2048 bit keys and that is the minimal acceptable standard of PCI DSS? What I know is that we simply added the contrib pgcrypto stuff into the database and started using 3des and it seemed to work. So my questions are: 1) What are the default 3des key lengths when you load postgresql enterprise db on a redhat ES x86_64 box? Dunno. 3des is usually a 112 bit key, though, IIRC. 168 at most. It's rather an old cipher by this point, but still secure enough for most things. 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? Long key lengths, thousands of bits, are something you tend to talk about when you're looking at an asymmetric cipher. RSA, DSA stuff like that. Symmetric ciphers (aka secret-key), like 3des, tend to use much shorter key lengths. A symmetric cipher uses the same key to encrypt and decrypt a message. An asymmetric cipher (aka public-key) uses one key to encrypt the message and needs a different key to decrypt it. 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? Yes, that's asymmetric cryptography, using something like DSA. For a web application capturing credit cards, say, doing that you might use something like pgp to handle all the encryption and decryption. You'd use PGP in your webapp using a public key to encode the credit card numbers you were given before storing them in the database. Any time you need to access that you'd pull it out of the database, and use PGP with the associated private key to recover the credit card number, probably on a separate secure system. That's reengineering your entire system architecture and business process, though, rather than just dropping in a new encryption algorithm. As I understand the PCI DSS requirements (which is only a little) you don't need to use asymmetric crypto to comply with them, and that as long as you have decent key management and access control, 3des would be fine. https://www.pcisecuritystandards.org/ has a bunch of the docs if you're interested. Cheers, Steve -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] 3des key lengths and key management
On Thu, Jul 23, 2009 at 6:11 PM, bulk 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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] 3des key lengths and key management
I am working for a small company that is going through a PCI DSS audit. The auditor wants to know how long the key lengths are for the fields that we have encrypted with pgcrypto 3des. I am by no means an expert in cryptology, so I am struggling with what to tell him?I've done a day or so of googling and the best I can tell is the 3des uses 3x56bit keys and encrypts the date 3 times with each of the keys. He did not seem to like that answer. He seems to believe that 3des can use 2048 bit keys and that is the minimal acceptable standard of PCI DSS? What I know is that we simply added the contrib pgcrypto stuff into the database and started using 3des and it seemed to work. So my questions are: 1) What are the default 3des key lengths when you load postgresql enterprise db on a redhat ES x86_64 box? 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? 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? Thanks in advance, --bb -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
