JavaScript与PHP AES加密互操作性指南：解决输出不一致问题-php教程-PHP中文网

JavaScript与PHP AES加密互操作性指南：解决输出不一致问题

本文旨在解决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代码，并分析它们之间的差异。

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生成的密文不一致。

Revealjs Presentations

创建、编辑并部署 reveal.js 演示文稿为单个 HTML 文件，可选自定义 CSS。适用于需要制作演示文稿、幻灯片或宣传材料时使用。

下载

解决方案：修正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使用方式：
1. 随机生成： 每次加密时都应生成一个全新的、密码学安全的随机IV。
2. 非秘密性： IV不需要保密，但必须是不可预测的。
3. 传输： IV通常与密文一同传输给解密方。常见的做法是将IV预置或追加到密文数据中。