Không phải vậy; kẻ tấn công có thể mã hóa bất kỳ tin nhắn nào. Bạn phải thêm tính toàn vẹn và tính xác thực của thông điệp vào bản rõ hoặc bản mã. Đối với điều này người gửi cần có khả năng xác thực các tin nhắn gửi đi. Điều này rõ ràng là không thể nếu chỉ sử dụng khóa mã hóa có sẵn công khai.
Khi chúng ta đang nói về các tin nhắn riêng biệt (ví dụ: bảo vệ tài liệu) thì điều này thường được thực hiện bằng cách sử dụng ký-rồi-mã hóa. Tại đây, người gửi ký vào các tin nhắn trước khi chúng được mã hóa bằng khóa riêng của họ. Sau đó, người nhận sẽ xác minh các tin nhắn sau khi giải mã bằng khóa chung của người gửi. Khóa công khai này của người gửi tất nhiên cần phải được tin cậy để chương trình này hoạt động.
Vì mã hóa khóa công khai không hiệu quả lắm đối với các thư lớn hơn và vì chữ ký (và thông tin meta) thường mở rộng các thư nên thường phải sử dụng mã hóa kết hợp để mã hóa đăng nhập hoạt động.Trong trường hợp đó, lược đồ mã hóa cũng có thể sử dụng Phương thức đóng gói khóa chẳng hạn như RSA-KEM hoặc (EC)IES.
Về nguyên tắc, cũng có thể sử dụng MAC (mã xác thực tin nhắn), nhưng điều đó sẽ yêu cầu khóa bí mật được chia sẻ trước, điều này sẽ phá hủy lợi thế của việc sử dụng mã hóa khóa công khai ngay từ đầu.
Trong bảo mật chế độ vận chuyển (ví dụ: TLS, SSH), mật mã khóa công khai thường được sử dụng để thiết lập bí mật giữa các bên trước khi tin nhắn được gửi qua kênh vận chuyển. Trong trường hợp đó, các tin nhắn được mã hóa bằng khóa phiên và được bảo vệ bằng thẻ xác thực. Thẻ này có thể được tính bằng MAC (ví dụ: HMAC) hoặc bằng cách sử dụng chế độ mã hóa được xác thực (ví dụ: ChaCha20/Poly1305).
Để điều này hoạt động, cả hai bên cũng cần phải được xác thực, nếu không, người gửi không biết ai đang nhận dữ liệu và người nhận không biết ai đang gửi dữ liệu đó. Vì vậy, mặc dù bản thân các thư được bảo vệ khác nhau, nhưng việc quản lý khóa cũng tương tự như bảo vệ các thư riêng biệt.
