On 9/18/07, Bill Moseley <moseley@xxxxxxxx> 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
