Здесь написано
Feruzbek Dilmurodov

Спасибо большое

Если я правильно понимаю, для фиксированного ключа i-тый бит блока открытого текста всегда будет вставать в j-тую позицию блока шифротекста. В таком случае возможна CCA-атака в два этапа. Сначала определяем i и j, затем запрашиваем у оракула расшифровку нужного шифротекста с инвертированным (flipped) j-тым битом. У полученного открытого текста инвертируем i-твй бит, и мы великолепны.

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

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

Спасибо за вопрос, кстати.

Я по работе сейчас далёк от внутреннего устройства криптографических примитивов, Ваши вопросы заставляют актуализировать знания и представления. Продолжайте в том же духе.

>Продолжайте в том же духе.

Вот если бы от этого "продолжания" был ещё хоть какой-то толк. :-)

Ну смотрите, перестановка у вас уже есть (за исключением порождения перестановки из ключа). Добавьте подстановку и можно собирать SP-сеть.

Ещё необходимо добавить, что размер блока в 56 бит маловат для использования в интернете вследствие парадокса дней рождения. Подробнее

http://rdvlivefromtokyo.blogspot.com/2019/11/22-birthday-paradox-or-when-should-i.html?m=1

>для фиксированного ключа
Подразумевается одинаковый ключ для всех блоков открытого текста? Если да, то даже мне это кажется весьма стрёмным (правда, я не смогу толком объяснить, почему). Целесообразнее, на мой взгляд, из ключа для каждого блока генерировать новый номер перестановки.

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

Вот если бы заменить лексикографический порядок на что-то более секурное и быстрое!

Во-первых, замечу, что лексикографический порядок я упомянул только потому, что других способов генерации перестановок я попросту не знаю.
Во-вторых, 56 бит были выбраны так: с одной стороны здесь в течении наверное апреля не без моего активного участия упоминался потоковый шифр, в котором использована  хеш-функция SHA-256 в качестве ГПСЧ. И эти 256-битные ключи у меня постоянно вертятся в голове. С другой стороны 56! - это не только 248,65 бит, но и семь полновесных восьмибитных байтов.

Я бы вставил перестановку перед наложением гаммы, но нужно что- посерьёзнее, чем алгоритм Нарайяны.

Я бы вставил перестановку ПОСЛЕ наложения гаммы

Здравствуйте. Подскажите, пожалуйста, есть ли возможность в видео h264 заменить исходные I-кадры на новые I-кадры, с сохранением других (P, B) кадров?

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

FR>Вот если бы заменить лексикографический порядок на FR>что-то более секурное и быстрое!

B, что Вы можете сказать про многомерную перестановку по кубику Рубика (конец страницы http://www.univer.omsk.su/omsk-old/Edu/infpro/1/kodir/metper.html)?

vb, ps скрипты как вариант

Но файл так или иначе присутствует

не обязательно

например, в powershell iex DownloadString

Скорее всего да, но у тебя же тогда картинка побьётся

I-фрейм это, насколько я помню, опорный кадр от которого идёт дельта-кодирование последующих