nodejs aes256加密不同于在线aes256加密工具 [英] nodejs aes256 encrypt is different from online aes256 encryption tool

查看:617
本文介绍了nodejs aes256加密不同于在线aes256加密工具的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我使用nodejs-aes256 HelloWorld > https://www.npmjs.com/package/nodejs-aes256 ,键为 apple ,输出为 1ivBqj + nVPcHvZjQlx7Di0SoxV49bNpWtog =
然后我使用在线工具 http://aesencryption.net用相同的密钥对相同的单词进行加密/ 输出为 LIxrc1buLeLLr9nJxtPhjHSYFVaceqsXiFamWiVWzYI =

I encrypted word HelloWorld using nodejs-aes256 https://www.npmjs.com/package/nodejs-aes256 with key apple the output was 1ivBqj+nVPcHvZjQlx7Di0SoxV49bNpWtog= then I encrypted same word with same key using online tool http://aesencryption.net/ the output was LIxrc1buLeLLr9nJxtPhjHSYFVaceqsXiFamWiVWzYI=

为什么不同?

推荐答案

首先, apple不能成为AES-256的密钥。还不够长。 AES-256密钥必须恰好是256位(32字节)。 苹果以可能的编码方式是5。所以这里已经存在问题。系统可能会为您填充零,但您不能依靠它。无论如何,这并不是AES密钥的样子;它们必须是32个有效随机字节; 苹果不是有效随机。

First, "apple" can't be a key for AES-256. It's not long enough. An AES-256 key has to be exactly 256 bits (32 bytes). "apple" is, in the likely ways of encoding it, 5. So there's already a problem here. The systems may be padding it out with zeros for you, but you can't rely on that. This isn't what AES keys should look like anyway; they need to be 32 "effectively random" bytes; "apple" is not "effectively random."

nodejs包指示它生成了随机IV。这可能意味着它还在输出中对随机IV进行了编码,并在输入中期望了它,而且肯定是我们在代码中看到的:

The nodejs package indicates that it generates a random IV. That likely means it also encodes the random IV in the output and expects it in the input, and sure enough that's what we see in the code:

ciphertext = Buffer.concat([iv, ciphertext, cipher.final()]);

假设PHP页面下方的源代码实际上与该工具相关,那么他们已经调用了此:

Assuming that the source code below the PHP page is actually related to the tool, then they've called this:

$this->setIV("");

这可能会转换为16个字节的零(这是非常不安全的IV)。

which probably translates somewhere into 16 bytes of zeros (which is a very insecure IV).

简短的答案是,绝对没有应用AES或编码输出的标准。您发现的绝大多数实现(包括这两种实现)都是非常不安全的,因为它们假定您知道如何添加缺失的所有部分。例如,这两种实现都需要HMAC,因为它们使用的是CBC模式,但都不包含HMAC模式,并且如果要传递 apple之类的字符串作为密码,则需要诸如PBKDF2之类的密钥派生函数将其转换为关键。 (这是将苹果之类的字符串转换为有效随机的方式。)任何安全实现都将与任何其他安全实现不兼容。

The shorter answer is that there is absolutely no standard for applying AES or encoding the output. The vast majority of implementations you find (including these two) are very insecure because they assume you know how to add all the pieces they're missing. For example, both of these implementations need an HMAC, since they used CBC mode, but neither includes one, and if you want to hand a string like "apple" as the password, you need a key derivation function like PBKDF2 to convert it to a key. (This is how you convert a string like "apple" into something "effectively random.") Any secure implementation will be incompatible with any other secure implementation. There just isn't a widely used standard format that is also secure.

总而言之,安全格式应始终导致两种加密具有不同的结果密文。 nodejs包通过包含随机IV来正确地做到这一点,并且如果您多次运行它,将会得到不同的结果。这项功能可防止某些类型的攻击。因此,获得不同的结果也就不足为奇了。

All that said, a secure format should always cause two encryptions to have different resulting cipher texts. The nodejs package does this correctly by including a random IV, and if you ran it multiple times, you would get different results. That's a feature that prevents certain kinds of attacks. So having different results shouldn't be surprising.

如果您正在寻找一种现成的AES格式,其中包括您需要的所有内容,那么请看一下在 RNCryptor libsodium

If you're looking for an off-the-shelf AES format that includes all the pieces you need, take a look at RNCryptor or libsodium.

这篇关于nodejs aes256加密不同于在线aes256加密工具的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆