This is a lightweight, fast implementation of AES (the US government’s Advanced Encryption Standard, aka “Rijndael”), written in C for speed. You can read more on the Wikipedia AES Page. The algorithm itself was extracted from work by Christophe Devine for the open source Netcat clone sbd. According to the community, this is a very high performance AES implementation:

> With some exceptions your code performs better than all others in 
> enc[ryption]/dec[ryption]. Do you have an explanation of that fact? Thanks. 
>
Well, I've tried to make the code as simple and straightforward as 
possible; I also used a few basic tricks, like loop unrolling.

This gem supports the most important features of AES, specifically:

• 128, 192, and 256-bit ciphers

• Electronic Codebook (ECB) mode only - see Security Note

• Encrypted blocks are padded at 16-bit boundaries (read more on padding)

You can read specifics about AES-ECB in the IPSec-related RFC 3602, if you really care that much.

Bottom line, this gem works. Fast.

I couldn’t find any that worked worth a crap. The ruby-aes project has Ruby 1.9 bugs that have been open over two years now, crypt/rijndael doesn’t work on Ruby 1.9 and is sloooow (as it’s written in Ruby), and some people even report getting inconsistent encryption results from other libraries.

So I grabbed some C reference code off the googles, wrapped a Ruby interface around it, and voíla.

gem install fast-aes

Simple encryption/decryption:

require 'fast-aes'

# key can be 128, 192, or 256 bits
key = '42#3b%c$dxyT,7a5=+5fUI3fa7352&^:'

aes = FastAES.new(key)

text = "Hey there, how are you?"

data = aes.encrypt(text)

puts aes.decrypt(data)   # "Hey there, how are you?"

Pretty simple, jah?

I’m going to guess you’re using Ruby with Rails, which means you’re doing 90+% web development. In that case, if you need security, SSL is the obvious choice (and the right one).

But there will probably come a time, padawan, when you need a couple backend servers to talk - maybe job servers, or an admin port, or whatever. Maybe even a simple chat server.

You can setup SSL certificates for this if you want it to be time-consuming to maintain. Or you can directly use an encryption algorithm, such as AES. Setting up an SSH tunnel is another good alternative, if you control both systems. I think it’s easier to configure encryption keys as part of your application, rather than having to mess with each individual system, but that’s me.

For more information on how SSL/AES/RC4/TLS all interact, read this article on SSL and AES

There are a bizillion (literally!) different encryption standards out there. If you have a PhD, and can’t find a job, writing an encryption algorithm is a good thing to put on your resume - on the outside chance that someone will hire you and use it. If you don’t possess the talent to write an encryption standard, you can spend hours trying to crack one - for similar reasons. As a result, of the many encryption alternatives, most are either (a) cracked or (b) covered by patents.

Personally, when it comes to encryption, I think choosing what the US government chooses is a decent choice. They tend to be “security conscious.”

As this software deals with encryption/decryption, please note there is NO WARRANTY, not even with regards to FITNESS FOR A PARTICULAR PURPOSE or NONINFRINGEMENT. This means if you use this library, and it turns out there’s a flaw in the implementation that results in your data being hacked, IT IS NOT MY FAULT. It’s YOUR responsibility to check the implementation of this library and algorithm. If you can’t understand C code, that’s NOT MY PROBLEM.

A little while back a github issue tracker was filed noticing that this gem supports ECB and not the (significantly) more secure CBC method. You can read more details on Wikipedia’s ECB writeup. From the article:

The disadvantage of this method is that identical plaintext blocks are encrypted into
identical ciphertext blocks; thus, it does not hide data patterns well. In some senses,
it doesn't provide serious message confidentiality, and it is not recommended for use in
cryptographic protocols at all.

I’ll be honest: I’m not a security expert, and I don’t use this for anything top secret. If you’re concerned about serious security, you need take responsibility for verifying whether this gem meets your requirements.

Original AES C reference code by Christophe Devine. Thanks Christophe!

This gem copyright © 2010-2011 Nate Wiger. Released under the MIT License.

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

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.