Adam, Thanks for answering.
On Thu, Nov 8, 2012 at 1:09 PM, Adam Back <[email protected]> wrote: > I'd guess they mean salt is pre-pended to the plaintext and then presume eg > then salt + plaintext encrypted with AES in CBC mode with a zero IV. That > would be approximately equivalent to encrypting with a random IV (presuming > the salt, IV and cipher block are all the same size) because > > CBC-Enc( iv = Enc( salt ), plain ) == CBC-Enc( iv = 0, salt || plain ) So what, if anything, do you think they might be using for padding? No padding at all? PKCS5 padding? Something else? > Now for indexing to set iv = 0 and salt = "" that might not be ideal as its > basically ECB for the first plaintext block. Particularly not good if the > plaintext is larger than the cipher block size and if there are repeats in > the first blocks worth of the plaintext. So for an SSN treated as a 9 char string (72-bits), for AES, that should not be a problem then since AES' block size is 128-bits, right? But would be a potential issue if used with 3DES since it's block size is only 64-bits. > 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. I agree that it's more secure. In particular, it's a lot easier to provide separation of duties and make it so that a DBA can't just dump the tables using SELECT, which I am pretty sure that they still could do with Oracle TDE. I was only considering it because it seemed like it was the easiest way to get from point A (plaintext SSNs) to point B (encrypted SSNs). Been trying to get that done for almost 2 yrs. They've been putting it off because of the supposed effort and using TDE should minimize their development effort. The question is whether TDE leaves us with acceptable risk, hence my attempt to better understand it. -kevin -- Blog: http://off-the-wall-security.blogspot.com/ "The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We *cause* accidents." -- Nathaniel Borenstein _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
