图南

客户端侧解密思路是没问题的，但是在某些情况下，我们可能希望在配置中心对敏感配置进行修改和查看，如果服务测能开放 SPI 桥接第三方加解密系统，同时又能通过口令管控加解密的权限，会不会更好一些。

> I think one way is to integrate the encrypt/decrypt process into the apollo portal configuration process which needs some careful design. Another way is to leave the encrypt/decrypt process...

可以提供一个类似于 spring boot 的 EnvironmentPostProcessor，作用于配置文件解析为环境配置对象后的时间点，其实不仅仅是密码的问题，如果用户能介入配置文件加载后的处理过程，就可以完全脱离现有配置文件的束缚，按自己的想法自定义很多行为。

crypto-js 库的性能还可以，该有的东西也都有，密钥可以通过主密码做 PBKDF 衍生，纯前端 JS 实现的话技术路径上应该没有什么障碍。

我大概看了一下 crypto-js 的文档，实现起来倒是不太复杂，但是想要与其他语言做互通的话，需要更改现有的一些数据形式，典型的，目前的『密码/密钥』输入框，需要明确更改为『密钥』输入框，而且需要明确指定密钥格式（base64 | hex）。 密码形式建议不再做支持，crypto-js 如果检测到输入是 string 的时候，会做密钥衍生和随机 iv 生成，对于这种工具性质的应用来说，一般没有什么用处，还会对使用方造成困扰。 国密算法中，目前引入的 sm-crypto 库只对 sm4 的 ECB | CBC 做了支持，想要扩展其他模式的话，工作量有点大，可以暂时不做支持。 我的主技术栈毕竟是 java/golang，对 js 不太熟悉，可以先照猫画虎把算法层实现了，UI 上后期 @baiy 再做调整。 大概这几天，我按照这个思路先实现一版看看。

https://i.goto327.top/CryptTools/SymmCrypt.aspx 这个网站实现的算法比较标准，可以参考一下。😁

我想知道你的对称密钥的生成和保存形式，以及你前端的密钥还原二进制密钥时的做法。 master 分支的代码的确对密钥的处理做了修改，密钥本身应该是一个 16 字节的随机数，它的 Hex 形式应该是 32 长度的字符串。 master 分支现在的做法通过解 Hex 串还原二进制密钥，而之前的做法是直接使用字符串本身的 byte 数组形式。 原则上来讲，master 分支其实是更标准的做法。

目前这个库的 sm4 算法只能接收 `array` 或者 `Hex` 格式的 sm4 密钥，因为你传入的是字符串，所以库默认会**认为你传入的是 Hex 字符串**。 由于 Hex 的表示范围只有 `0 1 2 3 4 5 6 7 8 9 a b c d e f`，你的密钥中含有...

> 在这都能碰见你 哈哈，就这么几个常用库😂

没有，SM2 属于 ECC 体系，我理解解析 PEM 结构走 ECC 的标准即可，你可以直接使用 forge 解析 ECC 的方法解析 SM2 的私钥和证书。