it-swarm-vi.com

Tính toán khóa mã hóa AES cho bản rõ và bản mã của nó?

Tôi được giao nhiệm vụ tạo các bảng cơ sở dữ liệu trong Oracle có chứa các chuỗi được mã hóa (nghĩa là, các cột là RAW). Các chuỗi được mã hóa bởi ứng dụng (sử dụng AES, khóa 128 bit) và được lưu trữ trong Oracle, sau đó được truy xuất từ ​​Oracle và được giải mã (tức là, chính Oracle không bao giờ thấy các chuỗi không được mã hóa).

Tôi đã đi qua một cột này sẽ là một trong hai chuỗi. Tôi lo lắng rằng ai đó sẽ chú ý và có lẽ tìm ra hai giá trị đó để tìm ra khóa AES.

Ví dụ: nếu ai đó thấy rằng cột là Cexttext # 1 hoặc # 2:

  • Bản mã số 1:

    BF,4F,8B,FE, 60,D8,33,56, 1B,F2,35,72, 49,20,DE,C6.
    
  • Bản mã số 2:

    BC,E8,54,BD, F4,B3,36,3B, DD,70,76,45, 29,28,50,07.
    

và biết các Nguyên đơn tương ứng:

  • Nguyên đơn số 1 ("Detroit"):

    44,00,65,00, 74,00,72,00, 6F,00,69,00, 74,00,00,00.
    
  • Nguyên đơn số 2 ("Chicago"):

    43,00,68,00, 69,00,63,00, 61,00,67,00, 6F,00,00,00.
    

anh ta có thể suy luận rằng khóa mã hóa là "Buffalo" không?

42,00,75,00, 66,00,66,00, 61,00,6C,00, 6F,00,00,00.

Tôi nghĩ rằng chỉ nên có một khóa 128 bit có thể chuyển đổi Plaintext # 1 thành Cexttext # 1. Điều này có nghĩa là tôi nên đi đến một khóa 192 bit hoặc 256 bit, hoặc tìm một số giải pháp khác?

(Ở một bên, đây là hai bản mã khác cho cùng một bản rõ nhưng có một khóa khác.)

  • Bản mã số 1 A ("Detroit"):

    E4,28,29,E3, 6E,C2,64,FA, A1,F4,F4,96, FC,18,4A,C5.
    
  • Bản mã # 2 A ("Chicago"):

     EA,87,30,F0, AC,44,5D,ED, FD,EB,A8,79, 83,59,53,B7.
    

[Câu hỏi liên quan: Khi sử dụng AES và CBC, IV có thể là hàm băm của bản rõ không? ]

31
Null Pointers etc.

Tôi đang thêm một câu trả lời dưới dạng wiki cộng đồng vì tôi tin rằng câu trả lời được chấp nhận là gây hiểu lầm nguy hiểm . Đây là lý do của tôi:

Câu hỏi là hỏi về việc có thể lấy được các phím AES. Về mặt đó, câu trả lời được chấp nhận là chính xác: được gọi là Tấn công đã biết rõ và AES chống lại kiểu tấn công đó. Vì vậy, kẻ tấn công sẽ không thể tận dụng điều này để lấy khóa và thực hiện với toàn bộ cơ sở dữ liệu.

Nhưng có một cuộc tấn công nguy hiểm tiềm tàng khác đang diễn ra ở đây: a Tấn công không mã hóa bản mã . Từ Wikipedia:

Cexttext không thể phân biệt là một thuộc tính của nhiều sơ đồ mã hóa. Theo trực giác, nếu một hệ thống mật mã sở hữu đặc tính không thể phân biệt, thì một kẻ thù sẽ không thể phân biệt các cặp mật mã dựa trên thông điệp mà chúng mã hóa.

OP cho chúng ta thấy rằng cột này chứa một trong hai giá trị có thể và do mã hóa có tính xác định (nghĩa là không sử dụng IV ngẫu nhiên) và kẻ tấn công có thể thấy các hàng nào có cùng giá trị với nhau. Tất cả những kẻ tấn công phải làm là tìm ra bản rõ cho cột đó cho một hàng và chúng đã bẻ khóa mã hóa trên toàn bộ cột. Tin xấu nếu bạn muốn dữ liệu đó được giữ riêng tư - điều mà tôi cho rằng đó là lý do tại sao bạn mã hóa nó ngay từ đầu.

Giảm thiểu: Để bảo vệ chống lại điều này, làm cho mã hóa của bạn không mang tính quyết định (hoặc ít nhất là xuất hiện không xác định đối với kẻ tấn công) để mã hóa lặp đi lặp lại của cùng một văn bản mã hóa khác nhau. Ví dụ, bạn có thể thực hiện việc này bằng cách sử dụng AES trong chế độ Chuỗi khối mã hóa (CBC) với ngẫu nhiên Vector khởi tạo (IV) . Sử dụng một trình tạo số ngẫu nhiên an toàn để tạo IV mới cho mỗi hàng và lưu IV trong bảng. Bằng cách này, không có khóa, kẻ tấn công không thể biết được hàng nào có văn bản gốc phù hợp.

45
Mike Ounsworth

Đối với một mật mã khối có khóa bit n -, nếu, được cung cấp một khối văn bản gốc và bản mã tương ứng, khóa có thể được đoán ít hơn 2n-1 bước trung bình, sau đó mật mã khối đó sẽ được gọi là "bị hỏng" và các nhà mật mã sẽ đưa ra quan điểm không sử dụng nó. AES không bị hỏng (chưa). Vì vậy, không phải lo lắng.

Một số điều vẫn có thể được nói, mặc dù:

  • Có một bản rõ và bản mã tương ứng cho phép kẻ tấn công xác minh một giá trị khóa tiềm năng.
  • 2n-1Giá trị thực sự bằng một nửa kích thước của không gian khóa. Ý tưởng là kẻ tấn công có thể thử tất cả các phím có thể, cho đến khi khớp. Trung bình, anh ta sẽ phải thử một nửa các phím trước khi nhấn đúng. Điều này giả định rằng không gian khóa có kích thước 2n. Bạn vẫn có khả năng giảm không gian khóa: ví dụ: nếu bạn quyết định rằng khóa của bạn là tên của một thị trấn ở Hoa Kỳ, thì số lượng khóa có thể thấp hơn rất nhiều (không được có hơn 100000 thị trấn ở Hoa Kỳ) . Do đó, bạn chỉ nhận được bảo mật 128 bit nếu quy trình tạo khóa của bạn thực sự có thể tạo ra bất kỳ khóa 128 bit nào.
  • Bạn rõ ràng mã hóa từng giá trị bằng cách nhồi trực tiếp vào lõi AES. AES mang tính quyết định, điều này có nghĩa là hai ô có cùng giá trị sẽ mang lại cùng một khối được mã hóa và bất kỳ kẻ tấn công nào cũng có thể nhận thấy điều đó. Nói cách khác, bạn rò rỉ thông tin về những ô nào bằng nhau. Tùy thuộc vào tình huống của bạn, điều này có thể hoặc không thể là một vấn đề; bạn nên nhận thức về nó.
  • Bạn không nói cách bạn xử lý các giá trị dài hơn 16 byte. Đây không phải là một vấn đề đơn giản. Nói chung, điều này đòi hỏi một chế độ chuỗi như CBC và Vector khởi tạo (tùy thuộc vào chế độ; CBC, giá trị ngẫu nhiên 16 byte - IV mới cho mỗi giá trị được mã hóa ) (điều này cũng có thể khắc phục rò rỉ thông tin từ điểm trước đó).
15
Thomas Pornin

Câu trả lời: Không, khóa AES không thể được phục hồi trong trường hợp này. AES an toàn trước các cuộc tấn công bằng văn bản đã biết. Điều này có nghĩa là, ngay cả khi kẻ tấn công biết bản rõ và bản mã tương ứng của nó (mã hóa của nó dưới một số khóa AES không xác định), thì kẻ tấn công không thể khôi phục khóa AES. Cụ thể, kẻ tấn công không thể khôi phục khóa AES nhanh hơn đơn giản là thử lần lượt từng khóa có thể - đó là một quá trình sẽ mất nhiều thời gian hơn cả đời của nền văn minh của chúng ta, giả sử rằng khóa AES được chọn ngẫu nhiên.

P.S. Tôi nhận thấy rằng bất cứ điều gì bạn đang sử dụng để mã hóa dường như không sử dụng IV. Đây là một rủi ro bảo mật. Tôi không biết bạn đang sử dụng chế độ hoạt động nào, nhưng bạn nên sử dụng chế độ mã hóa được đánh giá cao (ví dụ: mã hóa chế độ CBC, mã hóa chế độ CTR) với IV ngẫu nhiên. Thực tế là việc mã hóa cùng một tin nhắn nhiều lần luôn mang lại cho bạn cùng một bản mã mỗi lần là một rò rỉ bảo mật, tốt hơn nên tránh. Bạn có thể tránh rò rỉ này bằng cách sử dụng chế độ hoạt động tiêu chuẩn với IV thích hợp. (Có lẽ bạn cũng nên sử dụng mã xác thực tin nhắn (MAC) để xác thực bản mã và ngăn sửa đổi nó.)

5
D.W.

Muối mã hóa của bạn.

Bằng cách đó, sẽ không có bất kỳ yếu tố nào trong mã hóa của bạn. (Cũng có những lợi ích khác!)

https://stackoverflow.com/questions/5051007/what-is-the-purpose-of-salt

3
Morons

AES không dễ dàng như việc xây dựng một bàn Rainbow. Điều đầu tiên bạn phải nhận ra là bảng yêu cầu một vectơ khởi tạo. Miễn là bạn thay đổi điều này trên cơ sở bán thường xuyên, xây dựng một bảng Cầu vồng (không thực tế.) Sẽ mất một thời gian rất dài. Đơn đặt hàng độ lớn dài. Vì một bảng Rainbow điển hình sẽ có 2 chiều, về cơ bản bạn sẽ cần một khối các tập kết quả để tìm ra cả IV và khóa.

Nếu bạn đọc bài viết của Thomas Pornin, anh ấy sẽ đi sâu vào chi tiết khá tuyệt vời về ý nghĩa của điều này, về mặt vũ phu buộc kết quả.

Điều lo lắng thực tế là ai đó có quyền truy cập vào cơ sở dữ liệu sẽ có thể chèn một chuỗi từ một trường khác (có lẽ vì bạn không sử dụng giá trị đệm ngẫu nhiên trong cột cho mỗi phần tử. Hoặc gieo hạt.)

Nếu bạn chọn giá trị bạn sẽ không gặp phải vấn đề này và cuộc tấn công (thực tế) duy nhất vào chính văn bản mã hóa được thực hiện khó khăn hơn nhiều.

2
Ori