在 Node.js 中获取 256 位 AES GCM 加密的正确标签时出现问题

大家好，我们又见面了啊~本文《在 Node.js 中获取 256 位 AES GCM 加密的正确标签时出现问题》的内容中将会涉及到等等。如果你正在学习Golang相关知识，欢迎关注我，以后会给大家带来更多Golang相关文章，希望我们能一起进步！下面就开始本文的正式内容~

我需要编写以下解密函数的逆向（加密）：

const crypto = require('crypto');

let aesdecrypt = (data, key) => {
  const decoded = buffer.from(data, 'binary');

  const nonce = decoded.slice(0, 16);
  const ciphertext = decoded.slice(16, decoded.length - 16);
  const tag = decoded.slice(decoded.length - 16);

  let decipher = crypto.createdecipheriv('aes-256-gcm', key, nonce);
  decipher.setauthtag(tag)
  decipher.setautopadding(false);
  try {
    let plaintext = decipher.update(ciphertext, 'binary', 'binary');
    plaintext += decipher.final('binary');
    return buffer.from(plaintext, 'binary');
  } catch (ex) {
    console.log('aes decrypt failed. exception: ', ex);
    throw ex;
  }
}

上面的函数允许我按照规范正确解密加密的缓冲区：

| nonce/iv (first 16 bytes) | ciphertext | authentication tag (last 16 bytes) |

之所以 aesdecrypt 如此编写（auth 标记为最后 16 个字节），是因为这就是 aes 的默认标准库实现在 java 和 go 中加密数据的方式。我需要能够在 go、java 和 node.js 之间进行双向解密/加密。 node.js 中基于 crypto 库的加密不会将 auth 标签放在任何地方，开发人员可以自行决定如何存储它以在解密期间传递给 setauthtag()。在上面的代码中，我将标签直接烘焙到最终的加密缓冲区中。

因此，我编写的 aes 加密函数需要满足上述情况（无需修改 aesdecrypt，因为它可以正常工作），并且我有以下代码，但对我来说不起作用：

我知道对随机数进行硬编码是不安全的。我这样做是为了更容易地使用二进制文件比较程序（如 vbindiff）将正确加密的文件与我损坏的实现进行比较

我越以不同的方式看待这个问题，这个问题对我来说就越令人困惑。

我实际上非常习惯于实现基于 256 位 aes gcm 的加密/解密，并且在 go 和 java 中都有正常工作的实现。此外，由于某些情况，几个月前我在 node.js 中实现了 aes 解密的工作实现。

我知道这是真的，因为我可以在 node.js 中解密在 java 和 go 中加密的文件。我建立了一个快速存储库，其中包含专门为此目的编写的 go 服务器的源代码实现以及损坏的 node.js 代码。

为了让了解 node.js 但不懂 go 的人轻松访问，我提供了以下 go 服务器 web 界面，用于使用 https://go-aes.voiceit.io/ 上托管的上述算法进行加密和解密。您可以通过在 https://go-aes.voiceit.io/ 上加密您选择的文件并使用 decrypt.js 解密该文件来确认我的 node.js 解密功能是否正常工作（请查看 readme 以了解更多信息）如果您需要确认它是否正常工作，请了解如何运行它。）

此外，我知道这个问题具体与以下 aesencrypt 行有关：

    const tag = cipher.getAuthTag();
    encrypted += tag;

针对在 go 和 node.js 中加密的同一文件运行 vbindiff，文件开始仅在最后 16 个字节（写入 auth 标签的位置）显示差异。换句话说，go 和 node.js 中的随机数和加密负载是相同的。

由于 getauthtag() 非常简单，而且我相信我使用正确，所以我不知道此时我可以更改什么。因此，我也考虑了这是标准库中的错误的可能性。不过，我想在发布 github 问题之前我应该​​先尝试 stackoverflow，因为这很可能是我做错的事情。

在我设置的存储库中，我对代码进行了稍微更详细的描述，并证明了我如何知道什么是有效的。

提前谢谢您。

更多信息：节点：v14.15.4 go：go 版本 go1.15.6 darwin/amd64

解决方案

在 nodejs 代码中，密文生成为 binary string，即使用 binary/latin1 或 ISO-8859-1 编码。 iso-8859-1 是一个单字节字符集，它将 0x00 到 0xff 之间的每个值唯一地分配给特定字符，因此允许将任意二进制数据转换为字符串而不会损坏，另请参阅 here。

相比之下，cipher.getAuthTag() 不会以二进制字符串的形式返回身份验证标记，而是以缓冲区的形式返回。

当连接两个部分时：

encrypted += tag;

缓冲区使用 buf.toString() 隐式转换为字符串，默认情况下应用 UTF-8 编码。

与 iso-8859-1 不同，utf-8 是一种多字节字符集，它定义分配给字符 s 的长度在 1 到 4 字节之间的特定字节序列。 UTF-8 table。在任意二进制数据（例如身份验证标签）中，通常存在未为 utf-8 定义的字节序列，因此无效。无效字节在转换期间由带有代码点 u+fffd 的 unicode 替换字符表示（另请参阅@dave_thompson_085 的注释）。这会损坏数据，因为原始值丢失。因此utf-8编码不适合将任意二进制数据转换为字符串。

在随后转换为具有单字节字符集binary/latin1的缓冲区时：

return buffer.from(encrypted, 'binary');

仅考虑替换字符的最后一个字节 (0xfd)。

屏幕截图中标记的字节（0xbb、0xa7、0xea 等）都是无效的 utf-8 字节序列，s。 UTF-8 table，因此被 nodejs 代码替换为 0xfd，导致标签损坏。

要修复该错误，标签必须转换为binary/latin1，即与密文的编码一致：

let aesencrypt = (data, key) => {

    const nonce = 'bfvsfgerxsbfia00';                                   // static iv for test purposes only 
    const encoded = buffer.from(data, 'binary');                        
    const cipher = crypto.createcipheriv('aes-256-gcm', key, nonce);

    let encrypted = nonce;
    encrypted += cipher.update(encoded, 'binary', 'binary');             
    encrypted += cipher.final('binary');
    const tag = cipher.getauthtag().tostring('binary');                 // fix: decode with binary/latin1!
    encrypted += tag;

    return buffer.from(encrypted, 'binary'); 
}

请注意，在 update() 调用中，输入编码（第二个 'binary' 参数）将被忽略，因为 encoded 是一个缓冲区。

或者，可以连接缓冲区而不是二进制/latin1 转换后的字符串：

let AESEncrypt_withBuffer = (data, key) => {

    const nonce = 'BfVsfgErXsbfiA00';                                   // Static IV for test purposes only 
    const encoded = Buffer.from(data, 'binary');                        
    const cipher = crypto.createCipheriv('aes-256-gcm', key, nonce);

    return Buffer.concat([                                              // Fix: Concatenate buffers!
        Buffer.from(nonce, 'binary'),                                     
        cipher.update(encoded), 
        cipher.final(), 
        cipher.getAuthTag()
    ]);   
}   

对于 gcm 模式，出于性能和兼容性原因，nist 建议使用 12 字节的随机数长度，请参阅 here, chapter 5.2.1.1 和 here。go 代码（通过 newgcmwithnoncesize()）和 nodejs 代码应用 16 字节的随机数长度与此不同。

以上就是《在 Node.js 中获取 256 位 AES GCM 加密的正确标签时出现问题》的详细内容，更多关于的资料请关注golang学习网公众号！