Encryption speed

freebie

Hi,
I was wondering if anyone could tell me if using the mcrypt functions impede processing time to any noticeable amount (i know this depends on processor speed, the algorithm used, and the amount of data being encrypted).

What I'm thinking of doing involves encrypting information for about 15-25 columns (some short - normally VARCHAR( 80 ) for instance, and probably 5 or so that would have on average about 300 - 400 chars in a TEXT column) before inserting into a mysql database using one of the algorithms provided with mcrypt. The processor is 1 Gh. OS is redhat 9. The time it takes to encrypt is not the concern, but rather the time it takes to decrypt it when website users are browsing the information.

Which algorithm is considered pretty fast? I don't need the "ultimate" encryption, just something reasonably good and hopefully fairly fast.

Should the key chosen for these be a really long key, or is ok to use something relatively short like "php343mysql92215912". Will the key size affect the encryption/decryption speed?

Also, does anyone know if TEXT columns must be used for this purpose, or is it ok if varchar columns are used in cases where there might only be 20 -30 characters (I'd put the varchar size at 150 to since the length of the encrypted text will be bloated).

Thanks for any thoughts.

rrijnders

Well, if you are going encrypt the data in your DB, you may be better off using native mySQL encryption/decryption rather than doing the encoding and decoding in the scripting language (PHP).

As general rules go:

3DES is stronger while Blowfish is faster; AES is a good compromise IMHO.
The size of your key does have an impact on encryption/decryption speed; exponentially so, but don't confuse the key size with the length of the passphrase you select, they are not the same thing!. If you choose to use a 128 bit key, that does not mean that you have to pick a passphrase that is exactly 16 characters long. If your passphrase is "DOG" the key will still be 128 bits! So the size of the key matters, not the size of your passphrase (why does that sound kinky to me?).

freebie

Thanks rrijnders,
That does help clear up things a good bit.
The reason I'm encrypting within PHP is because my client wants a real secure solution and having it encrypted before it gets passed to mysql is more secure (since if someone had obtained root access, they would be able to sniff packets going into mysql). The PHP itself will be encoded with the Zend Encoder to keep the code from being readable, and the admin will be in a SSL secured domain.

The algorithm doesn't need to be super good. I'm sure 128 bit encryption will work just fine. My client doesn't want speed to be affected to any real noticeable amount by the encrypting/decrypting, so I guess blowfish would be the method of choice. Thanks for clearing up the passphrase length question.

freebie

For anyone who's interested, I found this code on the onlamp.com website. I tested and it's pretty darn fast. Granted it's only encrypting/decrypting one string, but I'm convinced that it's going to be fast enough. It's using Rijndael 128

<?php

// Designate string to be encrypted
$string = "Applied Cryptography, by Bruce Schneier, is 
a wonderful cryptography reference.";

// Encryption/decryption key
$key = "Four score and twenty years ago";

// Encryption Algorithm
$cipher_alg = MCRYPT_RIJNDAEL_128;

// Create the initialization vector for added security.
$iv = mcrypt_create_iv(mcrypt_get_iv_size($cipher_alg, 
MCRYPT_MODE_ECB), MCRYPT_RAND);

// Output original string
print "Original string: $string <p>";

// Encrypt $string
$encrypted_string = mcrypt_encrypt($cipher_alg, $key, 
$string, MCRYPT_MODE_CBC, $iv);

// Convert to hexadecimal and output to browser
print "Encrypted string: ".bin2hex($encrypted_string)."<p>";

$decrypted_string = mcrypt_decrypt($cipher_alg, $key, 
$encrypted_string, MCRYPT_MODE_CBC, $iv);

print "Decrypted string: $decrypted_string";

?>

-- My one last question on this is:
does anyone know if bin2hex should be called before inserting into the database. I assume it doesn't with TEXT fields, but would it with VARCHAR fields?
Some of my fields will only have 30 or so characters and I feel I would probably be OK using varchar 200 for these if that's possible rather than having all TEXT fields (thinking in terms of varchar probably performing better than TEXT fields for those small value columns)

Thanks