Bạn thậm chí không cần IV ngẫu nhiên nếu bạn đã có khóa bí mật ngẫu nhiên thay đổi cho mỗi tin nhắn. Vì vậy, bất kỳ câu trả lời nào cũng sẽ không sai về cơ bản, vì không có yêu cầu bảo mật nào đối với IV. Tuy nhiên, tôi sẽ đề nghị bạn đọc câu trả lời này được cung cấp bởi chú gấu thân thiện của chúng tôi trước khi bạn gặp một CON VẬT ít thân thiện hơn.
Tuy nhiên, tôi sẽ không bao gồm IV với khóa đầu vào AES vì một lý do cụ thể: nó sẽ không tương thích với bất kỳ phần cứng hoặc HSM nào (hoặc bất kỳ kho khóa nào khác) thực hiện gói khóa (tức là mã hóa khóa bằng khóa gói, trong trường hợp của bạn là khóa công khai RSA). Vì vậy, nếu bạn quyết định rằng bạn cần điều đó, bạn phải thay đổi giao thức. Nếu không, bạn phải giải mã và lưu trữ khóa trong phần mềm. Thành thật mà nói, đây không phải là một vấn đề lớn, vì dù sao thì dữ liệu cũng sẽ nằm trong bộ nhớ, nhưng đó là điều cần xem xét.
Nếu bạn nhấn mạnh vào một IV ngẫu nhiên thì bạn có thể sử dụng, ví dụ: một hàm băm trên khóa được bọc (tức là bản mã RSA) dưới dạng IV hoặc bạn có thể lấy nó từ chính vật liệu của khóa được bọc (sử dụng Hàm dẫn xuất khóa hoặc KDF). Cách thứ hai có lẽ là một trong những cách tiếp cận được hầu hết các nhà mật mã học sử dụng ở đây, mặc dù nó khó hiểu và khó thực hiện hơn (ví dụ: RSA-KEM, sau đó là HKDF-Extract, sau đó là 2 lần HKDF-Expand - một lần cho khóa, một lần cho IV - mặc dù điều này có thể không tương thích với nhiều phần cứng).
Như đã chỉ ra trong các nhận xét, việc có một thông báo được xác thực thường khá quan trọng. Điều đó thường sẽ yêu cầu đăng nhập rồi mã hóa, tuy nhiên, chế độ này dễ bị tấn công tiên tri đệm trên cả PKCS#1 và CBC nếu bạn định sử dụng chế độ đó. Nếu bạn chỉ xem xét một người nhận và tính bảo mật cũng như tính toàn vẹn thì mã hóa-rồi-ký có thể phù hợp hơn với bạn.
Tất nhiên, điều này cũng yêu cầu một cặp khóa RSA (đáng tin cậy) ở người nhận, cuối cùng, tất cả là về quản lý khóa.
