Шифрование и дешифрование AES (ключ, выведенный из парольной фразы)
Введите пароль и текст — получите копируемый шифртекст; верните шифртекст с паролем, чтобы получить исходный текст
① 加密：文字 + 口令 → 密文串
口令强度提示：长度与字符种类越多越难被暴力尝试（仅提示，不阻断使用）
迭代次数写在密文串里，解密时按密文串自身的记录执行，所以改这里只影响新加密的内容。手机上调太大（如 60 万）会明显变慢。
格式：QPS1.算法.迭代次数.base64(salt).base64(iv).base64(密文)。AES-GCM 的认证标签由 WebCrypto 附在密文末尾，所以不需要单独一段。这串密文自带全部参数，只要口令对、算法在，任何能跑本页的浏览器都能解开。
② 解密：密文串 + 口令 → 文字
密文串第二段写着用的是 AES-GCM 还是 AES-CBC、第三段是迭代次数，解密时不需要你再选一次；填错版本号或字段缺失会在下方就地报错。
只用 GCM 与 CBC 两个模式，口令错误与数据被篡改在两种模式下都表现为同一类失败：GCM 的认证标签校验不过、CBC 解出来不是有效文本，因此本页不会替你判定"是口令错了"还是"密文被动过"，只会如实说口令错误或数据被篡改。解密失败时结果区不会显示任何内容，绝不会把乱码当成功给你。
使用前请先看清楚：本页适合什么、不适合什么
① 这是本地、面向小数据的工具，不要用于生产密钥或敏感数据管理。适合把一段临时文本（配置片段、测试账号备注、一段要给同事的话）用口令加成一串密文发出去；不适合承载长期凭证、客户数据、私人证件信息。真要管理密钥与密码，请用专门的密码管理器。
② 安全性由口令强度决定，弱口令等于没加密。本页用 PBKDF2-SHA256 把口令派生成密钥（默认 15 万次迭代，可调高），迭代次数只能让暴力尝试变慢，不能补救"123456"这种口令。口令越短、字符种类越单一，被猜出来的代价就越低。
③ 加密算法来自浏览器（WebCrypto），不是我们自己写的密码学，但格式与参数由本页定义。AES、PBKDF2 都是浏览器内核实现的标准算法，本页只是按固定参数调用它们；而密文串的格式（QPS1 前缀与六段结构）是本页自己定的，所以与其它在线工具、命令行 openssl 生成的密文不一定互通——除非对方按同样的参数（PBKDF2-SHA256、同样的 salt/iv、GCM 标签 128 位）自己拼装。
④ 口令与明文不会上传，也不会留在本机。整页没有任何网络提交：口令与内容只作为 WebCrypto 的入参参与运算，不进网址、不写浏览器本地存储、不打印到控制台；密文串需要你自己复制带走。关掉页面，输入框里的东西就没有了。
关于"口令加密"这件事，你需要知道的几件事
口令不是密钥，中间必须有一次"派生"。AES-256 需要一把 32 字节、看起来完全随机的密钥，而人记得住的口令往往只有十几个字符，还常是词典里的词。直接把口令截断或填充当密钥用，会把密钥空间压缩到口令的规模——攻击者不用碰 AES，只要反复猜口令即可。所以本页先用 PBKDF2-SHA256 把口令"拉伸"成 256 位密钥：它把口令和一段随机 salt 一起做十多万次带哈希的迭代，每次猜测都要付出同样的计算代价。默认 15 万次是常见的折中（桌面端约几十毫秒），你可以调高到 30 万、60 万让每次尝试更贵，代价是自己也得等更久。迭代次数写在密文串里，解密时按它执行，因此调高不会让旧密文失效。
salt 与 iv 各自解决一个不同的问题，都不能省。salt 是给密钥派生用的随机数：没有它，同一个口令在任何地方都会派生出同一把密钥，攻击者可以预先算好"常见口令 → 密钥"的对照表（彩虹表），一次算好到处复用；有了随机 salt，同样的口令每次派生出不同密钥，预计算就失效了。本页每次加密都生成 16 字节随机 salt。iv（初始向量）是给 AES 分组加密用的：它保证同样的明文、同样的密钥，两次加密出来的密文也不同（本页每次生成 12 字节随机 iv）。如果 iv 固定，相同明文会产生相同密文，攻击者不用解密就能看出"这两段内容一样"，这在真实场景里经常直接泄漏信息。所以 salt 保护的是"口令 → 密钥"这一步，iv 保护的是"明文 → 密文"这一步，两者都在密文串里明文存着，公开它们不影响安全。
GCM 与 CBC 的区别是"认不认证"。AES-GCM 属于 AEAD（带关联数据的认证加密）：它在加密的同时算一个认证标签，解密时会先校验标签，只要密文、iv 或口令有任何一处不对，就整体拒绝并抛错——既解不出内容，也不会给你一段"看起来像明文"的垃圾。它还自带完整性保护，能挡住攻击者悄悄改动密文里的比特。AES-CBC 是更老的模式，只做加密、不做认证：它不校验任何东西，密文被改动一个字节，解密照样"成功"，只是解出来是乱码；攻击者还能利用这一点做 padding oracle 之类的攻击（服务端场景尤甚）。因此本页默认用 GCM，把 CBC 保留为兼容选项，并在选中时明确提示"不校验完整性、建议用 GCM"。另外，CBC 需要把明文补齐到 16 字节的整数倍，那部分填充规则也让它在面对篡改时更脆弱。
为什么这一页只做小数据，而不是当密码管理器用。把"加密/解密一个文本框"做得可靠，和"长期保管你的密码"是两件事。密码管理器要解决的是密钥怎么来（主密码 + 密钥文件）、条目怎么组织、怎么同步、怎么备份、设备丢了怎么办、主密码忘了怎么恢复——这些本页一个都没有：口令只存在你的脑子里，忘了就是真的打不开，密文串丢了也没有任何副本，浏览器一关输入框就清空。本页的价值在于"临时、一次性、小体积"的加密需求：给同事发一段配置片段、把一段笔记用口令包起来放进草稿箱、在共享文档里贴一段不希望被随手看到的文字。真要存长期凭证，请交给专业工具。
为什么加密不是"打开网页就算一遍"的事，而本页坚持不上传。任何"在线加密"服务，只要它把口令发到服务器，服务器就能在派生的那一刻拿到明文口令——加密就成了替别人保管秘密。浏览器内置的 crypto.subtle（WebCrypto）让我们可以完全在本地完成 AES 与 PBKDF2：口令与明文从输入框直接进入浏览器内核的加密例程，中间没有任何网络往返，也不会在浏览器本地存储里留下任何副本。这也带来一个必须说清的限制：WebCrypto 只在安全上下文（https 或 localhost）下可用，所以我们不会假装"http 也能用"，而是检测不到时直接告诉你换成 https 访问。至于"这段加密靠不靠得住"，请把它理解为：算法是浏览器厂商实现的成熟标准，参数与格式由本页定义并公开写在页面上，你可以自行核对；我们不对你的使用场景做任何安全承诺。
Частые вопросы
Нет. В строке шифра лежат только алгоритм, число итераций, соль, iv и сам шифр - ни копии фразы, ни канала «восстановить фразу», что и есть источник его стойкости. Храните фразу отдельно - в памяти или в собственном менеджере паролей, не рядом со строкой шифра.
По умолчанию они не стыкуются напрямую. Шестисегментный формат - собственное изобретение страницы (QPS1 - версия): другому инструменту сначала надо бы разрезать соль и iv по тем же правилам, вывести тот же ключ PBKDF2-SHA256 и расшифровать GCM со 128-битным тегом аутентификации. Совместимость мы намеренно не открываем, чтобы простое и проверяемое обещание держалось: все параметры едут внутри строки шифра - тому, кто держит строку, параметры не нужно угадывать.
Мы не различаем и не можем (говорим как есть, не сочиняя одно из двух). При сбое проверки AES-GCM браузер бросает один и тот же OperationError на всё: неверная фраза, изменённая соль, изменённый iv, тронутые байты шифра - выглядят одинаково. CBC тем более: он ничего не проверяет, при неверной фразе выходит негодный текст, который можно только оценить как провал. Проверяйте по порядку: совпадает ли фраза с шифровавшей до символа (регистр, пробелы, полноширинный против полуширинного ввода); не переносила ли, не обрезала ли и не подменяла ли символы переписка в мессенджере.
GCM в приоритете: у него проверка целостности - тронутый шифр даёт явную ошибку, а не правдоподобную кашу. CBC берите, только если нужно состыковаться со старой системой, знающей лишь CBC, - и примите риск непроверяемой целостности. По итерациям: стартуйте со 150 тысяч - на десктопе десятки миллисекунд, на телефоне около сотни-двух; 300k или 600k медленнее, но перебор заметно тяжелее. Один и тот же открытый текст под одной фразой дважды шифруется в совершенно разные шифры - это нормальное поведение случайных соли и iv, и оба результата раскрываются обратно.
Потому что страница опирается на встроенный crypto.subtle, который браузеры выдают только в безопасном контексте (https или localhost); на http-странице там undefined. Если мы его не находим, страница прямо сверху просит https, вместо того чтобы делать вид, что клики работают. Старые движки (IE, некоторые встроенные браузеры приложений) API тоже не дают - возьмите свежий Chrome / Edge / Firefox / Safari. Всё выполняется на вашей машине; даже при неудачной проверке страница никогда тайком не деградирует в «отправим содержимое шифроваться на сервер» - такого пути в коде здесь просто нет.