Tiêu đề gốc: "Chia sẻ bí mật M-of-N với những chia sẻ đã biết trước"
Tác giả gốc: Vitalik Buterin
Biên soạn gốc: Cháo qua đêm, Babbitt blockquote>
Tác giả gốc của bài viết này là Vitalik Buterin, người đồng sáng lập Ethereum, trong bài viết này ông mô tả một loại M mới Sơ đồ chia sẻ khóa -of-N và hai trường hợp ứng dụng ví não và thiết kế phục hồi xã hội được đề xuất.
Giả sử bạn muốn tạo ra một bí mật có thể được phục hồi bằng cách tập hợp M trong số N phần khóa lại với nhau, trong đó tất cả N phần khóa được biết đến trong nâng cao. Vì vậy, có hai trường hợp sử dụng cho giải pháp này:
1. Một ví trí tuệ trong đó N việc chia sẻ khóa là câu trả lời cho N câu hỏi bảo mật và bạn muốn Tiền có thể được được khôi phục chỉ bằng câu trả lời cho các câu hỏi bảo mật M (riêng các câu hỏi bảo mật thôi thì đã tệ rồi, nhưng nếu bạn kết hợp 20 câu hỏi bảo mật thì bạn có thể nhận được khá nhiều entropy);
2. Thiết kế khôi phục xã hội nơi bạn muốn sử dụng giải mã ngưỡng thay vì ví hợp đồng thông minh vì bạn đang cố gắng khôi phục quyền truy cập vào dữ liệu riêng tư chứ không phải tiền điện tử và bạn muốn đối tác khôi phục của mình có khả năng sử dụng các khóa mà họ đã có (để giảm nguy cơ mất các khóa đó);
Sơ đồ chia sẻ khóa M-of-N thông thường không phù hợp với bất kỳ trường hợp sử dụng nào vì nó chỉ cho phép M chia sẻ khóa được chọn trước, các chia sẻ khóa (N-M) còn lại phải được tạo từ M ban đầu bằng thuật toán xác định và có vẻ như dữ liệu ngẫu nhiên (trong trường hợp Brain Wallet, chúng không phù hợp làm câu trả lời cho vấn đề bảo mật, trong trường hợp Social Recovery, người dùng bắt buộc phải sử dụng phần mềm đặc biệt để lưu trữ chúng, thay vì lấy từ ví HD hiện có).
Vì vậy, đây là điều chúng tôi muốn cải thiện. Chúng tôi đã xây dựng sơ đồ ngưỡng N-of-(2N-M), bắt đầu từ N ban đầu khóa Chia sẻ khóa tạo ra (N-M) chia sẻ khóa bổ sung. Sau đó, chúng tôi xuất bản tất cả các cổ phiếu quan trọng bổ sung N-M trên blockchain. Nếu muốn, trong trường hợp phục hồi xã hội, người ta có thể chỉ cần cung cấp cho mỗi người tham gia một bản sao của tất cả các cổ phần chính bổ sung. Điều này khiến các phần chia sẻ khóa bổ sung trở thành thông tin công khai một cách hiệu quả: nguy cơ chúng bị mất là không đáng kể, nhưng bất kỳ kẻ tấn công nào cũng sẽ có được chúng. Và hóa ra là trong số N cổ phiếu khóa chưa được phát hành, miễn là M cổ phiếu khóa kết hợp với N-M cổ phiếu khóa bổ sung và tiết lộ dữ liệu, chúng ta có sơ đồ M-of-N, đó là điều chúng ta muốn.
Cập nhật ngày 18 tháng 7 năm 2021: Cơ chế thay thế cho trường hợp sử dụng phục hồi xã hội
Trong trường hợp sử dụng phục hồi xã hội , Chúng tôi muốn quá trình thiết lập diễn ra dễ dàng nhất có thể vì người dùng rất lười biếng và chắc chắn sẽ chọn một nhóm đối tác khôi phục nhỏ, không an toàn nếu khó thiết lập. Điều này có nghĩa là việc tạo Khóa phân tán (DKG) cần thiết để chia sẻ khóa theo cách phi tập trung có lẽ là một ý tưởng tồi vì nó yêu cầu 2 vòng liên lạc (có nghĩa là các giao dịch blockchain bổ sung hoặc mọi người đều trực tuyến cùng lúc và có các kênh liên lạc đồng bộ ).
Thay vào đó, chúng ta có thể lợi dụng thực tế là chủ tài khoản sở hữu khóa riêng của họ. Họ có thể chỉ cần yêu cầu mỗi đối tác khôi phục cung cấp khóa chung của họ (ví dụ: thông qua pk = G * hash(ecdsa_sign(msk, nonce)), trong đó msk là khóa chính của đối tác khôi phục) và sau đó xuất bản một giao dịch trên chuỗi Chứa giao dịch nonce và mã hóa (share_i, pk_i) cho mỗi i (lưu ý: trong đó share_i là khóa chia sẻ thứ i và pk_i là khóa chung của người tham gia thứ i).
Nếu chúng ta tránh sử dụng lại nonce và do đó không sử dụng lại khóa (ví dụ: đặt nonce = hash(secret, maddr_1 ... maddr_n), trong đó secret là giá trị được đưa vào recovery và maddr_i là địa chỉ của đối tác khôi phục thứ i, như vậy là đủ), chúng ta có thể sử dụng thuật toán mã hóa Diffie-Hellman cơ bản cho mã hóa, Điều này có nghĩa là một giao dịch chỉ có 32 * (n+1) byte dữ liệu cuộc gọi là đủ để lưu thông tin khôi phục.
Về kế hoạch này, thành viên diễn đàn ethresear.ch kelvin nhận xét:
![]()
"Điều này thật thú vị! Tôi đoán trong thiết kế khôi phục xã hội, N người tham gia sẽ thêm một số muối công khai vào khóa riêng của họ. , ám chỉ việc chèn một chuỗi cụ thể tại bất kỳ vị trí cố định nào của mật khẩu), sau đó băm nó để tạo ra N khóa chia sẻ đã biết trước.
p>
Nếu không, họ sẽ không sẵn lòng tiết lộ các chia sẻ khóa của mình để cho phép tính toán N−M chia sẻ khóa bổ sung và họ cũng sẽ phải tiết lộ M khóa để khôi phục bí mật.
Ngoài ra, bạn nghĩ mọi người sẽ phân phối loại dữ liệu riêng tư nào theo cách này."
Và Vitalik đã trả lời:
"Trên thực tế, họ sẽ sử dụng hash(ecdsa_sign(key, salt)) làm hàm băm để tạo khóa con, vì phương thức ecdsa_sign được hiển thị trong API web3 và có đầu ra xác định được tiêu chuẩn hóa. Nhưng điều này là một chi tiết triển khai và hiệu quả là như nhau.
Tôi chỉ đang nghĩ về "Email Ethereum" và những thứ như Khóa mã hóa cho các ứng dụng nhắn tin phi tập trung như Status. Một trường hợp sử dụng khác tất nhiên là khóa riêng cho các chuỗi khối khác."
Liên kết gốc
Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:
Nhóm Telegram đăng ký: https://t.me/theblockbeats
Nhóm Telegram thảo luận: https://t.me/BlockBeats_App
Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia