Hi, I have an application where I want to be able to encrypt large amounts of text before storing them to my DB (MySQL Text field - might be switched to a Blob). I have an idea of how to do this, but was wondering what the general consensus is within the community regarding the issue. I have come across a couple different plug ins/gems (Stringbox, EzCrypto), but am wondering what other people are using. I like the idea of using Symmetric-key cryptography (and in particular, I would like to be using Twofish), and then probably encrypting the random password and IV for each encryption using a public key scheme. I guess I am wondering what other people''s response to such an approach is, and whether or not there are suggestions for other approaches. My main concern with the approach noted above is how to secure the private key used to encrypt the key and IV used to encrypt the actual text. I am also wondering if using Twofish is possible with a Rails app. From what I have seen in the openSSL documentation, only Blowfish - the predecessor to Twofish - is availble, or AES. Looking forward to hearing any feedback. Thanks, Simon
Hi Simon, the combination of symmetric and asymmetric encryption as used in Strongbox works and performs quite well for me. The author of Strongbox has explained in detail how to do this in his blog (http:// stuff-things.net/2008/02/05/encrypting-lots-of-sensitive-data-with- ruby-on-rails/). As far as I know, you don''t have to encrypt the IV, just the random password. In my app, every user has his own pair of keys and the private key is stored encrypted with the users password. This works fine, as long as strong passwords are selected. You can make it harder to brute force the key through password salting and stretching (http:// en.wikipedia.org/wiki/Key_strengthening). When a user is logged in, his password is sttored temprarily in the session cookie. To prevent cookie sniffing, you should use encryption for this as well. Throug this, the encryption and decryption works transparently in the background without the users even noticing. Sam
Simon wrote:> Hi, > > I have an application where I want to be able to encrypt large amounts > of text before storing them to my DB (MySQL Text field - might be > switched to a Blob). I have an idea of how to do this, but was > wondering what the general consensus is within the community regarding > the issue.You should probably use a blob field unless you also Base64 encode the encryption, which then would allow you to use a text field.> I have come across a couple different plug ins/gems (Stringbox, > EzCrypto), but am wondering what other people are using. I like theA lot of the UNIX based systems (including Mac OS X) have the OpenSSL library pre-installed. OpenSSL contains all the modern crypto functionality you should ever need for this. Checkout the Ruby OpenSSL support.> idea of using Symmetric-key cryptography (and in particular, I would > like to be using Twofish), and then probably encrypting the random > password and IV for each encryption using a public key scheme.Why Twofish when there exists the very popular AES (Rijndael algorithm) that is really fast and very strong? In any case you certainly want to use a symmetric algorithm. Public/Private key encryption is very slow and inefficient. Use public key encryption only to encrypt the keys for the symmetric algorithm, but then only if you have to trasmitt the keys over a public network. If all the encryption occurs server-side there is no need to encrypt any keys. Just use the same security mechanisms to protect your symmetric key(s) as you would for protecting a private key.> I guess I am wondering what other people''s response to such an > approach is, and whether or not there are suggestions for other > approaches. My main concern with the approach noted above is how to > secure the private key used to encrypt the key and IV used to encrypt > the actual text.Securing the private key is easy, NEVER let anyone else gain access to it. :) You just have to setup the security of the system so that there is no public access to whatever is storing your private keys.> I am also wondering if using Twofish is possible with a Rails app. > From what I have seen in the openSSL documentation, only Blowfish - > the predecessor to Twofish - is availble, or AES.Again AES is the algorithm I would choose. It''s the most advanced symmetric algorithm I''m aware of and is the one used in the SSL/TLS protocols. -- Posted via http://www.ruby-forum.com/.
Hi, Thanks for the responses. Sam, you mentioned that in your app, every user has his own pair of keys and the private key is stored encrypted with the users password. How many users does your system have? I was also considering trying to set something like this up, but I believe it will be far to much overhead for the number of users my system will have. As for limiting access to the private key (or password for that private key), I think that one good step here would be to store it seperately from both the application server and the database server. My concern here is that users will be requesting encrypted data fairly regularly, which means I will need to fetch the encrypted value from the DB, decrypt it, and provide the plaintext to the user (over an SSL connection). I am concerned about the type of overhead that retrieving the key/password from a remote server might be. Maybe this isn''t the right approach for what I need to accomplish. In more detail, what I want is to allow users to be able to flag certain content to be encrypted within the DB. The system will have many users (possibly tens of thousands) that will be able to request to see this content when they are logged in (which will require the encrypted content to be retrieved, decrypted, and presented to the user). Still trying to iron this out. Any more thoughts on the issue? Thanks again, Simon
> Sam, you mentioned that in your app, every user has his own pair of > keys and the private key is stored encrypted with the users password. > How many users does your system have? I was also considering trying > to set something like this up, but I believe it will be far to much > overhead for the number of users my system will have.My system might have potentially many thousand users. For me, this approach only makes sense, because every user is storing and sharing very sensitive information, that only a limited number of people may access.> Maybe this isn''t the right approach for what I need to accomplish. In > more detail, what I want is to allow users to be able to flag certain > content to be encrypted within the DB. The system will have many > users (possibly tens of thousands) that will be able to request to see > this content when they are logged in (which will require the encrypted > content to be retrieved, decrypted, and presented to the user).If all users may access the same information, then you could use a shared key for all users. You could then encrypt the single private key with each users password. One drawback with a shared key is, that if one user has a weak password, it might be very easy to compromise your data through brute forcing the key. Also it is not so easy to retract a compromised key. Assigning each user his own pair of keys gives you other advantages like ensuring Authenticity and Integrity of the stored information. Anyway: There is not a single solution, that fits all needs. It all depends, against what kind of threats you want to protect your data. And: I am not an encryption expert, just someone trying to solve a similar problem.