Điểm:1

An toàn của AES-256/CBC/PKCS#7 + ngẫu nhiên hóa và tái sử dụng IV

lá cờ es

Để bắt đầu, tôi hoàn toàn không phải là chuyên gia hay bất cứ thứ gì gần đó về mật mã học. Tôi biết rất cơ bản về điều này, đủ để ít nhiều chọn một phương pháp để thực hiện và sau đó đọc về nó để tôi biết những gì tôi đang thực hiện. Vì vậy, xin vui lòng tha thứ cho bất kỳ câu hỏi được cho là ngu ngốc haha.

Với ý nghĩ đó, tôi đã tạo một lớp mã hóa/giải mã AES-256/CBC/PKCS#7 + HMAC-SHA512 trong ứng dụng trợ lý Android mà tôi đang tạo (được cho là có tại địa phương (rất?) những thứ cá nhân và tôi có thể xuất bản nó trên Cửa hàng Play, vì vậy nó không chỉ dành cho tôi). Sự kết hợp đó được cho là có độ an toàn cao trong những năm tiếp theo??(?). Có thể chậm hơn một chút, nhưng tôi không phiền, ít nhất là vào lúc này (rất ít dữ liệu). Mặc dù vậy, tôi cũng đọc được rằng có một vấn đề với điều này, đó là khi vectơ khởi tạo được sử dụng lại. Với CBC, có vẻ như không thể lấy lại dữ liệu (phải không?), giống như với các chế độ khác, và đó là lý do tại sao tôi chọn chế độ này. [Nếu có bất kỳ vấn đề nào khác với phương pháp này, tôi rất vui được biết về chúng.]

Nhưng sau một thời gian, có thể phát hiện các mẫu và xem các thông báo bằng nhau ở đâu (các khối 16 byte bằng nhau). Ví dụ, biết khối đó có nghĩa là gì, người ta có thể biết khối đó không thay đổi theo thời gian sau nhiều phiên bản được mã hóa khác nhau.

Vì vậy, tôi có một ý tưởng, đó là: tất cả dữ liệu tôi mã hóa phải được mã hóa bằng UTF-7. Các giá trị byte còn lại (128-255) được sử dụng làm giá trị ngẫu nhiên để đặt một giá trị mỗi 16 byte, ở một vị trí ngẫu nhiên. Ví dụ: trong chỉ mục 4, 154 byte được thêm vào và trong chỉ mục 19, 234 byte được thêm vào. Bằng cách này, nó luôn ngẫu nhiên và các khối dữ liệu thực tế bằng nhau sẽ khác nếu cùng một IV được sử dụng lại ("ngẫu nhiên" có thể lặp lại các giá trị và tôi không thể kiểm tra xem mình đã sử dụng chúng chưa trong trường hợp này, vì vậy tôi nghĩ về điều này để ngăn chặn các vấn đề).

Đây có phải là một cách tiếp cận tốt? Nó có thể giảm thiểu vấn đề? Có thể giải quyết nó hoàn toàn trong vô số năm tiếp theo và phương pháp bây giờ sẽ hoàn toàn an toàn hoặc ít nhất là an toàn hơn nhiều?

Ngoài ra, nếu bất cứ điều gì tôi nói là sai, tôi rất vui khi được sửa chữa! Cảm ơn!

Điểm:1
lá cờ in

Lý do duy nhất khiến bạn sợ tái sử dụng IV là nếu trình tạo số ngẫu nhiên bị tắt.

Giả sử IV hoàn toàn ngẫu nhiên, bạn có thể mã hóa $2^{64}$ khối trong AES-CBC và vẫn chỉ có một trong $~2^{64}$ cơ hội xảy ra va chạm (xấp xỉ). Lưu ý rằng vấn đề đầu vào lặp lại không giới hạn ở IV; Rốt cuộc, mỗi bản mã được sử dụng làm "vectơ" cho mã hóa khối AES tiếp theo.

Ý tưởng của bạn là ngẫu nhiên hóa phần nào các khối văn bản gốc, để giúp chống lại các xung đột IV, điều ít xảy ra hơn so với các xung đột ở đầu ra của AES (giả sử rằng các thông báo lớn hơn một khối). Nhưng điều đó sẽ không thực sự hữu ích, vì xung đột vẫn có thể xảy ra và nếu kẻ tấn công biết phần lớn nội dung của bản rõ thì sẽ dễ dàng đoán được nội dung trong khối khác.

Tuy nhiên, vẫn còn một vấn đề khác. Bây giờ bạn dường như có thông tin ngẫu nhiên để thực hiện ngẫu nhiên hóa các khối. Nếu bạn chỉ sử dụng dữ liệu ngẫu nhiên đó để tạo IV ngẫu nhiên an toàn thì có khả năng bạn sẽ không gặp sự cố ngay từ đầu.


Nếu bạn muốn bảo vệ dữ liệu của mình, tốt hơn hết bạn nên lấy hoặc đóng gói các khóa cụ thể của thông báo từ "khóa chính" của mình.

Nếu nguồn ngẫu nhiên của bạn không an toàn bằng mật mã, thì có lẽ bạn đang gặp rắc rối. Bạn có thể xem qua chế độ AES-SIV để giảm thiểu phần nào vấn đề. Trong chế độ đó, IV phụ thuộc vào thông điệp văn bản gốc.

Điều bạn chắc chắn không nên làm là sửa lỗi giao thức của mình để thử và che giấu những thiếu sót của thuật toán. Điều đó khó có thể thành công và nó làm tăng thêm tất cả các loại phức tạp không cần thiết. Mã hóa AES sẽ không yêu cầu bất kỳ thao tác nhấn nào nếu sử dụng đúng cấu trúc.


Lưu ý bảo mật:

  • Để bảo vệ chống lại những thay đổi trong tương lai, tôi khuyên bạn cũng nên đưa IV vào phép tính MAC. Sử dụng MAC trên IV sẽ chỉ thêm 16 byte vào phép tính, điều này tương đối không đáng kể.Hiện tại, kẻ tấn công không thể thay đổi IV của bạn, nhưng một thay đổi trong giao thức có thể khiến IV và do đó, tin nhắn của bạn dễ bị thay đổi.
  • Tôi cũng muốn cảnh báo bạn rằng nếu dữ liệu bị MAC'ed thì bạn dễ bị tấn công thay thế: thay thế dữ liệu của tệp này bằng tệp khác. Bạn cần một cái gì đó có thể kiểm chứng/duy nhất trong tiêu đề/siêu dữ liệu và MAC nó cùng với bản mã của bạn (chúng tôi có các sơ đồ AEAD để trợ giúp điều đó).
DADi590 avatar
lá cờ es
Chà, ý tưởng của tôi là vì tôi đã sử dụng trình tạo ngẫu nhiên an toàn (SecureRandom trong Java) cho IV, nên tôi có thể sử dụng lại nó để ngẫu nhiên hóa dữ liệu. Vì các giá trị ngẫu nhiên có thể lặp lại, tôi nghĩ về điều này. Và sau đó, những gì bạn đã nói "rốt cuộc, mỗi bản mã được sử dụng làm 'vectơ' cho mã hóa khối AES tiếp theo" cũng có thể được giảm thiểu vì về cơ bản, tất cả đều là ngẫu nhiên trong mỗi khối của thông báo là 16 byte (trong tôi không có chuyên gia gì cả haha). Nhưng tôi đã không nghĩ đến tần suất va chạm có thể xảy ra.... Chỉ nghĩ rằng "chúng sẽ xảy ra, vì vậy tôi sẽ làm cho nó khó hơn".
DADi590 avatar
lá cờ es
Nhưng nếu khả năng xảy ra va chạm thực sự thấp và ý tưởng của tôi sẽ không thực hiện được nhiều như vậy, thì tôi sẽ xóa nó và quay lại mã hóa UTF-8 bình thường. Ngoài ra, về AES-SIV, tôi không thể tiếp tục.Nó không được triển khai trong Android (Mật mã trên Nhà phát triển Android - Tóm tắt ở trên trong trường hợp bạn quan tâm). Phần đóng gói, nếu tôi lấy ngay từ Wikipedia, thì đó không phải là trường hợp của tôi. Tôi không lưu trữ khóa ở bất cứ đâu (ít nhất là bây giờ - không có máy chủ, chỉ là một dự án nhỏ). Nó bắt nguồn từ mật khẩu phải được nhập thủ công - đó là thứ phải đủ an toàn (tốt hơn là lưu trữ khóa cục bộ).
Maarten Bodewes avatar
lá cờ in
Chạy Argon2 hoặc - nếu bạn muốn sử dụng một cái đã được triển khai - PBKDF2.Xin lưu ý rằng bạn chỉ chấp nhận ASCII nếu bạn muốn duy trì khả năng tương thích với Java SE và bạn sử dụng hàm băm có kích thước đầu ra đủ lớn (không trích xuất nhiều hơn kích thước đầu ra của hàm băm từ hàm). Muối 16 byte ngẫu nhiên an toàn và số lần lặp càng cao càng tốt và bạn đã hoàn tất (bạn có thể muốn bao gồm số phiên bản trong giao thức của mình trong trường hợp bạn muốn nâng cấp nó hoặc số lần lặp). `SecureRandom()` mới nói chung là tốt và sẽ cung cấp cho bạn một PRNG có nguồn gốc tốt.
DADi590 avatar
lá cờ es
Về ghi chú bảo mật, tôi đã bao gồm IV trong tính toán MAC (tôi tính toán MAC bằng văn bản cypher, IV và khóa MAC). Tôi cũng đang sử dụng AEAD trên này. Tôi đã đọc chính xác những gì bạn nói, rằng có thể hoán đổi 2 tệp được mã hóa và chúng sẽ được đọc bằng mọi cách. Mặc dù vậy, nếu tôi bao gồm một số tiêu đề bên trong tệp, điều đó có thể không hoạt động. Nhưng trong mọi trường hợp, vâng, tôi sẽ sử dụng AAD để giúp ngăn chặn điều này. Cảm ơn vì tất cả thông tin! Tôi sẽ đánh dấu nó là câu trả lời!

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.