Kevin W. Wall wrote:
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
... along the same line of thoughts as Ian G, I guess ...
I was exposed to this requirement a few years ago (the regulatory
mandate to encrypt SSN -- social security numbers -- in the database but
still maintain index searches).
I quickly guessed the requirement originated from a misunderstanding of
cryptography "laws of physics." You just can't have your cake and eat
it. You just can't encrypt a data field and use it as if in cleartext.
Moreover, if you want any incremental security, you want your attacker
determined-enough-to-copy-the-database-contents to be isolated from the
decryption key. In the requirement, nothing points to how this
incremental security is gained (e.g. one can imagine that encrypted
backups are kept separate from the backup decryption key and bingo you
get some auditors points). Will you put an HSM to do the index
decryption in order to prevent malignant host code from accessing SSN in
the clear?
I guess the requirement originates from auditors with the expectation
that if you have AES so-many-bits you get X bonus points, without paying
attention to key management.
In short, not a use case for good crypto protections no matter what. So,
I agree with "the easiest way to get from point A to point B."
Application-level security breaches deserves application-level
countermeasures. IT security is a hindrance.
Regards,
--
- Thierry Moreau
CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, QC, Canada H2M 2A1
Tel. +1-514-385-5691
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
