[cryptography] Questions about crypto in Oracle TDE

Adam Back adam at cypherspace.org
Thu Nov 8 13:09:22 EST 2012


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 )

PGP when using IDEA (PGP uses CFB mode for IDEA) does something similar.. 
there is a zero IV and a randomish first plaintext block.


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.


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.

Adam

On Thu, Nov 08, 2012 at 11:49:42AM -0500, Kevin W. Wall wrote:
>All,
>
>I'm hoping someone on this list can either provide details on how
>Oracle's "Transparent Data Encryption" (TDE) works in their Oracle Database,
>especially with Oracle 10g.
>
>We have an application that is storing SSNs as cleartext which they are
>finally getting read to store in an encrypted format using 128-bit AES. (I am
>not sure if the SSNs are presently stored as NUMBER or VARCHAR2 though.)
>The application also will *still* have a legitimate business need of doing
>indexed searches via the *full* SSN.
>
>Oracle TDE is being looked at as oneoption because it is thought to be
>more or less transparent to application itself and its JDBC code. Also,
>presumably it would simplify key change operations as well since the
>development team wouldn't have to code for that.
>
>The Oracle TDE documentation (here for 10g:
>http://docs.oracle.com/cd/B19306_01/network.102/b14268/asotrans.htm)
>discusses the use of "salt" in section 3.2.4. Specifically, this documentation
>states:
>
>    "Salt is a way to strengthen the security of encrypted data.
>    It is a random string added to the data before it is encrypted,
>    causing repetition of text in the clear to appear different when
>    encryptee. Salt thus removes one method attackers use to steal data,
>    namely, matching patterns of encrypted text."
>
>Salting is the TDE default for encrypted columns (at least in 10g).  However,
>this documentation goes on to say:
>
>    "However, if you plan to index the encrypted column, you must
>    use NO SALT."
>
>Doing searches by full SSN over close to a 1M records is obviously going
>to need indexing, so that implies that salting cannot be used for SSNs
>(at least not w/out application changes, to say, search for a MAC of the
>SSN instead of the SSN itself, or some other similar mechanism).
>
>My confusion comes from trying to understand exactly what Oracle means
>when they refer to "salt". Are they really discussing the use of
>a random IV vs. a fixed IV? Or are the XOR'ing some random salt with
>the encryption key in some cases and not in others or what?
>
>For that matter, does anyone even know what cipher modes or padding
>schemes they use with Oracle TDE in Oracle 10g? For all I know they
>may be doing something like using ECB mode.
>
>It's hard to ascertain the downside of using Oracle TDE if I don't know
>any of these details so I'm hoping that someone on this list can
>comment on it.
>
>Thanks,
>-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
>cryptography at randombit.net
>http://lists.randombit.net/mailman/listinfo/cryptography



More information about the cryptography mailing list