Tuỳ thuộc vào bài toán của bạn. Nếu chỉ duy nhất 1 bên có thể mã hoá/giải mã thì symmetric encryption là đủ, việc bạn lưu encryption key ở đâu thì là câu chuyện về secure storage rồi.
Nếu trao đổi giữa 2 bên A/B, có vài cách dưới đây. Không cái gì là tuyệt đối tốt hơn cả, tuỳ thuộc vào bài toán của bạn (private/public client-server hay server-server...)
- Asymmetric encryption để bảo vệ encryption key, và dùng encryption key để symmetric encrypt message. Tại sao? Vì asymmetric encryption không nhanh, không phù hợp mã hoá dữ lượng lớn. Ví dụ: RSAOAP cho asymmetric key encryption, AESGCM cho symmetric message encryption.
- Key agreement. Đối với public-key cryptography như ECC không hỗ trợ asymmetric encryption thì có cách là key agreement. Hiểu nôm na là shared secret key = private key của A * public key của B = private key của B * public key của A. Sau đó dùng shared secret key để symmetric encrypt message như trên. Ví dụ: ECIES scheme với ECDH cho key agreement, sau đó tuỳ chọn symmetric encryption algorithm. Lưu ý ECDHE dùng rộng rãi hơn (vd SSL) do keypair là ephemeral, hiểu nôm na là dùng một lần vì vậy tính an toàn cao hơn (ví dụ Forward secrecy)
- Private shared key: shared key để tránh hiểu lầm ko phải là key exchange mà đơn giản là 2 parties có 1 cái key ngầm thảo thuận từ trước và dùng nó để encrypt. Cách này "nhà quê" vì đơn giản key mà nhiều người biết thì khó bảo mật.
- Key wrapping: giống gạch đầu dòng thứ nhất, tuy nhiên encryption key wrapped by a symmetric key. Cái symmetric key này làm thế nào để bảo mật secure giữa 2 bên thì lại là 1 vấn đề đau đầu khác
- Key agreement xong dùng để wrapping encryption key: 1 biến thể nữa, kết hợp của gạch đầu dòng thứ 2 + 4.
Mã hoá gồm nhiều params nữa như salt/iv/nonce (cái bọn này dùng lộn xộn, nhưng mình nghĩ là một): giá trị ngẫu nhiên được "trộn" vào lúc mã hoá để tránh 2 messages giống nhau sẽ cùng output. 1 hệ thống thiết kế tốt sẽ có own random generator module hoạt động độc lập để tránh bị đoán giá trị tạo ra.
Authentication tag: 1 số thuật toán mã hoá hỗ trợ authentication tag để đảm bảo message
integrity: attacker tạo mã hoá giả và tự xưng là B, gửi cho A để cố đoán khoá bí mật của A. Authentication tag (AAD) giúp chống tấn công bằng cách: A check auth tag trc, nếu không khớp không thèm decrypt. Ví dụ AES GCM, hình như CBC không có
tag: 1 số giải thuật ouput có sinh tag append với ciphertext. Chẳng rõ làm gì
KDF: tạo nhiều phiên bản từ 1 master key, mục đích tránh bị lộ master key nếu 1 trong những derived key bị lộ. KDF gần như bắt buộc trong mã hoá hiện đại, hiếm thấy protocol nào không có một bước KDF trước khi encrypt.
Hash: băm. HMAC: băm với thêm đầu vào là private key (mình hiểu nôm na vậy)
Gì nữa ta, dạo này mần mần toàn dùng ECC, không nhớ quên bài gì của RSA không
Quantum computing đúng là 1 cái gì đó rất hoành tráng, mà vẫn đang nghiên cứu thôi. Dự đoán nếu quantum computin mature thì RSA, ECC, internet bây giờ là lủng hết, bao giờ nó ra ae dev lại zác zú update code.
Nói tóm lại: cái khoá nó quan trọng lắm trong software. Nhớ cất kỹ.
) thì cách được khuyên dùng nhất là theo industry standard, ngta dùng cách gì thì mình dùng theo. 
.
