Стойкое шифрование данных в PNG

[TrllServ]

png картинками можно обмениваться много где, через всякие имгур.
Однако было бы вполне логично натянуть сову на глобус пиксельный шум на целевую картинку пропорционально. И оно станет менее заметным и привлекающим внимание, особенно если белый станет прозрачным.
Размер шага вычислять или задавать заранее.

PS:
Чем серьёзно дополнить?
Проанализировать вк-сжатие стандартное для jpg, отследив особенности создавать из оригинала фото и шумо-шифровки готовый jpg, который не тронет оптимизатор ВК посчитав картинку уже хорошей. Это правда уже тянет на звездочку(может еще на что) от товарища майора, и возможно запрет на статью об этом на хабре.

[sdore]

Нет, здесь ничего не поделать. JPG — он сам по себе не loseless, так что при конвертации со 100%-м шансом потеряются исходные байты.

[SystemXFiles]

Подтверждаю, сам одно время писал конвертер любого файла в изображение и JPG всегда бил файлы. Его тогда просто не использовал в итоге.

Как решение, можно использовать не все 256 значений цвета, а только 64 значений, которые размазаны от 0 до 255. Получается переизбыток в 4 раза, расстояние между цветами сделает байты «контрастнее» между собой. Так же если за пиксель взять не 1, а 4 пикселя, то есть шанс побороть проблему JPG.

Правда при чтении из него придется усреднять значения, а объем данных станет в 8 раз меньше помещаться.

Конечно это теоретически всё, эксперименты помогут найти лучшее решение и параметры.

[sdore]

Делал где-то в середине написания сего чуда. Аж в 8 раз апскейлил. Не помогло. Насчёт цвета — теряется компактность. А ещё, учитывая, что PNG так широко распространён, да и

png картинками можно обмениваться много где, через всякие имгур

можно просто использовать его.

[TrllServ]

Спасибо, но я в курсе, что jpg является lossy форматом, но и товарищ майор не раздает плюшки кому попало.
Повторюперефразирую мысль: сделать свой конвертор изображений в jpg, который и сожмет и расположит точки в нужных местах. А иначе звездочку давать неинтересно.

[Psychosynthesis]

Вроде бы ВК даже готовый JPG пережимает, так что врядли получится.

[Error1024]

У товарища майора щас поболее других проблем, чем докапываться до шифрования jpg в ВК.

[Sklott]

«Вы просто не умеете их готовить» (с)
Для JPG нужно инфу добавлять не в пиксели, а в коэффициенты фурье (если ничего не напутал, давно про JPG читал), которые вычисляются из картинки в момент сжатия.
Т.е. по сути нужно брать алгоритм сжатия JPG и внедряться внутрь него.

[SystemXFiles]

del

[Ocelot]

шифрование сжатых данных

Какой режим используете? Если ECB, то не надо так =)

Повторное сжатие зашифрованных данных

Зачем? У шифрованных данных высокая энтропия, они практически не сжимаются.

Вычисление MD5-хэша из ключа шифрования для сравнения при дешифрации

Это зачем? Чтобы убедиться, что ключ верный и всё корректно расшифруется? Тогда лучше используйте HMAC.

[YourChief]

Да, в конструкторе Crypto.Cipher.AES используется режим по умолчанию, который равен MODE_ECB. Это очень грустно.

[Kirillius]

Не поленился и посмотрел исходник. С точки зрения и криптографии, и стеганографии то, что Вы сделали — это дно. Простите, ничего личного. Теперь что именно делает Ваше решение дном:

1. Генерация AES ключа тупым дополнением его до нужной длинны нулями. Ключ Вы используете из командной строки, на практике это значит буквы+цифры+спецсимволы, то есть такой типичный пароль. Энтропия 26-30 бит приблизительно (ожидаемая, можно конечно упороться и ввести все битики, но я говорю об обычных людях, словарных паролях и прочих вещах из мира реальных пользователей). Кроме того, Вы любезно положили MD5 хэш от ключа в передаваемые данные, что сильно упрощает перебор (не надо много расшифровывать, достаточно сравнить хэши). То, что Вы сделали перебирается существенно более быстро, чем позволяет используемое шифрование. Читайте про key derivation functions;
2. Повторюсь про MD5 хэш. Никогда не давайте атакующему путь быстро проверить правильность ключа. Всегда надо строить шифрование так, чтобы надо было выполнить как можно больше действий и только потом узнать все ли правильно получилось. В вашем случае, надо было посчитать хэш от plaintext, добавить этот хэш к plaintext и потом все зашифровать. На проверке — расшифровываем и смотрим совпадают ли хэши. MD5 в качестве хэша тут внезапно ок, поскольку коллизии нас тут не интересуют. HMAC, который советовали выше тут вообще ни при чем;
3. AES ECB использовать нельзя. Проблема с ним заключается в том, что его выход сохраняет все статистические свойства входа. Кстати, поэтому он у вас немного сжимается; CBC, CTR или GCM на выходе дают практически белый шум;
4. Никогда не стройте безопасность на том, что атакующий не знает алгоритм. Это одна из основных аксиом криптографии;
5. Что касается «не трудно понять, что это шифр», то вообще говоря, стеганография — это о том, чтобы скрыть сам факт передачи сообщения. Если по картинке не трудно понять, то, извините, стеганографии не получилось.

[sdore]

А давайте я все эти замечания учту и поправлю код :)

[Kirillius]

Криптографию Вы поправите легко и просто. Советую PBKDF2+SHA256 c большим числом итераций для key derivation function (KDF), еще можно bcrypt / scrypt. Последние две — более стойкие против атак на GPU, но на практике, любая из этих KDF достаточно хороша. AES советую использовать либо в режиме ECB если надо попроще, либо в режиме CTR или CGM, если надо побыстрее (в counter режимах можно шифровать блоки параллельно). IV — криптографически безопасное случайное число (самый простой источник в питоне — random.SystemRandom().getrandbits), передавайте вместе с шифротекстом. Обратите внимание, в counter режимах нельзя использовать одну и ту же пару ключ-вектор инициализации для двух разных сообщений. Всей вашей безопасности придет кирдык. В GCM кроме всего прочего встроен собственный MAC. Его можно использовать для проверки правильно ли расшифровалось.
Что касается стеганографии, просто «поправить» тут мне кажется не выйдет.

[sdore]

Не раз уже отвечал, что стеганографии здесь не планировалось изначально. Остальное на днях поменяю, обновлю в репозитории.

[Chumicheff]

5-й пункт — краеугольный.

[PavelMSTU]

Прочитал пост. Плюсанул за попытку… Всё-таки кодили… Но это совсем не то, что я имел в виду.

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

Вот простой туториал, как это делать.

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

А то что вы сделали, это не хеш-стеганография… Это вообще не стеганография!!! Это упаковка весьма странного шифротекста в картинку.

Сории за резкость!

[sdore]

Так нигде и не сказано о стеганографии! Кроме ссылки на пост, подсказавший мне эту идею. Вот и всё.

[Sklott]

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

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

[PavelMSTU]

Да, есть и такая идея.
Только любые биты нельзя. Нужно те, которые не влияют на статистику стегоаналитического энтропийного анализатора.

Ещё раз. Любое вкрапление в изображение в общем случае может быть обнаружено. Вот очень простой пост об этом: securelist.ru/steganography-in-contemporary-cyberattacks/79090

[TrllServ]

Интересненько, зловреды и до изображений добрались. PavelMSTU, спасибо за ссылку на статью. Теоретическое применение этого обычными преступниками где-то обсуждалась, но вот реальное применение, как-то прозевал.
Этот самый «стегоаналитический энтропийный анализатор» можно где-то скачать?
что б пробежаться по всем картиночкам на компе?

Когда доберутся до gif'ок по 10-100mb которыми любят перекидываться в vk будет наконец-то их запретитьсовсем не хорошо. Тем более, что у гифок есть свои артефакты которые усложнят анализ.

[Sklott]

Ну я и написал, любые которые не сильно влияют на картинку.
Я думаю никакой анализатор не найдет отклонение в младших битах пикселя lossless картинки если их будет всего 8-12 на всю картинку. При этом ведь из этих 8-12 бит мы поменяем-то в среднем всего 4-6!!!

ЗЫ: Естественно речь не идет о картинках на которых любое изменение сразу заметно, типа контрастных геометрических узоров. Речь скорее про фотографии и т.п. где и так шума за глаза.

[Named]

Вся суть стеганографии потерялась же.
Осталось обычное шифрование, только зачем-то обернутое в изображение.