Thread: 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
moseley@hank.org

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

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
moseley@hank.org