摘要:大家可以根據(jù)代碼不同的填充方式來選擇不同的替換方案,但其中有三個(gè)細(xì)節(jié)需要說明為什么要有填充用替換后算法的名稱為何不同接下來會則會具體分析填充算法。
PHP7.1中使用openssl替換mcrypt
在php開發(fā)中,使用mcrypt相關(guān)函數(shù)可以很方便地進(jìn)行AES加、解密操作,但是PHP7.1中廢棄了mcrypt擴(kuò)展,所以必需尋找另一種實(shí)現(xiàn)。在遷移手冊中已經(jīng)指出了用openssl代替mcrypt,但未給出具體示例。網(wǎng)上有很多示例,可以替換大部分場景,但對于其中細(xì)節(jié)卻并未說明。同樣,簡單地使用網(wǎng)上示例在某種代碼場景下有可能導(dǎo)致代碼替換前后的兼容問題,以下則來談?wù)劸唧w代碼及原因。
首先我們直接給出替換的代碼,再從代碼中分析問題。(本文中分析的算法是AES-128-CBC)
替換示例示例會展示兩種mcrypt的使用方式,主要在于填充不同(在下文會解釋填充)。在整個(gè)加、解密過程中,完整程度高一點(diǎn)代碼則會自主實(shí)現(xiàn)填充、移除填充,簡單一點(diǎn)代碼會直接忽略填充,但兩種方式均可正常運(yùn)行;在實(shí)際開發(fā)中(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));
以上示例均可成功運(yùn)行,其中第一個(gè)示例(未使用填充,但在openssl中進(jìn)行了填充)和第二個(gè)示例(使用填充,在openssl中未使用填充)在替換前后輸出相同,并無兼容問題。大家可以根據(jù)代碼不同的填充方式來選擇不同的替換方案,但其中有三個(gè)細(xì)節(jié)需要說明
為什么要有填充?
用openssl替換后算法的名稱為何不同?
接下來會則會具體分析 填充 、算法。
填充為什么有填充則要從加密的算法說起。因?yàn)樵贏ES-128-CBC算法中,會把要加密的字符串以每16個(gè)byte的長度進(jìn)行分段,逐步計(jì)算,由此導(dǎo)致不足16byte的段則會進(jìn)行填充。所以給出的示例中會有兩種:一種是使用默認(rèn)的填充,另一種是自主填充。在與openssl的替換中,如何選擇填充方案,則需要對mcrypt與openssl針對默認(rèn)與自主填充有所了解。
mcrypt默認(rèn)填充
在php的源碼中,可以看出默認(rèn)會以x00進(jìn)行填充,事實(shí)上,并非是以x00進(jìn)行填充,從源碼中可以發(fā)現(xiàn),首先申請了一個(gè)16位的空字符串,所以初始化時(shí)每位字節(jié)均為x00, 實(shí)際上可以說其中并沒有填充,只是它本來就是x00 ,使用默認(rèn)填充得到的加密字符串會是如下形式:
所以解密時(shí)則要移除多余的x00。當(dāng)然也可以懶一點(diǎn),不移除x00。 因?yàn)樵趐hp中字符串"stringx00"與字符串"string"除了長度不一樣外,其他表現(xiàn)均一致,所以看起來并無區(qū)別,如下代碼:
// 尾部包含若干個(gè)`x00` 均可功輸出true if ("stringx00" == "string") { // 用雙引號可解析x00 echo true; }
x00填充后的示例:(請注意字符串的長度,由此可見用x00填充會影響長度)
mcrypt自主填充
填充算法需以如下算法進(jìn)行:
加入填充
/** * 填充算法 * @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; }
加入填充后字符串實(shí)際上如下形式:
移除填充
/** * 移去填充算法 * @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默認(rèn)填充
其默認(rèn)方式與標(biāo)準(zhǔn)的mcrypt的自主填充方式一致,所以在第二個(gè)示例中,對于使用了如上的填充算法后, 可直接使用openssl_encrypt替換,不會產(chǎn)生兼容問題。填充后的加密字符串如下形式:
需注意的是在openssl_encrypt與openssl_decrypt中內(nèi)置了填充與移除填充,所以直接使用即可,除非需自主實(shí)現(xiàn)填充,否則不需要考慮填充
openssl自主填充
openssl_encrypt提供了option參數(shù)以支持自主填充,但在查閱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填充的意思)
由此,我們就可以解釋,在第一個(gè)示例中openssl_encrypt之前加入了自主點(diǎn)充x00的代碼原因了
從以上的加、解密針對填充邏輯不同,針對上文中的示例可以很好地解釋:
示例1:
mcrypt加密時(shí)未使用填充,故以x00進(jìn)行了填充,所以在替換成openssl,需要自主實(shí)現(xiàn)x00填充。
示例2:
mcrypt加密時(shí)使用了標(biāo)準(zhǔn)的填充,同時(shí)openssl的填充方式也為標(biāo)準(zhǔn)填充,故直接使用即可。
分析到這,可以發(fā)現(xiàn),無論是何種填充策略都需注意在加密時(shí)加入填充,在解密時(shí)則必須要移除填充。至此,上文中示例中的填充相關(guān)則分析完成了,接下來我們再看看如何選擇替換后的算法。
選擇算法在以上的示例中,有一個(gè)問題在于,mcrypt中的AES-128-CBC算法,在openssl中怎么替換成了AES_256?
關(guān)于這一點(diǎn), 我也未找到合理的解釋,查看源碼一時(shí)半會也沒找到原因(能力有限~),但通過以下資料,還是完成了功能
openssl 解密 mcrypt AES 數(shù)據(jù)不兼容問題
Convert mcrypt_generic to openssl_encrypt Ask Question
若是有同學(xué)找到原因,歡迎給我留言,謝謝。
總結(jié)對于使用mcrypt AES 進(jìn)行加密密的部分,若是在替換過程中問題, 可以從算法替換或填充這兩方面著手考慮下。同時(shí)還是一必須滿足的條件是根據(jù)不同的填充方式選擇, 替換最重要的就要考慮兼容問題,保證替換后不發(fā)生任何改變。 雖然只是只是有細(xì)微的差別----尾部幾個(gè)字符串的不同,但若是在多平臺中同時(shí)進(jìn)行修改也是一件麻煩事,但變動越少風(fēng)險(xiǎn)越小。
本文只是針對AES算法進(jìn)行了簡單說明,對于其他算法是否適用還有待研究。
參考資料PHP 7.1.x 中廢棄的特性: http://www.php.net/manual/zh/migration71.deprecated.php
mcrypt擴(kuò)展廢棄: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擴(kuò)展原碼:https://github.com/php/php-src/blob/master/ext/openssl/openssl.c
openssl 解密 mcrypt AES 數(shù)據(jù)不兼容問題: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
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://systransis.cn/yun/28943.html
摘要:廢棄加密方法替換方案前瞻最近,我負(fù)責(zé)在重構(gòu)項(xiàng)目的支付渠道,因?yàn)橹岸际墙右粋€(gè)渠道在的方式,代碼顯的比較混亂,恰巧整體項(xiàng)目在微服務(wù)化,所以我們決定將支付做成一個(gè)微服務(wù),獨(dú)立出來。 PHP7.1廢棄加密方法替換方案 前瞻 最近,我負(fù)責(zé)在重構(gòu)項(xiàng)目的支付渠道,因?yàn)橹岸际墙右粋€(gè)渠道在ifelse的方式,代碼顯的比較混亂,恰巧整體項(xiàng)目在微服務(wù)化,所以我們決定將支付做成一個(gè)微服務(wù),獨(dú)立出來。當(dāng)前比...
摘要:擴(kuò)展已經(jīng)過時(shí)了大約年,并且用起來很復(fù)雜。因此它被廢棄并且被所取代。從起它將被從核心代碼中移除并且移到中。手冊在遷移頁面給出了替代方案就是用取代加密,支持加密要加密的數(shù)據(jù)加密加密后的數(shù)據(jù)解密要解密的數(shù)據(jù)加密解密后的數(shù)據(jù)可據(jù)需求,自行改編。 mcrypt 擴(kuò)展已經(jīng)過時(shí)了大約10年,并且用起來很復(fù)雜。因此它被廢棄并且被 OpenSSL 所取代。 從PHP 7.2起它將被從核心代碼中移除并且移...
摘要:問題描述最近在開發(fā)微信小程序涉及到加密數(shù)據(jù)的解密用的是代碼在運(yùn)行后報(bào)錯(cuò)提示方法已過時(shí)了經(jīng)研究得知是版本引起的可以使用方法代替解密首先要知道微信方使用的是加密的所以我們采用也應(yīng)該對應(yīng)對密文進(jìn)行解密需要解密的密文解密的初始向量解密得到的明文 問題描述 最近在開發(fā)微信小程序涉及到加密數(shù)據(jù)(encryptedData)的解密,用的是PHP代碼,在運(yùn)行后報(bào)錯(cuò)mcrypt_module_ xxx ...
摘要:項(xiàng)目背景因?yàn)樽约洪_發(fā)的接口希望在傳遞的工程中可以保證參數(shù)是密文的形式,主要是前端使用加密,后端使用解密在網(wǎng)絡(luò)上搜索了很多的方法,但是大部分的都是使用和進(jìn)行端的加解密,但是眾所周知的問題,這兩個(gè)方法在以后將會被廢棄,故而采用。 項(xiàng)目背景 因?yàn)樽约洪_發(fā)的接口希望在傳遞的工程中可以保證參數(shù)是密文的形式,主要是前端使用js加密,后端使用php解密 在網(wǎng)絡(luò)上搜索了很多的方法,但是大部分的都是使...
摘要:項(xiàng)目背景因?yàn)樽约洪_發(fā)的接口希望在傳遞的工程中可以保證參數(shù)是密文的形式,主要是前端使用加密,后端使用解密在網(wǎng)絡(luò)上搜索了很多的方法,但是大部分的都是使用和進(jìn)行端的加解密,但是眾所周知的問題,這兩個(gè)方法在以后將會被廢棄,故而采用。 項(xiàng)目背景 因?yàn)樽约洪_發(fā)的接口希望在傳遞的工程中可以保證參數(shù)是密文的形式,主要是前端使用js加密,后端使用php解密 在網(wǎng)絡(luò)上搜索了很多的方法,但是大部分的都是使...
閱讀 1192·2021-11-15 18:14
閱讀 3669·2021-11-15 11:37
閱讀 833·2021-09-24 09:47
閱讀 2481·2021-09-04 16:48
閱讀 2223·2019-08-30 15:53
閱讀 2411·2019-08-30 15:53
閱讀 413·2019-08-30 11:20
閱讀 1258·2019-08-29 16:08