Не могу правильно разработать алгоритм

просто зашифруй его как угодно, лол

Что в твоем понимании «зашифровать»?

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

openssl enc -in … -aes-256-cbc -pass stdin >…

Инфу прятать в изображении не надо. Насчет цвета пикселей. У нас есть строка-ключ - «secret_key», x, y координаты пикселей и RGB пикселя (0-255). И я думаю как это консолидировать для моей задачи

openssl enc -in … -aes-256-cbc -pass stdin >…

И как это превратит изображение в визуальный мусор?

а во что по-твоему это его превратит?

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

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

ну так хедер можно заново прилепить, например .bmp проще всего

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

Аааа, я понял, вы предлагаете не по пикселям менять, а сразу все байтовое тело изображения (но без хедеров). А оно вообще откроется?

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

так разницы никакой, вопрос в том, откроется ли в редакторе закодированное?

откроется ли в редакторе закодированное?

а зачем в редакторе закодированное открывать

Чтобы увидеть визуальный мусор.

ну можно шифровать после заголовка, а не целиком

только зачем смотреть на визуальный мусор? )

для несжатых форматов (bmp) прокатит без проблем, для сжатых JPG, PNG и прочих не прокатит

Чтобы другому человеку было понятно что это в принципе изображение и оно может быть дешифровано

gimp может открывать raw файлы без хедеров (даётся выбор формата пикселей)

для несжатых форматов (bmp) прокатит без проблем, для сжатых JPG, PNG и прочих не прокатит

вот проблемка

«визуальный мусор» всё равно почти не жмётся

для lossless прокатит же

Ватермарк «enсrypted» добавь.

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

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

сначала цветовая метка потом строка потом цветовая инфориация.

для сжатых JPG, PNG и прочих не прокатит

Это с какого перепугу? Если XOR-ить непосредственно DCT-коэффициенты и чанки, то самое то.

Может вернуться к попиксельному изменению?

они же Хаффманом потом жмутся, как оно зашифрованное распакует

Можно. Всё равно извлекать придётся для попиксельного. Это уже детали алгоритма

Хотелось бы услышать здравые идеи.

Кроме очевидного первого правила криптографии? Первый коммент глянь.

«ключом» генерится матрица такого-же размера как изображение, потом старый добрый XOR :-)

Мусор непременно должен быть визуальным? Или всё-таки контейнер не обязательно должен быть изображением?
Тогда упаковка архиватором с паролем тоже подходит под условия задачи.

как оно зашифрованное распакует

Как сожмёт, так и распакует. По Хаффману.

понятно что это

Скриншот /dev/random

и оно может быть дешифровано

В исходное состояние ГПСЧ

Кроме очевидного первого правила криптографии?

Не изобретать велосипед?

эх, лор уже не торт

https://imagemagick.org/script/cipher.php

https://imgur.com/a/3OCf7w9

А, ты спрашивал про алгоритм. Ну вот тогда: https://github.com/ImageMagick/ImageMagick/blob/master/MagickCore/cipher.c

Ого, не знал что есть такое уже готовое

Какие варианты можно придумать?

Чем тебя обычные алгоритмы шифрования не устроили? Ну а так вообще, по ключу генерируй псевдорандом и делай xor с картинкой.

почему для шифрования должна быть какая-то разница

Для хорошего шифрования без разницы. А если тупо коротким ключом xor-ить то будет видно паттерн, да и вообще изображение не особо «зашифруется».

То что ты изобретаешь, называется стеганография. Для jpg картиночек и mp3 файликов обычно делается в частотном пространстве, а не с «перемешиванием писелей».

Кстати кто нибудь посоветуйте годные мануалы по PIL. Ничего толком не находится.

Нет, стеганография когда незаметно, а у автора:

Задача в том чтобы каким-то образом превратить изображение по ключу в визуальный мусор

Чувак хочет мусор. Если AES, то нужно озаботится режимом шифрования. Т.к. на ECB будут видны контуры изображения. Но это для bmp актуально, если там какое-то сжатие у изображения, то не знаю.

То что делает любой алгоритм шифрования - переставляет биты в последовательности битов. Картинка -> пикселы -> цвета -> биты. Только при сохранении картинки используй lossless форматы

Вот пример. Картинка проксоренная по трем цветам отдельно. Видны контуры, восстановить в исходную теоретически возможно если знать степень сжатия и аргументы искл. ИЛИ.

http://xofficer.ru/images/output.jpeg

У него документация есть.

Главный вопрос. Какой формат хранения изображения будет использоваться? От этого и можно будет начинать думать про варианты.

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

А формат в любом случае - truecolor

Не всегда. ТС не уточнил пока формат.