PHP加密解密方法：mcrypt与openssl替代方案

PHP 7.2起已彻底移除存在严重安全缺陷的mcrypt扩展，开发者必须立即迁移到更可靠、更现代的加密方案——openssl（需严格遵循密钥/IV长度、填充与编码规范）或首选sodium（内置AEAD认证加密，自动处理完整性校验、无需手动填充、抗误用性强），本文不仅详解迁移中的典型陷阱（如RIJNDAEL与AES混淆、ECB模式风险、密钥字节错配、旧数据兼容难题），更提供可直接落地的代码范例与生产级实践建议，帮你避开升级后加密崩溃、数据无法解密、安全形同虚设等致命坑。

PHP 7.2+ 已彻底移除 mcrypt 扩展，强行启用会报 Call to undefined function mcrypt_encrypt() 错误；所有依赖它的旧代码必须迁移到 openssl —— 这不是可选项，是运行前提。

为什么不能继续用 mcrypt 函数（如 mcrypt_encrypt）

mcrypt 自 PHP 7.1 起被标记为废弃，7.2 正式删除。它存在多个无法修复的问题：MCRYPT_RIJNDAEL_128 不等于 AES-128（块大小与密钥长度混淆）、无认证加密（无法校验完整性）、不支持 AEAD 模式、底层 OpenSSL 兼容性差。

常见错误现象：

• 升级 PHP 后整个加密模块崩溃，日志里反复出现 Function mcrypt_module_open() is deprecated 或直接 Fatal error
• 用 mcrypt_encrypt(MCRYPT_RIJNDAEL_128, ...) 加密的数据，用 OpenSSL 解不出来——因为 RIJNDAEL_128 在 mcrypt 中指“块长度 128”，而 OpenSSL 的 aes-128-cbc 指“密钥长度 128”
• 相同密钥 + IV 下，两套函数输出完全不一致，且无法互相还原

openssl_encrypt() 和 openssl_decrypt() 最小可用写法

替代不是简单替换函数名，关键是统一算法、模式、填充和编码方式。以下是最简但生产可用的 AES-128-CBC 实现（带 PKCS#7 填充）：

// 加密
function aes128Encrypt($plaintext, $key, $iv) {
    $method = 'AES-128-CBC';
    $options = OPENSSL_RAW_DATA;
    $ciphertext = openssl_encrypt($plaintext, $method, $key, $options, $iv);
    return base64_encode($ciphertext);
}

// 解密
function aes128Decrypt($ciphertextBase64, $key, $iv) {
    $method = 'AES-128-CBC';
    $options = OPENSSL_RAW_DATA;
    $ciphertext = base64_decode($ciphertextBase64);
    return openssl_decrypt($ciphertext, $method, $key, $options, $iv);
}

关键注意点：

• $key 必须是 16 字节（AES-128），不能是任意字符串；建议用 hash('sha256', $password, true) 截取前 16 字节，而非直接 substr(md5(...), 0, 16)
• $iv 必须是 16 字节且**每次加密都随机生成**（不可复用！），并和密文一起存储/传输；用 openssl_random_pseudo_bytes(16) 生成
• OPENSSL_RAW_DATA 表示输出二进制，配合 base64_encode 才方便存储；若传 OPENSSL_ZERO_PADDING，需自行处理填充，极易出错
• 不要用 OPENSSL_PKCS1_OAEP_PADDING——那是 RSA 用的，AES 不认

如何安全迁移老 mcrypt 代码（含兼容解密）

如果数据库里存着大量 mcrypt 加密的旧数据，不能一次性全重刷，就得让新系统能反向解密。唯一可行路径是：在 PHP 7.1 环境下导出原始密钥、IV、明文，再用 OpenSSL 重新加密；或临时桥接——但这仅限过渡期。

真实场景中的硬约束：

• mcrypt_create_iv(16, MCRYPT_DEV_URANDOM) 生成的 IV ≠ openssl_random_pseudo_bytes(16) 生成的 IV（虽然都是真随机，但不可互换）
• 老代码若用 MCRYPT_MODE_ECB，必须立刻废弃——ECB 模式完全不安全，连调试都不该用
• 若原密钥是字符串（如 "my-secret-key"），直接喂给 openssl_encrypt 会失败：OpenSSL 要求密钥字节长度严格匹配算法，"my-secret-key" 是 13 字节，AES-128 需要 16 字节
• PHP 8.1+ 还废弃了 mcrypt_get_key_size() 等残留函数，连编译都过不去

更现代的选择：优先考虑 sodium_crypto_secretbox()

如果你用的是 PHP 7.2+ 且已启用 sodium 扩展（默认内置），直接跳过 OpenSSL —— sodium 提供开箱即用的 AEAD 加密（自动认证 + 加密），无需手动管理 IV、填充、HMAC 校验：

$key = sodium_crypto_secretbox_keygen();
$nonce = random_bytes(SODIUM_CRYPTO_SECRETBOX_NONCEBYTES);
$ciphertext = sodium_crypto_secretbox($message, $nonce, $key);

// 解密时自动验证完整性，失败直接返回 false
$plaintext = sodium_crypto_secretbox_open($ciphertext, $nonce, $key);

优势很实际：

• 不用记 AES-256-GCM 还是 CBC，sodium 就一个函数搞定全部安全需求
• 密钥、nonce 全部是固定长度，不会因传错字节数静默失败
• 解密失败时返回 false，而不是返回乱码（openssl_decrypt 在密钥错时可能返回非空字符串）
• PHP 8.3 已将 sodium 列为强制扩展，未来只会更稳

真正卡住人的从来不是“怎么写”，而是“密钥哪来”“IV 存哪”“旧数据怎么救”。这些细节没对齐，函数再标准也白搭。

以上就是《PHP加密解密方法：mcrypt与openssl替代方案》的详细内容，更多关于的资料请关注golang学习网公众号！