Làm thế nào khó để giải quyết


8

Từ biểu đồ đẳng cấu, chúng ta biết rằng hai đồ thị A và B là đẳng cấu nếu có ma trận hoán vị P sao cho A=P×B×P1

Vì vậy, để giải quyết vấn đề, nếu hai đồ thị là đẳng cấu, chúng ta cần tìm một ma trận hoán vị như vậy P. Vấn đề được cho là NP (và NP hoàn thành cho trường hợp đẳng cấu đồ thị con). Tuy nhiên, tôi đã tìm thấy một ví dụ để giải quyết P có vẻ hứa hẹn với tôi và có thể tìm thấy trong http://en.wikipedia.org/wiki/Permuting_matrix trong phần: giải quyết cho P.

Sự nhầm lẫn tôi có bây giờ là, điều đó có làm việc cho ma trận lớn hơn không? rất lớn? Tôi có đúng phương trình trên là khó giải và có thể là ứng cử viên cho một hệ thống mật mã không?


Di chuyển sang CS để bạn hy vọng sẽ nhận được câu trả lời mà bạn đang tìm kiếm.

Câu trả lời:


6

Đồ thị đẳng cấu đã được nghiên cứu kỹ. Một tóm tắt ngắn: vấn đề đẳng cấu đồ thị không được biết là trong P (không có thuật toán thời gian đa thức đã biết), nhưng nó không được tin là hoàn thành NP. Có các thuật toán heuristic cho đẳng cấu đồ thị hoạt động cực kỳ tốt trên hầu hết các trường hợp phát sinh trong thực tế. Đọc trang Wikipedia về biểu đồ đẳng cấu để biết thêm.

Đối với phương pháp đề xuất cụ thể của bạn: trang Wikipedia mà bạn đã liên kết đã giải thích lý do tại sao phương pháp đó không hoạt động nói chung. Phương pháp đó chỉ hoạt động nếu không có giá trị riêng lặp lại trong ma trận tương ứng với biểu đồ kề. Do đó, nó sẽ thất bại đối với các biểu đồ nơi có các giá trị riêng lặp đi lặp lại. Đồ thị như vậy không thể được bỏ qua. Do đó, phương pháp đó có thể hoạt động đối với một số biểu đồ nhưng nó sẽ thất bại (hoặc hoạt động kém) đối với các biểu đồ khác, vì vậy nó không phải là một giải pháp chung.

Đồ thị đẳng cấu không phải là một ứng cử viên tốt làm cơ sở cho một hệ thống mật mã, vì hai lý do. Đầu tiên, các thuật toán heuristic hiện có rất tốt trong việc giải quyết vấn đề trong thực tế và không rõ làm thế nào để tạo ra các trường hợp cứng của biểu đồ đẳng cấu. Thứ hai, và nghiêm trọng hơn, để có ích cho mật mã, chúng ta không chỉ cần có một vấn đề khó khăn; chúng ta cần phải có một "cửa bẫy ẩn" mà người tạo khóa công khai có thể nhúng, điều này làm cho vấn đề trở nên dễ dàng đối với người tạo, nhưng khó có ai phát hiện ra. Không ai biết làm thế nào để nhúng một "cái bẫy ẩn" như vậy vào vấn đề đẳng cấu đồ thị.


1

Như DW lưu ý đúng, đẳng cấu đồ thị không được biết là nằm trong P và được cho là không phải là NP-hard. Hơn nữa, nhiều người tin rằng nó nằm trong BQP, nhưng điều này chưa được chứng minh. Điều đó đặt nó vào cùng loại với các vấn đề khác mà các hệ thống mật mã thường dựa vào bảo mật của chúng, chẳng hạn như bao thanh toán chính và vấn đề nhật ký rời rạc, cả hai đều được biết là trong BQP. (Tôi không biết vấn đề nhân nghịch đường cong elip ở đâu hoặc bất cứ điều gì nó được gọi là liên quan đến BQP, nhưng điều đó sẽ không làm tôi ngạc nhiên nếu ít nhất tất cả các vấn đề hữu ích về mật mã này đều tương đương nhau.)

Đúng là chúng ta không biết về các vấn đề đẳng cấu đồ thị mà giải pháp là "khó". Tuy nhiên, hãy giả sử trong một khoảnh khắc mà chúng ta đã làm. Sau đó, có, bạn có thể sử dụng nó cho mật mã.

Ví dụ, chúng ta hãy xem xét một hệ thống khóa chứng minh không kiến ​​thức dựa trên sự đẳng cấu đồ thị.

Khóa riêng của Alice là một biểu đồ được dán nhãn (các nhãn chỉ có thể là số nguyên) đã được xây dựng sao cho "khó" kiểm tra sự đồng hình của biểu đồ và nó chứa một chu trình Hamilton mà nó "khó tìm". Khóa công khai của cô chỉ là biểu đồ được dán nhãn, không có thông tin về chu trình Hamilton. Lưu ý rằng việc lấy khóa riêng từ khóa chung yêu cầu giải quyết vấn đề chu trình Hamilton, đó là NP-hard và, chúng tôi giả sử, rất khó cho biểu đồ này nói riêng.

Alice muốn thuyết phục Bob rằng cô biết một chu trình Hamilton trong biểu đồ, mà không thực sự cho anh ta chu trình Hamilton. Đây là cách cô ấy làm điều đó.

Alice gửi cho Bob một biểu đồ không ghi nhãn. Cô ấy đưa ra cho anh ta một sự lựa chọn: Hoặc cô ấy sẽ tiết lộ các nhãn, hoặc cô ấy sẽ tiết lộ một chu kỳ Hamilton trong biểu đồ. Bob lật một đồng xu (hoặc đưa ra quyết định bằng một số phương tiện khác) về việc anh ta muốn cái nào, và Alice làm bất cứ điều gì trong số hai mà Bob yêu cầu.

Nếu Bob yêu cầu các nhãn được tiết lộ, anh ta có thể dễ dàng xác minh (theo thời gian tuyến tính) rằng biểu đồ được gắn nhãn lại giống như khóa công khai của Alice, nhưng không thể tìm thấy chu trình Hamilton vì đó sẽ là NP-hard. Mặt khác, nếu Bob yêu cầu chu trình Hamilton, anh ta có thể dễ dàng xác minh (một lần nữa, theo thời gian tuyến tính) rằng biểu đồ không ghi nhãn thực sự có chứa chu trình Hamilton, nhưng anh ta không thể xác minh rằng đó là biểu đồ khóa công khai của Alice, bởi vì đồ thị đẳng cấu là (có lẽ) cứng.

Theo quan điểm của Bob, Alice có thể đã cố gắng lừa Bob bằng cách đưa ra một biểu đồ có chu trình Hamilton đã biết nhưng không đồng nhất với khóa công khai của cô ấy hoặc bằng cách đưa cho anh ấy biểu đồ khóa chung của cô ấy với các nhãn bị xóa nhưng không biết Chu kỳ Hamilton. Cô sẽ đặt cược vào Bob khi lựa chọn sai. Giả sử rằng Bob thực sự đã lựa chọn ngẫu nhiên, thì thủ thuật này sẽ có 50% cơ hội thành công.

n2n

Tất nhiên, đây không phải là một hệ thống thực tế như hiện tại. Hơn nữa, có một số điều rõ ràng bạn có thể làm để làm cho nó an toàn hơn. Ví dụ, thay vì Alice gửi cho Bob một biểu đồ không ghi nhãn, cô ấy chỉ có thể gửi một hàm băm của nó. Khi Bob trả lời, sau đó cô có thể gửi biểu đồ và Bob có thể kiểm tra xem biểu đồ có khớp không.

Tuy nhiên, về nguyên tắc, bạn có thể tạo ra một hệ thống mật mã từ đó, ngay cả khi nó không hữu ích lắm.


không có "trường hợp cứng" nào của vấn đề - đối với mọi trường hợp đều có thuật toán thời gian tuyến tính giải quyết nó. những gì bạn cần cho tiền điện tử là một vấn đề trung bình khó (và đó là đối với tiền điện tử tối thiểu); ngay cả khi sự đồng hình hóa đồ thị hóa ra là khó, trung bình nó có thể không khó. trong thực tế, P \ neq NP không được biết là ngụ ý sự tồn tại của các vấn đề trung bình khó phân phối có thể lấy mẫu.
Sasho Nikolov

@Sasho Nikolov, cảm ơn đã làm rõ.
Bút danh
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.