From: Bruno Wolff III <bruno@wolff.to>
To: Daniel Struck <struck.d@retrovirology.lu>
Cc: Greg Stark <gsstark@mit.edu>
Cc: Mitch Pirtle <mitchy@spacemonkeylabs.com>
Cc: pgsql-php@postgresql.org
Subject: Re: [ADMIN] Secure DB Systems - How to
Date: Fri, 30 Jul 2004 10:30:49 -0500
Message-ID: <20040730153049.GA14646@wolff.to> (raw)
In-Reply-To: <20040730114331.38845c7f@gentoo>
References: <20040709152722.GA20935@wolff.to>
<20040713113557.31e9d6dc@localhost>
<20040713123817.GB3710@wolff.to>
<20040713151838.0004cb8e@localhost>
<40F3EC4A.1060101@spacemonkeylabs.com>
<20040727134133.676ab9cf@localhost>
<20040727194905.GA20499@wolff.to>
<87brhzsx9x.fsf@stark.xeocode.com>
<20040729180010.GA23523@wolff.to>
<20040730114331.38845c7f@gentoo>
On Fri, Jul 30, 2004 at 11:43:31 +0200,
Daniel Struck <struck.d@retrovirology.lu> wrote:
> > IVs act to make the key appear longer. This is especially useful when humans
> > are picking passphrases that are used to generate the key. If you control
> > what the actual keys are, then you can make dictionary attacks impractical.
> > However, there still would be the problem that identical items in the
> > database would be identical. Which, depnding on your application, might
> > be a problem because of information leakage.
I should have stated the above a bit differently. IVs are probably more used
to prevent the information leakage from have the same plain text encode
to the same cipher text when using the same, then for protecting users from
using poorly chosen keys.
> I don't think this is true for CBC mode. Here the first block of plaintext is XORed with the IV then encrypted with a block ciper like AES for example. The next plaintext block is than XORed with the previous cyphertext and so on.
In the context of records in a database you aren't (at least not normally)
going to treat multiple records as part of the same cipher stream, so that
using various types of block chaining over say a whole table isn't going to
happen.
> In my application I do use a different IV for every encrypted plaintext:
That is certainly a reasonable approach, though there may be cases where
it is useful to trade some information leakage for the ability to use
indexes while doing all decryption on the client.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: bruno@wolff.to, struck.d@retrovirology.lu, gsstark@mit.edu, mitchy@spacemonkeylabs.com, pgsql-php@postgresql.org
Subject: Re: [ADMIN] Secure DB Systems - How to
In-Reply-To: <20040730153049.GA14646@wolff.to>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox