CODEWITHSUNDEEP
phpmysqlencryptionlaravel-4
TH1981
TH1981

Reputation: 3193

Laravel 4 Encryption: how many characters to expect

I've just had an interesting little problem.

Using Laravel 4, I encrypt some entries before adding them to a db, including email address.

The db was setup with the default varchar length of 255.

I've just had an entry that encrypted to 309 characters, blowing up the encryption by cutting off the last 50-odd characters in the db.

I've (temporarily) fixed this by simply increasing the varchar length to 500, which should - in theory - cover me from this, but I want to be sure.

I'm not sure how the encryption works, but is there a way to tell what maximum character length to expect from the encrypt output for the sake of setting my database?

Should I change my field type from varchar to something else to ensure this doesn't happen again?

Upvotes: 3

Views: 3004

Answers (2)

lukasgeiter
lukasgeiter

Reputation: 153070

@MaartenBodewes' does a very good job at explaining how long the actual string probably will be. However you can never know it for sure, so here are two options to deal with the situation.

1. Make your field text

Change the field from a limited varchar to an "self-expanding" text. This is probably the simpler one, and especially if you expect rather long input I'd definitely recommend this.

2. Just make your varchar longer

As you did already, make your varchar longer depending on what input length you expect/allow. I'd multiply by a factor of 5.

But don't stop there! Add a check in your code to make sure the data doesn't get truncated:

$encrypted = Crypt::encrypt($input);
if(strlen($encrypted) > 500){
   // do something about it
}

What can you do about it?

You could either write an error to the log and add the encrypted data (so you can manually re-insert it after you extended the length of your DB field)

Log::error('An encrypted value was too long for the DB field xy. Length: '.strlen($encrypted).' Data: '.$encrypted);

Obviously that means you have to check the logs frequently (or send them to you by mail) and also that the user could encounter errors while using the application because of the incorrect data in your DB.

The other way would be to throw an exception (and display an error to the user) and of course also write it to the log so you can fix it...

Anyways

Whether you choose option 1 or 2 you should always restrict the accepted length of your input fields. Server side and client side.

Upvotes: 5

Maarten Bodewes
Maarten Bodewes

Reputation: 94038

Conclusion

First, be warned that there has been quite a few changes between 4.0.0 and 4.2.16 (which seems to be the latest version).

The scheme starts with a staggering overhead of 188 characters for 4.2 and about 244 for 4.0 (given that I did not forget any newlines and such). So to be safe you will probably need in the order of 200 characters for 4.2 and 256 characters for 4.0 plus 1.8 times the plain text size, if the characters in the plaintext are encoded as single bytes.

Analysis

I just looked into the source code of Laravel 4.0 and Laravel 4.2 with regards to this function. Lets get into the size first:

  1. the data is serialized, so the encryption size depends on the size of the type of the value (which is probably a string);
  2. the serialized data is PKCS#7 padded using Rijndael 256 or AES, so that means adding 1 to 32 bytes or 1 to 16 bytes - depending on the use of 4.0 or 4.2;
  3. this data is encrypted with the key and an IV;
  4. both the ciphertext and IV are separately converted to base64;
  5. a HMAC using SHA-256 over the base64 encoded ciphertext is calculated, returning a lowercase hex string of 64 bytes
  6. then the ciphertext consists of base64_encode(json_encode(compact('iv', 'value', 'mac'))) (where the value is the base 64 ciphertext and mac is the HMAC value, of course).

A string in PHP is serialized as s:<i>:"<s>"; where <i> is the size of the string, and <s> is the string (I'm presuming PHP platform encoding here with regards to the size). Note that I'm not 100% sure that Laravel doesn't use any wrapping around the string value, maybe somebody could clear that up for me.

Calculation

All in all, everything depends quite a lot on character encoding, and it would be rather dangerous for me to make a good estimation. Lets assume a 1:1 relation between byte and character for now (e.g. US-ASCII):

  1. serialization adds up to 9 characters for strings up to 999 characters
  2. padding adds up to 16 or 32 bytes, which we assume are characters too
  3. encryption keeps data the same size
  4. base64 in PHP creates ceil(len / 3) * 4 characters - but lets simplify that to (len * 4) / 3 + 4, the base 64 encoded IV is 44 characters
  5. the full HMAC is 64 characters
  6. the JSON encoding adds 3*5 characters for quotes and colons, plus 4 characters for braces and comma's around them, totaling 19 characters (I'm presuming json_encode does not end with a white space here, base 64 again adds the same overhead

OK, so I'm getting a bit tired here, but you can see it at least twice expands the plaintext with base64 encoding. In the end it's a scheme that adds quite a lot of overhead; they could just have used base64(IV|ciphertext|mac) to seriously cut down on overhead.

Notes

  • if you're not on 4.2 now, I would seriously consider upgrading to the latest version because 4.2 fixes quite a lot of security issues
  • the sample code uses a string as key, and it is unclear if it is easy to use bytes instead;
  • the documentation does warn against key sizes other than the Rijndael defaults, but forgets to mention string encoding issues;
  • padding is always performed, even if CTR mode is used, which kind of defeats the purpose;
  • Laravel pads using PKCS#7 padding, but as the serialization always seems to end with ;, that was not really necessary;
  • it's a nice thing to see authenticated encryption being used for database encryption (the IV wasn't used, fixed in 4.2).

Upvotes: 7

Related Questions