Bộ bài công bằng có thể chứng minh được sử dụng bởi máy khách và máy chủ

Giả sử một máy chủ chơi trò chơi xì dách với một khách hàng, và các lá bài được máy chủ xáo trộn và xử lý. Bản thân việc xáo bài có thể công bằng hoặc không, nhưng điều cần thể hiện là các quân bài được chia không bị thay đổi trong suốt quá trình chơi, tức là: sau khi bắt đầu ván bài, các quân bài trong bộ bài không bí mật có thứ tự thay đổi bởi máy chủ.

Tôi đã nghĩ đến giải pháp sau bằng cách sử dụng mật mã và muốn nhận được một số phản hồi xem giải pháp đó có được chấp nhận đối với hệ thống sản xuất hay không và nếu không thì tại sao không:

Bước 1) Máy chủ sẽ bí mật xáo trộn một bộ bài theo thứ tự nào đó, chẳng hạn như sau (chúng tôi bỏ qua bộ bài cho đơn giản): [3, 9, 2, ..., A]

Sau đó, nó sẽ tạo thông báo sau M:
M = "Xáo bài: [3, 9, 2, ..., A]. Số ngẫu nhiên: A96A...QT3"

Số ngẫu nhiên là một số ngẫu nhiên mà máy chủ tạo ra trong nội bộ và giữ bí mật cho đến khi trò chơi kết thúc. Độ dài của nó sẽ đủ dài để ngăn khách hàng bẻ khóa hàm băm thông qua vũ lực (giả sử nó có độ dài 512 ký tự).

Bây giờ, máy chủ sẽ băm M bằng cách sử dụng sha-256 hoặc một số thuật toán băm đáng tin cậy khác, ví dụ: hash(M)

Bước 2) Trước khi trò chơi bắt đầu, máy chủ sẽ gửi mã băm (M) này cho máy khách, mà máy khách sẽ lưu trữ. Khách hàng không có cách nào biết M từ những gì tôi có thể thu thập được.

Bước 3) Trò chơi bắt đầu, các lá bài được chia theo thứ tự xáo trộn, người chơi đưa ra quyết định và trò chơi cuối cùng kết thúc.

Bước 4) Bây giờ khách hàng muốn biết rằng trò chơi công bằng, nghĩa là: máy chủ không gian lận bằng cách thay đổi các quân bài trong ván bài. Hiện tại, máy chủ sẽ gửi thông báo "M" tới máy khách ở dạng văn bản gốc để hiển thị điều này.

Bước 5) Máy khách chạy hash(M) và thấy nó khớp với hash(M) của nó nhận được ở bước 1.

Đây có phải là một cách hợp lý để chứng minh trò chơi là công bằng, không có máy khách hoặc máy chủ nào có thể gian lận, loại trừ khả năng bản thân việc trộn bài không phải là ngẫu nhiên? Nếu máy chủ thay đổi các quân bài từ lần xáo ban đầu trong quá trình chơi bài, thì khách hàng sẽ thấy điều này ở Bước 5 (thứ tự sẽ khác rõ ràng đối với khách hàng hoặc hàm băm của tin nhắn được gửi ở Bước 4 sẽ khác với cái được gửi ở bước 2). Ngoài ra, chỉ một hàm băm duy nhất được gửi cho mỗi ván bài, vì vậy máy chủ không thể tạo ra một số lượng lớn các hàm băm và gửi chúng một cách riêng biệt, sau đó chọn hàm băm tốt nhất trong suốt quá trình của ván bài.

Để mở rộng câu trả lời của knaccc, thậm chí có thể sử dụng các lược đồ cam kết để chứng minh (đến một điểm) rằng máy chủ không gian lận trong quá trình xáo trộn, ví dụ: như thế này:

1. Máy chủ chọn một số 128 bit ngẫu nhiên $x$ và một yếu tố mù 128-bit $r_x$, và gửi cam kết $c_x = H(x \,||\, r_x)$ cho khách hàng.
2. Khách hàng chọn một số 128-bit ngẫu nhiên $y$ và gửi nó đến máy chủ. (Không cần cam kết ở đây.)
3. Máy chủ băm $x$ và $y$ với nhau để thu được hạt giống 128 bit $s = H(x \,||\, y)$.
4. Máy chủ sử dụng $s$ làm hạt giống cho PRNG xác định và sử dụng đầu ra PRNG để xáo trộn bộ bài một cách xác định.
5. Trò chơi được chơi với bộ bài xáo trộn.
6. Vào cuối trò chơi, máy chủ tiết lộ $x$ và $r_x$, cho phép khách hàng xác minh rằng bộ bài đã được xáo chính xác (và không bị sửa đổi sau khi được xáo).

Lưu ý rằng máy chủ có thể vẫn gian lận, theo mốt, bằng cách kiểm tra bộ bài đã xáo trộn sau bước 4 và hủy bỏ trò chơi (ví dụ: giả vờ rằng kết nối đã bị ngắt) nếu nó không thích bộ bài. Do đó, khách hàng nên nghi ngờ về các máy chủ thường xuyên ngắt kết nối giữa bước 2 và 5, hoặc thậm chí trong trò chơi ở bước 5. Lý tưởng nhất là nên có cách để khách hàng yêu cầu máy chủ tiếp tục trò chơi bị gián đoạn tại bất kỳ thời điểm nào, và một khách hàng nên được rất nghi ngờ các máy chủ từ chối làm như vậy.

(Việc triển khai một cách an toàn cơ chế tiếp tục như vậy theo cách hoạt động ngay cả khi máy chủ gặp sự cố và quên trạng thái trò chơi có vẻ khả thi, nhưng có thể nằm ngoài phạm vi của câu trả lời này. Hãy hỏi một câu hỏi mới nếu bạn quan tâm.)

Cũng lưu ý rằng giá trị mù $r_x$ không thực sự cần thiết ở đây, vì $x$ bản thân nó đã có đủ entropy để khiến cam kết không thể thực hiện được. Trên thực tế, có thể an toàn hơn một chút nếu bỏ qua $r_x$ và chỉ làm $x$ chính nó dài 256 thay vì dài 128 bit.

Độ dài bit của $y$ và $s$ cũng có thể được tăng lên nếu muốn; 128 bit chỉ là mức tối thiểu an toàn và thiết thực. Không có điểm nào trong việc thực hiện $s$ dài hơn tổng chiều dài của $x$ và $y$ cùng nhau, mặc dù.