在日常协作中，我们经常需要向同事或外部团队发送极其敏感的短文本，例如高权限 API Key、数据库临时密码或 Webhook Secret。如果直接通过微信、Slack 或邮件发送，明文信息极易在第三方平台的聊天记录、通知预览、搜索索引或企业归档系统中留下痕迹。
虽然市面上存在许多“阅后即焚”的一次性链接工具，但大多数仍依赖服务器进行存储或中转，其安全性高度取决于服务端的加密实现、密钥存放方式以及是否在后台处理明文。DropLock 则提供了一种截然不同的方案：它是一个端到端加密的秘密共享工具，核心流程完全依赖浏览器本地加密和静态页面分发，甚至将传统的“发送方加密”逻辑进行了反转。
什么是 DropLock？
DropLock 是一款无需后端的端到端加密秘密共享工具。 它并非传统的密码管理器或企业级密钥平台，而是一个极致轻量化的临时传密工具。其核心逻辑由“接收方”驱动：接收方在本地浏览器生成不可导出的私钥，发送方仅能使用对应的公钥进行加密。这种设计确保了服务器端无法接触到明文，极大地降低了凭证泄露的风险。
核心加密流程解析
与大多数“填入密码 $rightarrow$ 生成链接”的工具不同，DropLock 采用了“接收方索要”的逆向机制。虽然增加了一次交互，但却在纯前端环境下构建了一个完整的加密闭环：
1. 接收方创建“锁盒”
作为凭证的接收者，你首先打开 DropLock 页面。此时，浏览器会在本地生成一对公私钥，其中私钥以不可提取的 CryptoKey 形式保存在当前浏览器环境中，不会上传至服务器。随后，页面会生成一个包含公钥的“锁盒链接”，该链接不含任何秘密内容，仅作为加密指令告知发送方。
2. 发送方本地加密
发送方打开锁盒链接后，在浏览器中输入需要传递的 Token 或配置片段。此时，发送方浏览器会利用链接中的公钥在本地完成加密，并生成一个返回链接发回给接收方。
在技术实现上，它采用了混合加密流程：通过 ECDH 派生共享密钥，再经由 HKDF 派生出 AES-GCM 密钥对文本加密。这意味着明文在离开发送方设备前就已经被加密，服务器全程无法窥视内容。
3. 利用 URL Fragment 传输密文
DropLock 的链接结构分为两阶段：接收方的链接携带公钥，而发送方返回的链接将密文存放在 #m= 之后（即 URL Fragment 部分）。由于浏览器在请求网页时不会将 # 之后的内容发送给服务器，因此 DropLock 的服务器仅扮演静态页面分发者的角色，既不保存密文，也无法获取私钥。
DropLock 与同类工具的对比
与 Privnote 或 Yopass 等工具相比，DropLock 的重点不在于“阅后即焚”，而在于尽可能剔除服务器在存储和解密过程中的参与度。
- Privnote 等工具 ：侧重于“一次性读取”的体验，安全性取决于服务端的实现逻辑和日志策略。
- Yopass：支持自托管，适合希望掌控服务端环境的团队，但仍需后端存储加密内容。
- DropLock：通过“接收方预设私钥 $rightarrow$ 发送方公钥加密 $rightarrow$ Fragment 传输密文”的链路，实现了无需后端存储的轻量化传输。
这种模式使得 DropLock 极其易于审查，且非常适合部署在内部静态托管环境中。
使用注意事项与局限性
DropLock 定位于临时传输管道，而非长期的 Secret Manager（如 Vault 或 1Password）。在实际使用时，请注意以下限制：
- 中间人攻击 (MITM) 风险 ：目前工具未提供指纹校验。若攻击者在传输过程中将你的锁盒链接替换为自己的，发送方将把秘密加密给攻击者。对于极高机密数据，建议通过双通道核对链接。
- 私钥绑定设备 ：私钥存储在生成链接时的浏览器环境中。如果你在手机上生成锁盒，则必须使用同一台手机的同一浏览器来解密返回的密文，无法跨设备迁移。
- 缺乏企业级审计 ：该项目未经过专业安全审计，且不具备访问日志和过期控制功能，不能替代专业的密钥管理系统。
适用场景
DropLock 最适合低频、临时、点对点的敏感文本传递。
典型的应用场景包括：开发者之间临时传递 API Key、运维交接短期有效的数据库密码、发送 Webhook Secret 或邀请码等。对于这些内容，虽然篇幅短，但一旦明文泄露，潜在影响较大，使用 DropLock 可以有效规避服务器端的泄露风险。
