aesgcm在线加密工具

打开浏览器，线加输入一串网址，密工粘贴一段密文，线加点一下按钮——明文出来了。密工整个过程不到一秒钟。线加这就是密工AES-GCM在线加密工具给我的第一印象：快，且干净。线加

我最早接触这个工具是密工在一次前后端联调的时候。后端同事甩过来一个接口文档，线加里面写着“数据使用AES-GCM加密，密工密钥为32位随机字符串”。线加我一看就懵了——我这边是密工纯前端页面，连个加密库都没引。线加找来找去，密工最后在某个技术论坛的线加角落里看到有人推荐了一个在线AES-GCM工具。试了一下，直接把明文和密钥贴进去，点“加密”，输出框里就出现了一串看起来毫无规律的Base64字符。再点“解密”，原文又原封不动地回来了。

说实话，第一次用的时候我心里是犯嘀咕的。把敏感数据贴到网页上，万一这个网站偷偷把数据传到服务器怎么办？后来我看了下这个工具的源码——人家是纯前端实现，所有加密解密都在浏览器本地完成，连个后端请求都没有。这才放心了一些。不过话说回来，如果你处理的是真正的商业机密，我劝你还是别用在线工具，哪怕它再“纯前端”。这不是工具的问题，是浏览器环境本身就不够可控。

AES-GCM本身是个好东西。它不像老旧的ECB模式那样把相同明文加密成相同密文，也不像CBC模式那样需要额外处理填充和初始向量。GCM模式自带认证功能，加密的同时能生成一个认证标签，防止密文被篡改。这意味着你不需要再单独搞一套HMAC来校验完整性——一个算法全搞定了。对于在线工具来说，这省了不少理解成本。

用了几次之后，我慢慢摸清了这类工具的脾气。它们通常不会让你手动输入IV（初始向量），而是每次加密时自动生成一个随机IV，然后把它和密文拼在一起输出。解密的时候，工具会自己从密文里把IV拆出来。这样设计的好处是省心，坏处是——如果你拿到一段密文，想用别的工具解密，可能就解不出来，因为格式不兼容。我遇到过这种情况，密文是AES-GCM工具A生成的，放到工具B里就报“invalid tag”，折腾了半天才发现是IV的拼接方式不同。

所以我的建议是：这类在线工具适合做临时验证、调试算法参数、或者给不懂技术的人应急用。真要上生产环境，还是老老实实写代码吧。Node.js里用crypto模块，Python里用pycryptodome，也就几十行代码的事。但如果你只是偶尔需要解一段别人发来的密文，或者想验证一下自己写的加密逻辑对不对，那在线工具绝对是最快的那条路。

最后说个细节。有一次我用工具加密一段文本，结果发现密文里偶尔会出现“+”和“/”字符。一开始我还以为是bug，后来才想起来这是Base64编码的正常表现。但有些系统里，URL传参会把“+”解析成空格，导致解密失败。所以如果你要把密文放在URL里传，记得先做一下URL编码。这个坑，在线工具不会替你踩，得自己注意。