Ba giải pháp ưu tiên của a16z để giải quyết các vấn đề cốt lõi của mật mã khóa công khai

Nguồn: Noemi Glaeser, a16z crypto

Trong mật mã khóa công khai, luôn có một vấn đề khó khăn, đó là cách liên kết chính xác khóa mã hóa (chẳng hạn như khóa chung) với một danh tính cụ thể (chẳng hạn như một cá nhân hoặc tổ chức). Mấu chốt của vấn đề này là phải có một cách công khai và nhất quán để thể hiện mối quan hệ giữa danh tính và khóa chung để mọi người có thể tự tin sử dụng những khóa chung đó để mã hóa thông tin.

Nếu không có mối quan hệ rõ ràng như vậy, những người khác có thể không xác định được khóa công khai nào đó thuộc về ai, do đó có thể gửi mã hóa thông tin đến nhầm người, dẫn đến rò rỉ thông tin hoặc gây hậu quả nghiêm trọng khác. Trong Web3, vấn đề này vẫn tồn tại.

Đối với các vấn đề trên, hiện có ba giải pháp: Thư mục khóa công khai, mã hóa dựa trên danh tính (IBE) và mã hóa dựa trên đăng ký (RBE). Mỗi phương pháp trong số ba phương pháp này đều có ưu điểm riêng về tính ẩn danh, tính tương tác và hiệu quả. Ví dụ: IBE yêu cầu nền tảng tin cậy vững chắc, nhưng trong một số trường hợp, IBE hoạt động tốt hơn về tính ẩn danh và hiệu quả. Bài viết này nhằm mục đích khám phá ứng dụng của ba phương pháp này trên blockchain và so sánh ưu điểm và nhược điểm của chúng.

Ba phương pháp

Nói chung, phương pháp liên kết khóa mã hóa với thông tin nhận dạng A phổ biến Cách tiếp cận này là sử dụng cơ sở hạ tầng khóa công khai (PKI), trong đó cốt lõi của nó là thư mục khóa chung. Trong phương pháp này, người gửi thông tin cần tương tác với bên thứ ba đáng tin cậy (tức là cơ quan duy trì thư mục này, thường là cơ quan cấp chứng chỉ) để gửi thông tin được mã hóa.

Tuy nhiên, trong môi trường Web2, việc duy trì thư mục khóa công khai này đòi hỏi chi phí cao và các thao tác rườm rà. Ngoài ra, người dùng có nguy cơ bị cơ quan cấp chứng chỉ lạm dụng.

Một số giải pháp thay thế được các nhà mật mã đề xuất để giải quyết các vấn đề về cơ sở hạ tầng khóa công khai (PKI). Năm 1984, Adi Shamir đề xuất mã hóa dựa trên danh tính (IBE), trong đó danh tính của một bên (chẳng hạn như số điện thoại, email hoặc tên miền ENS) có thể được sử dụng trực tiếp làm khóa chung. Cách tiếp cận này loại bỏ nhu cầu duy trì một thư mục khóa chung, nhưng lại nảy sinh một vấn đề mới: phải dựa vào bên thứ ba đáng tin cậy (người tạo khóa) để tạo khóa riêng.

Năm 2001, Dan Boneh và Matthew Franklin đã đề xuất xây dựng IBE thực tế đầu tiên, nhưng công nghệ này chưa được áp dụng rộng rãi, chủ yếu ở một số hệ sinh thái khép kín, chẳng hạn như như môi trường triển khai doanh nghiệp hoặc chính phủ. Một lý do tại sao IBE không được sử dụng rộng rãi có thể là vì nó dựa trên giả định về độ tin cậy mạnh mẽ, tức là tin tưởng vào các khóa do bên thứ ba tạo ra.

Tuy nhiên, như sẽ được thảo luận sau trong bài viết này, vấn đề tin cậy này có thể được giải quyết bằng cách dựa vào một bên đáng tin cậy (tức là số đại biểu của một nhóm người tham gia) giải pháp và công nghệ blockchain có thể dễ dàng đạt được điều này.

Ưu điểm và nhược điểm

Có nhiều điều cần cân nhắc khác nhau khi so sánh các yếu tố của sơ đồ mã hóa này , Tôi đưa ra hai giả định về điều này:

Người dùng sẽ không cập nhật hoặc thu hồi khóa của họ: Điều này có nghĩa là trong cuộc thảo luận, giả định rằng các khóa của mỗi người dùng đều được cố định và sẽ không thay đổi.

Hợp đồng thông minh không sử dụng bất kỳ Dịch vụ sẵn có dữ liệu ngoài chuỗi (DAS) hoặc dữ liệu blob nào: nghĩa là giả định rằng hợp đồng thông minh dựa hoàn toàn vào chuỗi dữ liệu, không Liên quan đến các dịch vụ dữ liệu ngoài chuỗi hoặc lưu trữ dữ liệu bổ sung.

Thư mục khóa công khai

Bất kỳ ai cũng có thể chuyển ID mà người khác không chiếm giữ bằng cách gọi hợp đồng thông minh, đó là (id , pk) Mục nhập được thêm vào thư mục trên chuỗi.

PKI phi tập trung đề cập đến việc duy trì một danh mục danh tính (ID) và khóa công khai tương ứng của chúng thông qua hợp đồng thông minh. Thư mục này là công khai và không dựa vào bên thứ ba tập trung. Ví dụ: lấy  ENS  làm ví dụ, nó duy trì mối quan hệ ánh xạ giữa một tên miền (tức là danh tính) và siêu dữ liệu liên quan, bao gồm các địa chỉ được phân giải theo tên miền (khóa chung có thể được suy ra từ các giao dịch tại các địa chỉ này). ENS là một hệ thống phức tạp hơn, không chỉ ghi lại khóa công khai mà còn lưu trữ các siêu dữ liệu khác. Chức năng của PKI phi tập trung tương đối đơn giản: hợp đồng thông minh chỉ cần duy trì một danh sách và ghi lại khóa công khai tương ứng với từng danh tính.

Khi người dùng muốn đăng ký danh tính, trước tiên anh ta cần tạo một cặp khóa (khóa chung và khóa riêng) hoặc sử dụng cặp khóa đã được tạo , gửi ID nhận dạng và khóa chung của nó tới hợp đồng thông minh (cũng có thể trả một khoản phí nhất định), hợp đồng thông minh sẽ kiểm tra xem ID này đã được người khác đăng ký hay chưa. Nếu nó không bị chiếm dụng, hợp đồng thông minh sẽ thêm ID và khóa chung vào thư mục. Sau khi đăng ký hoàn tất, bất kỳ ai cũng có thể lấy khóa chung tương ứng với ID bằng cách yêu cầu hợp đồng thông minh gửi tin nhắn được mã hóa cho người dùng nếu người gửi đã mã hóa tin nhắn cho người dùng trước đó và đã có khóa, khóa chung của người dùng. , không cần phải yêu cầu lại khóa công khai từ hợp đồng thông minh. Sau khi có khóa chung, người gửi có thể sử dụng nó để mã hóa tin nhắn như bình thường, sau đó gửi tin nhắn đã mã hóa đến người nhận bằng khóa riêng tương ứng để giải mã tin nhắn và khôi phục văn bản gốc.

Hãy cùng điểm qua ưu nhược điểm của phương pháp này:

Ưu điểm và nhược điểm Giải mã không tương tác: Quá trình giải mã không yêu cầu tương tác với các bên khác và người giải mã có thể hoàn thành quá trình giải mã một cách độc lập. Không ngắn gọn: Hệ thống có thể không đủ đơn giản ở một số khía cạnh, điều này có thể có nghĩa là độ phức tạp cao hơn, khối lượng dữ liệu lớn hơn hoặc yêu cầu nhiều tài nguyên hơn. Tính minh bạch: Một hệ thống có thể minh bạch ở một số khía cạnh, nghĩa là các hoạt động được công khai và có thể được xem xét kỹ lưỡng. Mã hóa tương tác: Quá trình mã hóa có thể yêu cầu một số tương tác với các bên khác, làm tăng thêm độ phức tạp. Bất kỳ ID nào: Người dùng có thể tự do lựa chọn hoặc sử dụng bất kỳ ID nhận dạng nào mà không bị hạn chế bởi các định dạng hoặc quy tắc cụ thể. Người gửi không ẩn danh: Danh tính của người gửi có thể không hoàn toàn ẩn danh trong hệ thống.

Mã hóa dựa trên danh tính (IBE)

Danh tính của người dùng được xác định bởi khóa chung của họ Nghĩa là, khóa chung không chỉ được sử dụng để mã hóa mà còn được dùng làm mã định danh duy nhất cho người dùng. Nhưng cách tiếp cận này dựa vào một hoặc nhiều bên thứ ba đáng tin cậy chịu trách nhiệm tạo và cấp khóa. Ngoài ra, các bên thứ ba này được yêu cầu duy trì khóa chính trong suốt vòng đời của hệ thống, trong một số trường hợp, khóa này có thể được sử dụng để giải mã hoặc các hoạt động quan trọng khác.

Trong hệ thống IBE, người dùng không tự tạo một cặp khóa chung và khóa riêng như trong các hệ thống mã hóa truyền thống. Thay vào đó, người dùng cần đăng ký với một trình tạo khóa đáng tin cậy. Trình tạo khóa chứa một cặp khóa chính (bao gồm khóa riêng chính msk và khóa chung mpk chính). Khi người dùng cung cấp ID của họ, trình tạo khóa sẽ sử dụng khóa riêng chính msk và ID của người dùng để tính toán khóa riêng duy nhất cho người dùng đó. Khóa riêng được tạo cần phải được gửi đến người dùng thông qua kênh bảo mật Nói chung, giao thức trao đổi khóa được sử dụng để thiết lập kênh bảo mật này.

Đối với người gửi, hệ thống IBE đơn giản hóa quy trình mã hóa. Người gửi chỉ cần tải xuống khóa chung (mpk) chính của trình tạo khóa một lần và sau đó có thể sử dụng ID để mã hóa tin nhắn. Việc giải mã cũng đơn giản đối với người nhận. Người dùng đã đăng ký có thể giải mã văn bản mã hóa nhận được bằng khóa riêng do người tạo khóa cấp cho họ.

Khóa riêng chính (msk) của trình tạo khóa phải được giữ lại trong thời gian dài vì nó cần liên tục tạo khóa riêng của người dùng mới trong quá trình vận hành hệ thống. Điều này không giống như một số hệ thống SNARK được tạo trong quá trình thiết lập đáng tin cậy nhưng có thể bị hủy sau khi quá trình thiết lập hoàn tất. Trong hệ thống IBE, khóa riêng chính không thể bị xóa sau khi khởi tạo như trong SNARK.

Ngay cả khi khóa riêng chính (msk) được lưu giữ đúng cách, mỗi người dùng đã đăng ký vẫn cần tin tưởng rằng trình tạo khóa sẽ không đọc tin nhắn của họ. Điều này là do trình tạo khóa có thể giữ một bản sao khóa riêng của người dùng bất kỳ lúc nào hoặc tính toán lại khóa riêng của người dùng bằng khóa riêng chính.

Trình tạo khóa cũng có thể cung cấp cho người dùng khóa riêng có vấn đề hoặc bị hạn chế. Khóa này có thể giải mã hầu hết các tin nhắn nhưng không thể giải mã chúng. Thông báo cụ thể do một số trình tạo khóa đặt. Điều này có nghĩa là trình tạo khóa có khả năng điều khiển khả năng giải mã của người dùng, do đó có khả năng thực hiện một số mức độ kiểm soát hoặc hạn chế đối với hoạt động liên lạc của người dùng.

Ưu điểm Nhược điểm Lưu trữ trên chuỗi là không đổi/tối thiểu: Dung lượng lưu trữ mà hệ thống yêu cầu trên blockchain là nhỏ hoặc không đổi và không tăng theo thời gian. Giả định về sự tin cậy mạnh mẽ: Hệ thống dựa vào một hoặc nhiều bên thứ ba đáng tin cậy, điều đó có nghĩa là cần phải có sự tin tưởng mạnh mẽ vào các bên thứ ba này. Nếu các bên thứ ba này bị xâm phạm hoặc không đáng tin cậy thì tính bảo mật của hệ thống sẽ bị xâm phạm. Mã hóa không tương tác: Quá trình mã hóa không yêu cầu tương tác với các bên khác và người gửi có thể hoàn thành mã hóa một cách độc lập. Ẩn danh người gửi: Hệ thống có thể giữ ẩn danh danh tính của người gửi và bảo vệ quyền riêng tư. Bất kỳ ID nào: Người dùng có thể tự do lựa chọn hoặc sử dụng bất kỳ ID nhận dạng nào mà không bị hạn chế bởi các định dạng hoặc quy tắc cụ thể.

Mã hóa dựa trên đăng ký (RBE)

Giống như IBE, trong hệ thống này, Một người dùng danh tính (chẳng hạn như địa chỉ email hoặc số điện thoại) đóng vai trò trực tiếp như khóa chung của họ. Nhưng không giống như IBE, hệ thống này không còn dựa vào bên thứ ba đáng tin cậy hoặc một nhóm đại biểu để quản lý khóa. Thay vào đó, bên thứ ba đáng tin cậy này được thay thế bởi người phụ trách chính.

Tôi sẽ thảo luận về cách xây dựng RBE hiệu quả trong phần này, vì theo như tôi biết thì cách này có lợi thế đáng kể so với các cách xây dựng RBE thực tế khác. được triển khai trên blockchain vì nó dựa trên ghép nối chứ không dựa trên mạng.

Trong hệ thống RBE, mỗi người dùng tạo một cặp khóa (bao gồm khóa chung và khóa riêng). Người dùng cũng cần tính toán một số giá trị cập nhật (được đánh dấu a trong sơ đồ) dựa trên khóa riêng của họ và chuỗi tham chiếu chung (CRS). Những giá trị cập nhật này được sử dụng cho các hoạt động tiếp theo trong hệ thống. Sự hiện diện của Chuỗi tham chiếu chung (CRS) có nghĩa là hệ thống không được thiết lập hoàn toàn mà không có sự tin cậy. Tuy nhiên, quá trình tạo CRS sử dụng một phương pháp xây dựng gọi là công suất tau. Phương pháp xây dựng này có thể được hoàn thành thông qua tính toán hợp tác của nhiều người tham gia trong chuỗi. Chỉ cần có ít nhất một người tham gia trung thực thì CRS này sẽ an toàn.

Hợp đồng thông minh được thiết lập cho số lượng người dùng dự kiến ​​N, những người này được nhóm thành các nhóm khác nhau. Khi người dùng đăng ký vào hệ thống, họ cần báo cáo cho. hợp đồng thông minh Hợp đồng gửi ID nhận dạng riêng, khóa chung và giá trị cập nhật. Hợp đồng thông minh duy trì một tập hợp các tham số công khai pp, khác với chuỗi tham chiếu công khai (CRS) đã đề cập trước đó. Bạn có thể coi pp như một bản tóm tắt ngắn gọn về khóa chung của tất cả người dùng đã đăng ký trong hệ thống. Sau khi hợp đồng thông minh nhận được yêu cầu đăng ký của người dùng, nó sẽ kiểm tra các giá trị được cập nhật để xác minh tính chính xác của chúng. Sau khi quá trình xác minh được thông qua, hợp đồng thông minh sẽ nhân khóa chung của người dùng vào các nhóm tương ứng trong pp. Bước này tương đương với việc kết hợp khóa chung của người dùng mới vào bộ tham số chung của hệ thống để sử dụng sau này.

Trong hệ thống mã hóa dựa trên đăng ký (RBE), người dùng cần lưu cục bộ một số thông tin để giúp họ giải mã tin nhắn. Thông tin này cần được cập nhật khi người dùng mới được đăng ký trong cùng nhóm với họ. Người dùng có thể tự giám sát blockchain để cập nhật thông tin này theo cách thủ công hoặc hợp đồng thông minh có thể cung cấp thông tin người dùng đã đăng ký gần đây và người dùng có thể nhận được những cập nhật này thường xuyên để cập nhật thông tin được giải mã của họ.

Trong hệ thống này, người gửi chỉ cần thực hiện hai việc:

Tải xuống tài liệu tham khảo công khai Chuỗi (CRS): Chỉ cần tải xuống một lần và không cần cập nhật sau đó.

Tải xuống các tham số công khai: Người gửi thỉnh thoảng cần tải xuống các tham số công khai mới nhất. Điều quan trọng đối với người gửi là các tham số công khai này chứa khóa chung của người nhận mà không cần phải tải xuống phiên bản mới nhất mỗi lần, miễn là có thể tìm thấy khóa chung của người nhận.

Sau đó, người gửi sử dụng CRS đã tải xuống, các tham số công khai và ID của người nhận để mã hóa tin nhắn và gửi nó đến người nhận. Điều này có nghĩa là người gửi không cần cập nhật dữ liệu thường xuyên, miễn là nó đảm bảo rằng khóa chung của người nhận được đưa vào tham số chung.

Khi người dùng nhận được tin nhắn được mã hóa, trước tiên anh ta sẽ kiểm tra thông tin phụ trợ được lưu trữ cục bộ của mình để xem liệu có giá trị nào đáp ứng một điều kiện nhất định không (ví dụ: thông qua kiểm tra xác thực nhất định), nếu người dùng không thể tìm thấy giá trị phù hợp cục bộ, điều này có nghĩa là họ cần nhận thông tin cập nhật mới nhất từ ​​hợp đồng thông minh. Sau khi người dùng tìm thấy giá trị thông tin phụ trợ phù hợp, họ có thể sử dụng giá trị này và Sử dụng của bạn. khóa riêng của mình để giải mã bản mã nhận được, từ đó khôi phục được thông điệp gốc.

Rõ ràng, giải pháp này phức tạp hơn hai giải pháp còn lại. Nhưng nó yêu cầu ít bộ nhớ trên chuỗi hơn so với thư mục khóa công khai và tránh được giả định về độ tin cậy mạnh mẽ của IBE.

Tham số ngắn gọn:

• Kích thước tham số được lưu trữ trên chuỗi có tỷ lệ tuyến tính phụ với số lượng người dùng, nhỏ hơn nhiều so với dung lượng lưu trữ mà thư mục khóa chung yêu cầu (tăng tuyến tính), nhưng vẫn không cố định và do đó không tốt bằng như IBE tại thời điểm này (mã hóa dựa trên danh tính).

Mã hóa với khả năng tương tác nhất định:

• < p style="text-align: left;">Khi gửi tin nhắn, người gửi yêu cầu một bản sao của các tham số công khai chứa người nhận dự kiến. Điều này có nghĩa là người gửi cần cập nhật các tham số này vào một thời điểm nào đó sau khi người nhận đã đăng ký nhưng không cần cập nhật chúng riêng lẻ cho từng người nhận vì một bản cập nhật có thể chứa khóa cho nhiều người nhận. Nhìn chung, việc gửi tin nhắn có tính tương tác cao hơn IBE nhưng ít hơn việc sử dụng thư mục khóa chung.

Giải mã với khả năng tương tác nhất định:

• < p style="text-align: left;">Tương tự như mã hóa, người nhận cần có thông tin phụ trợ phù hợp với phiên bản của tham số công khai được sử dụng trong mã hóa. Khi người dùng mới đăng ký vào một nhóm nhất định, các tham số công khai và thông tin phụ trợ sẽ được cập nhật và giá trị có thể giải mã văn bản mã hóa tương ứng với phiên bản của tham số công khai được sử dụng trong quá trình mã hóa. Người dùng có thể chọn nhận các bản cập nhật thông tin phụ trợ theo định kỳ thay vì ngay lập tức trừ khi quá trình giải mã không thành công. Không giống như các cập nhật tham số công khai, việc nhận các cập nhật thông tin phụ trợ thường xuyên hơn sẽ không tiết lộ thông tin cá nhân.

Người gửi ẩn danh:

• Tương tự như tình huống với các thư mục khóa chung, người gửi có thể mã hóa tin nhắn một cách độc lập (miễn là nó có các tham số mới nhất) mà không cần truy vấn thông tin cụ thể về người nhận. Khi người gửi cần đọc thông tin từ chuỗi, thông tin đó không liên quan đến người nhận dự kiến ​​(trừ khi người gửi chỉ yêu cầu một nhóm điểm tham số cụ thể, điều này có thể làm rò rỉ một số thông tin).

Tính minh bạch:

• Mặc dù hệ thống cần được thiết lập thông qua thiết lập tin cậy (có thể được phân phối hoặc quản lý bên ngoài) và xuất ra CRS (chuỗi tham chiếu chung) đã sửa, nhưng sau khi thiết lập hoàn tất, không cần thiết Còn phụ thuộc vào bất kỳ bên thứ ba hoặc nhóm trọng tài đáng tin cậy nào. Mặc dù phụ thuộc vào bên thứ ba điều phối (hợp đồng thông minh), hệ thống hoàn toàn minh bạch và bất kỳ ai cũng có thể đóng vai trò là điều phối viên hoặc kiểm tra xem nó có hoạt động trung thực hay không bằng cách xác minh chuyển đổi trạng thái (đây cũng là lý do tại sao nó có thể được triển khai như một hợp đồng thông minh). Ngoài ra, người dùng có thể yêu cầu bằng chứng ngắn gọn về tư cách thành viên (không phải) để kiểm tra xem bản thân họ hoặc người khác đã được đăng ký trong hệ thống hay chưa. Điều này khác với các hệ thống IBE, nơi mà bên thứ ba đáng tin cậy khó chứng minh rằng họ không bí mật tiết lộ khóa giải mã (chẳng hạn như giữ một bản sao bí mật hoặc tiết lộ nó cho người khác). Ngược lại, thư mục khóa công khai hoàn toàn trong suốt.

Thu thập ID bị hạn chế:

• Được mô tả ở đây là phiên bản cơ bản của cấu trúc RBE. Để xác định rõ ràng nhóm mà ID thuộc về, các ID phải có thứ tự chung và nhất định. Số điện thoại có thể được sắp xếp dễ dàng, nhưng việc sắp xếp các chuỗi tùy ý có thể rất phức tạp hoặc thậm chí là không thể vì số lượng nhóm có thể rất lớn hoặc vô hạn. Điều này có thể được thực hiện bằng cách cung cấp một hợp đồng riêng để tính toán ánh xạ này hoặc bằng cách áp dụng phương pháp băm chim cu được đề xuất trong công việc tiếp theo để giảm bớt sự phức tạp này.

Người nhận ẩn danh:

• < p style ="text-align: left;">Phương pháp này ngăn văn bản mã hóa tiết lộ danh tính của người nhận.