Điểm:1

Việc lấy khóa từ khóa chính rồi mã hóa bằng AES-GCM có làm tăng tuổi thọ của khóa chính không?

lá cờ cn

Giả sử rằng chúng tôi có khóa chính 256 bit đối xứng và chúng tôi muốn mã hóa bằng AES-GCM với các IV ngẫu nhiên. Tôi hiểu rằng với các IV ngẫu nhiên, thời gian tồn tại của khóa chính là 2^32 để tuân thủ các yêu cầu của NIST.

Giả sử rằng chúng ta muốn tăng tuổi thọ của khóa chính. Chúng ta có thể làm điều này bằng cách thêm một bước dẫn xuất khóa trước khi mã hóa thực tế không? Giả sử rằng chúng tôi sử dụng khóa chính làm tài liệu tạo khóa đầu vào và một nonce ngẫu nhiên trong HKDF, liệu chúng tôi có thể kéo dài thời gian tồn tại của khóa chính không?

Nói cách khác, là AES-GCM(HKDF(MasterKey,...), IV,...) cung cấp bất kỳ lợi thế nào về tổng số tin nhắn so với AES-GCM(MasterKey, IV,...)?

Cụ thể, giả sử rằng HKDF có muối cố định và nonce 128 bit ngẫu nhiên làm đầu vào và GCM sử dụng IV ngẫu nhiên 96 bit, thì tôi giả định rằng (WK, IV) có xác suất va chạm thấp hơn (IV). Nếu giả định này là chính xác, làm cách nào để tính toán giới hạn cho thời gian tồn tại của khóa chính?

Swashbuckler avatar
lá cờ mc
"Tôi hiểu rằng với các IV ngẫu nhiên, thời gian tồn tại của khóa chính là 2^32 để tuân thủ các yêu cầu của NIST." Ừ, nhưng... GCM dựa trên chế độ CTR và có nghiên cứu cho thấy rằng bạn nên giới hạn tổng lượng dữ liệu được mã hóa bằng một khóa duy nhất (bất kể số lượng IV được sử dụng) là khoảng 64 GB (tùy thuộc vào mức độ chấp nhận rủi ro của bạn). "Cụ thể, chúng tôi cho thấy rằng các cuộc tấn công khôi phục tin nhắn chống lại chế độ CTR có thể được thực hiện với các yêu cầu gần giống nhau và cùng độ phức tạp như các cuộc tấn công chống lại chế độ CBC." Xem https://eprint.iacr.org/2018/159.pdf
kelalaka avatar
lá cờ in
Một số tính toán va chạm được thực hiện ở đây; [Dẫn xuất nhiều khóa AES từ khóa chính](https://crypto.stackexchange.com/questions/76588/multiple-aes-key-derivation-from-a-master-key/76589#76589), cũng có thể để sử dụng AES-GCM-SIV?
Điểm:1
lá cờ in

Giả sử rằng chúng ta muốn tăng tuổi thọ của khóa chính.Chúng ta có thể làm điều này bằng cách thêm một bước dẫn xuất khóa trước khi mã hóa thực tế không? Giả sử rằng chúng tôi sử dụng khóa chính làm tài liệu tạo khóa đầu vào và một nonce ngẫu nhiên trong HKDF, liệu chúng tôi có thể kéo dài thời gian tồn tại của khóa chính không?

Có, chắc chắn khi nói đến các yêu cầu của GCM. Tất nhiên có thể có những cân nhắc khác vì cùng một khóa chính vẫn đang bảo vệ một lượng lớn thư có thể.

Nói cách khác, là AES-GCM(HKDF(MasterKey,...), IV, ...) cung cấp bất kỳ lợi thế nào về tổng số tin nhắn so với AES-GCM(MasterKey, IV,...)?

Có khả năng là có, tất nhiên điều đó phụ thuộc vào các đầu vào khác của HKDF, nhưng miễn là đầu vào của HKDF là duy nhất, bạn có chức năng một chiều an toàn làm cho các khóa dẫn xuất độc lập với nhau.

Cụ thể, giả sử rằng HKDF có muối cố định và nonce 128 bit ngẫu nhiên làm đầu vào và GCM sử dụng IV ngẫu nhiên 96 bit, thì tôi giả định rằng (WK, IV) có xác suất va chạm thấp hơn (IV).

Không có "nonce" nào được định nghĩa là tham số đầu vào cho HKDF, nhưng bạn có thể sử dụng một tham số trong Thông tin cánh đồng.

Một "muối cố định" là rất ít hoặc không sử dụng. Tuy nhiên, bạn có thể sử dụng tham số muối trống và sử dụng nonce như một phần của Thông tin tham số và được an toàn hợp lý.

Với một loại muối, bạn không phải suy nghĩ về việc tách miền (ví dụ: sử dụng khóa chính của bạn cho bất kỳ thứ gì khác có thể gây trở ngại), trích xuất độc lập nguồn (ví dụ: khả năng lặp lại nonce hoặc entropy xấu của khóa chính) - nhưng bạn có thể làm mà không có.

Trên thực tế, bạn có thể bỏ qua một bước nếu bạn muốn và chỉ sử dụng HKDF-Mở rộng nếu khóa chính của bạn có đủ entropy. Trong trường hợp đó, không có Muối tham số cần thiết.

Tôi khuyên bạn nên có một số chuỗi hằng số bổ sung trong trường Thông tin cũng có thể được sử dụng để lấy các khóa từ chính cho các trường hợp sử dụng bổ sung. Ví dụ, các Thông tin trường có thể sử dụng một nhãn gọi là "Khóa mã hóa". Điều này chỉ đơn giản cho biết trường hợp sử dụng của các khóa con dẫn xuất là gì - nó cung cấp một số phân tách miền.

Nếu giả định này là chính xác, làm cách nào để tính toán giới hạn cho thời gian tồn tại của khóa chính?

Giả sử rằng bạn xuất các khóa 256 bit và sử dụng ít nhất SHA-256 làm hàm băm cơ bản. Sau đó, cơ hội va chạm bổ sung có thể được coi là không đáng kể; nó phụ thuộc hoàn toàn vào các thuộc tính va chạm của nonce được cung cấp.

Như đã chỉ ra, có thể có những lý do khác khiến bạn thỉnh thoảng muốn làm mới khóa chính của mình, vì tính bảo mật của thư vẫn phụ thuộc vào một khóa duy nhất đó.

user13129201 avatar
lá cờ cn
Cảm ơn bạn đã trả lời của bạn. Tôi vẫn còn một chút bối rối về điều này. Trong https://rwc.iacr.org/2018/Slides/Gueron.pdf, các tác giả tuân theo cách tiếp cận tương tự nhưng ranh giới được tính toán của họ thì khác. Hơn nữa, trong bài báo gốc, họ tuyên bố rằng AES-GCM với dẫn xuất khóa không cho phép mã hóa nhiều tin nhắn hơn khi IV được chọn ngẫu nhiên (chỉ các tin nhắn dài hơn). Trong câu trả lời của bạn, bạn có ngụ ý rằng điều này hoàn toàn phụ thuộc vào đầu ra của HKDF hay tôi đã hiểu nhầm? Đầu vào HKDF dựa trên cùng một nguồn entropy như IV, do đó, vấn đề sinh nhật bắt đầu ở cả thông tin và IV.
Maarten Bodewes avatar
lá cờ in
À, xin lỗi, vâng, nếu bạn sử dụng **ngẫu nhiên** nonce 128 bit thì rõ ràng bạn cần xem xét giới hạn sinh nhật cho điều đó. Tôi đã đặt nhầm chân khi bạn phân biệt giữa muối và nonce trong câu hỏi của mình. Bạn có thể chỉ ra những gì bạn nghĩ là sự khác biệt giữa hai thuật ngữ này?
user13129201 avatar
lá cờ cn
Về cơ bản, ý tôi là đặt 16 byte ngẫu nhiên vào thông tin. Tuy nhiên, tôi muốn khái quát hóa vấn đề này bên ngoài sự lựa chọn của KDF.Về lý thuyết, việc nối thêm bước KDF trước bước AESGCM có giúp hệ thống xử lý hơn 2^32 thông báo một cách an toàn không? Và nếu vậy, có phải vì khó tìm thấy các va chạm cặp (WK, IV) so với các va chạm IV đơn giản (tức là trường hợp của GCM đơn giản với bước KDF)?
Maarten Bodewes avatar
lá cờ in
Có, xung đột sẽ hoàn toàn xảy ra trong quá trình tạo khóa phụ. Khi khóa thay đổi, bạn hoàn toàn không cần IV ngẫu nhiên, vì khóa đã đặt, giờ đây IV sẽ gần như hoàn toàn dựa vào độ mạnh của khóa. Vì vậy, theo nghĩa đó, sẽ hợp lý hơn nếu đặt tất cả các bit ngẫu nhiên vào `Thông tin` của bạn. Tôi không nghĩ nó quan trọng lắm, nhưng đối với tôi sẽ hợp lý hơn khi đặt tất cả các bit đó vào muối - xét cho cùng đó là một giá trị ngẫu nhiên trên mỗi dẫn xuất - và sau đó sử dụng một số nhãn trong trường `Thông tin`. Tuy nhiên, nhược điểm của điều đó là bạn phải sử dụng HKDF đầy đủ.
millenseed avatar
lá cờ in
Tại sao nó lại dựa trên dẫn xuất khóa con? Chúng ta có phải nhân xác suất va chạm của cả khóa con và IV xảy ra cùng nhau không?
Maarten Bodewes avatar
lá cờ in
Vâng, tôi đã sử dụng một số tính toán ngoài ý muốn của mình và tôi nghĩ điều đó không quan trọng lắm, vì cuối cùng bạn sẽ phải nhân chúng lại với nhau như bạn đã nói. Tuy nhiên, đối với tôi, va chạm trong phím được sử dụng có vẻ nguy hiểm hơn là chỉ trong tổ hợp.

Đă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.