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!