Как оперирует SHA-512 в блочных шифрах с блоком менее 512 бит?
В большенстве блочных шифрах, размер блока 128 бит.
Если пароль хеширован SHA-512, выходное значение 512 бит.
Как выходное значение в 512 бит, работает в блочном шифре, где размер блока данных 128 бит?
384 Отбрасываются? Или 512 \ 4 и каждый 4й блок имеет свой ключ?
Не понял, с какой радости хэш-функция должна оперировать в блочных шифрах?
Вопрос относится к PGP? Тогда всё лишнее отбрасывается. Это вообще общепринятый подход. Дополнительно смотрите здесь[link1].
Вопрос видимо стоит так, что при шифровании блочным шифром любой информации в качестве ключа используется хеш-значение от введенного пароля. Скорее здесь вопрос нужно поставить иначе. 128 бит это блоки шифрумой информации (текста, файла), а в качестве ключа для шифра действительно используется хеш-значение от введенного пароля, причем насколько я знаю после неоднокртаных преобразований. Каким образом значение хеш функции приводится к значению размера ключа не могу ответить. Видимо подбором определенной хеш-функции или каким-либо преобразованием для приведения значения к стандартному значению.
1). По приведённой SATtv'ой ссылке я врубился. А если применять SHA-512 в Twofish например, то все лишние 256 бит тоже отбрасываются?
2). А какой смысл применять SHA-1 в 256-битовых блочных шифрах, ведь реальная стойкость SHA-1 80 бит, при нападении целесообразно тогда ломать хеш-функцию.
3). Применение SHA-512 даёт большую безопасность при атаках перебором нежели SHA-256 в 256-битовых блочных шифрах?
Да.
80 бит — это коллизионная стойкость. Эта характеристика не имеет значения в случаях применения алгоритмов хэширования для повышения энтропии пользовательского ввода (как в S2K). Здесь значима только длина выходного значения и равное распределение энтропии по всей длине выхода.
Вообще механизмы S2K (хэширование пароля в ключ) — это только подспорье для пользователя. В идеальном случае ключевой материал должен быть изначально получен из надёжного ГСЧ и именно в таком виде подаваться на вход шифровального алгоритма.
Никакой разницы, поскольку атаковать будут ключ шифра, а не выходное значение хэш-функции. Да и в любом случае вряд ли найдёте сумасшедший, который решит заняться полным перебором 256-битового шифровального ключа[link2].
В своё время были теоретические споры: как лучше укорачивать выход хэш-функции?
Например для преобразования {0,1}128 <– {0,1}512
предлагалось разделить выход хэш-функции на 4 части и объединить их значением XOR:
{0,1}128 <– part1{0,1}128 XOR part2{0,1}128 XOR part3{0,1}128 XOR part4{0,1}128 <– split: ( part1{0,1}128 || part2{0,1}^^128^^ || part3{0,1}128 || part4{0,1}128 ) <– {0,1}512
Но затем такую схему посчитали избыточной и доказали, что простое отбрасывание лишних битов даёт даже более стойкий результат.
По идее можно иметь хэш-функцию размером 512-бит на все случаи жизни и при необходимости укорачивать. Но для экономии вычислений, там где это критично, используется семейство функций SHA с уже заложенной разной длиной выхода.
При вычислении ключа из пароля вычисления не экономят, количество затраченных операций наоборот стараются увеличить для замедления перебора, поэтому используют хэш-функцию с самым большим выходом.