Стискати, а потім шифрувати чи навпаки?

Я пишу систему VPN, яка шифрує (AES256) свій трафік через мережу (Чому пишу мою власну, коли вже є 1 000 001 інших? Ну, моя спеціальна для конкретного завдання, яке не підходить жодному з інших).

В основному я хочу провести своє мислення повз вас, щоб переконатися, що я роблю це в правильному порядку.

На даний момент пакети просто шифруються перед надсиланням, але я хочу додати до них певний рівень стиснення, щоб трохи оптимізувати передачу даних. Не сильне стиснення - я не хочу постійно збільшувати процесор, але хочу переконатися, що стиснення буде максимально ефективним.

Отже, на мій погляд, я повинен стискати пакети перед шифруванням, оскільки незашифрований пакет буде стискати краще, ніж зашифрований? Або навпаки?

Я, ймовірно, буду використовувати zlib для стиснення.

Детальніше читайте в блозі Super User .

Якщо шифрування виконано належним чином, результат в основному є випадковими даними. Більшість схем стиснення працюють, знаходячи у ваших даних шаблони, які можна певним чином врахувати, і завдяки шифруванню зараз їх немає; дані є абсолютно нестислимими.

Стисніть перед шифруванням.

Стиснення перед шифруванням. Стислі дані можуть значно відрізнятися при невеликих змінах вихідних даних, тому ускладнюючи диференціальний криптоаналіз.

Крім того, як зазначає містер Альфа, якщо шифрувати спочатку, результат дуже важко стиснути.

Навіть якщо це залежить від конкретного випадку використання, я б радив Encrypt-then-Compress. В іншому випадку зловмисник може витікнути інформацію з кількості зашифрованих блоків.

Ми передбачаємо, що користувач надсилає повідомлення серверу та зловмиснику з можливістю додавати текст до повідомлення користувача перед відправкою (через javascript, наприклад). Користувач хоче надіслати деякі розумні дані на сервер, а зловмисник хоче отримати ці дані. Тож він може спробувати додати різні повідомлення до даних, які користувач надсилає на сервер. Потім користувач стискає своє повідомлення та доданий текст від зловмисника. Ми припускаємо стиснення LZ77 DEFLATE, тому функція замінює ту саму інформацію покажчиком на першу появу. Отже, якщо зловмисник може відтворити простий текст з отворами, функція стиснення зменшує розмір простого тексту до початкового розміру та покажчика. А після шифрування зловмисник може порахувати кількість блоків шифрів, щоб він міг бачити, чи були його додані дані такі, як дані, які користувач надсилав на сервер. Навіть якщо цей випадок здається трохи побудованим, це серйозна проблема безпеки в TLS. Ця ідея використовується атакою під назвою CRIME для витоку файлів cookie у TLS-з'єднанні для крадіжки сеансів.

джерело: http://www.ekoparty.org/archive/2012/CRIME_ekoparty2012.pdf

На мою думку, коли стискаєш повідомлення, ти проектуєш його на менший вимір, і для цього є менше біт, а це означає, що стиснене повідомлення (якщо вважати компресію без втрат) має ту саму інформацію в меншій кількості біт (ті, яких ти позбувся, були зайвими! ) Отже, у вас є більше інформації за біт і, отже, більше ентропії на біт, але така ж загальна ентропія, як і раніше, коли повідомлення не було стиснене. Тепер випадковість - інша справа, і саме там шаблони стиснення можуть кинути мавповий ключ.

Стиснення слід робити перед шифруванням. користувач не хоче витрачати час на очікування передачі даних, але йому потрібно це негайно зробити, не витрачаючи часу.

Стиснення перед шифруванням, як було зазначено раніше. Стиснення шукає структуру, яку вона може стиснути. Шифрування розшифровує дані, щоб уникнути виявлення структури. Спершу стискаючи, ви набагато більше шансів на те, що у вас буде менший файл і, таким чином, менше завантаження. Шифрування виконає свою роботу незалежно від того, стиснуте це чи ні, і, як уже було зазначено раніше, швидше за все буде складніше виконати диференціальний криптоаналіз на стисненому файлі.

Стиснення зменшує ентропію інформації. Максимальне стиснення робить ентропію мінімальним. Для ідеально зашифрованих даних (шуму) максимальна та мінімальна ентропія однакові.