Điểm:0

Băm bút danh sử dụng khóa công khai

lá cờ be

Tôi có các nhật ký chứa dữ liệu nhạy cảm (địa chỉ thư, tên người dùng, v.v.) không chỉ cần tuân thủ GDPR mà còn phải được bảo mật nói chung ở mức tốt nhất có thể, vì vậy ẩn danh/băm sẽ là một giải pháp dễ dàng. Tuy nhiên, đồng thời tôi cần có khả năng tương quan thông tin cho mục đích giám sát (ví dụ: xác định các cuộc tấn công). Đối với điều đó, các giá trị văn bản gốc không liên quan, nhưng tôi cần các giá trị băm giả được đặt tên bằng nhau cho cùng một nguồn văn bản gốc (tính xác định). Vì tôi không thể lưu trữ dữ liệu ở dạng văn bản gốc mà chỉ ở dạng bút danh, nên tôi cũng cần có khả năng giải mã các giá trị nếu cần . Vì có thể có nhiều nguồn dữ liệu cần được giải mã riêng lẻ (hiếm khi cần tất cả cùng một lúc), ý tưởng ban đầu của tôi là sử dụng phương pháp khóa công khai/riêng tư cũ đơn giản bằng RSA, mà tôi biết từ SSH của mình -day: Mã hóa các giá trị bằng khóa pub cho mỗi nguồn, lưu trữ khóa riêng trong két an toàn. Tuy nhiên, RSA giới thiệu tính ngẫu nhiên cho các giá trị băm, điều này có ý nghĩa từ quan điểm bảo mật, nhưng làm hỏng yêu cầu xác định "phải có khả năng tương quan" của tôi.

Bất kỳ ý tưởng về một giải pháp tốt? Có một thuật toán tương tự mà tôi có thể sử dụng không quá dễ dàng để bruteforce, nhưng có thể sử dụng cách tiếp cận khóa công khai/riêng tư không? Tôi có thiếu các điểm yếu khác không, ví dụ: cố gắng sử dụng RSA thô mà không có phần đệm ngẫu nhiên?

Về mặt hoạt động: Nguy cơ kẻ tấn công có thể truy cập vào một số lượng lớn các giá trị băm sẽ cao hơn rất nhiều so với việc kẻ tấn công có quyền truy cập vào khóa công khai vốn đã được bảo mật cao. Rủi ro lớn nhất được xác định (vẫn rất khó xảy ra) là kẻ tấn công có thể đưa dữ liệu của chính anh ta vào nguồn của đường ống được xử lý/mã hóa và sau đó xem các giá trị băm, cho phép anh ta so sánh văn bản gốc và giá trị băm ( = đoán các giá trị băm ). Tốc độ mã hóa không cần quá cao và tốc độ giải mã thậm chí còn ít quan trọng hơn.

Nếu có liên quan, việc triển khai thực tế sẽ cần được thực hiện bằng Python.

Maarten Bodewes avatar
lá cờ in
Với hàm băm, chúng tôi thường có nghĩa là bạn chạy dữ liệu của mình thông qua hàm băm mật mã, chẳng hạn như SHA-256. Bạn có nghĩa là loại băm đó, hay bạn có nghĩa là mã hóa tạo ra một bản mã để có được tính bảo mật?
kelalaka avatar
lá cờ in
Băm cho bình đẳng và đồng thời sử dụng AES-GCM với IV=số nhật ký.
Senshi avatar
lá cờ be
@MaartenBodewes Ý tôi là mã hóa, vì tôi cần có khả năng khôi phục bản rõ trong một số trường hợp. Theo hiểu biết của tôi, hàm băm là phương pháp "một chiều", nghĩa là tôi không thể lấy văn bản gốc từ hàm băm được tạo. Đúng không?
Điểm:3
lá cờ ar

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):

  1. Không lưu trữ hoặc xử lý dữ liệu đó nếu bạn có thể tránh được.

  2. 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.

  3. 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 đó ở đó.

lá cờ ar
ps. Câu trả lời trước đó có liên quan: https://crypto.stackexchange.com/questions/25808/one-way-deterministic-hash-for-low-entropy-input/25813#25813
Senshi avatar
lá cờ be
Cảm ơn rất nhiều. Tất cả những điều đó là siêu thông tin và cho tôi nhiều điều để suy nghĩ. Tôi đã đánh giá thấp lỗ hổng bruteforce với các kết hợp giới hạn và văn bản gốc đã chọn. Khuyến nghị 2 nghe có vẻ là một giải pháp hấp dẫn cho trường hợp cụ thể này. Quá trình phân tích tự động diễn ra trên một máy trạm bị cô lập, nơi khóa giải mã được lưu trữ mà tất cả người dùng không thể truy cập được và các báo cáo được tạo sẽ chỉ có thể truy cập được đối với một số nhà phân tích chọn lọc sử dụng IDM của chúng tôi. Dù sao thì việc giải mã đặc biệt cũng không bao giờ được phép xảy ra ngoại trừ các trường hợp pháp y đặc biệt.

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