Những gì bạn dường như đang yêu cầu là một số loại khóa công khai mã hóa hội tụ, mà các chương trình khác nhau tồn tại.
Tuy nhiên, tất cả các sơ đồ như vậy đều dễ bị tổn thương trước các cuộc tấn công đoán mò nếu số lượng bản rõ hợp lý thấp — giả sử, ít hơn khoảng một tỷ tỷ ($10^{24} â 2^{80}$).
Cụ thể, kẻ tấn công có bản mã hội tụ (hoặc chỉ là hàm băm mật mã) của một tin nhắn và khóa chung (nếu có) được sử dụng để tạo ra nó có thể đoán một bản rõ hợp lý, mã hóa nó và so sánh nó với bản mã/hàm băm để xác minh xem hoặc không dự đoán của họ là chính xác.
Một CPU máy tính để bàn điển hình có thể thực hiện theo thứ tự khoảng một tỷ ($10^9 â 2^{30}$) mã hóa một giây, vì vậy nếu có ít bản rõ có khả năng hơn thế, thì lược đồ này hoàn toàn không cung cấp bảo mật thực sự. Và nếu kẻ tấn công sẵn sàng dành thêm một chút thời gian và/hoặc mua (hoặc đánh cắp) sức mạnh tính toán cao hơn một chút so với mức đó, thì chúng có thể dùng vũ lực để vượt qua số lượng văn bản rõ gấp một nghìn, một triệu hoặc một tỷ lần như vậy. Ngoài ra, tấn công đồng thời nhiều bản mã theo cách này cũng nhanh như tấn công một bản mã.
Một kéo dài phím lược đồ có thể được sử dụng để làm chậm các cuộc tấn công như vậy, nhưng chỉ với cái giá là làm chậm các hoạt động mã hóa (và giải mã) hợp pháp theo cùng một hệ số. Vì vậy, ví dụ: nếu bạn có thể sống với một thao tác mã hóa đơn lẻ chiếm khoảng một giây CPU, thì bạn có thể buộc kẻ tấn công cũng mất khoảng một giây CPU (cho hoặc lấy hệ số 10 hoặc 100 tùy thuộc vào hiệu quả triển khai) để đoán và kiểm tra một bản rõ hợp lý duy nhất. Nhưng điều đó vẫn có nghĩa là kẻ tấn công có quyền truy cập vào 100 CPU (hoặc có thể là ~ một GPU nhanh) vẫn có thể kiểm tra một triệu bản rõ có thể có trong khoảng ba giờ.
Thông thường, dữ liệu như địa chỉ thư, tên người dùng, số điện thoại, v.v. có số lượng khá thấp và tệ hơn, ngay cả khi có thể có hàng triệu hoặc hàng tỷ khả thi địa chỉ, các rất có thể các kết hợp địa chỉ đang sử dụng ít hơn nhiều và có thể dễ dàng khám phá bằng cách sử dụng bản đồ công cộng và cơ sở dữ liệu địa chỉ. Vì vậy, trong thực tế, việc sử dụng hàm băm mật mã hoặc mã hóa hội tụ để đặt tên giả cho dữ liệu đó chắc chắn sẽ thất bại.
Thay vào đó, những gì bạn có thể làm là một trong những điều sau đây (theo thứ tự ưu tiên giảm dần):
Không lưu trữ hoặc xử lý dữ liệu đó nếu bạn có thể tránh được.
Nếu bạn phải lưu trữ dữ liệu như vậy, hãy lưu trữ dữ liệu được mã hóa (sử dụng mã thông thường tấn công bằng văn bản được chọn lược đồ mã hóa kháng) và chỉ giải mã nó để xử lý trên một hệ thống an toàn. Lưu trữ khóa giải mã một cách an toàn.
Nếu bạn phải đặt tên giả cho dữ liệu đó, ví dụ: để xử lý bởi các bên thứ ba không đáng tin cậy, tốt nhất hãy thực hiện bằng cách liên kết từng dữ liệu (địa chỉ, tên người dùng, v.v.) với một mã định danh hoàn toàn ngẫu nhiên và lưu trữ các liên kết trong cơ sở dữ liệu được mã hóa. Đảm bảo giữ an toàn cho cơ sở dữ liệu liên kết này như được mô tả ở trên.
Ngoài ra, bạn có thể tạo các số nhận dạng bút danh bằng cách áp dụng một PRF (Như là HMAC hoặc một số phím kéo dài KDF) vào các mục dữ liệu nhạy cảm bằng khóa bí mật. Nếu vậy, bạn phải bảo vệ khóa PRF khỏi bị xâm phạm, vì nó có thể được sử dụng để khử tên giả cho tất cả dữ liệu.
Dù bằng cách nào, nói chung là không khả thi để thực hiện bút danh "tại nguồn". Thay vào đó, bạn nên mã hóa bất kỳ dữ liệu nhạy cảm nào bằng cách sử dụng lược đồ khóa chung an toàn tại điểm thu thập (nên chỉ có có quyền truy cập vào nửa công khai của cặp khóa), hãy thu thập dữ liệu được mã hóa này vào một hệ thống an toàn và giải mã, xử lý và (tùy chọn) đặt bút danh cho dữ liệu đó ở đó.
