AES 256加密Java到PHP

Question

我有一个基于数据加密AES256的源代码，但是此代码是Java，我想转换为PHP，我正在尝试此示例，但不正确。 PHP中的示例使用随机IV，但我要求它们为零。

private String encryptAES(String strToEncrypt) {
    
    try {
        byte[] iv = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
        IvParameterSpec ivspec = new IvParameterSpec(iv);

        SecretKeyFactory factory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256");
        KeySpec spec = new PBEKeySpec(SECRET_KEY.toCharArray(), SALT.getBytes(), 65536, 256);
        SecretKey tmp = factory.generateSecret(spec);
        SecretKeySpec secretKey = new SecretKeySpec(tmp.getEncoded(), "AES");

        Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
        cipher.init(Cipher.ENCRYPT_MODE, secretKey, ivspec);
        return Base64.getEncoder().encodeToString(cipher.doFinal(strToEncrypt.getBytes(StandardCharsets.UTF_8)));
    } catch (Exception e) {
        log.error("Error while encrypting: " + e.toString());
    }
    return null;
}

我尝试了

function encrypt($data){
    $method = "AES-256-CBC";
    $salt = 'vzQ8p=z';
    $key =  '!5&3usT';

    $iv = [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 ];
    $chars = array_map("chr", $iv);
    $IVbytes = join($chars);

    $hash = openssl_pbkdf2($key,$salt,'256','65536', 'sha1');
    $encrypted = openssl_encrypt($data, $method, $hash, OPENSSL_RAW_DATA, $IVbytes);
    return base64_encode($encrypted);
}

Answer 1

最明显的缺陷是，尽管两者都使用PBKDF2，但您将HMAC-SHA2-256用作Java代码中的PRF（即伪随机函数，即Hash算法），而SHA1则用作PHP中的PRF。当然，这将产生两个不同的键（就像您通过SHA1和SHA2-256运行相同的字符串一样），因此您的文本将被加密到两个不同的密文，并且在每种情况下都需要相应的键来解密它。

您还需要检查您在两种情况下都使用相同的密码和填充方案。您在PHP中明确指定AES-256-CBC，但没有指定填充；您可以在Java中明确指定AES/CBC/PKCS5，但不是AES密钥大小。在实践中，我怀疑这是正确的（通过256位键时，Java可能会生成256位AES密钥，而PHP openssl_encrypt 使用 AES-256-CBC 可能会生成256位键。默认情况下使用PKCS5），但您不应该留下任何未指定的东西。

其他想法：

• 为什么使用PBE/PBKDF2？除非 secret_key / $ key 是一个用户途径的值，否则没有理由每次都这样做。这是浪费CPU时间。
• 如果“键”实际上是硬编码（如示例中的），那甚至更糟。在硬编码的“键”（密码）和盐上运行PBKDF2不仅是完全毫无意义的，而且使用硬编码键（或键的硬编码派生过程）是一个可怕的主意系统，任何看到您的代码或反复编译的人都会知道该系统曾经触摸的每个数据都已加密。
• 如 使用欧洲央行而不是CBC完全糟糕，但确实仍然非常糟糕。如果您实际上需要使用始终为零的IV，那么有人搞砸了。
• 此加密没有完整性保护。 CBC中的轻弹攻击并不像Steam Ciphers或类似流的操作模式那样糟糕，但它们仍然是一个真正的威胁。您需要通过使用身份验证的加密（并在解密时验证身份验证标签）来保护消息完整性。
• 没有查看解密代码，我们无法确定这是否是问题，但是PKCS5可能容易受到填充甲骨文攻击的影响。取决于解密过程如何处理错误的填充方式，攻击者可以尝试解密相同的消息（加上攻击者选择的修改）多次可能能够解密消息而不知道键本身（尽管通常这是一个毫无意义的点您将密钥编码）。