用密码做 AES 加密:把一段文本变成谁也读不懂的密文

我有个常年的小麻烦:需要把一串数据库连接字符串发给同事,或者把一个 API key 暂存进到处同步的云笔记。这些东西以明文出现在邮件和别人服务器上,总让我心里不踏实。后来我固定用一种做法:先把它用密码加密成一段 Base64 密文,只搬这段密文,谁拿到都读不出内容。这篇文章把背后的原理讲清楚,你可以直接在 AES 文本加密器上试。

AES 对称加密到底是什么

AES 全称 Advanced Encryption Standard,2001 年由美国国家标准与技术研究院(NIST)确定为联邦标准,取代了老旧的 DES。它属于对称加密:加密和解密用的是同一个密钥。这一点和你可能听过的非对称加密(比如 RSA、PGP 用一对公钥私钥)不同。

对称的好处是快,而且简单:你和接收方只要共享同一个密码,就能互相加解密,不用搭建一整套密钥分发体系。代价是这个密码必须通过安全的渠道告诉对方,不能和密文走同一条路。

AES-256、密钥和 IV 各自管什么

数字 256 指的是密钥长度 256 位,也就是 AES-256。AES 还有 128 位和 192 位版本,256 位是目前安全余量最大的一档,常被用在需要长期保密的场景里。

但你输入的是一个人能记住的密码,不是 256 位的随机比特。中间需要一个叫密钥派生函数的东西把密码"拉伸"成密钥。这个工具用的是 PBKDF2,配 SHA-256,跑 25 万次迭代:一个随机的 16 字节 salt 和你的密码一起,经过 25 万轮哈希运算,得到一把 256 位密钥。迭代次数高,是为了拖慢别人离线暴力破解的速度。

还有一个常被忽略的角色叫 IV(初始化向量)。AES-GCM 每次加密都生成一个全新的随机 12 字节 IV,作用是让同一段明文、同一个密码,两次加密产生的密文也完全不同。salt、IV 和密文会被打包进一段自描述的负载里,所以解密的人只需要这段字符串加密码,不用单独传密钥文件。

一段文本加密后长什么样

说概念不如看实物。我把一句话 数据库密码是 hunter2,周五前改掉 用口令 meeting-2026 加密,得到的密文大概是这种形态(每次都不同,因为 salt 和 IV 是随机的):

qZ8vKpY2Nf1bL3mX9tR0wA==U7hJ4cD2eF6gH1iK5lM8nP3qS7uV0xZ2aB4cE6gI8kM

它就是 salt(16 字节)、IV(12 字节)、AES-256-GCM 密文加认证标签,三段拼起来再做 Base64 编码的结果。接收方在 AES 文本加密器里粘进去,输入 meeting-2026,点解密,就还原出原话。没有这个口令,这串字符在计算上无法还原。

和哈希的根本区别:加密可逆,哈希不可逆

很多人会把加密和哈希混为一谈,其实它们的目的相反。加密是可逆的:拿对了密钥就能还原出原文,这正是你要的。哈希是单向的:MD5/SHA 哈希工具把任意输入压成一段固定长度的指纹,无法从指纹倒推回原文,通常用来校验文件完整性或存储密码摘要。

所以判断该用哪个,问一句话就够:这段内容以后还要不要读回来。要读回来,用加密;只是想验证有没有被改、或者比对两段内容是否一致,用哈希。

顺带提一个更容易踩的坑:Base64 不是加密。Base64 编码工具只是把数据换一种文本表示,任何人一键就能解码,不需要密码,什么都藏不住。它解决的是"二进制数据怎么走文本通道",不是"内容怎么保密"。把 Base64 当加密用,等于没锁门。

为什么本地加密、不上传这件事很重要

这个工具整套流程都跑在浏览器原生的 WebCrypto 上,随机数来自 crypto.getRandomValues。没有服务器,你的明文、密码、密文都不上传、不记录。它还刻意不往 localStorage 存任何东西,也不把你的输入写进 URL。

因为内容本身是敏感的,任何"为了方便分享"而把数据塞进链接或留在本地的设计,都是在制造泄露面。代价是关掉标签页就什么都不剩,没有历史记录可恢复。对这类工具来说,这恰恰是对的取舍:它不替你保管秘密,只负责在你这台机器上把秘密锁好。

用之前记住三件事

第一,密码别太短。PBKDF2 跑 25 万次迭代能拖慢暴力破解,但救不了一个 6 位密码,对方拿到密文就能在自己机器上慢慢猜,重要内容请用足够长的随机口令。第二,密文要整段复制,一个字符不落,包括结尾的 =,漏字符就解不开。第三,密码和密文别走同一个渠道,也别存在一起,那等于白加密。

把这几条记牢,AES 加密就是一件随手可做、又真的有用的小事。

Made by Toolora · Updated 2026-06-13