Điểm:0

Mặt nạ dữ liệu xác định

lá cờ jp

Chúng tôi đang xây dựng khung che giấu dữ liệu chủ yếu để che giấu PII. Quy mô của chúng tôi khá lớn và việc tạo mặt nạ sẽ được thực hiện vào thời điểm nhập liệu, vì vậy chúng tôi muốn việc tạo mặt nạ được thực hiện một cách hiệu quả. Một số hạn chế mà chúng tôi có là chúng tôi muốn việc che dấu có tính xác định và có thể đảo ngược. Tôi đã xem mã hóa AES để mã hóa PII, đặc biệt là AES SIV, trên macbook của tôi, mất khoảng ~2 mili giây, điều này có thể không lý tưởng cho quy mô của chúng tôi.

Sẽ thật tuyệt khi nhận được phản hồi từ cộng đồng nếu có bất kỳ giải pháp thay thế nào cho AES SIV nhanh hơn (và mang tính quyết định) hoặc nếu có bất kỳ giải pháp thay thế nào khác cho mã hóa AES.

Đây là phương pháp mã hóa của tôi. Tôi đang sử dụng Cryptodome.Cipher AES


    mã hóa def (khóa: byte, văn bản: str) -> str:
        nonce = Không có
        mật mã = ​​Không có
        encoded_text = text.encode('utf-8')

        nonce = get_random_bytes(AES.block_size)
        cipher = AES.new(key, AES.MODE_SIV, nonce=nonce)
        cipher_text, tag = cipher.encrypt_and_digest(encoded_text)

        ret_cipher_text = nonce + cipher_text
        ret_cipher_text = thẻ + ret_cipher_text
        trả lại b64encode(ret_cipher_text).decode()

Hiệu suất của mã hóa này ~2 mili giây cho một văn bản nhỏ.

poncho avatar
lá cờ my
2 msec để AES mã hóa một văn bản nhỏ vừa phải? Chắc chắn, CPU trên macbook không tệ đến thế - tôi nghi ngờ bạn đang sử dụng bộ mã hóa AES kém (hiệu suất thấp)...
Paul Uszak avatar
lá cờ cn
Cụm từ _"deterministic_" xuất hiện ba lần ở đây. Mối quan tâm cụ thể của bạn là gì?
lá cờ jp
@poncho - Vâng, văn bản nhỏ. Tôi đang sử dụng Cryptodome.Cipher AES. Có lựa chọn thay thế nhanh hơn? Có thể là sai lầm?
lá cờ jp
@PaulUszak - Tôi muốn biết liệu hiệu suất mã hóa AES SIV có thực sự dưới mức tối ưu hay không và liệu có bất kỳ cách thay thế nào để che giấu dữ liệu sao cho cùng một văn bản gốc được che giấu thành cùng một văn bản mật mã và có thể được chuyển đổi trở lại thành văn bản gốc .
Paul Uszak avatar
lá cờ cn
_"hoặc nếu có bất kỳ giải pháp thay thế nào khác cho mã hóa AES."_ : Bạn thấy rằng (ngoài http://tls) không có giải pháp mã hóa thay thế nào từ góc độ tiếp thị. AES hoặc phá sản.
Paul Uszak avatar
lá cờ cn
Bạn có chắc là bạn muốn điều này: _"cùng một bản rõ được ẩn thành chính xác cùng một bản mã" _ không? Điều này nói với tất cả rằng không có gì thay đổi và được coi là hình thức kém.
Điểm:2
lá cờ us

Vấn đề ở đây rất có thể con trăn và không AES.

Với hỗ trợ phần cứng (AES-NI) AES thường có thể được tính toán ở mức dưới ~1 chu kỳ CPU/byte nếu bạn có đủ nhiều tác vụ AES độc lập (ví dụ: với chế độ bộ đếm) và khoảng 2-5 chu kỳ CPU/byte nếu không (ví dụ: với chế độ CBC).

AES-SIV hiện hoạt động hiệu quả bằng cách xâu chuỗi một hoạt động giống như CBC với đầu ra của nó được sử dụng làm bộ đếm ban đầu cho chế độ bộ đếm. Do đó, hiệu suất dự kiến ​​là khoảng 3-6 chu kỳ trên mỗi byte để triển khai được tối ưu hóa.

Hai mili giây trên CPU 1GHz (đồng hồ của bạn có thể cao hơn) là khoảng 2 triệu chu kỳ CPU. Ngay cả khi giả sử triển khai khá tệ trên CPU cũ hơn với AES-NI, việc triển khai "xấu" sẽ đạt khoảng 20-30 chu kỳ/byte, nhưng không ở đâu gần bằng 2 triệu.

Vì vậy, vấn đề rất có thể liên quan đến việc trình thông dịch phải làm nhiều việc hơn so với cách diễn giải được biên dịch/tối ưu hóa.

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