Shhh 3.2.4 介绍与选型指南

目标：讲清楚 Shhh 是什么、能解决什么问题、怎么工作、适合谁用，并与同类一次性秘密分享工具做选型对比。本篇为认知与选型篇，全部信息均溯源自官方渠道（GitHub 仓库、官方 README、Docker Hub、Releases 发布历史），关键数据标注了来源与查询日期（2026-10-26）；部署与 API 的逐条实测见姊妹篇 《Shhh 3.2.4 Ubuntu 22.04 源码部署指南》、《Shhh 3.2.4 Docker Compose 部署指南》、《Shhh 3.2.4 配置参数详解》与 《Shhh 3.2.4 API 使用详解》。

一、环境信息

本篇是软件认知与选型文档，不涉及在本机做部署实测，因此本节记录的是信息溯源口径而非服务器环境，便于读者复核文中数据的时效性。

⚠️ 注意：Shhh 项目 README 顶部已明确标注 "Sunsetting..."（日落声明），说明作者正在把精力转向功能等价的继承项目 secretapi。这不影响 Shhh 作为自托管工具继续使用（代码已稳定、版本长期不变），但在「新项目是否选它」的决策里必须把维护状态作为一票否决级因素纳入权衡。详见「六、适用场景与限制」与「七、同类选型对比」。

二、软件概述

2.1 一句话定位

Shhh 的官方口号是 "Keep secrets out of emails and chat logs"（别把秘密留在邮件和聊天记录里）。它是一个自托管的一次性加密秘密分享（one-time encrypted secret sharing）Web 服务：发送人在页面上输入一段敏感文本（密码、API Key、恢复码等），设置一个口令（passphrase）和过期时间，Shhh 生成一个唯一链接；接收人打开链接、输入口令后能看到一次原文，秘密随即从数据库中永久删除。

💡 技术拓展：「一次性秘密分享」（也称自毁消息 / burner message）是一类专门工具，与直接在聊天软件里发密码的差别在于「阅后即焚 + 口令二次保护 + 服务端不存明文」。同类主要选项对比——

方案	原理/特点	适用场景
一次性秘密分享服务	秘密加密存储，读取一次或到期即毁	跨团队/跨公司传递口令、密钥
端到端加密聊天（Signal 等）	消息通道加密，但消息长期留在双方设备	个人日常沟通
密码管理器共享（Vaultwarden 等）	凭据集中管理、可撤销	团队长期共用凭据
加密文件/压缩包 + 口令	离线传递，依赖双方约定渠道	一次性文件交接

Shhh 属于第一类：它不管理长期凭据，只解决「把一段敏感文本安全地递出去一次」这个单一问题，因此部署形态极轻（单应用 + 单数据库）。

2.2 解决的核心痛点

把口令、API Key、恢复码这类敏感信息直接写进邮件、微信/Slack 消息，意味着这些明文会永久留在对方邮箱、聊天服务器日志、备份文件里，事后无法撤回。Shhh 把「传递」和「存储」分离：秘密本体只存在 Shhh 服务器上且强加密、读一次即毁，邮件/聊天里只留一个链接和口令——即使消息渠道被泄露，秘密也已被烧毁或从未在渠道里出现过明文。

2.3 项目身份与现状速览

• 起源与维护：作者 smallwat3r 的个人项目，GitHub 星数 420（shields.io 实时徽章，2026-10-26 查询）。
• 版本节奏：从 Releases 发布历史看约一年 1~2 个版本——3.0.7（2023-09-30）、3.1.0/3.2.0（2023-11-10）、3.2.1（2023-11-18）、3.2.2/3.2.3（2024-11-03）、3.2.4（2025-10-22），功能面已高度稳定。
• 现状：README 顶部声明项目正在 Sunset，后续开发转向继承项目 secretapi（截至 2026-10-26 星数 37，尚处早期）。
• 官方在线演示：shhh-encrypt.com，README 标注 "temporary unavailable until new deployment solution"（临时不可用），因此自托管是目前唯一可靠的体验方式——这与 Shhh「自己的秘密放自己的服务器」的定位也一致。

三、核心架构

3.1 组件构成

Shhh 是典型的单体小型 Web 应用，官方 README 与仓库结构显示的组件分层如下（溯源自 GitHub 仓库源码结构，2026-10-26）：

💡 技术拓展：Shhh 使用的 Fernet 是 cryptography 库内置的一种「带认证的对称加密信封」格式。常见可选方案对比——

方案	原理/特点	适用场景
Fernet	AES-128-CBC + HMAC-SHA256 认证，密文自带时间戳与签名，一行 API 即可用	应用层对称加密存储
AES-GCM（原始 API）	认证加密原语，需自行管理 nonce	有自定义协议需求
PGP/GPG 公钥加密	非对称，收件人私钥解密	邮件加密、无共享口令场景
libsodium sealed box	非对称匿名加密	公钥可知的无口令分发

Shhh 的做法是「口令派生密钥」：官方 README 注明加密方式为 Fernet with password, random salt value and strong iteration count (100 000)——口令不落库，用口令 + 随机盐经高强度迭代派生出 Fernet 密钥加密秘密，因此数据库被拖走也读不出明文。本方案选 Fernet，理由是与 Flask 应用同为 Python 生态、API 极简且自带完整性校验。

3.2 一次分享的生命周期

结合官方 README 描述与源码常量（shhh/constants.py），一条秘密从创建到销毁的机制如下：

1. 创建：发送人提交「秘密原文 + 口令 + 过期时间 + 最大尝试次数」，Shhh 校验口令强度（至少 8 字符、含 1 数字、1 大写）、原文长度（默认上限 250 字符）后，把加密后的密文与元信息写入数据库，返回一个含随机 external_id 的链接。
2. 读取：接收人打开链接输入口令。口令错误会扣减剩余尝试次数并返回提示；口令正确则返回原文，记录随即删除——同一条秘密永远只能被成功读取一次。
3. 销毁：除成功读取外，两个事件也会触发永久删除——过期时间到达（10 分钟到 7 天可选，默认 3 天，APScheduler 每分钟扫描清理）、或尝试次数超限（3/5/10 次可选，默认 5 次，超限后即使用对口令也读不到了）。

这套「过期 + 一次读取 + 暴力破解锁死」三重销毁条件是 Shhh 这类工具的核心安全语义，选型同类工具时应当逐项对照。

四、功能特性

以下功能清单溯源自官方 README 与 GitHub 仓库源码（2026-10-26），每一项在本专栏部署与 API 篇中都有逐条实测回显。

关键差异：功能面上 Shhh 刻意做减法——没有用户体系、没有发送记录、没有文件附件，全部能力围绕「一段文本的一次性传递」展开。这使它非常适合当作「基础设施级的临时信封」，但也意味着需要文件分享、多因素、审计报表的场景要选更重的产品（见第七节对比）。

五、快速开始（最小可用示例）

本节内容溯源自官方 README 的开发部署说明（2026-10-26 查询），给出最快跑通 Shhh 的路径；完整的生产化部署步骤、逐条命令与真实回显见本专栏部署篇。

官方仓库提供了基于 Docker Compose 的开发部署方式（README 原文说明，用于开发目的）：克隆仓库后，在仓库根目录执行：

git clone https://github.com/smallwat3r/shhh.git   # 克隆官方仓库
cd shhh
make dc-start                                      # 启动应用（PostgreSQL 栈）

README 注明镜像构建启动完成后可访问 http://localhost:8081 使用 Shhh（如需附带 Adminer 数据库管理界面可用 make dc-start-adminer，访问 8082 端口）。

打开页面后，最小可用的分享流程只有三步：

1. 在创建页输入秘密文本（如一段临时口令），设置口令（需满足 8 字符 + 数字 + 大写的强度要求，例如 Q1w2e3r4）与过期时间；
2. 页面生成一个形如 http://<host>/secret/<随机串> 的链接；
3. 把链接与口令分渠道发给接收人，对方打开链接输入口令即可读取一次，之后链接永久失效。

⚠️ 注意：官方 make dc-start 路径是开发配置（README 原文 "These instructions are for development purpose only"），使用的是仓库内示例环境变量文件与开发口令。生产部署请按部署篇的完整步骤执行：使用 FLASK_ENV=production、独立数据库口令、并显式完成数据库迁移（迁移是 Shhh 部署的必做步骤，漏做会导致创建秘密时返回 "An unexpected error"——部署篇已实录此排障过程）。

六、适用场景与限制

6.1 适用场景

• 跨人员/跨公司传递临时口令：把服务器初始密码、Wi-Fi 口令、临时账号发给外部协作者，避免明文留在聊天记录。
• 运维值守传递敏感参数：API Key、数据库连接串、恢复码在工单系统外单独投递，读到即毁。
• 自动化脚本内的口令分发：借助 REST API，CI/发布脚本生成一条秘密链接发给值班人，接收人凭口令一次性读取。
• 个人「给自己的便签」：在不受信设备上临时取回某凭据时，先从自己的服务器开一条自取链接。

6.2 限制与边界（选型前必读）

解读：这些限制里，「sunset」是决定性的——Shhh 适合作为已部署即可长期稳定运行的存量工具继续服役（功能封闭、攻击面小、版本冻结反而是优点），但如果你正在为全新场景选型、且希望跟随社区演进，应优先评估继承项目 secretapi 或第七节中的活跃竞品；若团队已有 OneTimeSecret 类服务，也没必要为重复场景再部署 Shhh。

七、同类选型对比

一次性秘密分享领域的主流自托管方案对比如下（星数与版本数据均为 2026-10-26 经 shields.io 徽章与官方 Releases 查询；未标注星数的产品为定性对比，未逐一取证）：

选型建议（「如果……则……」）：

• 如果你要的是最小依赖的一次性文本信封，且接受版本冻结——选 Shhh，Flask + PostgreSQL 两容器即可跑生产。
• 如果要社区最活跃、生态验证最充分——选 OneTimeSecret（3k 星，可参考 《OneTimeSecret v0.26.19 介绍与选型指南》）。
• 如果看重单二进制部署与持续演进，且能接受项目早期——直接上 secretapi（Shhh 的官方继承者）。
• 如果需要文件附件、端到端浏览器加密、多人讨论——选 PrivateBin 或 Yopass，Shhh 只做文本。
• 如果需要团队空间与更细的访问控制——选 Hemmelig 或 Password Pusher 这类偏平台化的产品。

一句话总结：Shhh 是这个品类里「教学级简洁」的实现——代码量小、语义纯正、API 好集成，非常适合作为一次性秘密分享机制的入门实践与轻量生产工具；唯一要带着走的是它已日落维期的现实。

八、参考链接

• GitHub 仓库：https://github.com/smallwat3r/shhh
• 版本发布历史（Releases）：https://github.com/smallwat3r/shhh/releases
• 官方 README（部署/环境变量/API 说明）：https://github.com/smallwat3r/shhh#readme
• Docker Hub 镜像：https://hub.docker.com/r/smallwat3r/shhh
• API 文档（SwaggerHub）：https://app.swaggerhub.com/apis-docs/smallwat3r/shhh-api/1.0.0
• 继承项目 secretapi：https://github.com/smallwat3r/secretapi
• 配套 CLI 客户端 shhh-cli：https://github.com/smallwat3r/shhh-cli
• 本专栏姊妹篇：《Shhh 3.2.4 Ubuntu 22.04 源码部署指南》、《Shhh 3.2.4 Docker Compose 部署指南》、《Shhh 3.2.4 配置参数详解》、《Shhh 3.2.4 API 使用详解》