Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 24
png картинками можно обмениваться много где, через всякие имгур.
Однако было бы вполне логично натянутьсову на глобус пиксельный шум на целевую картинку пропорционально. И оно станет менее заметным и привлекающим внимание, особенно если белый станет прозрачным.
Размер шага вычислять или задавать заранее.
PS:
Чем серьёзно дополнить?
Проанализировать вк-сжатие стандартное для jpg, отследив особенности создавать из оригинала фото и шумо-шифровки готовый jpg, который не тронет оптимизатор ВК посчитав картинку уже хорошей. Это правда уже тянет на звездочку(может еще на что) от товарища майора, и возможно запрет на статью об этом на хабре.
Однако было бы вполне логично натянуть
Размер шага вычислять или задавать заранее.
PS:
Чем серьёзно дополнить?
Проанализировать вк-сжатие стандартное для jpg, отследив особенности создавать из оригинала фото и шумо-шифровки готовый jpg, который не тронет оптимизатор ВК посчитав картинку уже хорошей. Это правда уже тянет на звездочку(может еще на что) от товарища майора, и возможно запрет на статью об этом на хабре.
Нет, здесь ничего не поделать. JPG — он сам по себе не loseless, так что при конвертации со 100%-м шансом потеряются исходные байты.
Подтверждаю, сам одно время писал конвертер любого файла в изображение и JPG всегда бил файлы. Его тогда просто не использовал в итоге.
Как решение, можно использовать не все 256 значений цвета, а только 64 значений, которые размазаны от 0 до 255. Получается переизбыток в 4 раза, расстояние между цветами сделает байты «контрастнее» между собой. Так же если за пиксель взять не 1, а 4 пикселя, то есть шанс побороть проблему JPG.
Правда при чтении из него придется усреднять значения, а объем данных станет в 8 раз меньше помещаться.
Конечно это теоретически всё, эксперименты помогут найти лучшее решение и параметры.
Как решение, можно использовать не все 256 значений цвета, а только 64 значений, которые размазаны от 0 до 255. Получается переизбыток в 4 раза, расстояние между цветами сделает байты «контрастнее» между собой. Так же если за пиксель взять не 1, а 4 пикселя, то есть шанс побороть проблему JPG.
Правда при чтении из него придется усреднять значения, а объем данных станет в 8 раз меньше помещаться.
Конечно это теоретически всё, эксперименты помогут найти лучшее решение и параметры.
Спасибо, но я в курсе, что jpg является lossy форматом, но и товарищ майор не раздает плюшки кому попало.
Повторюперефразирую мысль: сделать свой конвертор изображений в jpg, который и сожмет и расположит точки в нужных местах. А иначе звездочку давать неинтересно.
«Вы просто не умеете их готовить» (с)
Для JPG нужно инфу добавлять не в пиксели, а в коэффициенты фурье (если ничего не напутал, давно про JPG читал), которые вычисляются из картинки в момент сжатия.
Т.е. по сути нужно брать алгоритм сжатия JPG и внедряться внутрь него.
Для JPG нужно инфу добавлять не в пиксели, а в коэффициенты фурье (если ничего не напутал, давно про JPG читал), которые вычисляются из картинки в момент сжатия.
Т.е. по сути нужно брать алгоритм сжатия JPG и внедряться внутрь него.
del
шифрование сжатых данныхКакой режим используете? Если ECB, то не надо так =)
Повторное сжатие зашифрованных данныхЗачем? У шифрованных данных высокая энтропия, они практически не сжимаются.
Вычисление MD5-хэша из ключа шифрования для сравнения при дешифрацииЭто зачем? Чтобы убедиться, что ключ верный и всё корректно расшифруется? Тогда лучше используйте HMAC.
Не поленился и посмотрел исходник. С точки зрения и криптографии, и стеганографии то, что Вы сделали — это дно. Простите, ничего личного. Теперь что именно делает Ваше решение дном:
- Генерация AES ключа тупым дополнением его до нужной длинны нулями. Ключ Вы используете из командной строки, на практике это значит буквы+цифры+спецсимволы, то есть такой типичный пароль. Энтропия 26-30 бит приблизительно (ожидаемая, можно конечно упороться и ввести все битики, но я говорю об обычных людях, словарных паролях и прочих вещах из мира реальных пользователей). Кроме того, Вы любезно положили MD5 хэш от ключа в передаваемые данные, что сильно упрощает перебор (не надо много расшифровывать, достаточно сравнить хэши). То, что Вы сделали перебирается существенно более быстро, чем позволяет используемое шифрование. Читайте про key derivation functions;
- Повторюсь про MD5 хэш. Никогда не давайте атакующему путь быстро проверить правильность ключа. Всегда надо строить шифрование так, чтобы надо было выполнить как можно больше действий и только потом узнать все ли правильно получилось. В вашем случае, надо было посчитать хэш от plaintext, добавить этот хэш к plaintext и потом все зашифровать. На проверке — расшифровываем и смотрим совпадают ли хэши. MD5 в качестве хэша тут внезапно ок, поскольку коллизии нас тут не интересуют. HMAC, который советовали выше тут вообще ни при чем;
- AES ECB использовать нельзя. Проблема с ним заключается в том, что его выход сохраняет все статистические свойства входа. Кстати, поэтому он у вас немного сжимается; CBC, CTR или GCM на выходе дают практически белый шум;
- Никогда не стройте безопасность на том, что атакующий не знает алгоритм. Это одна из основных аксиом криптографии;
- Что касается «не трудно понять, что это шифр», то вообще говоря, стеганография — это о том, чтобы скрыть сам факт передачи сообщения. Если по картинке не трудно понять, то, извините, стеганографии не получилось.
А давайте я все эти замечания учту и поправлю код :)
Криптографию Вы поправите легко и просто. Советую PBKDF2+SHA256 c большим числом итераций для key derivation function (KDF), еще можно bcrypt / scrypt. Последние две — более стойкие против атак на GPU, но на практике, любая из этих KDF достаточно хороша. AES советую использовать либо в режиме ECB если надо попроще, либо в режиме CTR или CGM, если надо побыстрее (в counter режимах можно шифровать блоки параллельно). IV — криптографически безопасное случайное число (самый простой источник в питоне — random.SystemRandom().getrandbits), передавайте вместе с шифротекстом. Обратите внимание, в counter режимах нельзя использовать одну и ту же пару ключ-вектор инициализации для двух разных сообщений. Всей вашей безопасности придет кирдык. В GCM кроме всего прочего встроен собственный MAC. Его можно использовать для проверки правильно ли расшифровалось.
Что касается стеганографии, просто «поправить» тут мне кажется не выйдет.
Что касается стеганографии, просто «поправить» тут мне кажется не выйдет.
5-й пункт — краеугольный.
Прочитал пост. Плюсанул за попытку… Всё-таки кодили… Но это совсем не то, что я имел в виду.
Идея была в создании стохастического (не детерменированного) алгоритма, модифицирующего исходное изображение. И тогда можно модифицировать контейнер (картинку) нейронной сетью до тех пор, пока его хеш-код не совпадёт с передаваемым сообщением!
Вот простой туториал, как это делать.
Тогда вместо большой-большой базы данных с котиками нам потребуется ровно столько изображений, сколько каждое из них передает данных.
А то что вы сделали, это не хеш-стеганография… Это вообще не стеганография!!! Это упаковка весьма странного шифротекста в картинку.
Сории за резкость!
Идея была в создании стохастического (не детерменированного) алгоритма, модифицирующего исходное изображение. И тогда можно модифицировать контейнер (картинку) нейронной сетью до тех пор, пока его хеш-код не совпадёт с передаваемым сообщением!
Вот простой туториал, как это делать.
Тогда вместо большой-большой базы данных с котиками нам потребуется ровно столько изображений, сколько каждое из них передает данных.
А то что вы сделали, это не хеш-стеганография… Это вообще не стеганография!!! Это упаковка весьма странного шифротекста в картинку.
Сории за резкость!
Так нигде и не сказано о стеганографии! Кроме ссылки на пост, подсказавший мне эту идею. Вот и всё.
Зачем модифицировать картинку именно нейронной сетью??? Берем 8-12 любых бит картинки модификация которых не сильно скажется на результате, перебираем все возможные комбинации, считаем хэш, находим нужный. Гораздо быстрей чем нейронная сеть и практически никак не отслеживается статистическим анализом при условии отсутствия у злоумышленника оригинала картинки.
Кроме того, если взять какую-нибудь менее стойкую реализацию хэша, например CRC32, то можно буквально вычислить какой бит (или 2 или 3, в зависимости от длинны файла) нужно поменять чтобы получить нужный результат.
Кроме того, если взять какую-нибудь менее стойкую реализацию хэша, например CRC32, то можно буквально вычислить какой бит (или 2 или 3, в зависимости от длинны файла) нужно поменять чтобы получить нужный результат.
Да, есть и такая идея.
Только любые биты нельзя. Нужно те, которые не влияют на статистику стегоаналитического энтропийного анализатора.
Ещё раз. Любое вкрапление в изображение в общем случае может быть обнаружено. Вот очень простой пост об этом: securelist.ru/steganography-in-contemporary-cyberattacks/79090
Только любые биты нельзя. Нужно те, которые не влияют на статистику стегоаналитического энтропийного анализатора.
Ещё раз. Любое вкрапление в изображение в общем случае может быть обнаружено. Вот очень простой пост об этом: securelist.ru/steganography-in-contemporary-cyberattacks/79090
Интересненько, зловреды и до изображений добрались. PavelMSTU, спасибо за ссылку на статью. Теоретическое применение этого обычными преступниками где-то обсуждалась, но вот реальное применение, как-то прозевал.
Этот самый «стегоаналитический энтропийный анализатор» можно где-то скачать?
что б пробежаться по всем картиночкам на компе?
Когда доберутся до gif'ок по 10-100mb которыми любят перекидываться в vk будетнаконец-то их запретитьсовсем не хорошо. Тем более, что у гифок есть свои артефакты которые усложнят анализ.
Этот самый «стегоаналитический энтропийный анализатор» можно где-то скачать?
что б пробежаться по всем картиночкам на компе?
Когда доберутся до gif'ок по 10-100mb которыми любят перекидываться в vk будет
Ну я и написал, любые которые не сильно влияют на картинку.
Я думаю никакой анализатор не найдет отклонение в младших битах пикселя lossless картинки если их будет всего 8-12 на всю картинку. При этом ведь из этих 8-12 бит мы поменяем-то в среднем всего 4-6!!!
ЗЫ: Естественно речь не идет о картинках на которых любое изменение сразу заметно, типа контрастных геометрических узоров. Речь скорее про фотографии и т.п. где и так шума за глаза.
Я думаю никакой анализатор не найдет отклонение в младших битах пикселя lossless картинки если их будет всего 8-12 на всю картинку. При этом ведь из этих 8-12 бит мы поменяем-то в среднем всего 4-6!!!
ЗЫ: Естественно речь не идет о картинках на которых любое изменение сразу заметно, типа контрастных геометрических узоров. Речь скорее про фотографии и т.п. где и так шума за глаза.
Вся суть стеганографии потерялась же.
Осталось обычное шифрование, только зачем-то обернутое в изображение.
Осталось обычное шифрование, только зачем-то обернутое в изображение.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Стойкое шифрование данных в PNG