Các thanh ghi dịch chuyển phản hồi tuyến tính thường không được các nhà mật mã học khuyến khích?


10

Katz và Lindell đã đề cập đến trong cuốn sách của họ rằng LFSR đã trở nên khủng khiếp khi làm cơ sở cho các trình tạo giả danh, và ủng hộ rằng họ không được sử dụng nữa (tốt, họ cũng khuyên mọi người nên sử dụng mật mã khối thay vì mật mã dòng). Nhưng tôi thấy ví dụ rằng một trong những mật mã trong danh mục estream ( Grain , được nhắm mục tiêu cho phần cứng) sử dụng LFSR, vì vậy ý ​​kiến ​​cho rằng LFSR không tốt không phải là sự đồng thuận.

Tôi muốn biết liệu có nhiều nhà mật mã học chia sẻ ý kiến ​​của Katz và Lindell về LFSR (và về mật mã dòng) không?


1
Tôi nghĩ rằng câu hỏi trong tiêu đề của bạn và câu hỏi trong cơ thể của bài viết của bạn là mâu thuẫn. Mặc dù tôi không phải là nhà mật mã học, tôi sẽ nói "Có" với tiêu đề và "Không" cho câu hỏi trong phần thân bài. Bạn có thể cải thiện câu hỏi của bạn để nó chỉ có một câu hỏi hài hòa không?
Tyson Williams

2
Tôi không chắc chắn 100% nếu đây là chủ đề cho cstheory, nó có thể phù hợp hơn tại crypto.SE .
Artem Kaznatcheev

@Artem Kaznatcheev: Tôi không biết về tiền điện tử.SE. Tôi tin rằng danh tiếng của tôi không đủ để di chuyển câu hỏi, nhưng tôi sẽ không phiền nếu nó đã di chuyển. (Tôi cho rằng tiền điện tử.SE không chỉ là vấn đề triển khai)
Jay

2
@Artem, IMHO, câu hỏi nằm trong phạm vi cstheory. Tôi không phải là một chuyên gia về tiền điện tử, nhưng nhìn chung mọi người làm nhiều việc trong thực tế không có nền tảng, ví dụ như các hàm đơn giản được sử dụng như các trình tạo số ngẫu nhiên psuedo trong các chương trình nhưng chúng không thực sự ngẫu nhiên và có thể dự đoán dễ dàng. Jay, Nếu bạn muốn biết về lý do tại sao Katz và Lindell nói rằng LFSR không nên được sử dụng cstheory là nơi thích hợp cho câu hỏi. Mặt khác, hỏi nếu có sự đồng thuận không phải là một câu hỏi hay, câu trả lời là hiển nhiên, tức là không có. Ngoài ra câu hỏi bỏ phiếu không mang tính xây dựng.
Kaveh

1
@Jay, tôi đoán ý của họ khi không được hiểu rõ là họ không dựa trên các giả định về độ cứng hợp lý hoặc tiền điện tử, tức là không có lập luận mạnh mẽ cho tính không thể phá vỡ của họ. Bạn có thể muốn kiểm tra ghi chú bài giảng của Charles Rackoff , tôi nhớ rằng ông đã nói điều gì đó về vấn đề này (nhưng tôi không chắc liệu nó có trong bài giảng của mình không).
Kaveh

Câu trả lời:


9

Có nhiều loại tấn công bằng mật mã: xấp xỉ tuyến tính, tấn công đại số, tấn công thời gian bộ nhớ-dữ liệu-bộ nhớ, tấn công lỗi .

Ví dụ: bạn có thể đọc khảo sát: " Tấn công đại số trên mật mã dòng (khảo sát) "

Tóm tắt : Hầu hết các mật mã luồng dựa trên các thanh ghi dịch chuyển phản hồi tuyến tính (LFSR) dễ bị tổn thương trước các cuộc tấn công đại số gần đây. Trong bài khảo sát này, chúng tôi mô tả các cuộc tấn công chung: sự tồn tại của phương trình đại số và tấn công đại số nhanh. ...

Cuối cùng, bạn có thể tìm thấy các tài liệu tham khảo có liên quan khác.

Một bài viết hay khác về các cuộc tấn công lỗi để truyền mật mã là: " Phân tích lỗi của mật mã luồng "

Tóm tắt : ... Mục tiêu của chúng tôi trong bài viết này là phát triển các kỹ thuật chung có thể được sử dụng để tấn công các cấu trúc tiêu chuẩn của mật mã luồng dựa trên LFSR, cũng như các kỹ thuật chuyên dụng hơn có thể được sử dụng để chống lại các thuật toán mã hóa cụ thể như RC4, LILI -128 và SOBERt32. Mặc dù hầu hết các kế hoạch có thể bị tấn công thành công, chúng tôi chỉ ra một số vấn đề mở thú vị như tấn công vào các công trình được lọc của FSM và phân tích các lỗi trọng lượng Hamming cao trong LFSR.

Đối với các cuộc tấn công trao đổi dữ liệu bộ nhớ thời gian, bạn có thể đọc: " Thời gian mã hóa / Bộ nhớ / Trao đổi dữ liệu cho mật mã luồng ".


1
Cảm ơn bạn! Những giấy tờ này chắc chắn sẽ hữu ích.
Jay

3

Katz và LINDELL được đề xuất không nên sử dụng LFSRs tự như máy phát điện giả ngẫu nhiên. Tuy nhiên, có thể xây dựng một trình tạo giả ngẫu nhiên bằng cách sử dụng LFSR kết hợp với các cơ chế khác. (Đặc biệt, PRG dựa trên LFSR phải bao gồm một số thành phần phi tuyến tính.)

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.