Re: [GENERAL] pgcrypto: is an IV needed with pgp_sym_encrypt()?
On Tue, Sep 18, 2007 at 11:26:17AM +0300, Marko Kreen wrote: > Few bytes being same is normal. Those are PGP packet header, > telling "this is symmetrically encrypted session key packet, > with length X" plus some more details. I see. So, you are saying no need to generate my own IV to prepend to the plain text before encrypting. > If more that few bytes are same, and if the salt is not randomised > it _could_ be a sign of problem. Either pgcrypto bug or failure > to initialize random generator. If you suspect a problem, please > send me few example encryptions with keys and your setup details > (postgres version, openssl or not, os version) No, it was only a few bytes that were similar, so the headers explain that. > > Besides following the PCI DSS and external audit procedures, the plan > > is to use pgcrypto (pgp_sym_encrypt() with AES-256) as part of a > > credit card storage server. The server and db are SSL only and the > > key is passed from the application and never stored anyplace (except > > in memcached on other servers during the session). The key is a > > user's plain text password plus an application-specific secret. So, > > each row has its own key. Passwords must be changed periodically, > > etc. > > I don't know details of your setup, but I strongly suggest you > look into using public-key crypto. That allow you separate keys > for encryption and decryption. So in webserver where users only > input credit cards, you keep only public keys, so anybody cracking > that won't be able to decrypt data. I need to look at that more. But I've seen that suggested where one needs to decrypt the data at a later time. We don't have that need. Our plan was to never store any keys. Every user must log in to the application with a password. Their account passwords are only stored hashed on disk, so we don't know their passwords. The plan is to encrypt their plain-text password with a secret known by the application only and stored into memcached. It's this plain-text password that will be sent to a separate server to encrypt and (and decrypt) their credit card data when the user make a transaction. We only need to store the credit card data to allow subsequent charges to their "card on file" -- and that only happens when a user logs in and processes a transaction. We don't have any way to decrypt the data without this password stored in the session. If someone hacks an application server they could pluck active user's passwords from memcached and also find the application's secret word. Then if they also hacked the credit card server they could then decrypt the data using passwords they were able to sniff. See any glaring holes? Thanks for the help! -- Bill Moseley [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] pgcrypto: is an IV needed with pgp_sym_encrypt()?
On 9/18/07, Bill Moseley <[EMAIL PROTECTED]> wrote: > I'm just starting with pgcrypto, and I'm curious if it's > needed/recommended to use an initialization vector/value (IV) with > the pgp_sym_encrypt() function. > > The docs hint that an IV is used automatically, but encrypting plain > text that starts the same seems to result in initial common cipher > text. So, I'm not clear. Few bytes being same is normal. Those are PGP packet header, telling "this is symmetrically encrypted session key packet, with length X" plus some more details. Yout can use pgpdump (or www.pgpdump.net) to visualize packet structure. It does not show you IV but does show salt key S2K loop count, so you can check if those are randomized. Note that the random IV will be put into second packet, so quite far from start. > 2. Data is prefixed with block of random bytes. This is equal to > using random IV. > > So, I'm currently generating a substring of a md5 hash of a few items > and pre-pending that to the plain text I need to encrypt as the IV. > Then when I decrypt I remove that prefix. You could try with different (same-length) hashes, you'll still see that few bytes are same. Also, the PGP IV _must_ be there so to check you can always try decrypting with gnupg, to see if packet structure is sane. If more that few bytes are same, and if the salt is not randomised it _could_ be a sign of problem. Either pgcrypto bug or failure to initialize random generator. If you suspect a problem, please send me few example encryptions with keys and your setup details (postgres version, openssl or not, os version) > BTW, this is for credit card storage, which is a business requirement. > > Besides following the PCI DSS and external audit procedures, the plan > is to use pgcrypto (pgp_sym_encrypt() with AES-256) as part of a > credit card storage server. The server and db are SSL only and the > key is passed from the application and never stored anyplace (except > in memcached on other servers during the session). The key is a > user's plain text password plus an application-specific secret. So, > each row has its own key. Passwords must be changed periodically, > etc. I don't know details of your setup, but I strongly suggest you look into using public-key crypto. That allow you separate keys for encryption and decryption. So in webserver where users only input credit cards, you keep only public keys, so anybody cracking that won't be able to decrypt data. Also, if you only want to check if inputted credit card matches stored one, you don't need to store credit card at all, just store hash and then compare it with the hash of user-inputted one. For that it's preferable to use crypt() function with crypt-blowfish hash, which is couple of magnitudes stronger that MD5/SHA* for that purpose. > I'd welcome any comments or recommendations from others that have > implemented something similar. -- marko ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[GENERAL] pgcrypto: is an IV needed with pgp_sym_encrypt()?
I'm just starting with pgcrypto, and I'm curious if it's needed/recommended to use an initialization vector/value (IV) with the pgp_sym_encrypt() function. The docs hint that an IV is used automatically, but encrypting plain text that starts the same seems to result in initial common cipher text. So, I'm not clear. 2. Data is prefixed with block of random bytes. This is equal to using random IV. So, I'm currently generating a substring of a md5 hash of a few items and pre-pending that to the plain text I need to encrypt as the IV. Then when I decrypt I remove that prefix. BTW, this is for credit card storage, which is a business requirement. Besides following the PCI DSS and external audit procedures, the plan is to use pgcrypto (pgp_sym_encrypt() with AES-256) as part of a credit card storage server. The server and db are SSL only and the key is passed from the application and never stored anyplace (except in memcached on other servers during the session). The key is a user's plain text password plus an application-specific secret. So, each row has its own key. Passwords must be changed periodically, etc. I'd welcome any comments or recommendations from others that have implemented something similar. Thanks, -- Bill Moseley [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
