3

I've been extensively using Rijndael 256bit encryption in PHP for my API and would like to use it for my API wrapper that is written in JavaScript as well, but I've been unable to find a solution that gets the same result as in PHP.

By what PHP does I mean the following:

base64_encode(mcrypt_encrypt(MCRYPT_RIJNDAEL_256,$password,$secretInformation,MCRYPT_MODE_CBC,$iv));

and

base64_encode(mcrypt_encrypt(MCRYPT_RIJNDAEL_256,$password,$secretInformation,MCRYPT_MODE_EBC));

.. as well as the decryption variants.

I know that the many 256bit AES libraries don't get the same result that PHP does with its Rijndael 256bit encryption, thus I'm wondering if there is a library that is able to do what PHP does in the examples above?

Thanks!

kingmaple
  • 4,200
  • 5
  • 32
  • 44
  • 1
    This would expose your password to the user, making the encryption not very useful... – Dagg Nabbit Apr 08 '12 at 21:25
  • Why do you post such a link Grumpy? It's not on topic. – Maarten Bodewes Apr 08 '12 at 21:38
  • @GGG It does not matter, password is 'exposed' no matter what (even your Facebook login is exposed, even if you use HTTPS, if the listener has access to your computer). The idea is to make it possible for JavaScript to deal with encrypted data by first sharing the key and then unlocking data with that key as long as the session is open. I could do it by making a request to the server and then having the server communicate with target server through PHP, but that is much slower than a direct request. This is also useful when no session data is stored on server at all other than the key. – kingmaple Apr 08 '12 at 22:17
  • @kristovaher maybe I'm misunderstanding you, but I don't see how the password is exposed in the pure PHP solution. But yeah, if you change the password or the init vector with each session it should be okay... – Dagg Nabbit Apr 08 '12 at 22:21
  • Pure PHP is obviously a better solution, but I need to keep performance in mind as well. It would take twice as many requests if I will have browser contact Sever A that contacts server B that returns data to Server A that returns data to browser instead of having browser communicate with Server B directly. But apparently there really doesn't seem to be a Rijndael 256bit encryption library for JavaScript that does it the way PHP does, so I guess I'll either try writing it or letting it go :) – kingmaple Apr 08 '12 at 22:45
  • do you mean AES? There's plenty of libraries for that, just Google it. – gengkev Apr 09 '12 at 03:15
  • No, PHP's Rijndael 256bit encryption is a little different from AES, Rijndael initialization vector is in a different size compared to AES, for example. – kingmaple Apr 09 '12 at 05:54
  • how did you encrypted in client side ... check out my issue please http://stackoverflow.com/questions/18786025/why-encrypted-string-given-by-mcrypt-js-library-and-php-is-different – hsuk Sep 16 '13 at 06:00

1 Answers1

1

MCRYPT_RIJNDAEL_256 is not AES with a 256 bit key, its basically "AES" with a 256 bit block size( AES normally has a 128 bit block size). Rinjdael had a bunch of options and was standardized into AES by reduces those options to just the 128 or 256 bit key size. As such, must libraries support the standard (AES) and not the prototype.

If you want AES 256 or 128 , which is what almost all libraries actually support, use MCRYPT_RIJNDAEL_128 with a 128 bit or 256 bit key. The difference in block size doesn't really make much of a difference security wise .

Also, using a raw password as a key is a really really bad idea. You get keys from a password by using a password based key derivation function like PBKDF2.

imichaelmiers
  • 3,449
  • 2
  • 19
  • 25
  • Could you believe it that I just checked if this question has answers last night and found none? As for the password, why is it a bad idea? It needs to be a random string, correct? So why would md5() hashing with salt over the password be a bad idea? – kingmaple May 03 '12 at 05:42
  • I'll accept this as an answer though, since it gives me better understanding over the issue at hand, despite there not really being a solution I was looking for. – kingmaple May 03 '12 at 05:42
  • Originally I thought you were just putting in the password. However, md5 is not the best idea either md5() gets you a random string, but md5,sha1,sha512 and the like are very fast functions to compute. if your users use a somewhat common password, its really easy it just test a large number of guesses ( you can do 2300 million sha1 sums a second on a GPU). So in stead you use something that is slow, not slow enough to slow your program down, but slow enough to slow someone down who is just guessing passwords offline on a copy of the encrypted data they got.Hence use PBKDF2 – imichaelmiers May 03 '12 at 06:03
  • I think you're going a bit for an overkill here. First of all, I said that the MD5 is generated from password that is also salted, so this already disables majority of what you are implying. And let's not forget that IV is also entirely computer generated and known only for these two systems, so person trying to break in would also have to know the IV. (Of course IV is not used on EBC mode, which is where the salted password comes in handy). – kingmaple May 03 '12 at 06:15