Bằng chứng không có kiến ​​thức: Một ví dụ minh họa. Và điều gì xảy ra sau đó? Điều gì xảy ra sau tất cả những điều này?

Thuật ngữ đẹp là một trong những lợi thế mật mã hiện đại. Tên ban nhạc Punk hoặc biệt danh Tumbl là những thuật ngữ mật mã như "vị ngữ cốt lõi", "chức năng cửa bẫy" hoặc "phân tích mật mã vi sai không thể" nghe giống như vậy). Đối với tôi, có vẻ như một thuật ngữ như " không có kiến ​​thức".

Nhưng vẻ đẹp của thuật ngữ “không có kiến ​​thức” đã dẫn tới việc nó bị lạm dụng. Mọi người ngay lập tức nghĩ rằng không có kiến ​​thức đang trở thành đồng nghĩa với “rất, rất an toàn”. Vì lý do này, những từ này được thêm vào tên của các hệ thống an ninh và mạng ẩn danh– điều này thực sự không liên quan gì đến giao thức không có kiến ​​thức.

Chúng tôi đã nói tất cả những điều này để nhấn mạnh điều chính: chứng minh bằng không có kiến ​​thức(không có bằng chứng kiến ​​​​thức) là một trong những nhất công cụ mạnh mẽ mật mã từng phát triển. Nhưng thật không may, nó được nghiên cứu tương đối ít. Chúng ta hãy thử đưa ra một lời giải thích phi toán học về điều gì khiến ZK (không có kiến ​​thức) trở nên đặc biệt. Ở đây chúng ta sẽ nói về một số giao thức ZK hiện tại.

Nguồn gốc của kiến ​​thức không

Trước Goldwasser và những người khác, hầu hết công việc trong lĩnh vực này đều tập trung vào hệ thống chứng minh tính đúng đắn. Nghĩa là, trong trường hợp kẻ tấn công - Người kiểm tra - cố gắng đánh lừa Bộ điều khiển bằng cách đưa cho anh ta một giá trị sai. Nhưng Goldwasser, Micali và Rakoff lại nhìn vào mặt trái của vấn đề này. Thay vì chỉ lo lắng về Người kiểm tra, họ hỏi: điều gì sẽ xảy ra nếu bạn không tin tưởng Người kiểm soát?

Họ đặc biệt lo ngại về khả năng rò rỉ thông tin. Cụ thể, họ hỏi bao nhiêu thông tin thêm Kiểm soát viên sẽ nhận được gì trong quá trình chứng minh sự thật rằng tuyên bố đó là đúng?

Điều quan trọng cần lưu ý là đây không chỉ là mối quan tâm về mặt lý thuyết. Có thật ứng dụng thực tế, trong đó những điều này là quan trọng.

Đây là một trong số đó: hãy tưởng tượng rằng khách hàng đang ở trong thế giới thực muốn đăng nhập vào máy chủ web bằng mật khẩu. Cách tiếp cận tiêu chuẩnđến vấn đề "thế giới thực" liên quan đến việc lưu trữ phiên bản băm của mật khẩu trên máy chủ. Đăng nhập vào hệ thống như vậy được coi là một loại "xác nhận" rằng hàm băm của mật khẩu được cung cấp là đầu ra của hàm băm của mật khẩu hiện tại. Và quan trọng hơn, nó là “sự xác nhận” rằng khách hàng thực sự biết mật khẩu.

Hầu hết các hệ thống trong thế giới thực đều thực hiện "xác nhận" này theo cách tồi tệ nhất có thể. Máy khách chỉ cần chuyển mật khẩu ban đầu đến máy chủ, máy chủ sẽ tính toán lại hàm băm mật khẩu và so sánh nó với giá trị được lưu trữ. Vấn đề ở đây rất rõ ràng: máy chủ nhận được mật khẩu của tôi ở dạng hấp dẫn nhất đối với tin tặc, “văn bản thuần túy”. Và người dùng chỉ có thể cầu nguyện rằng bảo mật của máy chủ không bị xâm phạm.

Những gì Goldwasser, Micali và Rakoff đề xuất là niềm hy vọng về những phương pháp xác nhận mới. Nếu được triển khai đầy đủ, bằng chứng không có kiến ​​thức sẽ có thể cung cấp bằng chứng cho vấn đề được mô tả ở trên. Không tiết lộ một chút thông tin nào tương ứng với thực tế là “tuyên bố này là đúng”.

Ví dụ về "Thế giới thực"

Cho đến nay chúng ta đã nói về những điều khá trừu tượng. Hãy tiếp tục và đưa ra một ví dụ thực tế (hơi điên rồ) về giao thức không có kiến ​​thức.

Để giúp tôi giải thích ví dụ này, hãy tưởng tượng rằng tôi là một ông trùm viễn thông và tôi đang trong quá trình triển khai một mạng di động mới. Của tôi cấu trúc mạngđược trình bày dưới đây trong biểu đồ này. Mỗi đỉnh của biểu đồ đại diện cho một máy phát di động và các đường kết nối (cạnh) hiển thị vị trí hai ô chồng lên nhau. Ở những vị trí này, các máy phát sẽ gây nhiễu lẫn nhau. Điều tốt là cấu trúc mạng của tôi cho phép mỗi tháp được cấu hình ở một trong ba dải tần để tránh ảnh hưởng như vậy.

Do đó, nhiệm vụ triển khai mạng của tôi là chỉ định làn đường riêng cho mỗi tháp sao cho các ô không giao nhau. Nếu sử dụng màu sắc để biểu thị các dải tần, chúng ta có thể nhanh chóng phát triển một giải pháp cho vấn đề này:

Tất nhiên, nhiều bạn đã nhận thấy. Những gì tôi mô tả ở đây chỉ là trương hợp đặc biệt vấn đề lý thuyết nổi tiếng. Nó được gọi là “bài toán tô màu đồ thị ba màu”. Bạn cũng có thể biết về một tính năng thú vị vấn đề này. Đối với một số đồ thị, rất khó tìm ra nghiệm hoặc thậm chí xác định rằng nghiệm đó có tồn tại hay không. Bài toán tô màu đồ thị bằng ba màu (và tìm câu trả lời cho câu hỏi liệu giải pháp đó có tồn tại cho trường hợp này hay không), như đã biết, thuộc loại bài toán NP-đầy đủ.

Không cần phải nói rằng những câu đố về đồ chơi trên rất dễ giải. Nhưng nếu nó không dễ dàng như vậy thì sao? Ví dụ, hãy tưởng tượng rằng mạng của tôi thông tin di độngđã rất lớn và phức tạp. Trong trường hợp này, tôi sẽ không có đủ khả năng tính toán để tìm ra giải pháp. Trong trường hợp này, nên giao vấn đề cho người khác. Dành cho những người có đủ khả năng tính toán. Ví dụ: tôi có thể yêu cầu Google giải quyết vấn đề này.

Nhưng có một vấn đề.

Giả sử Google sẽ cung cấp cho tôi nhiều như tôi cần. khả năng tính toánđể tìm ra giải pháp tô màu chính xác cho biểu đồ của tôi. Tôi chắc chắn sẽ không trả tiền cho họ cho đến khi tôi chắc chắn rằng họ có giải pháp này. Đồng thời, Google sẽ không cung cấp cho tôi bản sao quyết định cho đến khi tôi thanh toán. Chúng ta đang ở ngõ cụt.

TRONG đời thực lẽ thường cho chúng ta biết câu trả lời cho vấn đề nan giải này liên quan đến luật sư và tài khoản ký quỹ. Nhưng ở đây chúng ta không nói về cuộc sống thực mà là về mật mã. Và nếu bạn đã từng đọc tác phẩm của các nhà mật mã học, bạn cũng biết rằng cách duy nhất để tìm ra giải pháp cho một vấn đề là nghĩ ra một điều gì đó hoàn toàn điên rồ. giải pháp kỹ thuật. Giải pháp kỹ thuật điên rồ (có mũ)

Hãy tưởng tượng rằng các nhân viên của Google đã tham khảo ý kiến ​​của Silvio Micali từ MIT và anh ấy đã hỏi các đồng nghiệp của mình là Oded Goldreich và Avi Wigderson. Sau khi tham khảo ý kiến, họ đã phát triển một giao thức đẹp đến mức thậm chí không cần đến máy tính. Một nhà kho lớn với nguồn cung cấp bút chì màu và giấy sẽ được sử dụng. Bạn cũng sẽ cần một số lượng lớn mũ.

Hãy xem nó hoạt động như thế nào

Đầu tiên, tôi sẽ đi vào một không gian nhà kho và phủ giấy lên sàn để tạo không gian đại diện cho mạng di động của mình. Sau đó tôi sẽ rời khỏi nhà kho. Giờ đây, Google có thể đến, xáo trộn bộ sưu tập bút chì và chọn ba màu bất kỳ (như đỏ/xanh/tím, như trong ví dụ này) và màu đại diện cho giải pháp. Lưu ý rằng màu cụ thể được sử dụng không quan trọng.

Trước khi rời khỏi nhà kho, Google đội một chiếc mũ lên mỗi đầu. Khi tôi trở lại đây là tất cả những gì tôi sẽ thấy:

Rõ ràng, phương pháp này sẽ bảo vệ hoàn hảo Bí mật của Google. Nhưng điều này sẽ không giúp tôi chút nào. Có thể Google đang tô màu ngẫu nhiên và do đó không đúng thứ tự. Hoặc có thể họ không điền gì cả.

Để thuyết phục tôi rằng vấn đề đã thực sự được giải quyết, Google cho tôi cơ hội “kiểm tra” kết quả tô màu biểu đồ của họ. Tôi có quyền chọn theo thứ tự ngẫu nhiên một mặt của biểu đồ này (nghĩa là dọc theo một đường thẳng giữa hai chiếc mũ liền kề). Google sẽ bỏ 2 chiếc mũ này ra, cho tôi xem Một phần nhỏ các giải pháp:

Xin lưu ý rằng thử nghiệm của tôi có hai kết quả có thể xảy ra:

Nếu hai đỉnh hiển thị có cùng màu (hoặc hoàn toàn không có màu!) thì tôi biết chắc chắn rằng Google đang nói dối tôi. Trong trường hợp này, tôi sẽ không trả cho Google dù chỉ một xu. Nếu hai đỉnh hiển thị có màu sắc khác nhau, có nghĩa là Google không lừa dối tôi trong trường hợp này.

Tôi hy vọng tuyên bố đầu tiên là rõ ràng. Thứ hai sẽ yêu cầu nhiều hơn giải thích chi tiết. Vấn đề là ngay cả khi thử nghiệm thành công, Google vẫn có thể lừa dối tôi. Tuy nhiên, tôi chỉ nhìn dưới hai chiếc mũ. Nếu có E cạnh riêng biệt trong biểu đồ thì có khả năng Google sẽ đưa ra giải pháp không chính xác. Ví dụ: sau một lần kiểm tra, họ đang đánh lừa tôi bằng xác suất (E-1)/E (đối với 1000 cạnh sẽ là 99,9%).

May mắn thay, Google đã có câu trả lời cho câu hỏi này. Chúng ta sẽ chạy lại giao thức!

Chúng tôi lấy giấy trắng để tạo một bản sao mới của biểu đồ. Google hiện đang thực hiện một cuộc ngẫu nhiên mới gồm ba cây bút chì màu. Sau đó, họ điền vào biểu đồ với giải pháp chính xác nhưng sử dụng một bộ ba màu ngẫu nhiên mới.

Một lần nữa chúng tôi thực hiện thao tác với mũ. Tôi quay lại và chọn ngẫu nhiên các đỉnh mới. Chúng ta hãy nhìn lại logic được mô tả ở trên. Lần này, nếu mọi việc suôn sẻ, tôi sẽ tự tin hơn nhiều rằng Google đang nói sự thật với tôi. Đó là vì để đánh lừa tôi, Google sẽ phải gặp may hai lần.

Một sự kiện như vậy có thể xảy ra - nhưng xác suất của nó sẽ còn thấp hơn. Khả năng Google đánh lừa tôi hai lần liên tiếp là (E-1)/E*(E-1)/E (hoặc khoảng 99,8% cơ hội cho ví dụ 1000 cạnh của chúng tôi).

May mắn thay, chúng ta không phải dừng lại ở hai lần thử. Chúng tôi sẽ thử đi thử lại cho đến khi chúng tôi tin rằng Google, với khả năng cao, đã nói sự thật.

Tôi khuyên bạn đừng tin lời tôi. Hãy thử Javascript này và tự mình xem.

Lưu ý rằng tôi không bao giờ hoàn toàn chắc chắn rằng Google đang trung thực - luôn có khả năng rất nhỏ là họ đang lừa dối tôi. Nhưng sau đó số lượng lớn lặp đi lặp lại (E^2, như trong trường hợp của chúng tôi), cuối cùng tôi sẽ đi đến điểm mà Google đang lừa dối tôi với xác suất không đáng kể - đủ để áp dụng thực tế. Sau đó, tôi có thể dễ dàng đưa tiền cho Google.

Điều quan trọng là Google cũng được bảo vệ trong trường hợp này. Nếu tôi cố gắng học bất cứ điều gì bằng cách lưu và phân tích các ghi chú giữa các lần chạy giao thức, tôi sẽ thất bại vì Google sử dụng màu sắc ngẫu nhiên trong mỗi lần lặp lại. Thông tin hạn chế tôi có thể nhận được sẽ không cho tôi biết bất cứ điều gì. Không có cách nào để tôi liên kết dữ liệu này lại với nhau.

Điều gì khiến ví dụ này trở thành "không có kiến ​​thức"?

Tôi đang cố thuyết phục bạn rằng giao thức này không cho phép thông tin rò rỉ ra ngoài Giải pháp của Google. Nhưng bạn không cần phải tin lời tôi! Nguyên tắc đầu tiên của các nhà mật mã là không bao giờ tin những điều như vậy mà không có bằng chứng.

Goldwasser, Micali và Rakoff đề xuất ba tiêu chí mà mọi giao thức không có kiến ​​thức đều phải đáp ứng. Một cách không chính thức, chúng có thể được mô tả như sau:

Sự hoàn thiện. Nếu Google nói cho tôi biết sự thật thì tôi phải có bằng chứng chắc chắn về điều đó (bằng chứng có xác suất cao). Độ tin cậy. Google chỉ có thể thuyết phục tôi nếu nó thực sự nói lên sự thật. “Không tiết lộ” (tiêu chí này thực sự được gọi như vậy). Tôi không cần phải tìm hiểu gì thêm ngoài giải pháp Google mà tôi có được.

Chúng tôi đã thảo luận về các lập luận cho sự đầy đủ. Giao thức cuối cùng sẽ thuyết phục tôi (với khả năng xảy ra lỗi không đáng kể) nếu tôi chạy nó đủ số lần. Độ tin cậy cũng khá dễ dàng để chứng minh. Nếu Google cố gắng lừa dối tôi, tôi sẽ phát hiện ra điều đó trong phần lớn các trường hợp.

Thuộc tính khó khăn nhất vẫn là “không có kiến ​​​​thức”. Để hiểu nó, chúng ta hãy làm một thí nghiệm tưởng tượng khá kỳ lạ.

Thí nghiệm tưởng tượng với cỗ máy thời gian

Đầu tiên, hãy bắt đầu với một giả định điên rồ. Hãy tưởng tượng rằng các kỹ sư của Google không thông minh như mọi người nghĩ. Họ giải quyết vấn đề này hàng tuần và không thể tìm ra giải pháp. Mười hai giờ trước thời hạn, Google trở nên tuyệt vọng. Họ quyết định lừa tôi và nói rằng họ có một cuốn sách tô màu cho Bá tước (mặc dù thực tế họ không có cuốn nào).

Ý tưởng của họ là ghé qua xưởng GoogleX và mượn nguyên mẫu cỗ máy thời gian của Google. Kế hoạch ban đầu là quay trở lại một vài năm và sử dụng thêm thời gian làm việcđể tìm giải pháp mới cho vấn đề. Thật không may, cũng như nhiều nguyên mẫu khác của Google, cỗ máy thời gian có một số hạn chế. Quan trọng nhất là cô ấy chỉ có thể du hành ngược thời gian bốn phút rưỡi.

Như vậy, không cần thiết phải sử dụng cỗ máy thời gian để tăng thời gian hoàn thành một công việc. Tuy nhiên, hóa ra công nghệ rất hạn chế này có thể được sử dụng để đánh lừa tôi.

Tôi thực sự không biết chuyện gì đang xảy ra ở đây. Nhưng có vẻ như nó sẽ có ích.

Kế hoạch hóa ra đơn giản đến mức quỷ dị. Nếu Google không biết nên tô màu biểu đồ như thế nào, họ sẽ chỉ ngẫu nhiên tô màu giấy rồi đội mũ lên trên. Nếu may mắn thay, các đỉnh có màu sắc khác nhau, tất cả chúng ta sẽ thở phào nhẹ nhõm và tiếp tục làm việc với niềm tin rằng mọi thứ đều ổn.

Giả sử tôi cởi một chiếc mũ ra và phát hiện ra hai đỉnh cùng màu. Nếu giao thức được triển khai theo cách thông thường, Google sẽ thất bại trong trường hợp này. Nhưng chúng ta sử dụng cỗ máy thời gian. Bất cứ khi nào Google thấy mình ở một tình thế khó xử, nó chỉ đơn giản là khắc phục tình hình đó. Tức là được bổ nhiệm đặc biệt nhân viên Google kéo công tắc, thời gian quay ngược lại bốn phút rưỡi, và Nhóm Google tô màu đồ thị bằng một giải pháp ngẫu nhiên hoàn toàn mới. Sau đó, họ tua nhanh thời gian và thử lại.

Về cơ bản, cỗ máy thời gian cho phép Google "sửa" mọi lần đăng nhập thất bại mà tôi không nghi ngờ gì. Vì kết quả xấu sẽ chỉ xảy ra 1/3 thời gian nên thời gian thực thi dự kiến ​​của giao thức (theo quan điểm của Google) chỉ dài hơn một chút so với khi giao thức được thực thi công bằng. Theo quan điểm của tôi, tôi thậm chí còn không biết việc du hành thời gian này đang diễn ra.

Điểm cuối cùng này là quan trọng nhất. Theo quan điểm của tôi, tôi tương tác với giao thức theo cách tương tự dù có cỗ máy thời gian hay không. Chưa hết, điều đáng chú ý nữa là ở phiên bản cỗ máy thời gian, Google hoàn toàn không có thông tin gì về cách tô màu đồ thị.

Và điều gì xảy ra sau đó?

Những gì chúng tôi vừa trình bày là một ví dụ lý thuyết. Trong một thế giới mà thời gian cứ trôi về phía trước và không ai có thể đánh lừa tôi bằng cỗ máy thời gian, giao thức mũ hoạt động chính xác. Sau E^2 vòng chạy, tôi nên tự tin (không hoàn toàn nhưng với xác suất gian lận không đáng kể) rằng biểu đồ được tô màu chính xác và Google đã cung cấp thông tin chính xác.

Nếu thời gian có thể bị thao túng (đặc biệt là nếu Google có thể "tua lại thời gian") thì nó có thể giả mạo giao thức, ngay cả khi nó không có thông tin nào về cách tô màu biểu đồ.

Theo quan điểm của tôi, sự khác biệt giữa hai giao thức này là gì? Chúng có cùng sự phân bố thống kê và truyền tải cùng một lượng thông tin hữu ích.

Dù bạn có tin hay không, điều này chứng tỏ một điều rất quan trọng.

Cụ thể, người ta cho rằng tôi (Người xác minh) ​​có một số loại chiến lược cho phép tôi "trích xuất" thông tin hữu ích về cách Google thực hiện tô màu nếu giao thức trung thực được chạy. Sau đó, chiến lược của tôi cũng sẽ có hiệu quả nếu tôi bị cỗ máy thời gian đánh lừa. Theo quan điểm của tôi, các giao thức chạy giống hệt nhau về mặt thống kê. Về mặt thể chất tôi không thể chỉ ra sự khác biệt.

Như vậy, lượng thông tin mà tôi sẽ nhận được trong “thí nghiệm thực tế” và “thử nghiệm cỗ máy thời gian” là hoàn toàn giống nhau. Lượng thông tin mà Google đưa vào thử nghiệm cỗ máy thời gian chính xác là bằng không. Vì vậy, ngay cả trong thế giới thực cũng sẽ không có hiện tượng rò rỉ thông tin. Tất cả những gì còn lại là chứng minh rằng các nhà khoa học máy tính có cỗ máy thời gian (suỵt, đó là bí mật).

Làm thế nào để thoát khỏi mũ và cỗ máy thời gian

Tất nhiên, chúng tôi thực sự không muốn chạy giao thức bằng cách sử dụng mũ. Và ngay cả Google (rất có thể) cũng không có cỗ máy thời gian thực.

Để gắn kết tất cả những thứ này lại với nhau, chúng ta cần đưa giao thức này vào thế giới kỹ thuật số. Để làm được điều này, chúng ta cần một “chiếc mũ” kỹ thuật số tương đương: thứ gì đó che giấu ý nghĩa kỹ thuật số, đồng thời “ràng buộc” ý nghĩa và người tạo ra nó (tạo ra một “cam kết”), để anh ta không thể thay đổi ý định. .

May mắn thay, chúng tôi có một công cụ tuyệt vời cho ứng dụng này. Nó được gọi là chương trình cam kết kỹ thuật số. Sơ đồ cam kết cho phép một bên tạo "cam kết" cho một tin nhắn, giữ bí mật và sau đó mở "cam kết" để xem nội dung bên trong. Chúng có thể được xây dựng từ Các thành phần khác nhau, kể cả từ kẻ mạnh chức năng mật mã băm.

Sau khi nhận được sơ đồ cam kết, chúng tôi đã lắp ráp tất cả các thành phần để khởi động vào ở dạng điện tử giao thức không có kiến ​​thức. Đầu tiên người thử nghiệm mã hóa màu của các đỉnh thành một tập hợp tin nhắn kỹ thuật số(ví dụ: các số 0, 1, 2), sau đó tạo ra nghĩa vụ kỹ thuật số cho mỗi số. Các nghĩa vụ này được chuyển tiếp đến Kiểm soát viên. Khi Bộ điều khiển mở một cạnh, Người kiểm tra sẽ hiển thị các giá trị cho các nghĩa vụ tương ứng với hai đỉnh.

Đây là cách chúng tôi đã loại bỏ được những chiếc mũ. Nhưng làm thế nào để chúng tôi chứng minh rằng giao thức này không có kiến ​​thức?

Nhưng bây giờ chúng ta đang ở trong thế giới kỹ thuật số. Do đó, chúng tôi không cần cỗ máy thời gian để xác nhận rằng giao thức hoạt động. Bí quyết chính là giao thức sẽ không hoạt động giữa hai người mà giữa hai chương trình máy tính khác nhau (hoặc chính thức hơn là hai máy Turing xác suất.)

Bây giờ chúng ta có thể chứng minh định lý sau: nếu Bộ điều khiển trích xuất thông tin hữu ích từ một lần chạy giao thức bình thường, anh ta sẽ nhận được cùng một lượng thông tin hữu ích như từ một lần chạy "gian lận" của giao thức mà Người kiểm tra không đưa vào bất kỳ thông tin nào để bắt đầu.

Chúng ta đang nói về các chương trình máy tính và chúng có thể “quay ngược thời gian”. Ví dụ: hãy cân nhắc sử dụng máy ảo có thể chụp ảnh nhanh. Ví dụ về "tua lại thời gian" bằng cách sử dụng máy ảo. Ban đầu, máy ảo đi theo một đường dẫn, quay về trạng thái ban đầu, sau đó thực thi các nhánh tới một đường dẫn mới.

Ngay cả khi chúng ta không xem xét đến máy ảo thì bất kỳ chương trình máy tính nào cũng có thể được "tua lại" thành trạng thái trước đó, chỉ đơn giản bằng cách chạy chương trình ngay từ đầu và gửi dữ liệu giống như dữ liệu đầu vào. Với điều kiện là các đầu vào (bao gồm cả đầu vào Số ngẫu nhiên), được sửa, chương trình sẽ luôn đi theo cùng một đường dẫn thực hiện. Vì vậy, chúng ta có thể tua lại chương trình, bắt đầu lại từ đầu và “phân nhánh” quá trình thực thi của nó khi chương trình đạt đến một điểm mong muốn nhất định.

Cuối cùng, những gì chúng ta nhận được có thể được biểu diễn dưới dạng một định lý. Nếu đối với Bộ điều khiển có chương trình máy tính, trích xuất thành công thông tin hữu ích từ Người kiểm tra (bằng cách tương tác với giao thức), sau đó Người kiểm tra có thể sử dụng thủ thuật tua lại chương trình, cung cấp các giải pháp ngẫu nhiên cho Bộ điều khiển. Nó sử dụng logic tương tự như chúng ta đã áp dụng ở trên: nếu Bộ điều khiển có thể trích xuất thành công thông tin bằng cách chạy một giao thức thực, thì nó sẽ thu được cùng một lượng thông tin bằng cách chạy một giao thức giả dựa trên việc tua lại chương trình. Nhưng vì giao thức giả mạo không truyền bất kỳ dữ liệu hữu ích nào nên không có thông tin nào có thể được trích xuất. Như vậy, thông tin mà Controller có thể trích xuất luôn bằng 0.

Điều gì xảy ra sau tất cả những điều này?

Tóm lại, chúng ta có thể nói rằng giao thức này đã hoàn chỉnh và đáng tin cậy. Chúng ta có thể nói về độ tin cậy trong mọi tình huống mà cả hai bên đều không cố gắng lừa dối nhau.

Đồng thời, giao thức không có kiến ​​thức. Để chứng minh điều này, chúng tôi đã chỉ ra rằng một chương trình mà Bộ điều khiển chạy để trích xuất thông tin sẽ có thể trích xuất dữ liệu từ một chương trình không có dữ liệu có ý nghĩa. Điều này dẫn đến một mâu thuẫn rõ ràng, cho chúng ta biết rằng giao thức trong mọi tình huống không bị rò rỉ thông tin.

Điều này mang lại cho chúng tôi những lợi thế quan trọng. Vì bất kỳ ai cũng có thể tạo bản ghi giả (như ví dụ trên Google khi họ cố gắng thuyết phục tôi rằng họ có giải pháp), tôi không thể phát lại bản ghi để chứng minh trường hợp của mình với bất kỳ ai khác (chẳng hạn như thẩm phán). Thẩm phán sẽ nói rằng ông ta không chắc chắn rằng đoạn ghi âm được thực hiện một cách trung thực và không bị chỉnh sửa (như trong ví dụ với Google và việc sử dụng cỗ máy thời gian). Điều này có nghĩa là bản ghi chép không chứa bất kỳ thông tin nào. Giao thức chỉ có ý nghĩa nếu bản thân tôi tham gia và có thể chắc chắn rằng mọi thứ diễn ra trong thời gian thực.

Bằng chứng cho tất cả các NP!

Đối với những người đã làm được điều này, tôi có một tin quan trọng. Bản thân nhiệm vụ tô màu mạng di động bằng ba màu rất thú vị, nhưng đó không phải là tất cả. Cho thật điều thú vị về bài toán tô màu ba màu là nó thuộc lớp NP-đầy đủ. Điều này có nghĩa là bất kỳ vấn đề nào khác thuộc lớp NP đều có thể được quy gọn thành vấn đề này.

Nói một cách đơn giản, Goldrich, Micali và Widgerson đã chứng minh rằng ZK "hiệu quả" tồn tại cho một loạt các bài toán hữu ích. Nhiều trong số chúng thú vị hơn nhiều so với vấn đề ấn định tần số trong mạng di động.

Bạn chỉ cần tìm câu lệnh (trong NP) mà bạn muốn kiểm tra và chuyển nó thành bài toán tô màu đồ thị ba màu. Từ thời điểm này, bạn có thể chạy phiên bản kỹ thuật số của giao thức của chúng tôi với mũ.

Thay vì kết quả

Tất nhiên, sẽ cực kỳ ngu ngốc nếu bắt đầu sử dụng giao thức này ngay lập tức trong thực tế. Chi phí tính toán của nó sẽ bao gồm kích thước tổng thể tuyên bố và bằng chứng ban đầu, cộng với chi phí chuyển vấn đề thành biểu đồ và một lần chạy E^2 khác của giao thức, cần thiết để xác minh tính đúng đắn của giải pháp. Về lý thuyết, điều này là "hiệu quả", nhưng vì tổng chi phí của việc chứng minh sẽ là đa thức của độ dài đầu vào nên nó không thể áp dụng được trong thực tế.

Vì vậy cho đến nay chúng ta chỉ chứng minh được rằng những bằng chứng như vậy là có thể thực hiện được. Vẫn còn phải tìm bằng chứng đủ thực tế để sử dụng thực sự.

Ghi chú

* Về mặt chính thức, mục đích của bằng chứng tương tác là thuyết phục Bên kiểm soát rằng chuỗi cụ thể thuộc về bất kỳ ngôn ngữ nào. Thông thường, Người kiểm tra trong các nhiệm vụ có quyền lực vô hạn và Người điều khiển bị hạn chế về khả năng thực hiện các phép tính.

**Ví dụ này dựa trên giải pháp ban đầu Goldwasser, Micali và Rakoff, và ví dụ hướng dẫn sử dụng mũ do Silvio Micali thiết kế.

****** Một ví dụ đơn giản về cam kết có thể được xây dựng bằng cách sử dụng hàm băm mẫu. Để tạo cam kết về giá trị "x", chúng tôi chỉ cần tạo một số chuỗi số ngẫu nhiên (đủ dài) mà chúng tôi gọi là "muối" và cam kết đầu ra là C = hash(salt || x). Để mở một cam kết, bạn chỉ cần mở "x" và "muối". Bất cứ ai cũng có thể xác minh rằng cam kết ban đầu là hợp lệ bằng cách tính toán lại hàm băm. Cái này phương pháp an toàn theo một số giả định khá mạnh về bản thân hàm số đó.

Bằng chứng không có kiến ​​thức) là một giao thức tương tác cho phép một trong các bên (người xác minh) ​​xác minh độ tin cậy của một tuyên bố (thường là toán học) mà không nhận bất kỳ thông tin nào khác từ bên kia (người chứng minh).

Bằng chứng không có kiến ​​thức phải có ba thuộc tính:

1. Tính đầy đủ: nếu tuyên bố thực sự đúng thì người chứng minh sẽ thuyết phục người xác minh về điều này.
2. Tính đúng đắn: Nếu tuyên bố sai, thì ngay cả một người chứng minh không trung thực cũng sẽ không thể thuyết phục được người xác minh ngoại trừ xác suất không đáng kể.
3. Không có kiến ​​thức: nếu tuyên bố là đúng, thì bất kỳ người xác minh nào thậm chí không trung thực cũng sẽ không biết gì khác ngoài sự thật rằng tuyên bố đó là đúng.

Cấu trúc chung của bằng chứng không có kiến ​​thức

Mỗi vòng hoặc công nhận bằng chứng bao gồm ba giai đoạn. Chúng có thể được mô tả sơ đồ như sau:

Lúc đầu MỘT chọn từ một tập hợp được xác định trước một phần tử trở thành bí mật của nó (khóa riêng). Dựa trên yếu tố này, khóa công khai được tính toán và sau đó được công bố. Biết một bí mật xác định nhiều câu hỏi mà MỘT sẽ luôn có thể đưa ra câu trả lời chính xác. Sau đó MỘT chọn một phần tử ngẫu nhiên từ tập hợp, theo các quy tắc nhất định (tùy thuộc vào thuật toán cụ thể) tính toán bằng chứng rồi gửi nó đi B. Sau đó B chọn một trong toàn bộ câu hỏi và hỏi MỘT trả lời đi ( gọi). Tùy theo câu hỏi, MỘT gửi câu trả lời B. Thông tin đã nhận Bđủ để kiểm tra xem MỘT sở hữu bí mật. Các vòng có thể được lặp lại nhiều lần nếu cần thiết cho đến khi xác suất MỘT câu trả lời "đoán" sẽ không đủ thấp.

Kỹ thuật này còn được gọi là “cắt và chọn”.

Ví dụ

Hãy gọi bên xác minh là Petya và bên chứng minh là Dima (trong văn học tiếng Anh cặp Peggy (từ câu tục ngữ) và Victor (từ người xác minh). Giả sử Dima biết chu trình Hamilton trong đồ thị lớn G. Petya biết Bá tước G, nhưng anh ta không biết chu trình Hamilton trong đó. Dima muốn chứng minh cho Petya rằng anh ta biết chu trình Hamilton mà không tiết lộ chính chu trình này hay bất kỳ thông tin nào về nó (có lẽ Petya muốn mua chu trình Hamilton này từ Dima, nhưng trước đó hãy đảm bảo rằng Dima thực sự có nó).

Để làm điều này, Petya và Dima cùng thực hiện một số vòng của giao thức:

Trong mỗi vòng, Petya chọn một bit ngẫu nhiên mới mà Dima không biết, vì vậy để Dima trả lời cả hai câu hỏi, điều cần thiết là H thực sự là đẳng cấu G và Dima nên biết chu trình Hamilton trong H(và do đó cũng trong G). Vì vậy, sau đủ số vòng, Petya có thể chắc chắn rằng Dima thực sự có chu trình Hamilton trong G. Mặt khác, Dima không tiết lộ bất kỳ thông tin nào về chu trình Hamilton trong G. Hơn nữa, Petya sẽ khó chứng minh cho bất kỳ ai khác rằng anh ấy hoặc Dima biết chu trình Hamilton trong G.

Giả sử Dima không có chu trình Hamilton trong G và anh ta muốn lừa dối Petya. Sau đó Dima cần một không đẳng cấu Gđồ thị G", trong đó anh ta vẫn biết chu trình Hamilton. Trong mỗi hiệp anh ấy cũng có thể chuyền cho Petya H"- đẳng cấu G", hoặc H- đẳng cấu G. Nếu Petya yêu cầu chứng minh đẳng cấu và được thông qua H, thì sự lừa dối sẽ không bị bại lộ. Tương tự như vậy, nếu anh ta yêu cầu biểu diễn chu trình Hamilton và được cho H". Trong trường hợp này, khả năng Dima vẫn lừa dối Petya sau N vòng bằng 1/2 n, có thể nhỏ hơn bất kỳ giá trị nào được xác định trước nếu có đủ số vòng.

Giả sử Petya không nhận ra chu trình Hamilton nhưng muốn chứng minh cho Vasya thấy rằng Dima biết điều đó. Ví dụ, nếu Petya quay phim tất cả các vòng của giao thức, Vasya khó có thể tin anh ta. Vasya có thể cho rằng Petya và Dima đang thông đồng với nhau và trong mỗi hiệp, Petya đã thông báo trước cho Dima về việc anh ấy chọn một bit ngẫu nhiên để Dima có thể truyền lại cho anh ấy Hđể kiểm tra đẳng cấu và H"để kiểm tra chu trình Hamilton. Do đó, nếu không có sự tham gia của Dima, người ta có thể chứng minh rằng anh ta chỉ biết chu trình Hamilton bằng cách chứng minh rằng các bit thực sự ngẫu nhiên đã được chọn trong tất cả các vòng của giao thức.

Lạm dụng

Một số cách để lạm dụng bằng chứng không có kiến ​​thức đã được đề xuất:

Xem thêm

• Nghị định thư Gillu-Kiskatra

Văn học

• A. Menezes, P. van Oorschot, S. Vanstone. Sổ tay mật mã ứng dụng. - Nhà xuất bản CRC, 1996. - 816 tr. - ISBN 0-8493-8523-7
• Schneier B. Mật mã ứng dụng. Giao thức, thuật toán, văn bản nguồn trong ngôn ngữ C = Mật mã ứng dụng. Giao thức, thuật toán và mã nguồn trong C. - M.: Triumph, 2002. - 816 tr. - 3000 bản. - ISBN 5-89392-055-4

Quỹ Wikimedia. 2010.

• Fonvizina, Natalya Dmitrievna
• chuzumovo

Xem “Bằng chứng kiến ​​thức không” là gì trong các từ điển khác:

bằng chứng không có kiến ​​thức về thông tin bí mật- Bằng chứng kiến ​​thức không thể xuyên thủng; bằng chứng về việc sở hữu bất kỳ thông tin nào mà không tiết lộ thông tin này. Chủ đề: bảo vệ thông tin EN bằng chứng kiến ​​thức không…

bằng chứng không có kiến ​​thức lặp đi lặp lại về thông tin nhạy cảm- — Chủ đề bảo mật thông tin EN không có kiến ​​thức lặp lại bằng chứngZKIP … Hướng dẫn dịch thuật kỹ thuật

bằng chứng không có kiến ​​​​thức không lặp lại về thông tin nhạy cảm- NDNR - [] Chủ đề bảo vệ thông tin Từ đồng nghĩa NDNR EN non iterative zero architecture proofNIZK ... Hướng dẫn dịch thuật kỹ thuật

mật mã- Máy mật mã Lorenz của Đức đã được sử dụng trong Thế chiến thứ hai để mã hóa những tin nhắn bí mật nhất Mật mã học (từ tiếng Hy Lạp khác ... Wikipedia

Danh sách các thuật toán- Trang này là một danh sách thông tin. Bài chi tiết: Thuật toán Dưới đây là danh sách các thuật toán được nhóm theo danh mục. Thông tin chi tiết hơn được đưa ra trong danh sách cấu trúc dữ liệu và ... Wikipedia

Nhà mật mã học- Máy mật mã Lorenz của Đức, được sử dụng trong Thế chiến II để mã hóa những thông điệp bí mật nhất. Mật mã học (từ tiếng Hy Lạp κρυπτός ẩn và γράφω viết) khoa học về phương pháp toán họcđảm bảo bí mật... ... Wikipedia

Thuật toán lập trình được- Một danh sách dịch vụ các bài viết được tạo ra để phối hợp công việc phát triển chủ đề. Cảnh báo này chưa được cài đặt... Wikipedia

SRP- Giao thức mật khẩu từ xa an toàn (SRPP) là giao thức xác thực mật khẩu có khả năng chống nghe lén và cuộc tấn công MITM và không yêu cầu bên thứ ba đáng tin cậy. SRP chứa một số thành phần từ các giao thức nhận dạng và trao đổi khóa khác... Wikipedia

Giao thức tiền pháp định- Giao thức Fiat Shamir là một trong những giao thức nhận dạng zero-know (Giao thức không kiến ​​thức) nổi tiếng nhất. Giao thức được đề xuất bởi Amos Fiat và Adi Shamir. Hãy để A... ... Wikipedia

Giao thức Fiat-Shamir- Giao thức Fiat Shamir là một trong những giao thức nhận dạng zero-know (Giao thức không kiến ​​thức) nổi tiếng nhất. Giao thức được đề xuất bởi Amos Fiat và Adi Shamir. Hãy cho A biết một số... ... Wikipedia

Bằng chứng không có kiến ​​thức là một giao thức mật mã cho phép một trong các bên (người xác minh, bên B) xác minh rằng bên kia (người chứng minh, bên A) biết một số tuyên bố, trong khi người xác minh không nhận được thông tin nào khác về chính tuyên bố đó. Nói cách khác, A chứng minh kiến ​​thức về bí mật mà không tiết lộ bí mật đó.

Việc sử dụng bằng chứng không có kiến ​​thức để chứng minh danh tính lần đầu tiên được đề xuất bởi Uriel Fieg, Amos Fiat và Adi Shamir. TRONG trong trường hợp này người dùng chứng minh kiến ​​thức của mình khóa riêng, trong trường hợp này hoạt động như một bí mật mà không tiết lộ nó. Bằng cách này, anh ta chứng minh được danh tính của mình.

Bằng chứng không có kiến ​​thức có ba thuộc tính chính:
1. Sự hoàn chỉnh. Nếu người chứng minh biết tuyên bố đó thì anh ta sẽ có thể thuyết phục người xác minh nó.
2. Tính đúng đắn. Nếu người chứng minh không biết tuyên bố đó thì anh ta chỉ có thể đánh lừa người xác minh với xác suất không đáng kể.
3. Không có kiến ​​thức. Người xác minh, ngay cả khi anh ta cư xử không trung thực, sẽ không học được gì khác ngoài thực tế là người chứng minh đã biết tuyên bố đó.

Bằng chứng có dạng một giao thức tương tác. Điều này có nghĩa là Bên B sẽ đặt một loạt câu hỏi cho người chứng minh, nếu biết bí mật thì sẽ trả lời đúng tất cả các câu hỏi. Nếu bên A không biết bí mật đó nhưng cô ấy muốn thuyết phục giám khảo bằng cách khác thì cô ấy có một số xác suất (có thể là 50%, như trong các ví dụ trong chủ đề này) để trả lời đúng câu hỏi. Tuy nhiên, sau một số câu hỏi nhất định (10 - 20), người xác minh bị thuyết phục với khả năng khá cao là người chứng minh không biết bí mật. Tuy nhiên, không có câu trả lời nào cung cấp bất kỳ thông tin nào về bí mật đó.

Hang động không kiến ​​thức

Bằng chứng không có kiến ​​thức được Jean-Jacques Quiscaterre và Louis Guilloux giải thích rõ ràng bằng cách sử dụng câu chuyện về hang động của Ali Baba (xem hình). Để đi qua hang, bạn cần mở cánh cửa giữa C và D. Cánh cửa chỉ mở khi có người nói ra những lời thần kỳ. Hãy để Peggy biết những lời thần kỳ và muốn chứng minh điều đó cho Victor mà không tiết lộ lời nói đó.

Đây là cách bằng chứng không có kiến ​​thức hoạt động trong trường hợp này:
1. Victor đang ở điểm A.
2. Peggy đi xuyên qua hang động đến cửa dọc theo lối đi C hoặc lối đi D. Victor không nhìn thấy Peggy đã đi theo hướng nào. Sau khi Peggy biến mất trong hang, Victor di chuyển đến điểm B.
3. Victor mắng Peggy hãy ra khỏi hang từ lối đi bên trái hoặc lối đi bên phải.
4. Peggy, sử dụng phép thuật để mở khóa cửa nếu cần thiết, thoát ra khỏi hang động từ lối đi mà Victor yêu cầu cô đi ra.
5. Peggy và Victor lặp lại các bước 1-4 nhiều lần.

Trong trường hợp Peggy không biết bí mật thì cô ấy sẽ không thể lừa dối Victor nếu các giai đoạn chứng minh (công nhận) được lặp lại nhiều lần liên tiếp. Vì cô ấy chỉ có thể thoát ra từ lối đi mà cô ấy đã đi vào nên trong mỗi vòng của giao thức, có 50% cơ hội đoán được Victor sẽ yêu cầu cô ấy đi ra từ bên nào. Theo đó, xác suất cô lừa được Victor cũng là 50%. Tuy nhiên, xác suất lừa được anh ta trong hai hiệp đã là 25%, trong n hiệp cô chỉ có một cơ hội trong 2^n. Victor có thể tự tin cho rằng nếu tất cả n (n=10-20) vòng chứng minh của Peggy đều đúng thì cô ấy biết những từ bí mật mở ra cánh cửa giữa điểm C và D.

Nếu Victor ghi lại mọi chuyện xảy ra trên máy quay phim thì đoạn video này không phải là bằng chứng cho bên thứ ba. Peggy và Victor lẽ ra đã thỏa thuận trước về việc Victor sẽ yêu cầu cô rời đi. Sau đó lần nào cô ấy cũng sẽ rời khỏi nơi mà Victor đã chỉ định mà không hề biết. từ kỳ diệu. Mặt khác, Victor có thể giả mạo đoạn video ghi lại, chỉ để lại những nỗ lực thành công của Peggy trong đó, cắt bỏ mọi thứ khác.

Cần lưu ý rằng sự tương tự trong hang động không hoàn toàn chính xác. Vì, để chứng minh kiến ​​​​thức về từ ngữ, Peggy có thể chỉ cần đi vào từ một phía, trong khi Victor nhìn thấy cô ấy đã đi theo hướng nào và thoát ra từ phía bên kia. Tuy nhiên, giao thức này mô tả hoàn hảo một bằng chứng không có kiến ​​thức từ quan điểm toán học.

Giao thức Fiat-Shamir

Một trong những giao thức nổi tiếng nhất để nhận dạng cá nhân bằng cách sử dụng bằng chứng không có kiến ​​thức là giao thức được đề xuất bởi Amos Fiat và Adi Shamir, sức mạnh của nó dựa trên sự khó khăn trong việc trích xuất modulo căn bậc hai một số tổng hợp đủ lớn n có hệ số hóa là không biết.

Trước đây, trước khi tự mình chứng minh, trung tâm tin cậy T sẽ chọn và xuất bản mô-đun một cách đầy đủ. số lượng lớn n = p*q, rất khó phân tích thành nhân tử. Trong trường hợp này p, q – số nguyên tố và được giữ bí mật. Mỗi người dùng A chọn một bí mật s từ khoảng (1, n−1) nguyên tố cùng nhau đến n. Sau đó, khóa chung v = s^2 (mod n) được tính toán.

Kết quả v được đăng ký bởi trung tâm tin cậy là khóa công khai người dùng A, và giá trị s là bí mật của A. Chính kiến ​​thức về bí mật s này cần được A chứng minh cho bên B mà không tiết lộ nó trong t vòng. Mỗi công nhận bao gồm các giai đoạn sau:
1. A chọn một r ngẫu nhiên từ khoảng (1, n−1) và gửi x = r^2 (mod n) cho bên B.
2. B chọn ngẫu nhiên bit e (0 hoặc 1) và gửi đến A.
3. A tính toán y = r*s^e (mod n) và gửi lại cho B.
4. Bên B kiểm tra đẳng thức y^2 ≡ x*v^e (mod n). Nếu đúng thì quá trình chuyển sang vòng tiếp theo của giao thức sẽ diễn ra, nếu không thì bằng chứng sẽ không được chấp nhận.

Việc chọn e từ tập hợp ngụ ý rằng nếu bên A thực sự biết bí mật thì anh ta sẽ luôn có thể trả lời đúng, bất kể e đã chọn là gì. Giả sử A muốn lừa B, chọn ngẫu nhiên r và gửi x = r^2/v thì nếu e = 0 thì A trả về thành công B y = r, trường hợp e = 1 thì A sẽ không bị có khả năng trả lời đúng, t .To. không biết s, nhưng giải nén Căn bậc hai từ v modulo n là khá khó khăn.

Xác suất người dùng A không biết bí mật s nhưng thuyết phục được thanh tra B ngược lại sẽ được ước tính bằng xác suất p = = 2^(–t), trong đó t là số lần công nhận. Để đạt được độ tin cậy cao thì chọn giá trị đủ lớn (t = 20 − 40). Do đó, B được chứng nhận biết A khi và chỉ khi tất cả t vòng đều thành công.

Để giao thức này thực thi chính xác, Bên A không bao giờ được sử dụng lại giá trị của x. Nếu A đã làm điều này và B, trong một vòng lặp khác, đã gửi cho A một bit ngẫu nhiên r khác ở bước 2 thì B sẽ có cả hai phản hồi của A. Khi đó B có thể tính giá trị của s và biết Chìa khóa bí mật Alice.

Phần kết luận

Đối với các triển khai như thẻ thông minh, giao thức Fiat-Shamir không phù hợp lắm vì trao đổi với thế giới bên ngoài mất thời gian và việc lưu trữ dữ liệu cho mỗi lần công nhận có thể nhanh chóng làm cạn kiệt khả năng hạn chế của thẻ. Do đó, Gillu và Kiskatr đã phát triển thuật toán nhận dạng không có kiến ​​thức phù hợp hơn cho ứng dụng tương tự. Trao đổi giữa Peggy và Victor, cũng như các chứng nhận song song trong mỗi trao đổi, được giữ ở mức tối thiểu tuyệt đối: đối với mỗi bằng chứng chỉ có một trao đổi, trong đó chỉ có một chứng nhận. Ngoài ra còn có sơ đồ Schnorr, là một phương án thay thế cho sơ đồ Gillu-Kiskatra và Fiat-Shamir. Nếu bạn thích chủ đề này, tôi sẽ viết về chúng trong chủ đề tiếp theo của tôi.

Một trong những điều tuyệt vời nhất về mật mã hiện đại là thuật ngữ tuyệt vời của nó. Bạn có thể tạo bao nhiêu ban nhạc punk tùy thích với những cái tên như Hardcore Predicate, Trapdoor Function hoặc Impossible Differential Cryptanalysis. Tuy nhiên, có một thuật ngữ vượt qua tất cả những thuật ngữ khác. Đây là Bằng chứng Không có Kiến thức - "không có bằng chứng kiến ​​thức".

Thuật ngữ “không có kiến ​​thức” hấp dẫn đến mức dẫn đến nhiều vấn đề. Mọi người sử dụng nó không chính xác, cho rằng không có kiến ​​thức là một từ đồng nghĩa "bảo mật rất, rất đáng tin cậy". Do đó, nó được sử dụng với mọi thứ - bao gồm cả hệ thống mã hóa và mạng ẩn danh - thực sự không liên quan gì đến các giao thức không có kiến ​​thức.

Tôi viết điều này để nhấn mạnh rằng bằng chứng không có kiến ​​thức là một trong những công cụ mạnh mẽ nhất từng được các nhà mật mã phát minh ra. Thật không may, chúng được hiểu một cách kém cỏi. Trong loạt bài đăng này, tôi sẽ cố gắng mô tả rõ ràng bằng chứng không có kiến ​​thức là gì và điều gì khiến chúng trở nên đặc biệt. Chúng ta cũng sẽ xem xét một số giao thức không có kiến ​​thức được sử dụng trong thế giới thực.

Lịch sử của kiến ​​​​thức không

Khái niệm “không có kiến ​​thức” lần đầu tiên được đề xuất vào những năm 1980 bởi các nhà nghiên cứu MIT Shafi Goldwasser, Silvio Micali và Charles Rackoff. Họ đã nghiên cứu các vấn đề liên quan đến hệ thống chứng minh tương tác - hệ thống lý thuyết trong đó một bên ("Người chứng minh") trao đổi thông điệp với bên thứ hai ("Người xác minh") cố gắng thuyết phục họ về sự thật của một số tuyên bố toán học.*

Trước Goldwasser và các đồng nghiệp của cô, công việc trong lĩnh vực này chủ yếu tập trung vào tính đúng đắn của hệ thống chứng minh. Nói cách khác, các nhà khoa học đã xem xét các tình huống trong đó Người kiểm chứng độc ác cố gắng “đánh lừa” Người xác minh tin vào một tuyên bố sai. Goldwasser, Micali và Rekoff đã lật ngược vấn đề. Thay vì chỉ lo lắng về Prover, họ quyết định xem xét điều gì sẽ xảy ra nếu bạn không tin tưởng Gửi thanh tra.

Vấn đề cụ thể mà họ đặt ra là rò rỉ thông tin. Các nhà khoa học đã tự hỏi Người xác minh học được bao nhiêu thông tin bổ sung trong quá trình chứng minh ngoài thực tế là tuyên bố đó là đúng.

Điều quan trọng cần lưu ý là điều này không chỉ được thực hiện vì lợi ích lý thuyết - những vấn đề như vậy có ứng dụng trong thế giới thực. Đây là một tình huống như vậy: Hãy tưởng tượng một người dùng trong thế giới thực muốn đăng nhập vào máy chủ web bằng mật khẩu. Cách tiếp cận "thực tế" tiêu chuẩn cho vấn đề này liên quan đến việc lưu trữ phiên bản băm của mật khẩu trên máy chủ. Vì vậy, việc đăng nhập vào máy chủ có thể được coi là một loại “bằng chứng” cho thấy hàm băm mật khẩu là kết quả của việc áp dụng hàm băm cho một số mật khẩu và trên thực tế, máy khách là biết mật khẩu.

Số đông hệ thống thực triển khai “bằng chứng” này theo cách tồi tệ nhất có thể: máy khách chỉ cần chuyển mật khẩu gốc đến máy chủ, máy chủ sẽ tính toán hàm băm của mật khẩu và so sánh nó với giá trị được lưu trữ. Nhược điểm của phương pháp này là rõ ràng: máy chủ đã biết được mật khẩu không được mã hóa của khách hàng. Do đó, việc vệ sinh mật khẩu hiện đại phần lớn dựa trên giả định rằng máy chủ không bị xâm phạm.

Những gì Goldwasser, Micali và Rekoff đề xuất đã mang lại hy vọng mới cho việc triển khai các bằng chứng không có kiến ​​thức mà có thể chứng minh được là không thể nói được không có thông tin ngoại trừ một bit có nghĩa là "tuyên bố này là đúng."

Ví dụ về "Thế giới thực"

Cuộc thảo luận của chúng ta hiện tại khá trừu tượng, vì vậy hãy xem một ví dụ "thế giới thực" về giao thức không có kiến ​​thức (hơi điên rồ).

Hãy tưởng tượng tôi là một ông trùm viễn thông đang triển khai một mạng di động mới. Cấu trúc mạng của tôi được hiển thị trong hình bên dưới. Mỗi đỉnh trong biểu đồ này đại diện cho một tháp vô tuyến và các cạnh của biểu đồ cho biết vị trí mà các ô chồng chéo, nghĩa là nơi việc thu tín hiệu có thể gặp khó khăn. May mắn thay, để tránh nhiễu, tôi có thể chỉ định mỗi tháp cho một trong ba dải tần số khác nhau.

Vì vậy vấn đề triển khai mạng là làm thế nào để phân công dải tần số tháp sao cho không có hai ô chồng chéo nào sử dụng cùng tần số. Bằng cách biểu thị các dải tần số bằng các màu khác nhau, chúng ta có thể nhanh chóng đề xuất một giải pháp cho vấn đề:

Tất nhiên, nhiều bạn đã nhận ra rằng đây chỉ là một ví dụ của bài toán lý thuyết nổi tiếng về việc tô màu đồ thị bằng ba màu. Vấn đề này rất thú vị vì đối với một số đồ thị rất khó tìm ra lời giải hoặc thậm chí không biết nó tồn tại Nó. Trên thực tế, tô màu ba màu—chính xác hơn là tìm hiểu xem liệu có thể tô màu một đồ thị cụ thể bằng ba màu hay không—nằm trong lớp phức tạp NP.

Rõ ràng ví dụ về đồ chơi của chúng ta rất dễ giải quyết bằng tay, nhưng nếu không thì sao? Ví dụ, hãy tưởng tượng rằng mạng di động của tôi rất lớn và phức tạp - đến mức tài nguyên máy tính mà tôi sử dụng không đủ để tìm ra giải pháp. Trong trường hợp này nó sẽ là mong muốn thuê ngoài vấn đề cho người khác có nhiều tài nguyên máy tính hơn. Ví dụ: tôi có thể nhờ bạn bè ở Google giải quyết giúp tôi theo thông số kỹ thuật.

Nhưng điều này dẫn đến một vấn đề.

Giả sử rằng Google dành một phần đáng kể cơ sở hạ tầng máy tính của mình để tìm cách tô màu biểu đồ của tôi. Tất nhiên, tôi sẽ không trả tiền cho họ cho đến khi tôi biết rằng họ thực sự đã tìm ra cách như vậy, nhưng đồng thời giờ Google sẽ không đưa cho tôi bản sao quyết định cho đến khi tôi trả tiền cho họ. Chúng ta đang ở ngõ cụt.

Có lẽ có một cách thực tế để thoát khỏi tình trạng bế tắc này, bao gồm cả việc nhờ đến luật sư và sử dụng tài khoản ký quỹ, nhưng đây không phải là một blog về cuộc sống thực mà là về mật mã. Nếu bạn đã từng đọc bất kỳ nghiên cứu nào về tiền điện tử, bạn sẽ nhận ra rằng Đúng cáchđể giải quyết vấn đề này là đưa ra một giải pháp kỹ thuật hoàn toàn điên rồ.

Giải pháp kỹ thuật điên rồ (có mũ!)

Lưu ý rằng tôi sẽ không bao giờ chắc chắn tuyệt đối rằng Google trung thực - sẽ luôn có ít nhất một khả năng nhỏ là Google đang lừa dối tôi. Tuy nhiên, sau một số lần lặp lớn (cụ thể là E^2 ) sự tự tin của tôi sẽ tăng lên đến mức xác suất Google bị lừa là không đáng kể - khá nhỏ, vậy nên trong mọi người vấn đề thực tế cô ấy có thể bị bỏ rơi. Bằng cách này, tôi có thể đưa tiền của mình cho Google một cách an toàn.

Chúng ta cần biết rằng Google cũng an toàn. Ngay cả khi tôi đang cố gắng tìm hiểu điều gì đó về giải pháp của Google bằng cách ghi chú giữa các lần chạy giao thức, điều đó cũng không thành vấn đề. Tôi bị bối rối bởi Google chọn ngẫu nhiên lựa chọn màu sắc trong các lần lặp khác nhau của giao thức. Thông tin hạn chế tôi nhận được là vô ích và tôi không có cách nào buộc dữ liệu từ các lần lặp khác nhau.

Điều gì làm nên "không có kiến ​​thức" này?

Trước đây tôi đã tuyên bố rằng giao thức này ngăn không cho quyết định của Google bị rò rỉ, nhưng đừng để tôi thoát khỏi dễ dàng như vậy! Nguyên tắc đầu tiên của mật mã hiện đại là đừng bao giờ tin người người đưa ra những tuyên bố như vậy mà không có bằng chứng.

Goldwasser, Micali và Rekoff đề xuất ba thuộc tính mà bất kỳ giao thức không có kiến ​​thức nào cũng phải đáp ứng. Một cách không chính thức, chúng có thể được thể hiện như sau:

1. Tính đầy đủ (sự đầy đủ). Nếu Google nói sự thật thì cuối cùng nó sẽ có thể thuyết phục được tôi (ít nhất là với khả năng cao).
2. Tính đúng đắn (sự lành mạnh). Google có thể thuyết phục tôi về quyết định đúng đắn chỉ một trong trường hợp đó, Nếu như thực sự nói sự thật.
3. Không có kiến ​​thức (số không— sự hiểu biết) . Tôi không nghe thấy gì thêm về quyết định của Google.

Chúng ta đã thảo luận về lập luận về tính đầy đủ. Giao thức này sao cho sau đủ lần lặp lại, cuối cùng Google sẽ thuyết phục được tôi (với khả năng xảy ra lỗi không đáng kể). Việc chứng minh tính đúng đắn của giao thức này cũng khá dễ dàng. Nếu Google cố gắng lừa dối tôi, tôi gần như chắc chắn sẽ phát hiện ra sự phản bội.

Tính chất thứ ba có vấn đề ở đây, nhưng để hiểu điều này, chúng ta cần thực hiện một thí nghiệm tưởng tượng rất kỳ lạ.

Thí nghiệm tư duy (với cỗ máy thời gian)

Hãy bắt đầu với một giả thuyết điên rồ. Hãy tưởng tượng rằng các kỹ sư của Google không có kỹ năng như họ tưởng. Họ đã giải quyết vấn đề của tôi hàng tuần, hàng tháng, nhưng họ không thể tìm ra giải pháp. Khi còn 12 giờ trước khi xác minh, nhân viên Google trở nên tuyệt vọng. Họ quyết định lừa dối tôi nên tôi nghĩ họ có cách tô màu đồ thị trong khi thực tế là không.

Ý tưởng của họ là thâm nhập vào xưởng GoogleX và mượn nguyên mẫu cỗ máy thời gian của Google. Ban đầu họ dự định du hành ngược thời gian vài năm để sử dụng thời gian làm việc thêm để giải quyết vấn đề. Thật không may, giống như hầu hết các nguyên mẫu của Google, cỗ máy thời gian có một số hạn chế: nó chỉ cho phép bạn du hành ngược thời gian bằng cách bốn phút rưỡi.

Do đó, tùy chọn sử dụng cỗ máy thời gian để có thêm thời gian làm việc đã bị loại bỏ. Tuy nhiên, hóa ra ngay cả công nghệ rất hạn chế này vẫn có thể được sử dụng để lừa tôi.

Tôi không biết chuyện gì đang xảy ra ở đây, nhưng tôi nghĩ bức ảnh này rất phù hợp.

Kế hoạch thật đơn giản. Bởi vì Google thực sự không biết tô màu đồ thị hợp lệ, Google chỉ cần tô màu tờ giấy với các màu ngẫu nhiên rồi chọn mũ. Nếu tình cờ chúng ta bắt gặp một cặp đỉnh có màu khác nhau, mọi người sẽ thở phào nhẹ nhõm và chúng ta sẽ tiếp tục làm theo quy trình. Càng xa càng tốt.

Tuy nhiên, chắc chắn sớm muộn gì tôi cũng sẽ đội mũ, khám phá hai đỉnh một màu sắc và bắt Google gian lận. Và đây là lúc cỗ máy thời gian xuất hiện. Khi Google thấy mình trong tình huống kỳ lạ này, nó chỉ đơn giản là loại bỏ nó. Nói cách khác, một “nhân viên Google” đặc biệt sẽ bật công tắc bật tắt, “tua lại” thời gian khoảng bốn phút và nhóm Google sẽ tô màu lại hoàn toàn biểu đồ bằng một giải pháp ngẫu nhiên mới. Sau đó họ bắt đầu lại thời gian, cho phép tôi thử lại.

Về cơ bản, cỗ máy thời gian cho phép Google "khôi phục" sau mọi điều tồi tệ xảy ra trong quá trình thực thi giao thức giả mạo của họ, điều này khiến mọi thứ đối với tôi dường như bình thường. Bởi vì cố gắng tốt thách thức giao thức chỉ xảy ra trong khoảng 1/3 số lần thử, thời gian thực hiện dự kiến ​​của giao thức (theo quan điểm của Google) chỉ dài hơn vừa phải so với thời gian thực hiện của giao thức công bằng. Về phần tôi, tôi thậm chí còn không nghi ngờ rằng việc du hành thời gian đang diễn ra.

Điểm cuối cùng là quan trọng nhất. Trên thực tế, theo quan điểm của tôi, việc không biết có liên quan đến cỗ máy thời gian sẽ dẫn đến chính xác sự tương tác giống như thực tế. Về mặt thống kê chúng giống hệt nhau. Chưa hết, một lần nữa điều đáng chú ý là trong phiên bản có cỗ máy thời gian TạiGoogle Hoàn toàn không có thông tin về cách tô màu đồ thị.

Tất cả những thứ này để làm gì?

Những gì chúng ta vừa xem là một ví dụ mô phỏng. Lưu ý rằng trong một thế giới mà thời gian chỉ chuyển động về phía trước và không ai có thể đánh lừa tôi bằng cỗ máy thời gian, giao thức đội mũ Chính xác, tức là sau E^2 vòng, tôi phải bị thuyết phục (vượt quá xác suất không đáng kể) rằng trên thực tế, biểu đồ có thể được tô màu và Google có giải pháp hợp lệ.

Chúng tôi vừa chỉ ra rằng nếu thời gian không trôi về phía trước - chính xác hơn là, nếu Google có thể "tua lại" ý tưởng của tôi về thời gian - thì Google có thể giả mạo hoạt động thực tế của giao thức ngay cả khi không có thông tin về màu sắc thực tếeđồ thị.

Theo quan điểm của tôi, sự khác biệt giữa hai tùy chọn giao thức là gì? Nếu chúng ta xem xét sự phân bổ thống kê của chúng thì không có sự khác biệt - cả hai đều báo cáo lượng thông tin hữu ích gần như nhau.

Dù bạn có tin hay không, điều này chứng tỏ một điều rất quan trọng.

Giả sử tôi (Người xác minh) ​​có một số chiến lược "trích xuất" thông tin hữu ích về màu sắc của Google sau khi quan sát việc thực hiện một giao thức trung thực. Sau đó, chiến lược của tôi sẽ hoạt động hiệu quả như nhau trong trường hợp tôi bị cỗ máy thời gian đánh lừa. Theo quan điểm của tôi, các lần chạy giao thức giống hệt nhau về mặt thống kê - về mặt vật lý, tôi không thể nhận ra sự khác biệt.

Vì vậy, nếu lượng thông tin tôi có thể trích xuất trong "thử nghiệm thực" và "thử nghiệm cỗ máy thời gian" giống hệt nhau, nhưng lượng thông tin mà Google cung cấp trong "thử nghiệm cỗ máy thời gian" chính xác bằng 0, điều này cho thấy rằng ngay cả trong trong thế giới thực, giao thức sẽ không tạo ra bất kỳ thông tin hữu ích nào. Tất cả những gì còn lại là chứng minh rằng các nhà khoa học máy tính có cỗ máy thời gian. Vâng, chúng tôi có chúng! (Đây là một bí mật được bảo vệ chặt chẽ.)

Loại bỏ mũ (và cỗ máy thời gian)

Tất nhiên, chúng tôi thực sự không muốn thực hiện giao thức mũ và thậm chí Google cũng không có cỗ máy thời gian thực (có thể).

Để gắn kết mọi thứ lại với nhau, trước tiên chúng ta cần đưa giao thức của mình vào thế giới kỹ thuật số. Điều này đòi hỏi chúng tôi phải xây dựng tương đương kỹ thuật số của một "chiếc mũ" - thứ vừa che giấu ý nghĩa kỹ thuật số vừa "ràng buộc" người sáng tạo với nó ("bắt buộc") để anh ta không thể thay đổi ý định sau khi thực tế.

May mắn thay, chúng tôi có công cụ hoàn hảo cho việc này, được gọi là Chương trình cam kết kỹ thuật số. Một kế hoạch cam kết cho phép một bên "cam kết" thực hiện tin nhắn cụ thể, cất vào “phong bì bí mật” rồi sau đó “mở” phong bì cam kết để lộ nội dung bên trong. Các cam kết có thể được tạo từ nhiều thành phần khác nhau, bao gồm các hàm băm mật mã (mạnh).***

Với kế hoạch cam kết, chúng tôi có mọi thứ cần thiết để thực thi điện tử giao thức không có kiến ​​thức. Trước tiên, bộ chuẩn mã hóa màu sắc của các đỉnh dưới dạng một tập hợp các thông báo kỹ thuật số (ví dụ: sử dụng các số 0, 1, 2), sau đó tạo ra các nghĩa vụ kỹ thuật số cho từng thông báo đó. Những nghĩa vụ này được chuyển đến Người đánh giá. Khi Người xác minh thách thức quyết định về một cạnh, Người chứng minh chỉ cần công bố các giá trị cho các cam kết tương ứng với hai đỉnh.

Vì vậy, chúng tôi đã loại bỏ những chiếc mũ, nhưng làm cách nào chúng tôi có thể chứng minh rằng đó là một giao thức không có kiến ​​thức?

May mắn thay, chúng ta hiện đang ở trong thế giới kỹ thuật số và chúng ta không cần xe thậtđã đến lúc chứng minh những tuyên bố về giao thức này. Bí quyết chính là chỉ ra rằng giao thức sẽ không hoạt động giữa mọi người, và giữa hai điểm khác nhau chương trình máy tính(hay nói một cách chính thức hơn là máy Turing xác suất).

Bây giờ chúng ta có thể chứng minh định lý sau. Nếu một chương trình máy tính có thể được tạo (cho Người xác minh) ​​để trích xuất thông tin hữu ích sau khi tham gia chạy giao thức, thì có thể sử dụng "cỗ máy thời gian" với chương trình đó để chương trình trích xuất cùng một lượng thông tin hữu ích từ một Giao thức "giả" chạy khi Prover không cung cấp thông tin.

Và vì bây giờ chúng ta đang nói về chương trình máy tính, rõ ràng, việc tua lại thời gian không phải là một khả năng phi thường chút nào. Trên thực tế, chúng ta tua lại các chương trình máy tính mọi lúc. Ví dụ: hãy lấy phần mềm dành cho máy ảo có chức năng chụp nhanh.

Một ví dụ về tua lại ảnh chụp nhanh của máy ảo. VM ban đầu được phát tiếp, hoàn nguyên về ảnh chụp nhanh ban đầu và sau đó một nhánh khác được thực thi.

Ngay cả khi bạn không có phần mềm máy ảo ưa thích, bất kỳ chương trình máy tính nào cũng có thể được "tua lại" thành nhiều hơn. trạng thái sớm, chỉ cần bắt đầu lại từ đầu và chuyển chính xác cùng một đầu vào. Nếu đầu vào - bao gồm tất cả các số ngẫu nhiên - là cố định, chương trình sẽ luôn đi theo cùng một đường dẫn thực hiện. Bạn có thể tua lại một chương trình bằng cách chỉ cần khởi động nó lại từ đầu và "ngắt" quá trình thực thi của nó khi nó đạt đến một số điểm mong muốn.

Cuối cùng ta thu được định lý sau. Nếu có một số chương trình máy tính của Người xác minh trích xuất thành công thông tin bằng cách thực thi tương tác giao thức này với một số Prover, chúng ta có thể chỉ cần sử dụng thủ thuật tua lại để thể hiện cam kết đối với một giải pháp ngẫu nhiên, sau đó "đánh lừa" Người xác minh bằng cách tua lại chương trình cho đến khi vượt qua sự thử nghiệm. Logic tương tự được áp dụng như trên: nếu Người xác minh đó thành công trong việc trích xuất thông tin sau khi thực hiện giao thức thực tế thì nó có thể trích xuất cùng một lượng thông tin từ một giao thức tua lại mô phỏng. Nhưng vì không có thông tin nào được chuyển đến giao thức mô phỏng nên không có gì để trích xuất. Do đó, lượng thông tin mà Người xác minh có thể trích xuất là bằng không.

Được rồi, vậy tất cả điều này có nghĩa là gì?

Vì vậy, từ phân tích trên, chúng ta biết rằng giao thức đã hoàn chỉnh và chính xác. Lập luận về tính đúng đắn có hiệu lực bất cứ khi nào chúng ta biết rằng không có ai đang thao túng thời gian - nghĩa là chương trình của Người xác minh đang chạy bình thường và không có ai tua lại quá trình thực thi của nó.

Đồng thời, giao thức cũng cung cấp kiến ​​thức bằng không. Để chứng minh điều này, chúng tôi đã chỉ ra rằng bất kỳ chương trình Người xác minh nào trích xuất thông tin thành công cũng phải có khả năng trích xuất thông tin từ giao thức tua lại chạy khi không có thông tin ban đầu có sẵn.Điều này dẫn đến một mâu thuẫn rõ ràng và cho chúng ta biết rằng việc rò rỉ thông tin khi thực hiện một giao thức như vậy là không thể xảy ra trong cả hai trường hợp.

Tất cả điều này có lợi thế quan trọng. Vì bất kỳ ai cũng có thể dễ dàng “làm giả” một mục nhập giao thức ngay cả sau khi hệ thống Google chứng minh cho tôi thấy cô ấy có giải pháp, tôi không thể xem lại bản ghi để chứng minh bất cứ điều gì với bất kỳ ai khác (chẳng hạn như thẩm phán). Đó là vì thẩm phán không đảm bảo rằng video được ghi lại một cách công bằng và tôi đã không đã chỉnh sửa nó giống như cách mà hệ thống Google có thể thực hiện với sự trợ giúp của cỗ máy thời gian. Điều này có nghĩa là bản thân mục nhật ký không chứa thông tin. Giao thức chỉ có ý nghĩa nếu bản thân tôi tham gia vào nó và chắc chắn rằng nó diễn ra trong thời gian thực.

Bằng chứng cho tất cả các NP!

Nếu bạn đã đọc đến đây, tôi chắc chắn rằng bạn đã sẵn sàng đón nhận một số tin tức quan trọng. Cụ thể là bạn sắp biết rằng mạng di động ba màu không phải là một vấn đề thú vị—ít nhất là không phải riêng lẻ.

Bài toán 3 màu thú vị chủ yếu vì nó thuộc lớp NP-đầy đủ. Nói một cách không chính thức, điều đáng ngạc nhiên về những vấn đề này là bất kỳ vấn đề nào khác từ lớp học NP có thể được chuyển đổi thành một trường hợp của vấn đề này.

Kết quả này, trong một cú trượt ngã - nhờ Goldreich, Micali và Widjerson - chứng minh rằng các bằng chứng không có kiến ​​thức "hiệu quả" tồn tại cho một loạt các phát biểu hữu ích, nhiều trong số đó nhiều hơn nữa thú vị hơn việc ấn định tần số cho các mạng di động. Bạn chỉ cần tìm câu lệnh (trong lớp NP) mà bạn muốn chứng minh, chẳng hạn như ví dụ về hàm băm của chúng tôi ở trên, sau đó chuyển nó thành một thể hiện của bài toán 3 màu. Sau đó, bạn chỉ cần chạy phiên bản kỹ thuật số của giao thức có mũ.

Hãy tóm tắt lại

Tất nhiên, việc thực sự chạy giao thức này cho các câu lệnh thú vị sẽ rất kỳ lạ và ngu ngốc, bởi vì nó đòi hỏi một khối lượng công việc khổng lồ phải thực hiện. Về lý thuyết, điều này là "hiệu quả" vì tổng chi phí chứng minh sẽ tăng đa thức theo kích thước của dữ liệu đầu vào, nhưng trên thực tế, nó sẽ hoàn toàn khác.

Vì vậy, cho đến nay chúng tôi chỉ cho thấy rằng bằng chứng đó khả thi. Việc tìm kiếm bằng chứng đủ thực tế để sử dụng trong thế giới thực là việc của chúng ta.

Trong các bài viết khác tôi sẽ nói về một số trong số đó - cụ thể là hiệu quả bằng chứng của các tuyên bố hữu ích khác nhau. Tôi sẽ đưa ra một số ví dụ (từ ứng dụng thực tế), nơi mà các kỹ thuật như vậy đã được sử dụng. Ngoài ra, theo yêu cầu của một độc giả, tôi sẽ cho bạn biết lý do tại sao tôi không thích giao thức SRP (Mật khẩu từ xa an toàn) đến vậy.

Ghi chú

* Về mặt hình thức, mục tiêu của bằng chứng tương tác là thuyết phục Người xác minh rằng một chuỗi cụ thể thuộc về một số ngôn ngữ. Thông thường, Prover rất mạnh (không giới hạn) và Người xác minh bị hạn chế về tài nguyên máy tính.

** Ví dụ này dựa trên giải pháp ban đầu của Goldwasser, Micali và Rekoff, và ví dụ hướng dẫn về mũ dựa trên lời giải thích của Silvio Micali. Tôi chỉ chịu trách nhiệm về những sai sót nếu có.

*** Một ví dụ đơn giản về cam kết có thể được xây dựng bằng hàm băm. Để tạo cam kết cho giá trị "x", chỉ cần tạo một số chuỗi số ngẫu nhiên (đủ dài), chúng tôi sẽ gọi là "muối" và in cam kết C = Băm(muối || x) . Để công khai cam kết, bạn chỉ cần hiển thị dấu "x" và muối. Bất cứ ai cũng có thể xác minh rằng cam kết ban đầu là hợp lệ bằng cách tính toán lại hàm băm. Nó an toàn miễn là đáp ứng được một số yêu cầu (nghiêm ngặt vừa phải) đối với chính chức năng đó.

Matthew xanh