Xáo trộn bit mã hóa 1 đến 1


7

Đưa ra một mục đầu vào (N byte), tôi đang tìm một hàm sẽ ánh xạ hàm này thành đầu ra (vẫn là N byte). Hàm nên có các phẩm chất sau:

  • Nó phải là 1-1 để tất cả các đầu vào ánh xạ tới một số đầu ra và sao cho không có hai đầu vào ánh xạ tới cùng một đầu ra.
  • Với một yếu tố đầu ra, sẽ khó đoán được đầu vào dẫn đến đầu ra đó, ngay cả khi ánh xạ hoàn toàn được biết đến.

Liệu một chức năng như vậy tồn tại? Tôi có thể tìm hiểu thêm ở đâu?


Nhân tiện, tôi là một kỹ sư thương mại và tôi chỉ có một nền tảng ứng dụng trong khoa học máy tính. Vì vậy, xin vui lòng tha thứ cho việc sử dụng thuật ngữ lỏng lẻo / không chính xác của tôi.
JnBrymn

3
Đây chỉ là vì tò mò hay bạn có một số lý do để muốn làm điều này? Nếu bạn muốn triển khai điều này trong một số hệ thống, tôi thực sự khuyên bạn nên hỏi về Bảo mật thông tin xem liệu điều bạn đang hỏi ở đây có phải là giải pháp hợp lý cho vấn đề bạn đang cố gắng giải quyết không.
David Richerby

Câu trả lời:


10

Điều này được gọi là hoán vị một chiều . "Hoán vị" đề cập đến yêu cầu đầu tiên trong hai yêu cầu của bạn; "một chiều" đề cập đến yêu cầu thứ hai trong hai yêu cầu của bạn. Có nhiều cách xây dựng ứng cử viên khác nhau cho hoán vị một chiều, ví dụ, dựa trên việc nâng lên mô đun công suất thứ ba một mô đun RSA hoặc các sơ đồ khác.


Nó cũng đáng để tìm kiếm các mạng Feistel. Chúng là một phương pháp tiêu chuẩn để biến các hàm tổng quát thành hoán vị.
Bút danh

2
@Pseudonymous, mạng Feistel yêu cầu khóa và chúng không phải là một chiều: bạn cần khóa để tính toán bản đồ và với khóa, bạn có thể dễ dàng đi lùi. Vì vậy, họ giải quyết một vấn đề khá khác nhau.
DW

Định nghĩa nghiêm ngặt của mạng Feistel là nó yêu cầu khóa, nhưng công dụng duy nhất của chúng là làm đầu vào cho các hàm tròn. Việc sửa đổi cấu trúc để sử dụng các hàm mà không có tham số là chuyện nhỏ.
Bút danh

1
@Pseudonymous, vâng, nhưng với sửa đổi đó không phải là một chiều. Thật dễ dàng để tính toán bản đồ ngược như tính toán bản đồ chuyển tiếp. Chúng là một kỹ thuật rất hay, nhưng chúng không giải quyết được vấn đề đặc biệt này.
DW

À, tất nhiên rồi! Tôi đã bỏ lỡ chi tiết đó, xin lỗi.
Bút danh

-1

Bạn có thể muốn có một cái nhìn về DES hoặc AES, họ đang làm chính xác những gì bạn muốn. những phương pháp này tùy thuộc vào việc có một khóa mã hóa / giải mã văn bản thuần túy. Một phương pháp khác là sử dụng khóa kép (khóa chung & khóa riêng), đây là phương pháp được sử dụng rất phổ biến hiện nay và phổ biến nhất là RSA, chủ yếu là sử dụng khóa công khai mà mọi người đều biết và khóa riêng là chính bạn nên biết điều đó và nếu một ai đó muốn gửi cho bạn thứ gì đó, anh ta sẽ mã hóa nó bằng khóa chung của bạn (lưu ý rằng anh ta không thể xác nhận lại được nữa vì nó chỉ bị khóa bởi khóa riêng của bạn). và nếu bạn muốn xác thực, bạn có thể gửi một cái gì đó được mã hóa bằng khóa riêng của mình và người nhận sẽ xác nhận nó bằng khóa chung của bạn theo cách đó anh ta sẽ chắc chắn rằng nó được gửi bởi bạn.

thêm thông tin có thể được tìm thấy ở đây:

https://en.wikipedia.org/wiki/RSA_(cryptystem)


1
AES và DES yêu cầu một khóa và chúng không phải là một chiều: bạn cần khóa để tính toán bản đồ và với khóa, bạn có thể dễ dàng đi lùi. Vì vậy, họ giải quyết một vấn đề khá khác nhau.
DW

-2

Bạn có thể thử điều này:

Đầu tiên, lấy SHA-256 hoặc hàm băm khác của giá trị đầu vào của bạn. Sau đó, sử dụng một cypher cơ bản, một cái gì đó giống như A = C, B = D, C = E ...

Sự khác biệt là bạn sử dụng SHA-256 của toàn bộ chuỗi đầu vào để xác định mức độ dịch chuyển của nó (có phải là A = B, A = C, A = D, v.v.)

Lưu ý: Tôi không phải là chuyên gia về mật mã và không chắc chắn mức độ an toàn của nó.


1
Điều này là không an toàn khủng khiếp. Không quan trọng là phương pháp bạn sử dụng để xác định khóa của một cypher Caesar như thế nào: vẫn chỉ có 26 tùy chọn và bạn có thể giải mã bằng cách chỉ thử lần lượt từng cái. Ngoài ra, câu hỏi yêu cầu một cái gì đó một cái, cái này có thể không, và nó yêu cầu một cái gì đó một chiều, điều này chắc chắn là không. Quy tắc 1 của tiền điện tử: không "tự lăn".
David Richerby
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.