The library is written as a sample code that can be used without any significant modifications to the code. It also includes some code that show some ideas on how it can be used in your application.

The library has the following features:
  • A header for the cryptosystem that includes:
    • Versioning, so you can update the library anytime to make improvements by bumping up the version number.
    • Algorithm(s) being used for crypto agility
    • Key ID – in order to support multiple keys
  • Support for two AES mode of operation; CBC (with HMAC for data integrity) & GCM.
GCM support thanks to the usage of CLR Security library, which is available through Codeplex http://clrsecurity.codeplex.com/.
NOTE; If you decide to not use the CLR Security library, it should be very easy to exclude the class that makes use of it, and simply use the CBC class instead.
  • Integrity verification that includes protection against row-swapping by binding the authentication verification to another column, typically a primary key.
  • Ability to define behavior for decryption failure (i.e. invalid key, corrupted data, etc.): throw exception or return null.

The usage example application includes code that show scenarios for the following areas:
  • A simple schema that has customers & orders tables, which contain sensitive data in plaintext that we want to protect.
  • Derive a key from a password – As the sample code has no real key management support, I decided to show an alternative by using a password derived key.
  • Modifying the schema & encrypting all existing data
  • Inserting new rows
  • Selecting data
    • All rows
    • Find a single row based on an equality lookup on an encrypted column (via HMAC)
    • Find one or more rows based on a scan on an encrypted column (no HMAC)
    • Find one or more rows based on a scan on an encrypted column (no HMAC)
  • Failure to decrypt data after a row-swapping attack.
  • Key rotation.

(09/23/2014)
Added support for ECB mode. I restricted the plaintext to 15 bytes in order to make sure that only one block will result from encrypting data and avoid block-manipulation-based attacks.
This mode may be useful for some scenarios where having two separate columns for the index & the encrypted data is not possible/desirable, and where data integrity is controlled without the need to have integrity verification.

NOTE: For ECB I didn't included any integrity verification as it is likely to be used as a primary key. In the usage example I mixed using ECB for the SSN column & CBC/GCM for the e-mail column (using the encrypted SSN column for integrity verification).

Last edited Sep 23, 2014 at 11:36 PM by raulga, version 5