签名与密钥
SUBFROST 的托管建立在几项已被充分理解的密码学技术之上。本页把它们统一讲清楚：比特币本身已经在使用的 Schnorr 签名、让一个群体能够共同签名的门限方案、生成共享密钥的仪式过程，以及你的密钥在设备上是如何被保护的。
关于这些技术具体如何保障 frBTC 锚定的安全，参见 frBTC 锚定与托管。
Schnorr 签名
Schnorr 签名是比特币在 Taproot 升级（BIP-340）中采用的数字签名方案。它运行在 secp256k1 之上，这正是比特币一直以来使用的椭圆曲线，因此 Schnorr 签名是一种原生的、第一等公民级别的比特币签名。这对 SUBFROST 来说至关重要：这个群体必须生成能够花费真实 BTC 的签名，因此签名方案必须使用比特币自身的“语言”。
Schnorr 有三个特性使它成为这里的正确基石：
- 线性性。 签名和密钥可以干净地相加。多个签名者各自生成一个部分签名，这些部分签名可以组合成一个有效的完整签名。正是这个特性使得门限签名成为可能，而这恰恰是旧式 ECDSA 签名所不具备的。
- 固定且紧凑的大小。 一个 Schnorr 签名是 64 字节。
- 可证明的安全性。 只要离散对数问题依然困难，该方案就在标准假设下是安全的。
由于组合出来的签名是一个普通的 Schnorr 签名，最终落在比特币链上的东西与单密钥花费是无法区分的。链上看不到多重签名；它看到的只是一个签名。
使用 FROST 和 ROAST 的门限签名
SUBFROST 不会把控制托管的密钥交给任何一方。相反，密钥通过 FROST 与 ROAST 这两种门限方案被分散到整个签名者集合中。你可以在 frBTC 锚定与托管 中了解它们。
FROST 与 ROAST 结合起来，让一个由 n 个签名者组成的群体，只有在其中 t 个（门限数量）共同协作时才能生成签名，而任何一个签名者都不会单独持有完整的私钥。
签名分为两个阶段：
- 预计算。 每个参与者提前生成 nonce 材料，并分享其公开部分。这可以在任何具体的签名需求出现之前完成。
- 在线签名。 当需要为某条具体消息（例如一笔比特币提款交易）生成签名时，每个参与者使用自己的密钥份额和预先计算好的 nonce 生成一个部分签名。一个协调者（可以是任意参与者）负责把这些部分签名聚合成一个有效的完整签名。
ROAST 正是让这一切在现实世界中变得稳健的部分：即便部分参与者反应缓慢或掉线，它也能让签名会话继续推进，因此单个无响应的签名者不会拖住整个提款流程。
签名者集合并非一成不变。参与者可以通过一次**重新分享（reshare）**加入或退出，这个过程会把份额重新分配给新的群体，同时保持相同的群体公钥不变，因此托管地址不会改变，也不会发生任何资金转移。
分布式密钥生成
在这个群体能够签署任何东西之前，它必须先就一个共享密钥达成一致。这是通过分布式密钥生成（DKG）完成的，这是一个交互式的仪式过程，参与者共同生成一个单一的群体公钥，而每个人最终只持有对应私钥的一份秘密份额。
其中的关键特性在于，完整的私钥从未在任何地方被拼凑出来过，不在任何一台机器上，即便是低于门限的一小撮合谋者也无法做到。不存在完整密钥曾经存在过、因而可能被窃取的那一刻。这正是整个托管模型赖以立足的基石。
你设备上的密钥
作为用户，你自己也持有密钥：你自己钱包背后的秘密，以及，如果你参与签名的话，你所持有的群体密钥份额。这些都保存在你设备上的一个**密钥库（keystore）**中。
密钥库从不以明文形式保存密钥。当你设置它时，你会选择一个密码短语，然后：
- 该密码短语会通过一个密钥派生函数并配合随机盐值进行拉伸计算。这个过程被刻意设计得很慢，因此即便有人复制了文件，离线猜测密码短语的代价也很高。
- 派生出的密钥使用 AES-256-GCM 加密你的秘密，这是一种经过认证的密码算法，既能保护机密性（数据不可读），也能保护完整性（篡改可被检测到）。
在移动端，这一机制在硬件条件允许的情况下由设备的安全硬件来支撑，在 Android 上使用 StrongBox，在 iOS 上使用 Secure Enclave，因此这把用于保护的密钥可以被绑定到设备本身，永远不会暴露给应用或操作系统。
接下来看什么
- frBTC 锚定与托管：这套签名机制如何保障 frBTC 背后 BTC 的安全。
- 什么是 SUBFROST：全局概览。