Nén rồi mã hóa, hay ngược lại?

Tôi đang viết một hệ thống VPN mã hóa lưu lượng truy cập của nó (AES256) trên mạng (Tại sao lại tự viết khi có 1.000.001 người khác ở ngoài đó? À, tôi là một người đặc biệt cho một nhiệm vụ cụ thể mà không ai trong số họ phù hợp).

Về cơ bản tôi muốn chạy suy nghĩ của tôi qua bạn để đảm bảo rằng tôi đang làm điều này theo đúng thứ tự.

Hiện tại các gói chỉ được mã hóa trước khi được gửi đi, nhưng tôi muốn thêm một số mức nén cho chúng để tối ưu hóa sự an toàn của dữ liệu một chút. Không phải nén nặng - Tôi không muốn tối đa hóa CPU mọi lúc, nhưng tôi muốn đảm bảo rằng việc nén sẽ hiệu quả nhất có thể.

Vì vậy, suy nghĩ của tôi là, tôi có nên nén các gói trước khi mã hóa vì một gói không được mã hóa sẽ nén tốt hơn một gói được mã hóa? Hoặc cách khác xung quanh?

Tôi có thể sẽ sử dụng zlib để nén.

Đọc thêm trên blog Siêu người dùng .

Nếu mã hóa được thực hiện đúng thì kết quả về cơ bản là dữ liệu ngẫu nhiên. Hầu hết các lược đồ nén hoạt động bằng cách tìm các mẫu trong dữ liệu của bạn theo cách nào đó có thể được thực hiện và nhờ vào mã hóa hiện không có mẫu nào; dữ liệu hoàn toàn không thể nén được.

Nén trước khi bạn mã hóa.

Nén trước khi mã hóa. Dữ liệu nén có thể thay đổi đáng kể đối với những thay đổi nhỏ trong dữ liệu nguồn, do đó, rất khó thực hiện phân tích mật mã.

Ngoài ra, như Mr.Alpha chỉ ra, nếu bạn mã hóa trước, kết quả rất khó nén.

Ngay cả khi nó phụ thuộc vào trường hợp sử dụng cụ thể, tôi sẽ khuyên Encrypt-then-Compress. Nếu không, kẻ tấn công có thể rò rỉ thông tin từ số khối được mã hóa.

Chúng tôi giả sử người dùng gửi tin nhắn đến máy chủ và kẻ tấn công có khả năng nối văn bản vào tin nhắn của người dùng trước khi gửi (thông qua javascript, ví dụ). Người dùng muốn gửi một số dữ liệu hợp lý đến máy chủ và kẻ tấn công muốn lấy dữ liệu này. Vì vậy, anh ta có thể cố gắng nối các thông điệp khác nhau vào dữ liệu người dùng gửi đến máy chủ. Sau đó, người dùng nén tin nhắn của mình và văn bản được nối thêm từ kẻ tấn công. Chúng tôi giả sử nén DEFLATE LZ77, do đó, hàm thay thế thông tin tương tự bằng một con trỏ để xuất hiện đầu tiên. Vì vậy, nếu kẻ tấn công có thể tái tạo bản rõ lỗ, hàm nén sẽ giảm kích thước của văn bản thuần thành kích thước ban đầu và một con trỏ. Và sau khi mã hóa, kẻ tấn công có thể đếm số khối mật mã, vì vậy anh ta có thể thấy, nếu dữ liệu được nối thêm của anh ta giống với dữ liệu mà người dùng gửi đến máy chủ. Ngay cả khi trường hợp này nghe có vẻ hơi xây dựng, đó là một vấn đề bảo mật nghiêm trọng trong TLS. Ý tưởng này được sử dụng bởi một cuộc tấn công có tên CRIME để rò rỉ cookie trong kết nối TLS để đánh cắp các phiên.

nguồn: http://www.ekoparty.org/archive/2012/CRIME_ekoparty2012.pdf

Quan điểm của tôi là khi bạn nén một tin nhắn, bạn chiếu nó xuống một chiều thấp hơn và do đó có ít bit hơn, điều đó có nghĩa là tin nhắn được nén (giả sử nén không mất dữ liệu) có cùng thông tin trong ít bit hơn (những tin nhắn bạn đã loại bỏ là dư thừa! ) Vì vậy, bạn có nhiều thông tin hơn trên mỗi bit và do đó nhiều entropy hơn trên mỗi bit, nhưng tổng số entropy như bạn đã có trước đó khi tin nhắn không được nén. Bây giờ, tính ngẫu nhiên là một vấn đề khác và đó là nơi các mô hình nén có thể ném cờ lê khỉ.

Nén nên được thực hiện trước khi mã hóa. một người dùng không muốn mất thời gian chờ đợi để chuyển dữ liệu, nhưng anh ta / cô ta cần phải được thực hiện ngay lập tức mà không lãng phí bất kỳ thời gian nào.

Nén trước khi mã hóa như đã được chỉ ra trước đó. Nén tìm cấu trúc nó có thể nén. Mã hóa làm xáo trộn dữ liệu để tránh bị phát hiện cấu trúc. Bằng cách nén trước tiên, bạn có nhiều khả năng có một tệp nhỏ hơn và do đó tải trọng ít hơn để chuyển. Mã hóa sẽ thực hiện công việc của mình bất kể nó có được nén hay không và, một lần nữa như đã chỉ ra trước đó, có thể khó thực hiện phân tích mật mã hơn trên một tệp nén.

Nén làm giảm entropy thông tin. Nén tối đa làm cho entropy tối thiểu. Đối với một dữ liệu được mã hóa hoàn hảo (nhiễu) tối đa và entropy tối thiểu là như nhau.