Shamir's Secret Sharing 与 Drop 的混合模型
钱包如何保护您的密钥，看起来是一个技术选择。它同时也是一个关于人的选择：谁可以动用您的资金，谁可能把它弄丢，以及您必须信任谁。技术决策就是道德决策。
安全模型页面介绍了 Drop 如何保护您的密钥。本页讨论其背后的一项决策：我们为什么不使用 Shamir's Secret Sharing 这种最常见的密钥拆分方式，以及这一选择的代价。
Shamir's Secret Sharing 简介
Shamir's Secret Sharing（SSS）将私钥拆分成称为份额的若干部分，并让您选择需要多少份才能重建私钥，例如 3 份中的任意 2 份。持有份额不足的人无法获知关于密钥的任何信息，丢失一份份额也不会丢失密钥。该方法诞生于 1979 年，在整个行业中广泛使用。
典型的 SSS 钱包在您的设备上保存一份份额，在服务提供方保存一份，另有一份恢复份额由您自己保管。
Drop 则将密钥拆分为两份份额，并且两份始终都需要。不存在像 SSS 那样能够重建私钥的额外份额。
三项决策
备用份额由谁保管？
使用 SSS 时，由您保管。可以丢失一份份额是它最大的吸引力，而这依赖于存放在某处的备用份额：一个文件、一个云盘、一份打印出来的代码。这又多了一样您可能丢失或泄露的东西。
使用 Drop 时，没有备用份额，您也不需要额外保管任何东西。
代价：份额不能丢失，因此备份的责任落在我们以及您的第二台设备上。
东西被盗时，会询问谁？
使用 SSS 时，可能谁也不问。如果恢复份额与设备份额放在了一起，在同一部手机、同一个云账户或同一份笔记本电脑备份中，那么进入这一处的人就拥有了完整的密钥。没有批准步骤、没有限额、也没有警报，因为两份份额就足够了。
使用 Drop 时，被复制的文件或被盗的备份永远不够。使用受支持的通行密钥时，您这一侧的份额离开该通行密钥就毫无用处，而我们的服务只会为您的通行密钥批准的请求释放另一份份额。
运算中可能出多少差错？
使用 SSS 时，比您预想的要多。它依赖的运算留有普通测试发现不了的出错空间。Privy 的开源库构建严谨、使用广泛，但一次独立审计发现，在某些情况下，少于预期数量的份额就能恢复秘密的一部分。Privy 修复了这个问题并公开撰文说明。SSS 也无法判断某份份额是否有误：合并一份错误的份额会在没有任何警告的情况下得到另一个密钥。
使用 Drop 时，两份份额以最简单的方式合并。这保留了 SSS 受重视的特性，即单独一份份额不泄露任何信息，同时可能出错的地方少得多。Drop 还会在使用前检查重建出的密钥是否与您钱包的地址相符。
代价：灵活性。“3 份中的任意 2 份”正是那些额外运算换来的。
我们如何弥补这些代价
- 我们这一侧的三份备份。 目前我们为加密的服务器端份额保留三份备份，并可能扩展为更多副本：一份在备份数据库中，一份在独立且隔离的 AWS 账户的数据库中，一份在离线硬件中
- 您这一侧的第二台设备。 使用备份通行密钥配对一台设备，这样丢失一台设备不会让您无法访问
- 一条退路。 您可以随时导出私钥。从那时起，那份副本只能由您自己保护