И что?

нтфс он вроде прддерживает

Ещё скорее всего придётся загрузчик виндовый менять

Атака padding oracle актуальна для тех режимов с выравниванием (паддингом), в которых есть возможность, воздействуя на шифротекст, контролируемо изменять открытый текст (кроме того, нужен оракул корректности выравнивания)


В режиме ctr выравнивание, как правило, не используется. Но если его реализовать, то атака padding oracle будет актуальна, т.к. воздействуя на последний байт шифротекста, мы напрямую изменяем последний байт открытого текста, а узнав его через оракула, вычисляем последний байт гаммы. Процесс затем повторяется для предпоследнего байта и т.д.

Да, я понимаю, как это работает: ВИ можно считать публичным уникальным продолжением пароля, который вводит пользователь.

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

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

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

Да, я это учел

Спасибо, однако у меня ещё два с половиной вопроса:
0) под выравниванием подразумевается дополнение самого последнего блока открытого текста до полного блока, да?
0.1) а что если самый последний блок открытого текста дополнить нулями (0x00) или каким-то мусором, а потом в отдельном - дополнительном, служебном - блоке зашифровать действительную длину сообщения или последнего блока? Это поможет противодействовать такой атаке?
1) как оракул может дать ответ, если злоумышленник по определению не знает ключ шифрования и не может его передать оракулу, чтобы оракул что-то вернул злоумышленнику в ответ?

0) да. Очевидно, что для ctr режима, по сути превращающего блочный шифр в потоковый, выравнивание не требуется, лишние байты гаммы можно просто отбросить.

Также в зависимости от алгоритма выравнивания, к полному блоку добавляется ещё один блок, блок выравнивания. Это делается для избежания неоднозначности при снятии выравнивания (н-р. 01 - это последний байт полного блока данных  или байт выравнивания?).

0.1) если есть оракул корректности выравнивания (в т.ч. через взаимодействие с шифруемым протоколом) и возможность предсказуемо влиять на открытый текст через манипуляции с закрытым текстом (т.н. malleability), то длину сообщения, на мой взгляд, удастся узнать. Лучший способ защититься от атаки - использовать аутентификацию сообщения / имитовставку. ETM, GCM и т.д.
1) оракул в данном случае отвечает, корректно ли выравнивание открытого текста. На некоторые байты открытого текста атакующий может влиять через манипуляции с шифротекстом (чего он не сможет делать при аутентификации сообщения). Понимая, какой шифротекст соответствует открытому тексту с выравниванием 01, 0202, 030303 и т.д., атакующий, в зависимости от используемого режима блочного шифра, узнает байты открытого текста или гаммы.

>В режиме ctr выравнивание, как правило,
>не используется.

До меня только сейчас дошёл смысл Ваших слов: можно ведь просто обрезать гамму по длине последнего неполного блока открытого текста, ничем его не дополняя! Нет padding'а - нет и padding oracle-атаки 😁😂

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

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

Добрый вечер! Решил-таки рассказать о своей "вундрвафле", которую сподобился "выдумать" (на самом деле вспомнил на новый лад давно прочитанное и забытое). Получился блочный шифр в режиме CTR (режим гаммирования; со счётчиком). Область применения шифра: переписка, например, по электронной почте. То есть, там, где не требуется шифровать мегабиты в секунду, так как в качестве ГПСЧ взята хеш-функция SHA256 (но можно использовать и любую другую функцию, которая устойчива против атаки нахождения прообраза).


Порядок шифрования такой:
0) сжимаем открытый текст алгоритмом сжатия без потерь (Хаффмана, Шенона-Фано или каким-то другим).
1) вычисляем хеш сжатого текста и дописываем этот хеш в конце сжатого текста.
2) генерируем 256-битный одноразовый вектор инициализации (ВИ, синхропосылка) и записываем его в файл, где будет сохранён шифротекст.
3) дописываем ВИ _после_ (не перед, а именно _после_) длинной парольной фразы, которую ввёл пользователь.
4) хешируем сцепку из предыдущего пункта №3. Это будет начальное (нулевое) значение нашего 256-битного счётчика.
5) увеличиваем счётчик на единицу.
6) хешириуем новое значение счётчика, которое вычислили в предыдущем пункте №5.
7) складываем по модулю двойки (xor) 256-битный хеш, полученный в предыдущем пункте №6, с 256-битным блоком открытого текста.
8) записываем зашифрованый текст, полученый в предыдущем пункте №7, в файл (т.е., сразу после ВИ).

Для каждого блока открытого текста повторяем пункт с пятого по восьмой включительно. Если последний блок открытого текста меньше 256 бит, то 256-битную гамму, которая уже вычислена для него в пункте №6, "обрезаем" по фактической длине последнего неполного блока открытого текста.

9) по желанию в конец файла, в котором сохранён шифротекст, можно ещё дописать хеш шифротекста.

Требование к ВИ: если разные сообщения зашифровываются один и тем же постоянным паролем, то ВИ обязательно должен быть уникальным (неповторяющимся, одноразовым) для каждого сообщения.

Стойкость шифра сопоставима со стойкостью хеш-функции против атаки восстановления прообраза по известному хешу.

ну удачи обосновать пользу внедрения очередного медленного алгоритма не проверенного временем и без киллер фичи чтобы был реализован в куче имейл клиентов. даже тот же gpg и тот не везде реализован

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

думаю не появилось

Спасибо.

Разобраться бы с существующими атакам, а то так ничего и не вышло

А зачем вам использовать MD4 в 21 веке? Или это учебное задание?

Идея интересная.
Подобное уже пытались делать:
https://crypto.stackexchange.com/questions/1703/a-simple-block-cipher-based-on-the-sha-256-hash-function
Только там ключ не догадались инкрементировать при переходе на следующий блок.
Также была идея Фила Карна по созданию блочного шифра на основе MD5, но там тоже без инкрементации ключа.
Попробуйте самостоятельно реализовать алгоритм на каком нибудь языке, например на Java и заодно провести крипто анализ.
Попробуйте исследовать ГПСЧ на основе хеша от счетчика на тестах типа DieHard и TestU01.
Также можно попробовать создать Rainbow table для хэш функции. Практически это можно использовать  только для слабого пароля или же для случайного попадания.
Вместо хеширования вектора инициализации и парольной фразы можно использовать хеширование вектора инициализации и хеша от пароля.
То есть, типа:
Counter = Hash1(salt1 +  Hash2(salt2 + password) + IV);
Где salt1, salt2 соли инфраструктуры, если можно так сказать

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

Вычислять начальное значение счётчика можно, действительно, по-разному, так как сила этого и любого другого потокового шифра заключается не столько в процедуре выработки ключа из пароля, сколько в самом ГПСЧ, гамму которого потом ксорят с открытым текстом. В том виде, как его "придумал" я, злоумышленнику придётся найти только два прообраза: по хешу для блока и по хешу сцепки парольной фразы с ВИ. А в Вашем варианте, конечно, посложнее, так как парольная фраза хешируется не один, а больше раз.