本文旨在解决javascript和php之间aes加密输出不一致的问题。通过分析共享密钥长度、加密算法选择和初始化向量（iv）的正确设置，我们将演示如何将php的`openssl_encrypt`配置为与javascript的`aes-js`库生成相同的密文。强调了使用32字节密钥时应选择`aes-256-cbc`算法，并正确构建二进制零值iv，同时警示了静态iv的安全风险。
理解AES加密互操作性
在跨语言环境中实现加密互操作性，特别是像AES这样复杂的对称加密算法，需要精确匹配所有关键参数。这些参数包括加密算法模式（如CBC）、密钥长度、初始化向量（IV）以及填充方式。任何细微的不匹配都将导致密文不一致，从而无法正确解密。
本教程将聚焦于解决JavaScript（使用aes-js库）和PHP（使用openssl_encrypt函数）在AES-CBC模式下加密输出不一致的问题。
核心加密参数概述
在深入分析代码之前，我们先回顾几个关键概念：
- AES算法与密钥长度： AES（Advanced Encryption Standard）支持不同的密钥长度，常见的有128位、192位和256位。密钥长度决定了所使用的具体AES算法变体，例如128位密钥对应AES-128，256位密钥对应AES-256。在CBC模式下，通常表示为AES-128-CBC或AES-256-CBC。
- CBC模式（Cipher Block Chaining）： 一种分组密码工作模式，它要求一个初始化向量（IV）。IV的目的是在相同的密钥下，对相同的明文进行多次加密时产生不同的密文，从而增加安全性。IV必须是随机且不可预测的，并且与密文一同传输（但不需要保密）。
- 填充（Padding）： AES是分组密码，处理固定大小的数据块（16字节）。如果明文数据长度不是块大小的整数倍，就需要进行填充。PKCS7是常用的填充标准。
问题分析：JavaScript与PHP的差异
我们来看一下原始的JavaScript和PHP代码，并分析它们之间的差异。
立即学习“PHP免费学习笔记（深入）”；
JavaScript加密代码分析
const SHARED_KEY="XXelkee4v3WjMP81fvjgpNRs2u2cwJ7n3lnJzPt8iVY="; // Base64编码的密钥
const ZERO_IV=[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]; // 16字节的零值IV
let data="6104337983063890";
aesEncrypt = async (data) => {
try{
// 将Base64编码的密钥转换为Uint8Array
let key = new Uint8Array(this.base64ToArray(SHARED_KEY));
// 使用CBC模式，传入密钥和IV
let aes = new aesJs.ModeOfOperation.cbc(key, ZERO_IV)
// 将UTF-8字符串转换为字节数组
let bData = aesJs.utils.utf8.toBytes(data);
// 执行加密，并应用PKCS7填充
let encBytes = aes.encrypt(aesJs.padding.pkcs7.pad(bData))
// 将加密结果转换为十六进制字符串
return this.arrayToHex(encBytes)
}catch(err) {
console.error(err)
return null
}
}JavaScript代码的关键点：
- 密钥长度： SHARED_KEY经过Base64解码后，其原始字节长度为32字节（XXelkee4v3WjMP81fvjgpNRs2u2cwJ7n3lnJzPt8iVY= 的Base64解码结果是32字节）。32字节的密钥对应的是AES-256算法。
- IV： 使用了一个16字节的全部为零的ZERO_IV数组。
- 算法： aesJs.ModeOfOperation.cbc在内部会根据传入的密钥长度自动选择AES-128、AES-192或AES-256。由于密钥是32字节，它会使用AES-256。
- 填充： 明确使用了aesJs.padding.pkcs7.pad进行PKCS7填充。
PHP加密代码分析
$sharedSecret=base64_decode('XXelkee4v3WjMP81fvjgpNRs2u2cwJ7n3lnJzPt8iVY='); // Base64解码的密钥
$iv = '0000000000000000'; // 字符串形式的IV
$data="6104337983063890";
$output = openssl_encrypt(
$data,
'AES-128-CBC', // 指定加密算法
$sharedSecret,
OPENSSL_RAW_DATA,
$iv
);
$output=bin2hex($output);PHP代码的问题所在：
- 算法选择不匹配： PHP代码明确指定了'AES-128-CBC'。然而，$sharedSecret（Base64解码后）的长度是32字节，这与AES-128（需要16字节密钥）不符，而是与AES-256（需要32字节密钥）相匹配。openssl_encrypt在密钥长度与算法不匹配时，可能会截断密钥或产生不一致的结果。
- IV格式不正确： PHP代码将$iv定义为一个字符串'0000000000000000'。虽然这个字符串有16个字符，但它不是16个字节的二进制零值。openssl_encrypt函数期望IV是一个二进制字符串，而不是字符'0'组成的字符串。这意味着PHP使用的IV实际上是ASCII码的'0'（即0x30）重复16次，而非JavaScript中真正的0x00重复16次。
这些不匹配导致了JavaScript和PHP生成的密文不一致。
解决方案：修正PHP加密代码
为了使PHP的openssl_encrypt函数与JavaScript代码生成相同的密文，我们需要进行以下两项关键修正：
- 将加密算法更改为AES-256-CBC： 这是因为共享密钥的长度为32字节，对应AES-256。
- 正确构建二进制零值IV： 使用hex2bin()函数将十六进制字符串'00000000000000000000000000000000'转换为16字节的二进制零值。
修正后的PHP代码
<?php
$sharedSecret=base64_decode('XXelkee4v3WjMP81fvjgpNRs2u2cwJ7n3lnJzPt8iVY='); // 32字节密钥
// 正确创建16字节的二进制零值IV
$iv = hex2bin('00000000000000000000000000000000');
$data="6104337983063890";
$output = openssl_encrypt(
$data,
'AES-256-CBC', // 更改为AES-256-CBC以匹配32字节密钥
$sharedSecret,
OPENSSL_RAW_DATA, // 确保输出原始二进制数据，不进行Base64编码
$iv
);
// 将二进制密文转换为十六进制字符串
$output=bin2hex($output);
echo "PHP Output: " . $output . PHP_EOL;
// 预期输出应与JavaScript一致：4b685c988d9e166efd0bc5830e926ae0d60111d9dd73d7b4f3c547282994546f
?>经过上述修正后，PHP代码将产生与JavaScript代码完全相同的密文输出：4b685c988d9e166efd0bc5830e926ae0d60111d9dd73d7b4f3c547282994546f。
安全注意事项
尽管上述修正解决了JavaScript和PHP之间的加密互操作性问题，但需要特别强调一个重要的安全隐患：
切勿在生产环境中使用静态或零值IV！
- 静态IV的风险： 初始化向量（IV）的主要目的是确保即使使用相同的密钥加密相同的明文，也能产生不同的密文。如果每次加密都使用相同的静态IV（尤其是零值IV），攻击者可以通过分析密文模式来推断明文信息，甚至可能进行重放攻击或选择明文攻击。这严重削弱了CBC模式的安全性。
-
正确的IV使用方式：
- 随机生成： 每次加密时都应生成一个全新的、密码学安全的随机IV。
- 非秘密性： IV不需要保密，但必须是不可预测的。
- 传输： IV通常与密文一同传输给解密方。常见的做法是将IV预置或追加到密文数据中。
推荐的PHP安全IV生成方式
// 生成一个密码学安全的随机IV
$iv = openssl_random_pseudo_bytes(openssl_cipher_iv_length('AES-256-CBC'));
// 然后将 $iv 与 $output（密文）一同传输
// 例如，可以拼接起来：$encryptedData = $iv . $output;
// 解密时，先分离出IV，再进行解密总结
实现JavaScript和PHP之间AES加密的互操作性，关键在于确保所有加密参数的精确匹配。本教程通过修正PHP代码中的算法选择（从AES-128-CBC到AES-256-CBC，以匹配32字节密钥）和IV的正确格式（使用hex2bin生成二进制零值IV），成功解决了密文不一致的问题。
然而，更重要的是，开发者必须始终遵循加密最佳实践，尤其是在IV的使用上。在任何生产环境中，都应使用随机生成的IV，以确保加密系统的安全性。静态IV，尤其是零值IV，应仅用于调试或非常特定的、已充分理解其安全影响的场景。
