当前位置: 首页 > news >正文

node 后端和浏览器前端,有关 RSA 非对称加密的完整实践, 前后端匹配的代码演示

前言

前天,写了一篇文章《我设计的一个安全的 web 系统用户密码管理流程》,里面提到了有关非对称加密 RSA 的一些事情。思想归思想,实践要重于理论,所以我想趁周末,来完成这个时间。

结果发现现实比理想要困难许多,这事儿折腾了我昨儿一天,今天,终于完成了。

主要困难点有如下:

  1. 之前我们的 RSA 一般使用 pkcs1 格式。但是在最新的 NODE v22 版本中,这种格式被认为是不安全的,所以要改。(或许之前的版本就更新了,这里我没去查升级日志,只确定 v22+ 肯定是不行)
  2. 之前我们前端代码中经常使用的 JSEncrypt 库已经好几年不更新了,对最新的规范支持不完整。
  3. 我一直使用的 1024 的秘钥,结果这里也出现了问题。

也就是说,我之前代码跑得好好的,经过这么一升级,代码烂了!!!

中间我踩过的坑太多了,字字泣血,这里只展示最终成果吧。

生成秘钥

# 生成私钥
openssl genrsa -out src/config/key/rsa_private_key.pem 2048
# 生成公钥
openssl rsa -in src/config/key/rsa_private_key.pem -pubout -out src/config/key/rsa_public_key.pem

NODE 后端

在后端时间库的选择上,我一开始选择的是 node-rsa 库,但是在不断的调整中,最后选择了 node-forge 库。

但,我并不确定 node-rsa 库是有问题的,因为最终我发现我的问题并不是后端的问题,而是我前端的问题。以下代码是可用的,如果我等下还有心情,我再尝试一下 node-rsa

import { readFile } from 'node:fs/promises'
import { RSA_KEY } from '@/config'
import * as forge from 'node-forge'const { RSA_PRIVATE_KEY_PATH, RSA_PUBLIC_KEY_PATH } = RSA_KEY// 公钥加密方法
export const encrypt = (str: string) => {return new Promise((resolve, reject) => {readFile(RSA_PUBLIC_KEY_PATH, 'utf-8').then((data) => {try {const publicK = forge.pki.publicKeyFromPem(data)const res = publicK.encrypt(str, 'RSA-OAEP', {md: forge.md.sha256.create(),mgf1: forge.md.sha256.create(),})const Base64Res = forge.util.encode64(res)resolve(Base64Res)} catch (e) {reject(new Error(`RSA加密失败: ${e.message || e}`))}})})
}// 私钥解密方法
export const decrypt = (str: string) => {return new Promise((resolve, reject) => {if (!str || typeof str !== 'string') {return reject(new Error('RSA解密失败: 无效的输入'))}readFile(RSA_PRIVATE_KEY_PATH, 'utf-8').then((data) => {try {const privateK = forge.pki.privateKeyFromPem(data)const base64Str = forge.util.decode64(str)const res = privateK.decrypt(base64Str, 'RSA-OAEP', {md: forge.md.sha256.create(),mgf1: forge.md.sha256.create(),})resolve(res)} catch (e) {reject(new Error(`RSA解密失败: ${e.message || e}`))}})})
}

浏览器前端

在JSEncrypt 确认不可用的前提下,我找了很多资料,遇到了很多坑。经过不断的研究,我决定,不使用任何库类,而是直接使用现代浏览器支持的 Web Crypto API 特性。
Web Crypto API 的支持情况
如上图所示,Web Crypto API 已经被广泛的现代浏览器所支持了。估计,这也是为什么 JSEncrypt 这个库不更新了的原因。

完整代码如下:

async function importPublicKey(pem: string) {const pemHeader = "-----BEGIN PUBLIC KEY-----"const pemFooter = "-----END PUBLIC KEY-----"const pemContents = pem.replace(pemHeader, "").replace(pemFooter, "").replace(/\s+/g, "")const binaryDer = base64ToArrayBuffer(pemContents)return await window.crypto.subtle.importKey("spki",binaryDer,{name: "RSA-OAEP",hash: { name: "SHA-256" }},true,["encrypt"])
}function base64ToArrayBuffer(base64: string) {const binaryString = atob(base64)const bytes = new Uint8Array(binaryString.length)for (let i = 0; i < binaryString.length; i++) {bytes[i] = binaryString.charCodeAt(i)}return bytes.buffer
}export async function encrypt(publicKeyStr: string, message: string) {const importedPublicKey = await importPublicKey(publicKeyStr)const encrypted = await crypto.subtle.encrypt({ name: "RSA-OAEP" },importedPublicKey,new TextEncoder().encode(message))// 将加密后的二进制数据转换为 base64 字符串return btoa(String.fromCharCode.apply(null, new Uint8Array(encrypted)))
}

主要关键点是,从接口拿到后端的公钥后,需要去头去尾,转换一下格式,才能被使用。

好的,以上代码都是在 node v22 环境下验证可用的,预计短期几年内应该不会有太大变化。

后记

其实,以上代码写出来还好,我遇到把我卡住的关键点是我服务端使用的是 1024 的秘钥。而使用这个秘钥,用来加密 sha256 的 hash 值的时候一直报错。我一直以为是我前后端代码没搞好的问题。但是,经过不断的调试猛然发现,其在加密短字符串的时候是没问题的,而 sha256 的 hash 值是 64 位的长度。

在我抓耳挠腮的时候,我福至心灵,把服务端的秘钥换成 2048 的秘钥后,所有问题就都解决了,顿时间,拨云见日。

最终,我查看资料,知道 使用 ‌SHA-256‌ 时,1024 位 RSA-OAEP 加密支持单次最大 ‌62 字节明文‌。这里,多出了2个字节。

好吧,我今天可以睡个好觉了!祝各位看官,安康!

相关文章:

  • 从零开始实现大语言模型(十六):加载开源大语言模型参数
  • Flink 并行度的设置
  • 给个人程序加上MCP翅膀
  • 基于labview的声音采集、存储、处理
  • GitHub 趋势日报 (2025年05月17日)
  • C++(243~263)STL常用算法、遍历算法(for_each,Transform)、查找算法、拷贝和替换、常用算术生成,常用集合算法。
  • C++学习:六个月从基础到就业——C++17:if/switch初始化语句
  • 【随机过程】贝叶斯估计
  • 【计算机网络】第一章:计算机网络体系结构
  • TIMER免疫浸润分析
  • 轻量级视频剪辑方案:FFmpeg图形化工具体验
  • 国内人工智能行业研究报告 投资要点
  • Spring Cloud 技术实战
  • 非线性1 修改
  • 23种设计模式解释+记忆
  • 5.18本日总结
  • VMware虚拟机磁盘扩容与LVM分区操作指南
  • GC全场景分析
  • Redis进阶知识
  • 服务端高并发分布式结构演进之路
  • 三星“七天机”质保期内屏幕漏液被拒保,澎湃介入后已解决
  • 全球前瞻|特朗普19日将与俄乌总统分别通话,英国脱欧后首开英欧峰会
  • AI创业者聊大模型应用趋势:可用性和用户需求是关键
  • 高温最强时段来了!北方局地高温有明显极端性
  • 人民网:激发博物馆创新活力,让“过去”拥有“未来”
  • 小米汽车回应部分SU7前保险杠形变