|
mcrypt_generic
This function encrypts data
(PHP 4 >= 4.0.2, PHP 5)
Code Examples / Notes » mcrypt_genericryan thomas, ryanrst
If you wish to store encrypted data in a cookie variable on the browser you will encounter problems when decrypting the data. This is because cookies will only store US-ASCII characters and your encrypted data may contain non-US-ASCII characters. The solution: base64_encode your encrypted string before you store it in the cookie and base64_decode the string stored in the cookie becore decrypting. Example: function setEncryptedCookie($cookieName, $data) { setcookie($cookieName, base64_encode($this->encrypt($data)), time()+$this->expire); } function getEncryptedCookie($cookieName) { return $this->decrypt(base64_decode($_COOKIE[$cookieName])); } pauls
If you are encrypting binary and there is a null terminator partway through your encryption, you will loose the rest of the string. A workaround is to base64_encode your binary string first. We found this problem while trying to encrypt CC information. Some CC values would not decrypt after we converted them to a binary string. We were using the MCRYPT_RIJNDAEL_256 module to encrypt with. Hope this helps someone. chad 0x40 herballure 0x2e com
If the data is already n*blocksize long, PHP pads with another full block of "\0", so there will be between 1 and mcrypt_enc_get_block_size($td) bytes of padding. You can create binary-safe padding by unconditionally adding a 0x80 to the string, then stripping trailing "\0"s PHP added, plus the one 0x80 byte. <?php function pad($text) { // Add a single 0x80 byte and let PHP pad with 0x00 bytes. return pack("a*H2", $text, "80"); } function unpad($text) { // Return all but the trailing 0x80 from text that had the 0x00 bytes removed return substr(rtrim($text, "\0"), 0, -1); } ?> eric
I was able get php and perl to play together with blowfish using cipher block chaining. The blowfish key needs to be atleast 8 chars (even though blowfish min is 8 bits, perl didn't like keys smaller than 8 chars) and max 56. The iv must be exactly 8 chars and padding needs to be null because php pads with nulls. Also, php needs libmcrypt >= 2.4.9 to be compatible with perl. PERL ---- use Crypt::CBC; $cipher = Crypt::CBC->new( {'key' => 'my secret key', 'cipher'=> 'Blowfish', 'iv' => '12345678', 'regenerate_key' => 0, 'padding' => 'null', 'prepend_iv' => 0 }); $cc = 'my secret text'; $encrypted = $cipher->encrypt($cc); $decrypted = $cipher->decrypt($encrypted); print "encrypted : ".$encrypted; print " "; print "decrypted : ".$decrypted; PHP --- $cc = 'my secret text'; $key = 'my secret key'; $iv = '12345678'; $cipher = mcrypt_module_open(MCRYPT_BLOWFISH,'','cbc',''); mcrypt_generic_init($cipher, $key, $iv); $encrypted = mcrypt_generic($cipher,$cc); mcrypt_generic_deinit($cipher); mcrypt_generic_init($cipher, $key, $iv); $decrypted = mdecrypt_generic($cipher,$encrypted); mcrypt_generic_deinit($cipher); echo "encrypted : ".$encrypted; echo " "; echo "decrypted : ".$decrypted; tmacedo
completing the post from Ryan Thomas, ryanrst at gmail dot com, if u post a cookie w/ HTTP method, its may be encoded; As some chars in base64 will be encoded to another things, u can just replace them before encode and after decode; Its a tweak from dawgeatschikin at hotmail dot com to original idea from massimo dot scamarcia at gmail dot com (see @ http://www.php.net/manual/en/function.base64-encode.php): <?php function urlsafe_b64encode($string) { $data = base64_encode($string); $data = str_replace(array('+','/','='),array('-','_','.'),$data); return $data; } function urlsafe_b64decode($string) { $data = str_replace(array('-','_','.'),array('+','/','='),$string); $mod4 = strlen($data) % 4; if ($mod4) { $data .= substr('====', $mod4); } return base64_decode($data); } ?> maxximus007
Behaviour change: Since 5.2.x mcrypt_generic will issue a warning when the datastring is empty.
chad 0x40 herballure 0x2e com
Addendum to my previous note: apparently there was some sort of character encoding breakage; PHP does not pad if no padding is needed, and the extra padding I saw was the result of chr(X) returning multiple bytes or something. The pad/unpad functions I gave are still binary-safe, though, and are to the best of my knowledge completely compatible with NIST 800-38a. |
Change Languagemcrypt_cbc mcrypt_cfb mcrypt_create_iv mcrypt_decrypt mcrypt_ecb mcrypt_enc_get_algorithms_name mcrypt_enc_get_block_size mcrypt_enc_get_iv_size mcrypt_enc_get_key_size mcrypt_enc_get_modes_name mcrypt_enc_get_supported_key_sizes mcrypt_enc_is_block_algorithm_mode mcrypt_enc_is_block_algorithm mcrypt_enc_is_block_mode mcrypt_enc_self_test mcrypt_encrypt mcrypt_generic_deinit mcrypt_generic_end mcrypt_generic_init mcrypt_generic mcrypt_get_block_size mcrypt_get_cipher_name mcrypt_get_iv_size mcrypt_get_key_size mcrypt_list_algorithms mcrypt_list_modes mcrypt_module_close mcrypt_module_get_algo_block_size mcrypt_module_get_algo_key_size mcrypt_module_get_supported_key_sizes mcrypt_module_is_block_algorithm_mode mcrypt_module_is_block_algorithm mcrypt_module_is_block_mode mcrypt_module_open mcrypt_module_self_test mcrypt_ofb mdecrypt_generic |