We have been using a different approach for securing particular fields in the database.
The main issue with symmetric ciphers inside (distributed) systems is that the encrypting entity is always the most numerous weak point. Whoever subverts your input flow - and there are lots of opportunities there - gets keys to everything. Your distributed system is not really distributed - it's mostly distributing vulnerabilities. However, if you use asymmetric crypto (say, 1024 or 2048-bit RSA), give only public key(s) to encrypting flows, and reserve the secret key(s) for modules that need the actual plaintext access (a rare situation in practice), then: - the storage size remains the same; - you can use the first 512 bits or so for indexing (you may get a collision once before the Universe cools down, or whatever your belief about the curvature is.) - there are no ECB issues (for field sizes < 1024 or 2048 bits, most are); - the extra CPU cost for modular arithmetic (to insert or search) is negligible (at least in use cases we've seen so far); - the security requirements on the input side drop down big time. You can (continue to) have bozos code your 'apps'. More philosophically, the database is just a wire with a delay. You would never directly use symmetric keys in other communications (by sharing them under the table), would you? --- On Thu, 11/8/12, Adam Back <a...@cypherspace.org> wrote: > IMO this fixed IV for searchability/indexability crypto pattern is a common > mistake. I prefer and consider it more secure to use a > (keyed) MAC of the > plaintext as the index, and then encrypt the plaintexts > conventionally with a random IV. _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
