John R Pierce <pierce@hogranch.com> wrote:
>
> Eric Soroos wrote:
> >> an index on the encrypted SSN field would do this just fine. if
> >> authorized person needs to find the record with a specific SSN, they
> >> encrypt that SSN and then look up the ciphertext in the database...
> >> done.
> >
> > This will only work for e(lectronic?) code book ciphers, and not
> > chained block ciphers, since the initialization vector will randomize
> > the output of the encryption so that E(foo) != E(foo) just to prevent
> > this sort of attack.
>
> can those sorts of chained block ciphers decode blocks in a different
> order than they were originally encoded? for this sort of
> application, wouldn't each field or record pretty much have to be
> encrypted discretely so that they can be decrypted in any order, or any
> single record be decrypted on its own?
Eric is right about CBC ciphers. The problem is that any function that
will produce the same output for the same input (such as md5 or sha) leaves
us open to brute force attacks if the number of choices is small, or
pattern discovery attacks in other cases. And anything that protects
us against such attacks (such as aes-cbc) will generate data that I
can't pre-encrypt and search against.
I haven't tried it, but I don't believe CBC ciphers can decrypt data out
of order.
In the implementation I've built, the IV is stored with the ciphertext,
much the same way that crypt() stores the salt with the password hash.
As a result, if you have the key, you then have all the data required
to decrypt the field, but you can't easily brute force it or do any
pattern analysis.
--
Bill Moran
http://www.potentialtech.com