Clearly, this screams for a plugin; watch this space.

Well, it took a while and it turned out to be a gem, but Strongbox has arrived.

First a recap:

You have a web application and you need to encrypt the data your receive from your users. The most common form of encryption is symmetric-key encryption, where one password is used for both encryption and decryption. This works very well, but it means that everyone who enters data needs to know the password and everyone who knows the password can decrypt the data.

Enter Public-key cryptography which used one password (key) to encrypt and a different key to decrypt. This solves the problem; make the encryption password, the public key, available to your application, and keep the decryption password, the private key, well, private. Users don’t need to know or care how, they fill out a form and the data gets encrypted. One small problem, size. The most you can practically encrypt using this method is 245 bytes. Good enough for the launch codes, but not so for driving directions to the buried treasure.

No problem, if we have larger data, we simply combine the two. We generate a random password and use it to symmetrically encrypt to data. We then use the public key to encrypt the random password. To get the data back, the private key is used to decrypt the random password which is in turn used to decrypt the original data.

Got it? Good. Strongbox takes the above three paragraphs and reduces them to this:

class User < ActiveRecord::Base
  encrypt_with_public_key :secret,
                          :key_pair => 'path/to/keypair.pem'
end

>> @user = User.new
>> @user.secret = 'Ssssh'
>> @user.secret  # => "*encrypted*"
>> user.secret.decrypt ‘letmein’ # => "Ssssh"

OK, it’s sightly more complex. The column “secret” needs to exist in the database and be type “binary” (more on this in a bit). In additional, because we are using symmetric encryption (the default), we need two binary columns “secret_key” and “secret_iv” to store the generated symmetric key and Initialization vector (IV) (which you can think of as a second key (but it’s not) once they are encrypted with the public key.

If you are certain that the data you are encrypting won’t be larger than 245 bytes, you can use the following:

class User < ActiveRecord::Base
  encrypt_with_public_key :secret,
                          :key_pair => 'path/to/keypair.pem',
                          :symmetric => :never
  validates_length_of :secret, :maximum=> 245
end

This skips the symmetric encryption, is faster, and you only need the binary “secret” column.

You’ll also need to generate a key pair. Be sure to choose a strong pass phrase, as this is the one that will decrypt everything (as always, I suggest using Diceware).

% openssl genrsa -des3 -out private.pem 2048
Generating RSA private key, 2048 bit long modulus
......+++
.+++
e is 65537 (0x10001)
Enter pass phrase for key_pair.pem:
Verifying - Enter pass phrase for key_pair.pem:

If you aren’t going to be decrypting data on a regular basis you might want to deploy just the public key. Extract it:

mv key_pair.pem private.pem
openssl rsa -in private.pem -out public.pem -outform PEM -pubout
Enter pass phrase for private.pem:
writing RSA key

And change your model:

class User < ActiveRecord::Base
  encrypt_with_public_key :secret,
                          :public_key => 'path/to/public.pem'
                          :private_key => 'path/to/private.pem'
end

You could then have rake/Capistrano task to deploy and remove the private key as needed. Or you could limit it’s use to a separate, non-public, server.

As noted above you want your database column(s) to be binary. If your database does not have a binary type you can add the :base64 option:

class User < ActiveRecord::Base
  encrypt_with_public_key :secret,
                          :key_pair => 'path/to/keypair.pem',
                          :base64 => :true
end

This will convert the binary data to text using Base64. You must, must make your column type “text”. Base64 increases the length of the data it encodes by approximately 137%. Type “string” is typically 256 bytes, 245 * 1.37 = 335.65 bytes. If you use a “string” column and encrypt anything greater than 186 bytes your data will be lost.

Finally, there are two addition options for tweaking the encryption settings that you are unlikely to need:

“:symmetric_cipher” lets you change the algorithm that’s used for symmetric encryption. The default is 256 bit Advanced Encryption Standard (AES) using Cipher Block Chaining (CBC) (‘aes-256-cbc’ in OpenSSL terms). AES has been approved by the NSA for top secret information, so it’s probably good enough, but Blowfish (‘bf-cbc’) is know to work as well. Other ciphers in CBC mode should also work, but have not been tested by me. (Note that all ciphers may not be supported by your version of OpenSSL, “openssl list-cipher-commands” will provide a list.)

“:padding” allows you to change the method used to pad data encrypted with the public key. Unless you are working with legacy data, you shouldn’t need to change this. The default is “RSA_PKCS1_PADDING”, see the code if you need other options.

Disclaimer

I am not a security expert. This software using an off the shelf encryption tool, namely OpenSSL, that has been well tested, but that is not a guarantee that this implementation doesn’t have weakness. Be sure you understand what Strongbox does, and review it for your application. A few things to keep in mind:

• Strongbox encrypts the data as it is saved, but no sooner. Be sure to use HTTPS for submitting the forms (and decrypting data!).
• If an attacker gains entry to your system the encryption should protect your data. However, they might be able to hack your code to intercept new data or, much worse, your private key password. Protect your server.
• When decrypting make sure your data isn’t cached.

And test, test, test. If there is a problem with how your data is encrypted, there is no getting it back.

One concern I have is garbage collection. If you decrypt something into a variable which then goes out of scope, how long does it hang around in memory? Can you force it out? I haven’t found much information on this; if there are any Ruby GC experts out there, share your knowledge!

I am always open to suggestions and improvement, but, to quote the License:

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY
KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE
WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF
CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS IN THE SOFTWARE.

So there!

Finally, I’d like to give a shout-out to thoughtbot. While this software has existed for many years, the final form of the gem was greatly inspired by Paperclip. It’s a nice example of an approach to adding complex features to an ActiveRecord attribute and how to test them. In additional, the gem sat unpublished for nearly a year because it needed test coverage and my testing was week. Then I took thoughtbot’s Advanced Ruby on Rails class which really helped me get my head around testing and TDD, and got this moving again. If you know Rails, but need to improve your processes, I highly recommend this class.

Prior to Rails 2.0, ActiveRecord will always generate an SQL UPDATE statement that includes all of the attributes in the model, even if they hadn’t changed.

product = Product.find(:first)
=> #<Product:0x23a7d00 @attributes={"name"=>"Product", "description"=>"Lorem ipsum",  "price"=>"9.99", "sku" => "000001"}>
# Inflation
product.price += 1.00.to_d # You're not using floats for prices, are you?
product.save

=> UPDATE products SET `price` = '10.99', `available` = 1, `description` = 'Lorem ipsum',  `name` = 'Product', `sku` = '000001' WHERE `id` = 1

If “sku” happens to be read-only, the update will fail, and so will your app.

The right way to fix this is to upgrade to Rails 2.x. Starting 2.0 you can use attr_readonly which (silently) removes the attribute from the UPDATE statement.

attr_readonly :sku
product = Product.find(:first)
=> #<Product:0x23a7d00 @attributes={"name"=>"Product", "description"=>"Lorem ipsum",  "price"=>"9.99", "sku" => "000001"}>
product.price += 1.00.to_d
product.save

=> UPDATE products SET `price` = '10.99', `available` = 1, `description` = 'Lorem ipsum',  `name` = 'Product' WHERE `id` = 1

And, starting with 2.1, ActiveRecord only updates attributes that have been changed. As long as you don’t change the value of an attribute, it won’t be included in the UPDATE statement.

product = Product.find(:first)
=> #<Product:0x23a7d00 @attributes={"name"=>"Product", "description"=>"Lorem ipsum",  "price"=>"9.99", "sku" => "000001"}>
product.price  += 1.00.to_d
product.save

=> UPDATE `products` SET `price` = '10.99'  WHERE `id` = 1

(Obviously, it’s better to explicitly mark an attribute as read-only then to depend on this behavior.)

But, what if you are working with a pre 2.X version of Rail? As I said above, ActiveRecord generates the UPDATE statement based on the attributes in the model. The trick, or should I say ugly hack, is to load the record with only the fields you want to update using :select. This way, when the UPDATE is generate it will only include those attributes that were loaded into the record.

product = Product.find(:first, :select => 'id, name, price')
=> #<Product:0x23a7d00 @attributes={"name"=>"Product", "price"=>"9.99", "id"=>"1"}>
product.price  += 1.00.to_d
product.save

=> UPDATE `products` SET `price` = '10.99',   `name` = 'Product' WHERE `id` = 1

When doing this, you need to include the “id” column (or whatever your primary key is) in the select. Also note that while this will work with find_by_ methods, find_or_initialize_by_ methods do not take the :select option.

Yup, it’s ugly but, it does, in fact, work.

For example:

class ProductImage  < ActiveRecord::Base
  belongs_to :product
  has_attachment :content_type => :image,
                 :storage => :file_system,
                 :path_prefix => '/public/images/products/',
                 :resize_to => '300',
                 :thumbnails => {:thumb => '75x75' }

  validates_as_attachment
end

The above will take an image, resize it to 300 pixels wide (automatically adjusting the height to preserve the original images aspect ratio), and to 75 by 75 pixels for a thumbnail, and save resulting images. Combined with a Product model that has_one :image, or has_many :images, and the right form, you can easily manage your product images.

However, an image with both a fixed width, and fixed height, like our thumbnail, can be a problem. If the original, and resized image do not have the same aspect ratio the resized image will be distorted. In this case, if the original is not square, our thumbnail will be look squished in which ever dimension was longer originally. This is not a problem for the main image because we let the height be calculated automatically.

Fortunately, there is a simple trick that allows us to override the method attachment_fu uses to resize image and manipulate it ourselves. Add the following to the ProductImage model:

  protected

  # Override image resizing method
  def resize_image(img, size)
    # resize_image take size in a number of formats, we just want
    # Strings in the form of "crop: WxH"
    if (size.is_a?(String) && size =~ /^crop: (\\d*)x(\\d*)/i) ||
        (size.is_a?(Array) && size.first.is_a?(String) &&
          size.first =~ /^crop: (\\d*)x(\\d*)/i)
      img.crop_resized!($1.to_i, $2.to_i)
      # We need to save the resized image in the same way the
      # orignal does.
      self.temp_path = write_to_temp_file(img.to_blob)
    else
      super # Otherwise let attachment_fu handle it
    end
  end

and change the thumbnail size to:

:thumbnails => {:thumb => 'crop: 75x75' }

Now, if the image size starts with ‘crop: ‘, the image will be resized and then cropped to fit. Otherwise, it’s passed on to attachment_fu and handed normally. I’m using the RMagic crop_resized! method, which resize the image using the smaller dimension and then crops the large one to fit. If you are using minimagick, or ImageScience you may need to fiddle a bit with the code. Obviously, you can extend this approach to manipulate the image anyway you see fit. For example you could automatically put a border on the images:

  def resize_image(img, size)
    # Add a 2x2 red border and pass the image to attachment_fu
    img.border!(2,2,'red')
    super
  end

Or blur them:

  def resize_image(img, size)
    img = img.blur_image
    super # Pass the blured image to attachment_fu
  end

Or any other weirdness your heart desires. Have fun!