Сжать, а затем зашифровать или наоборот?


88

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

По сути, я хочу обдумать твои мысли, чтобы убедиться, что я делаю это в правильном порядке.

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

Итак, я думаю, я должен сжимать пакеты перед шифрованием, поскольку незашифрованный пакет будет сжимать лучше, чем зашифрованный? Или наоборот?

Я, вероятно, буду использовать zlib для сжатия.

Узнайте больше на блоге Super User .


4
Написание как "программирование"? Было бы лучше для переполнения стека.
Suma

4
Если бы я спрашивал о программировании этого, да, но я не. Это обычное сжатие, затем шифрование или шифрование, а затем сжатие вопроса, которое можно применить к простой работе с простыми файлами, если вы хотите. Сторона программирования - это просто контекст для того, почему я задаю вопрос.
Majenko


Вероятно, этот вопрос лучше всего подходит для security.stackexchange.com
Джефф Ферланд

1
Они знают о сжатии, не так ли?
Majenko

Ответы:


176

Если шифрование выполнено правильно, то результатом являются в основном случайные данные. Большинство схем сжатия работают путем нахождения шаблонов в ваших данных, которые могут быть каким-то образом учтены, и благодаря шифрованию теперь их нет; данные полностью несжимаемы.

Сжатие перед шифрованием.


41
Более важно: сжатие добавляет энтропию. Добавление энтропии хорошо для вашего шифрования (сложнее взломать с помощью атак с открытым текстом).
Олли

8
Кроме того, шифрование стоит ресурсов, шифрование меньшего файла потребует меньше ресурсов. Так что сожмите перед шифрованием.
GAThrawn

9
@Olli - не обязательно, если схема сжатия добавляет известный текст. В худшем случае представьте, если он поместил известный заголовок размером 512 байт в начало данных, и вы использовали шифрование в блочном режиме.
Мартин Беккет

26
Я не уверен, почему за комментарий @ Olli проголосовали, так как он неправильный; Мало того, что это значительно менее важно, для любого полуприличного шифрования оно не должно быть вообще важным . То есть сила шифрования должна быть совершенно не связана с энтропией сообщения.
BlueRaja - Дэнни Пфлюгофт

8
Если вы вообще сжимаете, это можно сделать только перед шифрованием сообщения, но имейте в виду, что это может привести к утечке информации о «сжимаемости» исходного сообщения, поэтому вам следует подумать, есть ли какие-либо последствия для этой стороны канал. Рассмотрим файл фиксированного размера, который имеет либо все 0, либо сообщение. Файл all 0 приведет к уменьшению полезной нагрузки при любой разумной схеме сжатия. Однако вряд ли проблема в этом конкретном случае использования.
Эдвард КМЕТТ

22

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

Кроме того, как указывает г-н Альфа, если вы сначала зашифруете, результат будет очень трудно сжать.


12
Ну, это правильно, но было опубликовано за 2 часа до того, как вы опубликовали ... Энтропия
Konerak

3

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

Мы предполагаем, что пользователь отправляет сообщение на сервер, а злоумышленник может добавить текст к сообщению пользователя перед отправкой (например, с помощью javascript). Пользователь хочет отправить некоторые разумные данные на сервер, а злоумышленник хочет получить эти данные. Поэтому он может попытаться добавить разные сообщения к данным, которые пользователь отправляет на сервер. Затем пользователь сжимает свое сообщение и добавленный текст от злоумышленника. Мы предполагаем сжатие DEFLATE LZ77, поэтому функция заменяет ту же информацию указателем на первое появление. Поэтому, если злоумышленник может воспроизвести открытый текст дыры, функция сжатия уменьшает размер простого текста до исходного размера и указателя. А после шифрования злоумышленник может подсчитать количество блоков шифра, чтобы он мог видеть, были ли его добавленные данные такими же, как данные, отправленные пользователем на сервер. Даже если этот случай звучит немного сконструирован, это серьезная проблема безопасности в TLS. Эта идея используется атакой CRIME для утечки файлов cookie в соединении TLS для кражи сеансов.

источник: http://www.ekoparty.org/archive/2012/CRIME_ekoparty2012.pdf


2

Я считаю, что когда вы сжимаете сообщение, вы проецируете его в более низкое измерение, и поэтому в нем меньше битов, что означает, что сжатое сообщение (при условии сжатия без потерь) содержит ту же информацию в меньшем количестве битов (те, которые вы избавились, были избыточны! ) Таким образом, у вас есть больше информации на бит и, следовательно, больше энтропии на бит, но такая же общая энтропия, которая была у вас ранее, когда сообщение не было сжато. Теперь случайность - это другое дело, и именно здесь паттерны сжатия могут бросить гаечный ключ.


1

Сжатие должно быть сделано до шифрования. пользователь не хочет тратить время на ожидание передачи данных, но ему / ей нужно, чтобы это было сделано немедленно, не теряя времени.


1

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


Похоже, это повторение принятых и вторых ответов. Каждый ответ должен дать принципиально новое решение вопроса.
fixer1234

0

Сжатие уменьшает информационную энтропию. Максимальное сжатие делает энтропию минимальной. Для идеально зашифрованных данных (шум) максимальная и минимальная энтропия совпадают.


2
Подожди, разве нет этого назад? Я думал, энтропия увеличилась с уменьшением избыточности. Поэтому сжатие должно увеличить энтропию.
Zan Lynx

Нет, меньше энтропии = больше паттернов. Случайность имеет наибольшую энтропию.
AbiusX

1
Но это информационная энтропия, так что все дело в значении. Случайность ничего не значит, поэтому она не применима. Английское предложение может иметь измененные буквы и все равно означать то же самое, поэтому оно имеет низкую энтропию. Сжатое английское предложение может быть нечитаемым, если один бит изменяется, поэтому он имеет больше всего. Или я так думаю.
Zan Lynx

Энтропия не о смысле и умении читать или понимать, а о моделях. Сжатые файлы полны шаблонов.
AbiusX

1
@AbiusX: Верно. Узоры. И чем меньше шаблонов, тем больше энтропии. Это означает, что сжатие, которое заменяет все повторяющиеся шаблоны одной копией, увеличивает энтропию.
Zan Lynx
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.