Cryptographic foundations
Every primitive the SDK implements, mapped to the paper or standard that defines it. Useful for security review, regulator engagement, and developers who want to understand what's underneath the API.
Every primitive in the SDK is implemented against a published paper, RFC, or NIST standard. This page is the map — pick a feature and follow the citation to the formative spec. Citations are also inlined on each scheme's documentation page.
| What the SDK does | Reference |
|---|
t-of-n secret sharing over GF(p) — Lagrange interpolation in the combiner, exact for any threshold-sized subset. The core building block under DKG, recovery bundle, and every threshold decryption scheme. | Shamir, A. (1979). How to Share a Secret. Communications of the ACM, 22(11), 612–613. |
| Feldman commitments — each party publishes a commitment to its polynomial so peers can verify the partial shares they receive without reconstructing the secret. | Feldman, P. (1987). A Practical Scheme for Non-Interactive Verifiable Secret Sharing. FOCS '87. |
| What the SDK does | Reference |
|---|
Multi-party DKG with publicly verifiable shares — used by EmbeddedAgent.create() and ClusterAgent.sessions.createKeyShare(). Each party generates a random polynomial, publishes Feldman commitments, distributes encrypted partial shares to peers, and reconstructs its final share once threshold-many partials arrive. | Pedersen, T. P. (1991). Non-Interactive and Information-Theoretic Secure Verifiable Secret Sharing. CRYPTO '91. |
Robust DKG — resilient against up to t-1 malicious parties (the threshold model). | Gennaro, R., Jarecki, S., Krawczyk, H., & Rabin, T. (2007). Secure Distributed Key Generation for Discrete-Log Based Cryptosystems. Journal of Cryptology, 20(1), 51–83. |
The SDK runs a 2-round DKG, a 2-round presigning ceremony, and a 1-round message-signing step — matching the Gennaro-Goldfeder GG18 / GG20 protocol architecture. The cluster session phases (visible in AgentSessionResponse.phase) trace each round directly:
| Ceremony | Round | Network shape | Phase name | What flows |
|---|
| DKG | 1 | Broadcast (every party → every party) | AwaitingPeerCommitments | Feldman commitments to polynomial coefficients, plus optional NIZK proofs of knowledge per coefficient |
| DKG | 2 | Point-to-point (every party → every peer individually) | AwaitingPeerShares | Encrypted partial shares — party i's polynomial evaluated at peer j's index, sealed for peer j's static X25519 key |
| DKG | Local | No network | Reconstructing | Each party verifies received shares against received commitments, sums into its final Shamir share, derives the joint public key |
| Reshare | 1 | Broadcast from old-cohort holders | AwaitingPeerCommitments | Each old holder publishes Feldman commitments to a fresh polynomial whose constant term is its existing share |
| Reshare | 2 | Point-to-point to new-cohort participants | AwaitingPeerShares | Encrypted sub-shares — old holders' polynomials evaluated at the new participants' indices |
| Reshare | Local | No network | Reconstructing | New participants Lagrange-combine threshold-many sub-shares into their fresh shares; the root public key is preserved by design |
| Presigning | 1 | Broadcast | AwaitingPeerCommitments | Feldman commitments to a fresh joint nonce polynomial |
| Presigning | 2 | Point-to-point | AwaitingPeerShares | Encrypted nonce-shares; each party reconstructs the joint nonce point R = k · G while keeping its share k_i private |
| Signing | 1 | Broadcast | CollectingPartialSignatures | Each party publishes its partial π_i = e + R_x · x_i mod n against the message digest e; combiner Lagrange-interpolates locally to recover (r, s) |
Why two rounds and not three. Some threshold ECDSA protocols (notably CGGMP21) add a third round for identifiable-abort accountability — if the ceremony fails, the protocol identifies which party deviated. The SDK's choice is the simpler GG18/GG20 two-round structure with cryptographic fail-fast: per-partial validation in finalizeSignature catches malformed contributions but doesn't attribute blame to a specific cohort member at the protocol layer (the application layer correlates against presigSessionId audit logs instead). The trade-off is faster ceremonies at the cost of needing the application-layer audit trail (see Audit logs) to pinpoint a misbehaving party post-mortem.
The relevant CGGMP21 paper is cited under Threshold ECDSA below for readers who need to compare the SDK's round model to UC-secure multi-round protocols.
| What the SDK does | Reference |
|---|
t-of-n ECDSA signing with offline presigning + online single-round signing. Each party holds a Shamir share of x (the private key); per signature, parties first agree on a presignature (a fresh nonce share + the corresponding R point), then each party publishes a partial signature π_i = e + R_x · x_i mod n against the message digest e. The combiner Lagrange-interpolates the partials to recover (r, s) without anyone ever holding the full x or k. | Gennaro, R., & Goldfeder, S. (2018). Fast Multiparty Threshold ECDSA with Fast Trustless Setup. ACM CCS '18. |
| Presignature pool design — separates the heavy multi-party round (presigning) from the light per-message round (signing), enabling sub-100ms hot-path signing. | Gennaro, R., & Goldfeder, S. (2020). One Round Threshold ECDSA with Identifiable Abort. IACR ePrint 2020/540. |
| Recent academic work on threshold ECDSA that informs the protocol's security analysis. | Canetti, R., Gennaro, R., Goldfeder, S., Makriyannis, N., & Peled, U. (2021). UC Non-Interactive, Proactive, Threshold ECDSA with Identifiable Aborts. ACM CCS '21. |
| What the SDK does | Reference |
|---|
Trusted-dealer threshold RSA (ThresholdRsa.shamirShareD) — the dealer generates (n, e, d), then Shamir-splits d across n holders. Threshold-many partials reconstruct d at combine time. Simple and fast; the dealer is a trust assumption. | Shoup, V. (2000). Practical Threshold Signatures. EUROCRYPT 2000. |
Zero-trust combiner-blind threshold RSA (ThresholdRsa.shamirShareDShoup) — Shoup's "Lagrange in the exponent" technique. The combiner never reconstructs d; even a malicious combiner colluding with threshold-many holders cannot forge unrelated decryptions. The trade-off is per-decryption overhead proportional to (maxShares)!. | Shoup, V. (2000). Practical Threshold Signatures §2.2. Same paper as above; the constructive part of the SDK implements §2.2 directly. |
| What the SDK does | Reference |
|---|
Hashed ElGamal (DHIES) over an EC group — c1 = r·G, K = KDF(r·pk), ct = AES-256-GCM(K, plaintext, nonce). Threshold variant: each holder publishes D_i = y_i · c1; the combiner Lagrange-interpolates to recover s = x · c1 without anyone ever learning x. | ElGamal, T. (1985). A Public Key Cryptosystem and a Signature Scheme Based on Discrete Logarithms. CRYPTO '84. |
| The threshold-decryption pattern (each holder publishes a partial; the combiner interpolates) is the canonical Desmedt-Frankel construction. | Desmedt, Y., & Frankel, Y. (1989). Threshold cryptosystems. CRYPTO '89. |
| The hybrid-encryption analysis used to bound the security of hashed ElGamal under chosen-ciphertext attacks. | Abdalla, M., Bellare, M., & Rogaway, P. (2001). The Oracle Diffie-Hellman Assumptions and an Analysis of DHIES. CT-RSA 2001. |
| What the SDK does | Reference |
|---|
Paillier cryptosystem with the g = n+1 simplification — Encrypt(m) = (1 + m·n) · r^n mod n². Additively homomorphic: Decrypt(Encrypt(m1) · Encrypt(m2)) = m1 + m2 mod n. Exposed as addCiphertexts and scalarMul. | Paillier, P. (1999). Public-Key Cryptosystems Based on Composite Degree Residuosity Classes. EUROCRYPT '99. |
The trusted-holder shape (one party owns the keypair, partials carry the plaintext directly) lifted to a uniform threshold API matching the partialDecrypt / combine shape of the other schemes. | Damgård, I., & Jurik, M. (2001). A Generalisation, a Simplification and Some Applications of Paillier's Probabilistic Public-Key System. PKC '01. |
The threshold-RSA technique (Shoup '00) extends to Paillier via λ-sharing — the SDK's planned multi-party Paillier mode follows the same template. | Fouque, P. A., Poupard, G., & Stern, J. (2000). Sharing Decryption in the Context of Voting or Lotteries. Financial Crypto '00. |
| What the SDK does | Reference |
|---|
| ECDSA over secp256k1 / P-256 / P-384 / P-521 / StarkNet curve. Standards-compliant: produces signatures byte-identical to OpenSSL / Web Crypto / Apple CryptoKit over the same curve. | ANSI X9.62, NIST FIPS 186-4 §6 (ECDSA). |
| Threshold variant — see Threshold ECDSA above. | (See above.) |
| What the SDK does | Reference |
|---|
Ed25519 deterministic signatures — RFC 8032's reference algorithm, byte-identical output to libsodium / Go's crypto/ed25519 / openssh. | RFC 8032 (2017). Edwards-Curve Digital Signature Algorithm (EdDSA). Bernstein, D. J., Duif, N., Lange, T., Schwabe, P., & Yang, B.-Y. (2012). High-speed high-security signatures. Journal of Cryptographic Engineering. |
| Ed448 ("Ed448-Goldilocks") signatures — RFC 8032's Ed448 variant with SHAKE-256-based hashing. | RFC 8032 (2017). Hamburg, M. (2015). Ed448-Goldilocks, a new elliptic curve. IACR ePrint 2015/625. |
| What the SDK does | Reference |
|---|
BIP-340 Schnorr signatures over secp256k1 — used for Bitcoin Taproot. The 32-byte x-only public key format, the tagged_hash domain separation, and the even-Y rule for nonce reduction are all per the BIP. | Wuille, P., Nick, J., & Ruffing, T. (2020). BIP-340: Schnorr Signatures for secp256k1. |
| sr25519 — Schnorr signatures over Ristretto25519 (Substrate / Polkadot). | de Valence, H., Grigg, J., Hamburg, M., Lovecruft, I., Tankersley, G., & Valsorda, F. (2020). The Ristretto Group. |
| Mina / Pallas curve Schnorr — Schnorr over the Pasta cycle. | O(1) Labs (2020). Mina Protocol Specification. |
| Zilliqa EC-Schnorr — the protocol's native scheme. | Zilliqa (2018). The Zilliqa Whitepaper. |
| The original Schnorr construction underlying every above variant. | Schnorr, C. P. (1989). Efficient Identification and Signatures for Smart Cards. CRYPTO '89. |
| What the SDK does | Reference |
|---|
| ML-DSA-44 / ML-DSA-65 / ML-DSA-87 — module-lattice-based deterministic signatures. NIST Levels 2 / 3 / 5. ML-DSA-65 is the FIPS-recommended general-purpose choice. | NIST FIPS 204 (2024). Module-Lattice-Based Digital Signature Standard. Lyubashevsky, V., Ducas, L., Kiltz, E., Lepoint, T., Schwabe, P., Seiler, G., Stehlé, D., & Bai, S. (2018). CRYSTALS-Dilithium: A Lattice-Based Digital Signature Scheme. IACR TCHES. |
| SLH-DSA-SHA2-128f / SLH-DSA-SHA2-192f / SLH-DSA-SHA2-256f — stateless hash-based signatures. NIST Levels 1 / 3 / 5. Conservative threat model with hash-function-only security. | NIST FIPS 205 (2024). Stateless Hash-Based Digital Signature Standard. Bernstein, D. J., et al. (2019). The SPHINCS+ signature framework. ACM CCS '19. |
| What the SDK does | Reference |
|---|
RSA-OAEP-SHA256 padding for ThresholdRsa.encrypt and the Utils.wrap / Utils.unwrap envelope. Byte-identical to OpenSSL's RSA-OAEP-SHA256 output. | RFC 8017 (2016). PKCS #1 v2.2: RSA Cryptography Specifications. Bellare, M., & Rogaway, P. (1994). Optimal Asymmetric Encryption — How to encrypt with RSA. EUROCRYPT '94. |
| What the SDK does | Reference |
|---|
| ECIES-style envelope: ephemeral P-256 keypair, ECDH against the recipient's static P-256 pubkey, HKDF-derive an AES-256-GCM key with the license fingerprint as additional context, wrap and authenticate. | ANSI X9.63, ISO/IEC 18033-2 (ECIES). NIST SP 800-56A Rev. 3 (ECDH key agreement). |
| What the SDK does | Reference |
|---|
| BIP-32 hierarchical deterministic derivation — supported for every secp256k1- and ed25519-family curve. Hardened indices use the private key; non-hardened indices work from the public key alone (watch-only). | Wuille, P. (2012). BIP-32: Hierarchical Deterministic Wallets. |
BIP-44 path layout (m / purpose' / coin_type' / account' / change / address_index) for cross-chain wallet derivation. | Palatinus, M., & Rusnak, P. (2014). BIP-44: Multi-Account Hierarchy for Deterministic Wallets. |
| What the SDK does | Reference |
|---|
| X25519 ECDH for sealing per-peer envelopes inside the agent's intra-cluster ceremony transport. Ephemeral-static pattern: every envelope has a fresh ephemeral X25519 key on the sender side, the recipient's static X25519 pubkey is the long-term identity. | RFC 7748 (2016). Elliptic Curves for Security. Bernstein, D. J. (2006). Curve25519: new Diffie-Hellman speed records. PKC '06. |
| Ed25519 signatures on every transport envelope for peer authentication. | RFC 8032 (see above). |
This map is intentionally explicit. If you're submitting an MPC architecture for security review, regulator engagement, or academic audit, you need to be able to cite the exact construction the SDK implements — not "we use threshold ECDSA" but "we use Gennaro-Goldfeder GG18 threshold ECDSA with Pedersen-style DKG, AES-256-GCM transport envelopes per NIST SP 800-38D, and BIP-32 derivation." The citations above are the answer.
Each scheme's documentation page repeats the most relevant citations inline, so you don't have to dig back to this index every time. Use this page as the master index and the per-scheme pages for context.
