Re: Hashed hash

Ben.Goren@asu.edu foolishly says:
>I'm planning on implementing the "cryptographic protection of databases"

And wonders about the hash being too fast to compute, that a
brute-force traversal of the database would be too easy.  The idea is
then to hash a bunch of times to burn CPU cycles, but what if the hash
is a group, extra hashing could be reversed quickly.  (Did I get that
right?)


Well, as the LOUD proponent of making secret keys s-l-o-w-e-r to
decrypt, I have thought about this a bit, and have a suggestion:

Hash once, then do a zillion encryptions of the hash with a non-group
cypher like DES.  

Another idea (something I have thought less about): send every legit
user of the database a custom version with the parts encrypted with
that user's public key--and do the trick mailing list companies use,
scatter some dummy info in the list.  When a dummy (not just me) gets
a junk mailing, go beat up on the user who's copy had to have supplied
the junk.  Not perfect: combinations of dummies are needed in case the
junk mailer cracks multiple copies (multiple work) and then trys to
sift unique dummies that way.  Another problem: it is expensive to
monitor the dummies.  (1990's biz opportunity?, the monitoring of data
that no one is supposed to have.)


-kb, the Kent who doesn't want to be thought of as only a card player


--
Kent Borg                                                  +1 (617) 776-6899
kentborg@world.std.com                                
kentborg@aol.com                                      
          Proud to claim 35:00 hours of TV viewing so far in 1994!

On Sun, 17 Jul 1994, Kent Borg wrote:
> sift unique dummies that way.  Another problem: it is expensive to
> monitor the dummies.  (1990's biz opportunity?, the monitoring of data
> that no one is supposed to have.)
Well, you can pass the expense on to the company that is doing the 
mailing, by making the ratio of the dummies to the real ones about 10 to 1.

Roger.