📋 Tóm tắt — Đọc trong 60 giây
SSS: Toán Học Chia Secret Không Mất Thông Tin
Shamir Secret Sharing (SSS) là thuật toán mật mã cho phép chia một secret (private key, seed entropy) thành N shares, sao cho bất kỳ K shares nào (K ≤ N) có thể reconstruct secret đầy đủ, nhưng K−1 shares bất kỳ không tiết lộ bất kỳ thông tin gì. Tính chất bảo mật này là information-theoretic — không thể phá dù có máy tính lượng tử.
Điểm yếu cốt lõi: để dùng secret (ví dụ ký transaction), phải reconstruct đầy đủ tại một máy — tạo ra điểm tấn công tạm thời. Đây là lý do MPC (TSS) ra đời để khắc phục cho operational signing. SSS vẫn là giải pháp tốt nhất cho backup và recovery dài hạn.
01 · Cơ chế
Polynomial bậc K−1, secret là f(0), shares là f(1)…f(N)
02 · Bảo mật
Information-theoretic: K−1 shares không tiết lộ gì về secret
03 · SLIP-39
Chuẩn Trezor: chia master seed thành mnemonic shares
04 · Giới hạn
Cần reconstruct key tại một máy — MPC tốt hơn cho signing thường xuyên
SSS được đề xuất bởi Adi Shamir — đồng tác giả RSA — năm 1979 trong paper "How to Share a Secret". Đây là một trong những paper cryptography ngắn nhất (chỉ 4 trang) nhưng ảnh hưởng nhất trong lịch sử bảo mật.
Ý tưởng cốt lõi dựa trên một tính chất hình học đơn giản:
- Hai điểm xác định duy nhất một đường thẳng (polynomial bậc 1).
- Ba điểm xác định duy nhất một parabol (polynomial bậc 2).
- K điểm xác định duy nhất một polynomial bậc K−1.
SSS khai thác tính chất này: secret là giá trị của polynomial tại x = 0. Các shares là giá trị tại x = 1, 2, 3, …, N. Với đủ K shares, có thể xác định polynomial duy nhất và tính f(0) = secret. Với K−1 shares, có vô số polynomial bậc K−1 pass qua K−1 điểm đó — không thể biết cái nào đúng, do đó không học được gì về secret.
🔬
Bối cảnh lịch sử
Cùng năm 1979, George Blakley cũng phát minh một scheme tương tự dựa trên hyperplane geometry thay vì polynomial — hai phương pháp độc lập, cùng giải quyết bài toán. SSS của Shamir trở nên phổ biến hơn vì hiệu quả hơn về mặt kích thước shares. Cả hai đều có tính chất information-theoretic security — khác với các scheme sau này dùng computational security.
Ứng dụng trong blockchain
Trong context wallet security, secret cần được chia thường là:
- BIP-39 entropy (128 hoặc 256 bit ngẫu nhiên tạo ra seed phrase) — chia entropy, mỗi share là một chuỗi bytes.
- Master private key — chia trực tiếp key 256-bit.
- Decryption key của encrypted backup — chia key dùng để decrypt một database.
Kết quả: thay vì lưu một seed phrase duy nhất (single point of failure), bạn phân phối N shares đến N vị trí/người khác nhau. Mất bất kỳ N−K shares nào vẫn recover được; kẻ tấn công cần đủ K shares mới có thể dùng.
Toán học của SSS hoạt động trên finite field GF(p) — tập số nguyên modulo một số nguyên tố p. Phải dùng finite field thay vì số thực để tránh floating point errors và đảm bảo tính chất information-theoretic. Trong thực tế, p thường là 2²⁵⁶ hoặc một số nguyên tố 256-bit lớn.
Để recover secret từ K shares, dùng Lagrange interpolation — công thức toán học xác định duy nhất polynomial bậc K−1 khi biết K điểm trên đó, rồi tính giá trị tại x = 0:
# Ví dụ minh họa: 2-of-3 SSS trên GF(7)
# Secret = 3, threshold K = 2, shares N = 3
# Bước 1: Tạo polynomial bậc K-1 = 1
# f(x) = a0 + a1*x (mod 7)
a0 = 3 # secret — hệ số tự do
a1 = 2 # random coefficient
# Bước 2: Tạo 3 shares: (x, f(x) mod 7)
share1 = (1, (3 + 2*1) % 7) → (1, 5)
share2 = (2, (3 + 2*2) % 7) → (2, 0)
share3 = (3, (3 + 2*3) % 7) → (3, 2)
# Bước 3: Recovery chỉ dùng share1 (1,5) và share3 (3,2)
# Lagrange basis tại x=0:
# L1(0) = (0-3)/(1-3) mod 7 = (-3)/(-2) = 3 * modinv(5,7) = 3*3 = 9 ≡ 2 (mod 7)
# L3(0) = (0-1)/(3-1) mod 7 = (-1)/(2) = 6 * modinv(2,7) = 6*4 = 24 ≡ 3 (mod 7)
# f(0) = y1*L1(0) + y3*L3(0)
f_0 = (5*2 + 2*3) % 7
= (10 + 6) % 7
= 16 % 7
= 3 ✓ (đúng secret!)
Trong thực tế, p là số nguyên tố 256-bit và các shares là byte strings dài tương đương. Thư viện như python-secretsharing, secrets.js (JavaScript), hay tss-lib xử lý toàn bộ chi tiết modular arithmetic này.
🔐
Information-theoretic security — Tại sao mạnh hơn AES?
AES-256 an toàn vì tấn công brute-force không khả thi về mặt tính toán — nhưng về lý thuyết, nếu có máy tính đủ mạnh, có thể phá. SSS với K−1 shares mạnh hơn theo nghĩa toán học: kẻ tấn công có thể thử mọi giá trị possible của secret và tất cả đều "có vẻ đúng" với K−1 shares họ đang có. Không có thông tin nào để phân biệt đúng/sai — ngay cả máy tính lượng tử cũng không giúp được.
Cấu hình K-of-N có hai tham số: K (threshold) là số shares tối thiểu cần để recover, và N (total) là tổng số shares tạo ra. Chọn đúng K và N là bài toán cân bằng giữa security (K cao hơn = khó attack hơn) và availability (K thấp hơn = dễ recover hơn).
| Cấu hình | Chịu mất tối đa | Phù hợp khi | Rủi ro |
|---|
| 2-of-3 |
1 share |
Cá nhân hoặc small team, recovery dễ |
2 shares bị compromise cùng lúc là mất |
| 2-of-5 |
3 shares |
Redundancy cao, phân tán rộng |
Threshold thấp — chỉ cần 2 trong 5 bị lộ |
| 3-of-5 |
2 shares |
Tổ chức, board quản lý |
Cần 3 người cùng tham gia recovery |
| 4-of-7 |
3 shares |
High-value institutional backup |
Phức tạp trong vận hành |
| 5-of-9 |
4 shares |
Rất phân tán, chịu được nhiều mất mát |
Nếu distribution kém sẽ tạo false sense of security |
⚠️
Ronin Bridge — 5-of-9 đúng cấu hình nhưng sai distribution
Ronin Bridge ($625M hack, 2022) dùng 5-of-9 multisig — về mặt số học là cấu hình tốt. Nhưng 4 trong 9 validator nodes đều thuộc Axie Infinity, và 1 node thuộc một đối tác tin cậy. Kẻ tấn công (có khả năng là Lazarus Group) compromise được 5 nodes liên quan. Bài học: N-of-M scheme an toàn đến mức nào phụ thuộc vào
independence của distribution — không chỉ con số K và N. Điều này áp dụng cho cả SSS lẫn Multisig.
Nguyên tắc phân phối shares
- Vật lý tách biệt: Mỗi share lưu ở địa điểm khác nhau — không cùng tòa nhà, không cùng thành phố với các share khác.
- Người giữ độc lập: Các người giữ share không có quan hệ tổ chức hay gia đình — để tránh một compromise dẫn đến nhiều shares bị lộ.
- Không lưu metadata: Người giữ share không cần biết (và không nên biết) bao nhiêu share tổng cộng, ai giữ share nào.
- Đánh số thứ tự, không đánh nhãn nội dung: Share chỉ cần label "Share 1/3" — không label "Private key của ví ETH công ty."
SSS và Multisig đều yêu cầu nhiều bên tham gia, nhưng hoạt động ở hai tầng hoàn toàn khác nhau và phù hợp với các mục đích khác nhau.
| Tiêu chí | SSS | Multisig (Gnosis Safe) |
|---|
| Tầng hoạt động | Off-chain, thuần mật mã | On-chain, Smart Contract |
| Key reconstruction | Cần reconstruct full key tại một máy | Không reconstruct — từng signer giữ key riêng |
| Signing flow | Collect shares → reconstruct → sign → dùng xong xóa | Từng signer ký riêng → submit on-chain |
| Audit trail | Off-chain — ai collect shares? Không có record on-chain | Mọi approval visible trên block explorer |
| Chain support | Mọi blockchain và hệ thống (off-chain) | Chỉ EVM chains có Smart Contract support |
| Gas cost | Không tốn gas | ~50–100k gas overhead mỗi transaction |
| Phù hợp nhất | Long-term key backup, disaster recovery | Operational treasury, DAO governance |
Kết luận thực tế: SSS và Multisig không phải thay thế nhau — nhiều tổ chức dùng cả hai: Multisig để vận hành hàng ngày (transparency, auditability), SSS để backup master keys trong trường hợp disaster recovery khi toàn bộ multisig setup bị mất.
Xem thêm Multisig Wallet Là Gì? Gnosis Safe và M-of-N Setup.
Đây là so sánh quan trọng nhất để hiểu SSS nên được dùng ở đâu và không nên dùng ở đâu.
SSS vs MPC — Điểm Khác Biệt Cốt Lõi Khi Signing
SSS (Shamir Secret Sharing):
Party A ─ Share A ─┐
Party B ─ Share B ─┤ RECONSTRUCT → Full Key → Sign → Xóa key
Party C ─ Share C ─┘
↑ Key tồn tại tại một điểm — attack window!
MPC / TSS:
Party A ─ Share A ─┐
Party B ─ Share B ─┤ MPC PROTOCOL → Valid Signature
Party C ─ Share C ─┘ (multi-round interactive)
↑ Full key KHÔNG bao giờ tồn tại ở bất kỳ đâu
| Tiêu chí | SSS | MPC / TSS |
|---|
| Key reconstruction | Cần reconstruct tại 1 máy | Không bao giờ reconstruct |
| Attack window | Tồn tại khi reconstruction diễn ra | Không có attack window |
| Parties online cùng lúc | Không cần — collect shares rồi reconstruct offline | Phải online đồng thời (liveness requirement) |
| Complexity | Đơn giản — toán học rõ ràng | Phức tạp — giao thức nhiều round |
| Implementation risk | Thấp — well-understood | Cao hơn — bugs trong protocol có thể nghiêm trọng |
| Phù hợp cho | Backup, disaster recovery, infrequent use | Operational signing, hot wallet, frequent use |
Nếu frequency signing cao (hàng ngày hoặc nhiều lần mỗi ngày), MPC là lựa chọn tốt hơn vì không có risk mỗi lần signing. Nếu signing hiếm (vài lần mỗi năm, emergency recovery), SSS đơn giản và đủ an toàn.
Tìm hiểu chi tiết hơn về MPC tại MPC Wallet Là Gì?
SLIP-39 (Shamir's Secret Sharing for Mnemonic Codes) là chuẩn được phát triển bởi SatoshiLabs (Trezor) để áp dụng SSS vào seed phrase backup. Thay vì một mnemonic BIP-39 duy nhất, SLIP-39 tạo ra nhiều mnemonic shares — mỗi share là một chuỗi 20 hoặc 33 từ.
Cấu trúc SLIP-39
SLIP-39 mở rộng SSS cơ bản với khái niệm group threshold — cho phép cấu hình phức tạp hơn:
- Group threshold G: Cần ít nhất G nhóm thỏa mãn threshold của mình.
- Mỗi nhóm có threshold riêng: Nhóm A cần 2-of-3 shares, nhóm B cần 1-of-2 shares.
Ví dụ cấu hình thực tế: Cần 2 trong 3 nhóm — Nhóm "Gia đình" (2-of-3), Nhóm "Luật sư" (1-of-2), Nhóm "Két sắt" (1-of-1). Đây cho phép nhiều kịch bản recovery khác nhau mà không có single point of failure nào.
# SLIP-39 share — ví dụ cấu trúc 20 từ
# Mỗi từ mã hóa 10 bits — tổng 200 bits payload
Share 1/3 (nhóm A, share 1):
academic acid acne apart Duke adjust agency alive always answer
beard beyond bolt branch branch burden busy careful carpet cargo
# Cấu trúc payload của mỗi share:
# [identifier 15b][extendable 1b][iteration_exponent 4b]
# [group_index 4b][group_threshold 4b][group_count 4b]
# [member_index 4b][member_threshold 4b]
# [value 128b hoặc 256b]
# [checksum 30b — RS1024]
SLIP-39 vs BIP-39 — So sánh
| Tiêu chí | BIP-39 | SLIP-39 |
|---|
| Số lượng phrases | 1 phrase duy nhất (12 hoặc 24 từ) | N shares, mỗi share 20 hoặc 33 từ |
| Threshold | Không có — cần đúng 1 phrase | K-of-N, hỗ trợ group threshold |
| Passphrase support | Có (từ thứ 25) | Có (encryption passphrase) |
| Hardware wallet support | Trezor, Ledger, tất cả | Trezor Model T, Model One (firmware mới) |
| Wordlist | 2.048 từ tiếng Anh | 1.024 từ tiếng Anh (tập con của BIP-39) |
| Error detection | Checksum 4-bit (yếu) | RS1024 — phát hiện lỗi mạnh hơn nhiều |
⚠️
Trezor vs Ledger — Compatibility quan trọng
Trezor Model T và Model One (firmware ≥ 2.3.0) hỗ trợ SLIP-39 native — có thể tạo và restore trực tiếp. Ledger
không hỗ trợ SLIP-39 natively. Nếu dùng Ledger và muốn SSS backup, cần reconstruct entropy từ shares trên máy an toàn trước, sau đó nhập dạng BIP-39 25-word (entropy raw). Đây là thao tác nguy hiểm — key tồn tại briefly trên máy. Hãy thực hiện trên air-gapped machine.
Khi nào nên dùng SSS
- Backup seed phrase cá nhân: Chia 2-of-3, lưu ở nhà, ngân hàng, và người thân tin cậy — thay cho một tờ giấy duy nhất.
- Kế hoạch kế thừa: Chia key với điều kiện recovery yêu cầu kết hợp thừa kế + luật sư + ngân hàng.
- Disaster recovery key: Encryption key của backup database — chia cho các admin khác nhau trong tổ chức.
- Bootstrap key cho MPC: Master key dùng để khởi tạo MPC system — share qua SSS trong quá trình setup, sau đó mỗi node nhận share và key được deleted.
Giới hạn và rủi ro thực tế
- Reconstruction attack surface: Khi collect đủ shares, full key tồn tại tại một máy — nếu máy bị malware hoặc không air-gapped, key có thể bị steal ngay lúc reconstruction.
- Share custody không tốt: SSS bảo vệ mathematical — không bảo vệ nếu shares được lưu thiếu an toàn (text file, email). Mỗi share cần được bảo vệ như một secret riêng biệt.
- Không có on-chain accountability: Ai collect shares, ai trigger reconstruction, khi nào — hoàn toàn off-chain và không có audit trail tự động. Với tổ chức, cần process kiểm soát riêng.
- Share vật lý dễ mất hoặc hỏng: Giấy cháy, kim loại bị mài mòn — cần backup của backup, tăng complexity.
🔑
Best Practice: SSS cho cá nhân
Setup 2-of-3:
Share 1 — Lưu trong két sắt tại nhà (hoặc safe deposit box ngân hàng).
Share 2 — Đưa cho người thân tin cậy nhất, kèm hướng dẫn ngắn cách sử dụng nếu bạn gặp chuyện.
Share 3 — Lưu ở một địa điểm thứ ba (văn phòng luật sư, hoặc location địa lý khác). Không ai trong số này biết các share khác ở đâu. Test recovery ít nhất mỗi năm để đảm bảo shares vẫn đọc được và bạn còn nhớ quy trình.
SSS và MPC khác nhau thế nào?+
Đây là điểm quan trọng nhất: SSS cần reconstruct secret đầy đủ tại một máy để sử dụng — tạo ra điểm tấn công tạm thời. MPC (TSS) ký giao dịch mà không bao giờ reconstruct key — signing xảy ra phân tán qua nhiều round communication. SSS phù hợp cho backup và recovery dài hạn nơi bạn trust một máy thực hiện reconstruction (ví dụ air-gapped machine). MPC phù hợp cho operational signing thường xuyên khi không muốn key tồn tại đầy đủ ở bất kỳ đâu.
SLIP-39 là gì và khác BIP-39 thế nào?+
BIP-39 tạo một mnemonic phrase (12/24 từ) duy nhất đại diện cho toàn bộ wallet — một single point of failure. SLIP-39 (Shamir Backup của SatoshiLabs) dùng SSS để chia master secret thành nhiều mnemonic shares — bạn có thể cấu hình 2-of-3 hay 3-of-5. Để restore wallet, nhập đủ threshold shares vào Trezor. SLIP-39 còn hỗ trợ group threshold phức tạp hơn: cần 2 nhóm, trong đó nhóm A cần 2-of-3 shares và nhóm B cần 1-of-2 shares. Ledger không hỗ trợ SLIP-39 natively.
Nếu ai đó có K−1 shares thì có biết gì về secret không?+
Không — đây là tính chất information-theoretic của SSS. Với K−1 shares (dưới threshold), kẻ tấn công không thu được bất kỳ thông tin gì về secret. Polynomial bậc K−1 có vô số nghiệm có thể pass qua K−1 điểm đã biết — f(0) có thể là bất kỳ giá trị nào với xác suất bằng nhau. Đây là bảo mật mạnh hơn AES hay RSA vốn là computational security — SSS là information-theoretic security, không thể phá dù có máy tính lượng tử.
Có thể dùng SSS để backup seed phrase của MetaMask không?+
Có, nhưng cần tool phù hợp. MetaMask dùng BIP-39 seed phrase. Bạn có thể dùng tool offline như iancoleman.io/bip39 để lấy entropy gốc (128 hoặc 256 bit), sau đó dùng SLIP-39 compatible tool hoặc Trezor Suite để chia entropy đó thành SSS shares theo SLIP-39. Trezor Model T hỗ trợ SLIP-39 native. Ledger KHÔNG hỗ trợ SLIP-39 — nếu restore từ SLIP-39 shares, cần reconstruct entropy trước rồi nhập dạng BIP-39. Luôn thực hiện toàn bộ quá trình này trên máy air-gapped, không kết nối internet.
Tài liệu tham khảo
Paper gốc, chuẩn kỹ thuật và documentation thực tế về SSS và SLIP-39.
- Shamir, A. How to Share a Secret. Communications of the ACM, 22(11), 612–613. 1979. — Paper gốc định nghĩa SSS — 4 trang, đọc được trong 15 phút.
- Blakley, G.R. Safeguarding Cryptographic Keys. AFIPS 1979. — Phương pháp hyperplane độc lập, song song với Shamir.
- SatoshiLabs. SLIP-39: Shamir's Secret-Sharing for Mnemonic Codes. github.com/satoshilabs/slips/slip-0039. — Specification đầy đủ SLIP-39.
- SatoshiLabs. python-shamir-mnemonic — SLIP-39 Reference Implementation. github.com/trezor/python-shamir-mnemonic. — Reference implementation Python.
- Beimel, A. Secret-Sharing Schemes: A Survey. LNCS 2011. cs.bgu.ac.il/~beimel/Papers/Survey.pdf. — Survey toàn diện về secret sharing schemes.
- Gennaro, R. & Goldfeder, S. Fast Multiparty Threshold ECDSA. ACM CCS 2018. eprint.iacr.org/2019/114. — TSS — giải pháp không cần reconstruct key, khắc phục điểm yếu của SSS.
- ZRO Research. MPC Wallet Là Gì? — TWT.VN. twt.vn/mpc-wallet-la-gi/. — Bài giải thích MPC, nâng cấp của SSS.
- ZRO Research. Wallet Infrastructure & Key Management — TWT.VN. twt.vn/. — Pillar page toàn bộ cluster.
TWT.VN