Việc liên kết các khóa mật mã với danh tính đã là vấn đề từ khi sự giới thiệu của công nghệ. Thách thức là cung cấp và duy trì ánh xạ công khai và nhất quán giữa danh tính và khóa công khai (mà những danh tính đó có khóa riêng). Nếu không có ánh xạ như vậy, các thông điệp được dự định là bí mật có thể trở nên tồi tệ - đôi khi với kết quả thảm khốc. Thách thức tương tự này cũng tồn tại trong web3.

Ba giải pháp khả thi hiện đang tồn tại. Hai cách tiếp cận cổ điển là thư mục khóa công khai và mã hóa dựa trên danh tính. Thứ ba là mã hóa dựa trên đăng ký, cho đến gần đây hoàn toàn là lý thuyết. Ba cách tiếp cận cung cấp sự đánh đổi khác nhau giữa ẩn danh, tương tác và hiệu quả, thoạt nghe có vẻ rõ ràng, nhưng cài đặt blockchain giới thiệu các khả năng và ràng buộc mới. Mục tiêu của bài đăng này là khám phá không gian thiết kế này và so sánh các phương pháp này khi được triển khai trên blockchain. Khi người dùng cần tính minh bạch và ẩn danh trên chuỗi, một chương trình RBE thực tế là người chiến thắng rõ ràng – vượt qua giả định tin cậy mạnh mẽ của mã hóa dựa trên danh tính, nhưng phải trả giá.

Ba phương pháp tóm tắt

Cách tiếp cận cổ điển để liên kết các khóa mật mã với các danh tính là cơ sở hạ tầng khóa công khai (PKI), với một thư mục khóa công khai ở trung tâm. Cách tiếp cận này đòi hỏi một người gửi tiềm năng phải tương tác với một bên thứ ba đáng tin cậy (người duy trì thư mục, hoặc cơ quan chứng nhận) để gửi tin nhắn. Ngoài ra, trong môi trường web2, việc duy trì thư mục này có thể tốn kém, mệt mỏi và dễ gặp lỗi, và người dùng đang đối mặt với rủi ro củalạm dụng bởi cơ quan chứng nhận.

Những nhà mật mã học đã đề xuất các phương án thay thế để vượt qua các vấn đề với PKI. Năm 1984, Adi Shamir đề xuấtmã hóa dựa trên danh tính (IBE), trong đó người dùng được định danh — số điện thoại, email, tên miền ENS — được sử dụng như là khóa công khai. Điều này loại bỏ việc cần phải duy trì một thư mục khóa công khai nhưng đồng thời đưa ra chi phí là phải có một bên thứ ba tin cậy (người tạo khóa). Dan Boneh và Matthew Franklin đã cấu trúc IBE thực tiễn đầu tiêntrong năm 2001, nhưng IBE vẫn chưa nhận được sự thông dụng rộng rãi trừ trong hệ sinh thái đóng như doanh nghiệp hoặc các triển khai của chính phủ, có lẽ do giả định tin tưởng mạnh mẽ. (Như chúng ta sẽ thấy bên dưới, giả định này có thể được giảm bớt một phần bằng cách phụ thuộc vào một nhóm đồng thuận tin cậy của các bên thay vì, mà một blockchain có thể dễ dàng tạo điều kiện.)

Một lựa chọn thứ ba, mã hóa dựa trên đăng ký (RBE), đã đượcđề xuất vào năm 2018. RBE duy trì kiến trúc chung giống như IBE nhưng thay thế trình tạo khóa đáng tin cậy bằng một "trình quản lý khóa" minh bạch chỉ thực hiện tính toán trên dữ liệu công khai (cụ thể, nó tích lũy khóa công khai thành một loại "tiêu hóa" có sẵn công khai). Tính minh bạch của người quản lý chính này làm cho cài đặt blockchain – nơi một hợp đồng thông minh có thể lấp đầy vai trò của người quản lý – một sự phù hợp tự nhiên cho RBE. RBE là lý thuyết cho đến năm 2022, khi các đồng tác giả của tôi và tôi giới thiệu xây dựng RBE hiệu quả thực tế đầu tiên.

Đánh giá sự đánh đổi

Không gian thiết kế này phức tạp, và để so sánh những kế hoạch này yêu cầu xem xét nhiều chiều hướng. Để giữ mọi thứ đơn giản hơn, tôi sẽ đưa ra hai giả định:

1. Người dùng không cập nhật hoặc thu hồi khóa của họ.
2. Hợp đồng thông minh không sử dụng bất kỳ dịch vụ khả dụng dữ liệu ở ngoại lai (DAS) hoặc dữ liệu blob nào.

Tôi sẽ thảo luận vào cuối về cách mà mỗi yếu tố bổ sung này có thể ảnh hưởng đến ba giải pháp tiềm năng của chúng tôi.

Thư mục Khóa Công khai

Tóm tắt: Bất kỳ ai đều có thể thêm một (id, pk) vào bảng trên chuỗi (thư mục) bằng cách gọi hợp đồng thông minh, miễn là ID chưa được yêu cầu.

Một PKI phi tập trung về cơ bản là một hợp đồng thông minh giữ một thư mục về danh tính và khóa công khai tương ứng của họ. Ví dụ, Đăng ký Ethereum Name Service (ENS)duy trì một bản đồ tên miền (“nhận dạng”) và siêu dữ liệu tương ứng của chúng, bao gồm các địa chỉ mà chúng giải quyết đến (từ giao dịch nơi có thể tạo ra một khóa công khai). Một PKI phi tập trung sẽ cung cấp tính năng đơn giản hơn nữa: danh sách được duy trì bởi hợp đồng sẽ chỉ lưu trữ khóa công khai tương ứng với mỗi ID.

Để đăng ký, người dùng tạo một cặp khóa (hoặc sử dụng cặp khóa được tạo trước đó) và gửi ID và khóa công khai của nó đến hợp đồng (có thể cùng với một số khoản thanh toán). Hợp đồng kiểm tra xem ID chưa được xác nhận quyền sở hữu hay chưa và nếu không, nó sẽ thêm ID và khóa công khai vào thư mục. Tại thời điểm này, bất kỳ ai cũng có thể mã hóa tin nhắn cho người dùng đã đăng ký bằng cách yêu cầu hợp đồng cung cấp khóa công khai tương ứng với ID. (Nếu người gửi đã mã hóa thứ gì đó cho người dùng này trước đó, họ không phải hỏi lại hợp đồng.) Với khóa công khai, người gửi có thể mã hóa tin nhắn của mình như bình thường và gửi bản mã cho người nhận, người có thể sử dụng khóa bí mật tương ứng để khôi phục tin nhắn.

Hãy xem xét các thuộc tính của phương pháp này.

Mặt tiêu cực của sổ cái:

• Không ngắn gọn. Thư mục key đầy đủ cần được lưu trữ trên chuỗi kết nối để luôn sẵn có cho tất cả mọi người (hãy nhớ, hiện tại chúng ta đang giả sử không có DAS). Với ~900K các tên miền duy nhất được đăng ký trong ENS vào thời điểm viết bài này, điều này có nghĩa là gần 90MB dung lượng lưu trữ liên tục. Các bên đăng ký cần phải trả tiền cho việc lưu trữ mà mục nhập của họ chiếm khoảng 65K gas (hiện tại khoảng $ 1 - xem đánh giá hiệu suất bên dưới).
• Một chút mã hóa tương tác. Người gửi cần đọc chuỗi để lấy khóa công khai của người dùng, nhưng chỉ khi đó là lần đầu tiên người gửi mã hóa một tin nhắn cho người dùng cụ thể đó. (Hãy nhớ rằng, chúng ta giả định người dùng không cập nhật hoặc thu hồi khóa của họ.)
• Không phải người gửi ẩn danh. Khi bạn truy xuất khóa công khai của ai đó, bạn liên kết chính mình với người nhận, cho biết rằng bạn có một số mối quan hệ với họ. Hãy tưởng tượng ví dụ bạn lấy khóa công khai cho WikiLeaks: Điều này có thể tạo ra sự nghi ngờ rằng bạn đang làm rò rỉ tài liệu mật. Vấn đề này có thể được giảm thiểu bằng "lưu lượng truy cập bìa" (truy xuất một lô khóa lớn, hầu hết trong số đó bạn không có ý định sử dụng) hoặc tương tự bằng cách chạy một nút đầy đủ hoặc truy xuất thông tin cá nhân (PIR).

Mặt tích cực là:

• Giải mã không tương tác. Người dùng giải mã các tin nhắn bằng khóa bí mật được lưu trữ cục bộ, do đó không yêu cầu tương tác.
• Rõ ràng. Danh sách người dùng và khóa hoàn toàn công khai, vì vậy bất kỳ ai cũng có thể kiểm tra xem họ đã được đăng ký đúng cách hay chưa.
• Bộ ID tùy ý. Miền giá trị của các ID không bị giới hạn trước bởi cấu trúc; trong lý thuyết, ID có thể là mộtchuỗi tùy ý(đến giới hạn được áp đặt bởi việc triển khai và lưu trữ cụ thể của hợp đồng).

Khi nào bạn có thể sử dụng một thư mục khóa công khai? Một thư mục khóa công khai phi tập trung dễ dàng để thiết lập và quản lý, vì vậy nó là sự lựa chọn cơ bản tốt. Tuy nhiên, nếu chi phí lưu trữ hoặc quyền riêng tư là một vấn đề, một trong những lựa chọn khác dưới đây có thể là một lựa chọn tốt hơn.

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

Tóm lược: Danh tính của người dùng là khóa công khai của họ. Cần có một bên thứ ba hoặc các bên thứ ba tin cậy để phát hành khóa và giữ một bí mật chủ (cửa rọi) cho suốt thời gian hoạt động của hệ thống.

Trong IBE, người dùng không tạo ra cặp khóa riêng của mình mà thay vào đó đăng ký với một trình tạo khóa đáng tin cậy. Trình tạo khóa có một cặp khóa 'chủ' (msk, mpk trong hình vẽ). Dựa trên ID của người dùng, trình tạo khóa sử dụng khóa bí mật chủ msk và ID để tính toán một khóa bí mật cho người dùng. Khóa bí mật đó phải được truyền đến người dùng qua một kênh an toàn (có thể thiết lập với một giao thức trao đổi khóa).

IBE tối ưu hóa trải nghiệm của người gửi: Nó tải xuống mpk của trình tạo khóa một lần, sau đó nó có thể mã hóa một tin nhắn cho bất kỳ ID nào bằng cách sử dụng chính ID đó. Giải mã cũng đơn giản: một người dùng đã đăng ký có thể sử dụng khóa bí mật được cấp cho nó bởi trình tạo khóa để giải mã văn bản được mã hóa.

Khóa bí mật chủ của trình tạo khóa có tính bền vững hơn so với“chất thải độc hại” được tạo ra bởi các buổi lễ thiết lập đáng tin cậyđược sử dụng cho một số SNARK. Trình tạo khóa cần nó để phát hành bất kỳ khóa bí mật mới nào, vì vậy trình tạo khóa không thể xóa nó sau khi thiết lập như các tham gia trong lễ SNARK làm. Đó cũng là một thông tin nguy hiểm. Bất kỳ ai có msk đều có thể giải mã tất cả các tin nhắn được gửi đến bất kỳ người dùng nào trong hệ thống. Điều này có nghĩa là luôn có nguy cơ rò rỉ với hậu quả thảm khốc.

Ngay cả khi msk được giữ an toàn, mọi người dùng đăng ký trong hệ thống cần tin tưởng trình tạo khóa không đọc tin nhắn của nó, vì trình tạo khóa có thể giữ một bản sao khóa bí mật của người dùng hoặc tính toán lại từ msk bất cứ lúc nào. Thậm chí có thể trình tạo khóa có thể cấp khóa bí mật bị lỗi hoặc "bị ràng buộc" cho người dùng để giải mã tất cả các tin nhắn ngoại trừ một số tin nhắn bị cấm do trình tạo khóa xác định.

Niềm tin này thay vào đó có thể được phân phối trong một nhóm các máy tạo khóa, để người dùng chỉ cần tin tưởng một số ngưởi trong nhóm. Trong trường hợp đó, một số ít máy tạo khóa gian lận không thể khôi phục lại các khóa bí mật hoặc tính toán các khóa không tốt, và một kẻ tấn công sẽ phải xâm nhập vào nhiều hệ thống để đánh cắp toàn bộ bí mật chủ chốt.

Nếu người dùng đồng ý với giả định tin cậy này, (ngưỡng) IBE đem lại rất nhiều lợi ích:

• Lưu trữ trên chuỗi liên tục / tối thiểu. Chỉ khóa công khai chính (một phần tử nhóm duy nhất) mới cần được lưu trữ trên chuỗi. Con số này ít hơn nhiều so với dung lượng lưu trữ được yêu cầu bởi thư mục khóa công khai trên chuỗi. Đối với IBE Boneh-Franklin trên đường cong BN254, điều này có nghĩa là thêm 64 byte lưu trữ trên chuỗi liên tục một lần trong giai đoạn thiết lập, yêu cầu dịch vụ chỉ tiêu tốn 40K gas.
• Mã hóa không tương tác. Người gửi chỉ cần khóa công khai chính (mà anh ta tải xuống một lần ở đầu) và ID của người nhận để mã hóa một tin nhắn. Điều này đối lập với thư mục khóa công khai, nơi nó sẽ cần lấy một khóa cho mỗi người dùng mới mà nó muốn giao tiếp.
• Giải mã không tương tác. Một lần nữa, người dùng sử dụng các khóa bí mật được lưu trữ cục bộ của họ để giải mã tin nhắn.
• Người gửi-ẩn danh. Người gửi không cần lấy bất kỳ thông tin nào về người nhận từ chuỗi. So với trường hợp của một bảng đăng ký khóa công khai, người gửi phải tương tác với hợp đồng theo một cách phụ thuộc vào người nhận.
• Bộ ID tùy ý được thiết lập. Giống như trong danh sách đăng ký khóa công khai, các ID có thể là chuỗi tùy ý.

Nhưng!

• Giả định tin cậy mạnh mẽ. Khác với bảng đăng ký khóa công khai, nơi người dùng tạo ra các khóa của riêng mình, IBE yêu cầu một bên tin cậy hoặc một nhóm các bên với một bí mật chủ (cửa sau) để phát hành các khóa. Bí mật chủ phải được giữ trong suốt tuổi thọ của hệ thống và có thể làm compromat tất cả các tin nhắn của người dùng đã đăng ký nếu nó bị rò rỉ hoặc lạm dụng.

Khi nào bạn muốn sử dụng (ngưỡng) IBE? Nếu có một bên thứ ba hoặc các bên thứ ba đáng tin cậy và người dùng sẵn lòng tin tưởng họ, IBE cung cấp một lựa chọn tiết kiệm không gian (và do đó là rẻ hơn) so với việc đăng ký khóa trên chuỗi.

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

Tương tự như IBE, danh tính của người dùng được sử dụng như là khóa công khai của họ, nhưng bên thứ ba/ủy quyền tin cậy được thay thế bằng một bộ tích lũy minh bạch (được gọi là “người quản lý khóa”).

Trong phần này, tôi sẽ thảo luận về việc xây dựng RBE hiệu quả từ bài báo của tôi, vì khác với (theo kiến thức của tôi) chỉ có xây dựng thực tế khác, nó hiện có thể được triển khai trên một blockchain (dựa trên cặp thay vì dựa trên mạng tinh thể). Bất cứ khi nào tôi nói "RBE", tôi muốn nói đến cấu trúc cụ thể này, mặc dù một số tuyên bố có thể đúng với RBE nói chung.

Trong RBE, người dùng tạo cặp khóa của riêng mình và tính toán một số “giá trị cập nhật” (a trong hình) được suy ra từ khóa bí mật và chuỗi tham chiếu chung (CRS). Mặc dù sự hiện diện của một CRS có nghĩa là việc thiết lập không hoàn toàn không đáng tin cậy, CRS là powers-of-tauconstruction, which can betính toán phối hợp trên chuỗivà là an toàn miễn là có một đóng góp trung thành duy nhất.

Hợp đồng thông minh được thiết lập cho một số lượng người dùng dự kiến N, được nhóm lại thành các nhóm. Khi một người dùng đăng ký trong hệ thống, nó sẽ gửi ID, khóa công khai và giá trị cập nhật của mình đến hợp đồng thông minh. 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 CRS), có thể được xem như một “bản tóm tắt” ngắn gọn của các khóa công khai của tất cả các bên đã đăng ký trong hệ thống. Khi nhận được yêu cầu đăng ký, nó thực hiện kiểm tra trên các giá trị cập nhật và nhân khóa công khai vào nhóm thích hợp của pp.

Người dùng đã đăng ký cũng cần duy trì một số “thông tin phụ trợ” ở địa phương, mà họ sử dụng để giúp giải mã và được thêm vào mỗi khi một người dùng mới đăng ký trong cùng một nhóm. Họ có thể tự cập nhật điều này bằng cách theo dõi blockchain để đăng ký trong nhóm của họ, hoặc hợp đồng thông minh có thể giúp bằng cách duy trì một danh sách các giá trị cập nhật nó nhận từ các đăng ký gần đây nhất (ví dụ, trong tuần trước), mà người dùng có thể lấy định kỳ (ít nhất một lần một tuần).

Người gửi trong hệ thống này tải xuống CRS một lần và thỉnh thoảng tải xuống phiên bản mới nhất của các tham số công khai. Đối với các tham số công khai, tất cả những gì quan trọng theo quan điểm của người gửi là chúng bao gồm khóa công khai của người nhận dự định; Nó không nhất thiết phải là phiên bản cập nhật nhất. Sau đó, người gửi có thể sử dụng CRS và các tham số công khai, cùng với ID người nhận, để mã hóa thư cho người nhận.

Sau khi nhận được một tin nhắn, người dùng kiểm tra thông tin phụ trợ được lưu trữ cục bộ của nó để kiểm tra giá trị qua một số kiểm tra. (Nếu không tìm thấy, điều đó có nghĩa là nó cần lấy thông tin cập nhật từ hợp đồng.) Sử dụng giá trị này và khóa bí mật của mình, người dùng có thể giải mã văn bản được mã hóa.

Rõ ràng, hệ thống này phức tạp hơn hai hệ thống khác. Nhưng nó yêu cầu ít lưu trữ trên chuỗi hơn thư mục khóa công khai trong khi tránh giả định niềm tin mạnh mẽ của IBE.

• Thông số ngắn gọn. Kích thước của các tham số được lưu trữ trên chuỗi là thăng hoa về số lượng người dùng. Con số này nhỏ hơn nhiều so với tổng dung lượng lưu trữ cần thiết cho một thư mục khóa công khai (tuyến tính về số lượng người dùng), nhưng vẫn không phải là hằng số và do đó kém hơn so với IBE.
• Mã hóa tương tác đến một mức độ nào đó. Để gửi một tin nhắn, người gửi cần một bản sao của các thông số công khai chứa thông tin người nhận dự định. Điều này có nghĩa là nó cần cập nhật các thông số tại một thời điểm nào đó sau khi người nhận dự định đăng ký, nhưng không nhất thiết cho mỗi người nhận dự định đăng ký, vì một bản cập nhật có thể bao gồm nhiều khóa của người nhận. Tổng thể, việc gửi tin nhắn tương tác hơn so với IBE nhưng ít tương tác hơn so với một thư mục.
• Một số tương tác giải mã. Tương tự như trường hợp mã hóa, người nhận cần một bản sao của thông tin phụ trợ mà 'khớp' với phiên bản tham số công cộng được sử dụng cho việc mã hóa. Cụ thể hơn, cả tham số công cộng và các thùng phụ trợ được cập nhật mỗi khi một người dùng mới đăng ký trong thùng đó, và giá trị có thể giải mã của mật mã là giá trị tương ứng với phiên bản pp được sử dụng để mã hóa. Giống như việc cập nhật tham số công cộng, người dùng có thể quyết định lấy các cập nhật phụ trợ chỉ định kỳ, trừ khi giải mã thất bại. Không giống như việc cập nhật tham số công cộng, việc lấy các cập nhật phụ trợ thường xuyên hơn không tự nhiên làm rò rỉ thông tin.
• Người gửi-ẩn danh. Tương tự như trong trường hợp thư mục, người gửi có thể mã hóa một tin nhắn hoàn toàn một mình (miễn là có thông số cập nhật) mà không cần truy vấn thông tin cụ thể cho người nhận. Thông tin đọc từ chuỗi, khi cần thiết, độc lập với người nhận dự định. (Để giảm giao tiếp, người gửi có thể yêu cầu chỉ một phần nhất định của pp bucket, rò rỉ thông tin một phần.)
• Trong suốt. Mặc dù hệ thống cần được thiết lập bằng cách sử dụng một buổi lễ thiết lập đáng tin cậy (có khả năng phân phối và / hoặc được quản lý bên ngoài) xuất ra CRS bị thủng, nhưng nó không dựa vào bất kỳ bên hoặc đại biểu đáng tin cậy nào sau khi thiết lập đã hoàn tất: mặc dù nó dựa vào bên thứ ba điều phối (hợp đồng), nó hoàn toàn minh bạch và bất kỳ ai cũng có thể là điều phối viên hoặc kiểm tra xem họ đang cư xử trung thực bằng cách xác nhận quá trình chuyển đổi trạng thái của nó (đó là lý do tại sao nó có thể được thực hiện như một hợp đồng thông minh). Hơn nữa, người dùng có thể yêu cầu bằng chứng ngắn gọn (không phải thành viên) để kiểm tra xem họ (hoặc bất kỳ ai khác) đã đăng ký / không đăng ký trong hệ thống. Điều này trái ngược với trường hợp IBE, nơi bên / bên đáng tin cậy khó thực sự chứng minh rằng họ không bí mật tiết lộ khóa giải mã (cho chính họ bằng cách tạo một bản sao bí mật hoặc cho người khác). Mặt khác, thư mục khóa công khai hoàn toàn minh bạch.
• Bộ ID bị hạn chế. Tôi đã mô tả một phiên bản "cơ bản" của việc xây dựng RBE. Để xác định một ID thuộc vào thùng nào một cách minh bạch, các ID phải có một thứ tự công khai và xác định được. Số điện thoại có thể được đặt theo thứ tự đơn giản, nhưng việc đặt thứ tự các chuỗi tùy ý là không thuận tiện nếu không thể vì số lượng thùng có thể rất lớn hoặc không giới hạn. Điều này có thể được giảm bớt bằng cách cung cấp một hợp đồng riêng biệt tính toán một ánh xạ như vậy hoặc bằng cách áp dụng phương pháp cuckoo-hashing đề xuất trong ...công việc theo sau này.

Với tiện ích mở rộng:

• Người nhận-ẩn danh. Lược đồ có thể được mở rộng để các bản mã không tiết lộ danh tính của người nhận.

Khi nào bạn có thể muốn sử dụng RBE? RBE sử dụng ít không gian lưu trữ trên chuỗi hơn một đăng ký trên chuỗi trong khi đồng thời tránh các giả định tin cậy mạnh cần thiết bởi IBE. So với một đăng ký, RBE cũng cung cấp đáng tin cậy về quyền riêng tư hơn cho người gửi. Tuy nhiên, vì RBE chỉ mới trở thành một lựa chọn có thể thực hiện được cho quản lý khóa, chúng tôi chưa chắc chắn về các kịch bản nào sẽ hưởng lợi nhiều nhất từ sự kết hợp này.hãy cho tôi biếtnếu bạn có bất kỳ ý tưởng nào.

So sánh hiệu suất

Tôi ước tính chi phí (tính đến ngày 30 tháng 7 năm 2024) của việc triển khai từng phương pháp trong số ba phương pháp tiếp cận này trên chuỗi trong máy tính xách tay Colab nàyKết quả cho một hệ thống có khả năng ~900K người dùng (số lượng tên miền duy nhất được đăng ký trong ENS tại thời điểm viết bài này) được hiển thị trong bảng dưới đây.

PKI không có chi phí thiết lập và chi phí đăng ký thấp cho mỗi người dùng, trong khi IBE có chi phí thiết lập nhỏ và đăng ký thực tế miễn phí cho mỗi người dùng. RBE có chi phí thiết lập cao hơn và chi phí đăng ký cao bất ngờ, mặc dù yêu cầu lưu trữ trên chuỗi thấp.

Phần lớn chi phí đăng ký (giả sử tính toán được thực hiện trên L2) đến từ thực tế là các bên phải cập nhật một phần của các tham số công khai trong lưu trữ liên tục, điều này làm tăng thêm chi phí đăng ký cao.

Mặc dù RBE đắt hơn các phương án thay thế, nhưng phân tích này cho thấy nó có thể triển khai được trên Ethereum mainnet một cách khả thi ngay hôm nay - mà không cần giả định rủi ro tiềm ẩn của PKI hoặc IBE. Và đó là trước các tối ưu hóa như triển khai nhiều phiên bản nhỏ hơn (và do đó rẻ hơn) hoặc sử dụng dữ liệu blob. Với những ưu điểm của mình như độ ẩn danh mạnh hơn và giả định tin cậy giảm đi, RBE có thể hấp dẫn đối với những người quan tâm đến sự riêng tư và các thiết lập không đáng tin cậy.

Noemi Glaeserlà một ứng cử viên tiến sĩ trong Khoa học Máy tính tại Đại học Maryland và Viện Max Planck cho Bảo mật và Quyền riêng tư và là một thực tập nghiên cứu tại a16z crypto trong mùa hè năm '23. Cô ấy là người nhận Học bổng Nghiên cứu Sau đại học NSF, và trước đó cô ấy là một thực tập nghiên cứu tại NTT Research.

Phụ lục: Cân nhắc bổ sung

Xử lý cập nhật/ thu hồi chìa khóa

Trong trường hợp của một thư mục khóa công khai, việc xử lý cập nhật và thu hồi khóa là đơn giản: để thu hồi một khóa, một bên yêu cầu hợp đồng xóa nó khỏi thư mục. Để cập nhật một khóa, mục nhập (id, pk) được ghi đè bằng một khóa mới thành (id, pk’).

Để thu hồi trong IBE, Boneh và Franklin đề nghị người dùng cập nhật định kỳ khóa của họ (ví dụ: mỗi tuần) và người gửi bao gồm khoảng thời gian hiện tại trong chuỗi nhận dạng khi mã hóa (ví dụ: "Bob "). Do tính chất không tương tác của mã hóa, người gửi không có cách nào biết khi nào người dùng thu hồi khóa của nó, vì vậy một số cập nhật thời gian là cố hữu. Boldyreva, Goyal và Kumar đã đưa ra một cơ chế thu hồi hiệu quả hơndựa trên"Fuzzy" IBE yêu cầu hai khóa để giải mã: khóa "nhận dạng" và khóa "thời gian" bổ sung. Bằng cách này, chỉ có khóa thời gian phải được cập nhật thường xuyên. Các khóa thời gian của người dùng được tích lũy trong một cây nhị phân và người dùng có thể sử dụng bất kỳ nút nào dọc theo đường dẫn (trong trường hợp cơ bản, chỉ cần root và đó là phần duy nhất được xuất bản bởi trình tạo khóa). Thu hồi khóa đạt được bằng cách không còn xuất bản cập nhật cho một người dùng cụ thể (xóa các nút dọc theo đường dẫn của người dùng đó khỏi cây), trong trường hợp đó, kích thước của bản cập nhật tăng lên nhưng không bao giờ nhiều hơn logarit về số lượng người dùng.

Cấu trúc RBE hiệu quả của chúng tôi đã không xem xét các bản cập nhật và thu hồi, một công việc theo dõicung cấp một trình biên dịch có thể “nâng cấp” hệ thống của chúng tôi để thêm các chức năng này.

Di chuyển dữ liệu ngoài chuỗi với DAS

Sử dụng giải pháp khả dụng dữ liệu (DAS) để di chuyển lưu trữ trên chuỗi khỏi chuỗi chỉ ảnh hưởng đến phép tính cho danh mục khóa công khai và RBE, giảm cả hai về cùng một lượng lưu trữ trên chuỗi. RBE vẫn giữ được lợi thế của việc bảo mật hơn cho người gửi, vì nó vẫn tránh rò rỉ danh tính người nhận thông qua các mô hình truy cập. IBE đã có lưu trữ trên chuỗi tối thiểu và không có lợi ích từ DAS.

Tuyên bố từ chối trách nhiệm:

1. Bài viết này được in lại từ [A16zcrypto], Tất cả bản quyền thuộc về tác giả gốc [Noemi Glaeser ]. Nếu có ý kiến ​​phản đối về việc tái in này, vui lòng liên hệ với Gate Họcđội ngũ, và họ sẽ xử lý nhanh chóng.
2. Miễn trừ trách nhiệm: Các quan điểm và ý kiến được thể hiện trong bài viết này chỉ thuộc về tác giả và không đưa ra bất kỳ lời khuyên đầu tư nào.
3. Các bản dịch của bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi có ghi chú, việc sao chép, phân phối hoặc đạo văn các bài viết đã được dịch là bị cấm.