摘要:大家可以根據代碼不同的填充方式來選擇不同的替換方案,但其中有三個細節需要說明為什么要有填充用替換后算法的名稱為何不同接下來會則會具體分析填充算法。
PHP7.1中使用openssl替換mcrypt
在php開發中,使用mcrypt相關函數可以很方便地進行AES加、解密操作,但是PHP7.1中廢棄了mcrypt擴展,所以必需尋找另一種實現。在遷移手冊中已經指出了用openssl代替mcrypt,但未給出具體示例。網上有很多示例,可以替換大部分場景,但對于其中細節卻并未說明。同樣,簡單地使用網上示例在某種代碼場景下有可能導致代碼替換前后的兼容問題,以下則來談談具體代碼及原因。
首先我們直接給出替換的代碼,再從代碼中分析問題。(本文中分析的算法是AES-128-CBC)
替換示例示例會展示兩種mcrypt的使用方式,主要在于填充不同(在下文會解釋填充)。在整個加、解密過程中,完整程度高一點代碼則會自主實現填充、移除填充,簡單一點代碼會直接忽略填充,但兩種方式均可正常運行;在實際開發中(7.1之前版本),建議加上填充。請看如下具體示例:
mcrypt未使用填充
mcrypt加密:
$key = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"; $iv = "aaaaaaaaaaaaaaaa"; $data = "dataString"; $cipher = mcrypt_module_open(MCRYPT_RIJNDAEL_128, "", MCRYPT_MODE_CBC, ""); mcrypt_generic_init($cipher, $key, $iv); $cipherText256 = mcrypt_generic($cipher, $data); mcrypt_generic_deinit($cipher); return bin2hex($cipherText256);
相同功能的openssl加密代碼:
$key = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"; $iv = "aaaaaaaaaaaaaaaa"; $data = "dataString"; $data = $data . str_repeat("x00", 16 - (strlen($data) % 16)); // 雙引號可以解析asc-ii碼x00 return bin2hex(openssl_encrypt($data, "AES-256-CBC", $key, OPENSSL_RAW_DATA | OPENSSL_ZERO_PADDING, $iv));
mcrypt使用填充
mcrypt加密:
$key = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"; $iv = "aaaaaaaaaaaaaaaa"; $data = "dataString"; // 填充(移除填充反著移除即可) $block = mcrypt_get_block_size(MCRYPT_RIJNDAEL_128, MCRYPT_MODE_CBC); $pad = $block - (strlen($data) % $block); if ($pad <= $block) { $char = chr($pad); $data .= str_repeat($char, $pad); } $cipher = mcrypt_module_open(MCRYPT_RIJNDAEL_128, "", MCRYPT_MODE_CBC, ""); mcrypt_generic_init($cipher, $key, $iv); $cipherText256 = mcrypt_generic($cipher, $data); mcrypt_generic_deinit($cipher); return bin2hex($cipherText256);
相同功能的openssl加密代碼:
$key = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"; $iv = "aaaaaaaaaaaaaaaa"; $data = "dataString"; return bin2hex(openssl_encrypt($data, "AES-256-CBC", $key, OPENSSL_RAW_DATA | OPENSSL_ZERO_PADDING, $iv));
以上示例均可成功運行,其中第一個示例(未使用填充,但在openssl中進行了填充)和第二個示例(使用填充,在openssl中未使用填充)在替換前后輸出相同,并無兼容問題。大家可以根據代碼不同的填充方式來選擇不同的替換方案,但其中有三個細節需要說明
為什么要有填充?
用openssl替換后算法的名稱為何不同?
接下來會則會具體分析 填充 、算法。
填充為什么有填充則要從加密的算法說起。因為在AES-128-CBC算法中,會把要加密的字符串以每16個byte的長度進行分段,逐步計算,由此導致不足16byte的段則會進行填充。所以給出的示例中會有兩種:一種是使用默認的填充,另一種是自主填充。在與openssl的替換中,如何選擇填充方案,則需要對mcrypt與openssl針對默認與自主填充有所了解。
mcrypt默認填充
在php的源碼中,可以看出默認會以x00進行填充,事實上,并非是以x00進行填充,從源碼中可以發現,首先申請了一個16位的空字符串,所以初始化時每位字節均為x00, 實際上可以說其中并沒有填充,只是它本來就是x00 ,使用默認填充得到的加密字符串會是如下形式:
所以解密時則要移除多余的x00。當然也可以懶一點,不移除x00。 因為在php中字符串"stringx00"與字符串"string"除了長度不一樣外,其他表現均一致,所以看起來并無區別,如下代碼:
// 尾部包含若干個`x00` 均可功輸出true if ("stringx00" == "string") { // 用雙引號可解析x00 echo true; }
x00填充后的示例:(請注意字符串的長度,由此可見用x00填充會影響長度)
mcrypt自主填充
填充算法需以如下算法進行:
加入填充
/** * 填充算法 * @param string $source * @return string */ function addPKCS7Padding($source) { $source = trim($source); $block = mcrypt_get_block_size(MCRYPT_RIJNDAEL_128, MCRYPT_MODE_CBC); $pad = $block - (strlen($source) % $block); if ($pad <= $block) { $char = chr($pad); $source .= str_repeat($char, $pad); } return $source; }
加入填充后字符串實際上如下形式:
移除填充
/** * 移去填充算法 * @param string $source * @return string */ function stripPKSC7Padding($source) { $source = trim($source); $char = substr($source, -1); $num = ord($char); if ($num == 62) return $source; $source = substr($source, 0, -$num); return $source; }
openssl默認填充
其默認方式與標準的mcrypt的自主填充方式一致,所以在第二個示例中,對于使用了如上的填充算法后, 可直接使用openssl_encrypt替換,不會產生兼容問題。填充后的加密字符串如下形式:
需注意的是在openssl_encrypt與openssl_decrypt中內置了填充與移除填充,所以直接使用即可,除非需自主實現填充,否則不需要考慮填充
openssl自主填充
openssl_encrypt提供了option參數以支持自主填充,但在查閱php源碼中openssl的測試用例代碼才找到正確用法:
// if we want to manage our own padding $padded_data = $data . str_repeat(" ", 16 - (strlen($data) % 16)); $encrypted = openssl_encrypt($padded_data, $method, $password, OPENSSL_RAW_DATA|OPENSSL_ZERO_PADDING, $iv); $output = openssl_decrypt($encrypted, $method, $password, OPENSSL_RAW_DATA|OPENSSL_ZERO_PADDING, $iv); var_dump(rtrim($output));
(備注:如上,OPENSSL_ZERO_PADDING 并非是為0填充的意思)
由此,我們就可以解釋,在第一個示例中openssl_encrypt之前加入了自主點充x00的代碼原因了
從以上的加、解密針對填充邏輯不同,針對上文中的示例可以很好地解釋:
示例1:
mcrypt加密時未使用填充,故以x00進行了填充,所以在替換成openssl,需要自主實現x00填充。
示例2:
mcrypt加密時使用了標準的填充,同時openssl的填充方式也為標準填充,故直接使用即可。
分析到這,可以發現,無論是何種填充策略都需注意在加密時加入填充,在解密時則必須要移除填充。至此,上文中示例中的填充相關則分析完成了,接下來我們再看看如何選擇替換后的算法。
選擇算法在以上的示例中,有一個問題在于,mcrypt中的AES-128-CBC算法,在openssl中怎么替換成了AES_256?
關于這一點, 我也未找到合理的解釋,查看源碼一時半會也沒找到原因(能力有限~),但通過以下資料,還是完成了功能
openssl 解密 mcrypt AES 數據不兼容問題
Convert mcrypt_generic to openssl_encrypt Ask Question
若是有同學找到原因,歡迎給我留言,謝謝。
總結對于使用mcrypt AES 進行加密密的部分,若是在替換過程中問題, 可以從算法替換或填充這兩方面著手考慮下。同時還是一必須滿足的條件是根據不同的填充方式選擇, 替換最重要的就要考慮兼容問題,保證替換后不發生任何改變。 雖然只是只是有細微的差別----尾部幾個字符串的不同,但若是在多平臺中同時進行修改也是一件麻煩事,但變動越少風險越小。
本文只是針對AES算法進行了簡單說明,對于其他算法是否適用還有待研究。
參考資料PHP 7.1.x 中廢棄的特性: http://www.php.net/manual/zh/migration71.deprecated.php
mcrypt擴展廢棄:http://www.php.net/manual/zh/book.mcrypt.php
AES算法:https://blog.csdn.net/qq_28205153/article/details/55798628
mcrypt源碼:https://github.com/php/php-src/blob/php-7.0.30/ext/mcrypt/mcrypt.c
openssl擴展原碼:https://github.com/php/php-src/blob/master/ext/openssl/openssl.c
openssl 解密 mcrypt AES 數據不兼容問題:https://www.v2ex.com/t/370493
Convert mcrypt_generic to openssl_encrypt Ask Question:https://stackoverflow.com/questions/48800725/convert-mcrypt-generic-to-openssl-encrypt
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/28943.html
摘要:廢棄加密方法替換方案前瞻最近,我負責在重構項目的支付渠道,因為之前都是接一個渠道在的方式,代碼顯的比較混亂,恰巧整體項目在微服務化,所以我們決定將支付做成一個微服務,獨立出來。 PHP7.1廢棄加密方法替換方案 前瞻 最近,我負責在重構項目的支付渠道,因為之前都是接一個渠道在ifelse的方式,代碼顯的比較混亂,恰巧整體項目在微服務化,所以我們決定將支付做成一個微服務,獨立出來。當前比...
摘要:擴展已經過時了大約年,并且用起來很復雜。因此它被廢棄并且被所取代。從起它將被從核心代碼中移除并且移到中。手冊在遷移頁面給出了替代方案就是用取代加密,支持加密要加密的數據加密加密后的數據解密要解密的數據加密解密后的數據可據需求,自行改編。 mcrypt 擴展已經過時了大約10年,并且用起來很復雜。因此它被廢棄并且被 OpenSSL 所取代。 從PHP 7.2起它將被從核心代碼中移除并且移...
摘要:問題描述最近在開發微信小程序涉及到加密數據的解密用的是代碼在運行后報錯提示方法已過時了經研究得知是版本引起的可以使用方法代替解密首先要知道微信方使用的是加密的所以我們采用也應該對應對密文進行解密需要解密的密文解密的初始向量解密得到的明文 問題描述 最近在開發微信小程序涉及到加密數據(encryptedData)的解密,用的是PHP代碼,在運行后報錯mcrypt_module_ xxx ...
摘要:項目背景因為自己開發的接口希望在傳遞的工程中可以保證參數是密文的形式,主要是前端使用加密,后端使用解密在網絡上搜索了很多的方法,但是大部分的都是使用和進行端的加解密,但是眾所周知的問題,這兩個方法在以后將會被廢棄,故而采用。 項目背景 因為自己開發的接口希望在傳遞的工程中可以保證參數是密文的形式,主要是前端使用js加密,后端使用php解密 在網絡上搜索了很多的方法,但是大部分的都是使...
摘要:項目背景因為自己開發的接口希望在傳遞的工程中可以保證參數是密文的形式,主要是前端使用加密,后端使用解密在網絡上搜索了很多的方法,但是大部分的都是使用和進行端的加解密,但是眾所周知的問題,這兩個方法在以后將會被廢棄,故而采用。 項目背景 因為自己開發的接口希望在傳遞的工程中可以保證參數是密文的形式,主要是前端使用js加密,后端使用php解密 在網絡上搜索了很多的方法,但是大部分的都是使...
閱讀 1169·2021-11-15 18:14
閱讀 3637·2021-11-15 11:37
閱讀 760·2021-09-24 09:47
閱讀 2442·2021-09-04 16:48
閱讀 2185·2019-08-30 15:53
閱讀 2386·2019-08-30 15:53
閱讀 395·2019-08-30 11:20
閱讀 1239·2019-08-29 16:08