Gennadiy UsovПри рассмотрении известных подходов построения блочных шифров нужно отметить следующее:

1)Почему переход с блока 64 на 128 (или более крупный блок) представляет собой событие, если в программе это должно означать просто замену переменной – размер блока?
Просто всем пользователям рассылается новая программа шифрования.

Блоки наращивали свои размеры эволюционно. Тоесть в середина 20-го века хватало 32х бит.
И процессоры имели встроенные регистры именно такой длины. Чуть позже количественный рост
и потребности техники заставили удвоить регистры и как следствие возникла пустая ниша
и потребность просто расширить алгоритм на более широкую сетку. Вам как математику
эти сведененья не интересны ибо длина регистра это нечто техническое. Под капотом.

Но важно отметить что эта потребность была еще и продиктована растущими угрозами
криптоаналитики. Если есть железо и более мощное - то можно предположить что атакующий
будет перебирать 32х разрядные ключи на 64х разрядном регистре в два раза быстрее
используя возможности новых процессоров и систем команд. Тоесть это как-бы гонка
вооружений.

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

Gennadiy Usov2)Есть понятие рассеивание информации и перемешивание информации.
Причем, перемешивание информации более уязвимо, чем рассеивание информации.

Хм. Это Шенноновский термин? "рассеяние". Не помню что это. Надо почитать.

Gennadiy Usov3)Чтобы в блоках не отследить перемешивание информации, необходимо делать перемешивание надблочное, чтобы в блоках были только отдельные символа от слов текста.
А если идти ещё дальше, то делать такое перемешивание, псевдослучайное, чтобы в блоке собирать определенные буквы. Вот только как передать такое, псевдослучайное число?
Это я не понял.

Смотрите. Один из постулатов Керхгофа (насколько я понимаю) - это перенос 100% секретности
в ключ. Сам алгоритм не должен иметь секретов.

Если вам нужно передать некий вектор инициализации (IV) и он увеличивает секретность переписки
даже будучи опубликованным - то публикуйте. Прямо в теле сообщения. Это тоже метод. И это практикуется.

Dima TЯ придумал как быстро узнать ключ при возможности дать на вход что угодно.
Даем на вход блоки


Дальше смотрим где вышла единица после каждого шифрования.
Давайте в топике будем называть этот метод - Метод Бегущего Бита (МББ).
Чуть позже я попробую повоздействовать этим методом на DES и посмотреть
как меняются блоки.

Gennadiy UsovЕсли всё дело в железе, то мне, как математику, не понятно различие скорости шифрования и дешифрования на 64х разрядном регистре для 32х разрядных ключей и 64х разрядных ключей. Неужели обрабатываются сразу 2 блока?
Да. Это старая техника. Называется SIMD https://ru.wikipedia.org/wiki/SIMD

Вкратце. Вместо сложения двух на два 32х разрядных регистров чтобы получить два слагаемых можно
сделать одну SIMD операцию. Над 64х битным регистром просто указать что подразумевается семантика
разделения одного большого 64х битного регистра на 2 по 32.

Или 4 по 16. И также к целочисленному умножению и делению и булевым операциям.

Обычно программисты редко прибегают к Simd напрямую. Чаще эти операции зашиты в библиотеках.

Gennadiy UsovDimitry Sibiryakovпропущено...

Это зависит от алгоритма, но таки да: RSA на 64-х битной арифметике в 2 раза быстрее, чем на 32-х битной за счёт увеличения блока и, как следствие, уменьшения количества операций, необходимых для вычисления результата.Значит, скорость шифрования (дешифрования) зависит только от разрядного регистра и не зависит от разряда ключей и размера блока? Конечно, при одинаковом количестве операций (раундов).
Вы верно рассуждаете. Значит уже читаете литературу по К.

Давайте проведем эксперимент по влиянию бегущего бита.

Я сгенерил 3 файлика. Длиной 16 байт. Заполненный нулями и с включенным ведущим битом. И еще один с соседним битом.
0000-0000-0000-0000.dat
8000-0000-0000-0000.dat
4000-0000-0000-0000.dat

Случайный ключик 0d4a494028f352d6 (binhex)

И три эксперимента с кодером DES(ECB), salt=off.

Посмотрите что получилось. До и после. Пока не комментирую.

Dimitry SibiryakovmaytonПосмотрите что получилось.
Предсказуемо получилось. У DES блок 64 бита, соответственно вторые 64 бита исходного файла, заполненные одними и теми же нулями дали один и тот же криптотекст. Откуда вылезли ещё 64 бита - неясно. Возможно контрольная сумма или ещё какой openssl-ный потрох. У AES блок 128 бит, с ним ты бы получил другую картину.
Где вы видите контрольную сумму?

Есть первые 8 байтов - это и есть шифротекст. Он определённо зависит от исходных данных.
Оставшиеся 16 байтов - константа. Они не зависят от открытого текста.

Кстати обратите внимание на эффект лавины. 1 бит совершенно определённо влияет
на 50% данных всего DES-блока. Рекомендация Шеннона работает. И Димина атака
бегущим битом даёт просто равномерный шум.

Поправка. Первые 16 байт шифротекст. И оставшиеся 8 - хвостик.

Gennadiy UsovА если идти дальше, то с помощью ключа можно так поменять буквы на буквы, что может получиться шифрограмма:

яяяяяяя.ща

или что-то похожее на эту шифрограмму.

И как это для криптоаналитика?

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

Симметричный шифр - биективная функция над блоками.

Ваше яяяяяя - после обратного преобразования превратится во что?