v3 洋葱地址剖析：56 个字符究竟编码了什么
每个 v3 洋葱地址看起来都像键盘噪音：56 个小写字母和数字，以字母 d 结尾。这最后一个字符并非巧合，字符串里的其他内容也一样。56 个字符中的每一个都按照 Tor 隐匿服务规范（rendezvous specification）中的一小段配方计算而来，它把一个服务的公钥精确地转换成 Tor Browser 将会接受的地址。
56 个字符究竟编码了什么
rendezvous 规范中的编码章节将洋葱地址定义为恰好 35 个字节的 base32 编码，后跟 .onion 后缀：- 第 1–32 字节：服务的 ed25519 身份公钥——其私钥一半为该服务发布的一切内容签名。
- 第 33–34 字节：校验和，取 SHA3-256 对常量字符串 ".onion checksum"、公钥和版本字节计算结果的前两个字节。
- 第 35 字节：版本字段，对第三代地址固定为 0x03。
捕捉拼写错误的校验和
这两个校验和字节的存在，是因为洋葱名称没有注册机构、没有 WHOIS，也没有浏览器自动补全来捕捉笔误。这一设计借鉴自比特币——其 Base58Check 地址会附加类似的哈希派生后缀；当 Tor 的开发者在 2017 年初提出该格式时，他们在一份邮件列表提案中列明了其中的算术："如果地址出现拼写错误，我们有 1/65536 的概率无法检测出该错误。"仅仅一个输错的字符就会改变哈希输入，因此重新计算的校验和几乎不可能匹配，Tor 客户端会在尝试任何连接之前就把该字符串判定为无效并拒绝。大约每 65,536 个错误中只有一个会漏网，而一个通过校验和的拼写错误会落在一个随机的 32 字节密钥上，该密钥几乎肯定不属于任何服务。这一残余风险的代价是两个字节；否则，错误输入的地址解码到哪里，就会无声地连接到哪里。
地址即密钥：无需证书颁发机构
在普通网络上，浏览器之所以相信一个名称属于某个密钥，是因为证书颁发机构如此担保。洋葱地址把这种担保折叠进名称本身。这 56 个字符就是服务的公钥，因此地址不需要注册表，也不可能被签发两次——两个服务无法共享同一个地址，因为每个地址就是一个不同的密钥。Tor 的洋葱服务文档描述了这在连接时如何运作：服务发布一个以其地址中编码的密钥的私钥一半签名的描述符，客户端在建立任何链路之前就验证该签名，确认描述符"只可能出自该洋葱服务，别无他人"。 这就是 Tor 开发者所说的自我认证。Tor Project 2021 年的v3 服务概述也把该格式的隐私收益归功于同一设计：目录中继只接触身份密钥的一个盲化派生量，因此介绍点永远无法得知地址所拼出的公钥。换言之，认证不是通过第三方附加的；它存在于每一个字符之中。私钥泄露意味着什么
把身份集中在一个密钥中，也就把风险集中在一个文件里。任何获得服务私钥的人都可以签署有效描述符、响应引入并完全冒充该服务——而地址上不会有任何异常，因为攻击者使用的是真正的密钥。校验和依然通过，签名依然有效；这种冒充对该格式提供的所有客户端检查都不可见。"如果你的密钥泄露，他人可以冒充你的洋葱服务，使其被视为已被入侵、毫无用处且危险而不可访问。"与泄露的密码不同，这里没有可以轮换的东西：地址无法在不放弃它的前提下更改。Tor 的设置指南把 private_key 文件当作唯一重要的机密，警告运营者将其保密，并建议在服务需要比硬件存活更久时安全地备份。对于从外部观察洋葱服务的人来说，实际的教训是：一个结构上完美的地址只证明字符串完好无损——它对今天是谁掌握着密钥只字未提。
手动验证校验和
整项验证在任何支持 SHA-3 的脚本语言中只需几行代码，步骤直接来自规范：- 去掉 .onion 后缀，确认剩余 56 个 base32 字符。
- 将其解码为 35 个字节：前 32 个是公钥，随后两个是校验和，最后一个是版本字节。
- 把常量字符串 ".onion checksum"、32 字节的密钥、版本字节依次输入 SHA3-256。
- 将摘要的前两个字节与校验和字节比较。匹配即表示字符串被正确复制。