Вопрос по алгоритму ГОСТ 28147-89

Такие вещи зависят от конкретного протокола и реализации (сеансовое, дисковое, многопользовательское шифрование и др.), но практически не зависят от того, какой шифр используется, хоть ГОСТ, хоть AES. Все шифры должны условно считаться неотличимыми от идеальных или выводиться из использования. Из конкретики в случае ГОСТ может быть только учтён размер блока (64 бит) и размер ключа (256 бит).

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

И как часто следует менять ключи учитывая размеры блока и ключа?

От такого размера ключа ничего не зависит, а вот в соответствии с размером блока для всех 64-битных шифров в некоторых режимах шифрования не рекомендуется шифровать более 2³² бит ≈ 1 гигабайт на одном ключе.

unknown, ваши ставки падают. Тут вы писали, что 2³² ≈ 32Гб. Какому из ваших постов верить? :)

Вообще-то, 2³² бит – это 512Мбайт.

Наш Гигабайт, как хотим, так и меряем.

Э, BlowFish'ем в OpenBSD можно шифровать только пол гига? Не, ну это совсем несерьёзно.

Thus even when used with a proper encryption mode (e.g. CBC or OFB), only 2³² x 8 B = 32 GB of data can be safely sent under one key[citation needed]. In practice a greater margin of security is desired, restricting a single key to the encryption of much less data – say a few hundred megabytes. Once that seemed like a fair amount of data, but today it is easily exceeded. If the cipher mode does not properly randomise the input, the limit is even lower.

В вики тоже путаются в показаниях :) В разных работах тоже есть разброс.

Всё легко проясняется.

На самом деле, в старом моём посте верно указан размер, но не правилен расчёт, надо учитывать размер блока не только в показателе степени, но и в множителе: (8 B)•2³² ≈ 32 гиг. Но это самый максимум, если с запасом, то и нескольких сотен мегабайт нежелательно.

Вот здесь посчитали вероятность утечки данных для 64-битных блоков в зависимости от объёма шифруемых данных:

Bytes Acquired	Probability
1 MB = 1'048'576	0.0000000005
16 MB = 16'777'216	0.0000001
128 MB = 134'217'728	0.00001
512 MB = 536'870'912	0.0001
1 GB = 1'073'741'824	0.0005
32 GB = 34'359'738'368	0.39

This weakness of the CBC mode is not essentially new, but it is not so well known. It is being experimented with LASEC. The attack requires a regular personal computer and less than one hour of computations for the 1GB case. Research on other results are in process.

Вот здесь посчитали вероятность утечки данных для 64-битных блоков в зависимости от объёма шифруемых данных:

Для режима CBC? Так ведь в ГОСТе его нет..

На самом деле, в старом моём посте верно указан размер, но не правилен расчёт, надо учитывать размер блока не только в показателе степени, но и в множителе: (8 B)•232 ≈ 32 гиг

Возможно, Вы имеете ввиду 2^30*4*8 бит, что эквивалентно 4-м гигабайтам (гибибайтам)?

Короче, считайте всё в битах на степенях двойки, тогда точно не запутаетесь :) Если 8•2³² бит шифровать нельзя, то Гугл-калькулятор подсказыавет, что это
8 * (2^32) bit = 4.2949673 десятичных гигабайта.

Или всё-таки 8 * 8 * ((2^32) bit) = 34.3597384 десятичных гигабайта. Потому что в показателе имеется в виду количество блоков, а в множителе их размер — 64 бита.

И для режима CFB.

А если использовать более продвинутый режим шифрования (XTS?), то даже малая длина блоков (64) будет не страшна?

XTS стандартизирован только для AES. В линукс-ядре с другими 128-блочными шифрами работает, но выдаёт предупреждение о невозможности проверки тестовых векторов. Можно ли его запустить с 64-блочным шифром — не в курсе. Если в этом режиме необходимы операции с полиномами в GF(2¹²⁸), то скорее всего — никак.

Хорошо, но вопрос был не столько про XTS, сколько в принципе: «Лечится ли эта проблема подбором соответствующего режима шифрования, или единственный способ — увеличивать длину блока?». Наверное, как-то можно продумать шифрование больших блоков данных даже с помощью BlowFish'а, но это поди всё равно бессмысленные костыли будут.

В OpenBSD применяется схема (как впрочем, должен уже быть и XTS), похожая на CBC-ESSIV, которая достаточно безопасна, она и с 64-блочными шифрами должна работать адекватно. Правда, если меняется только IV, но не ключ, то, возможно, от атаки утечки это не защищает.

Применяется ли в дисковом шифровании смена не только IV, но и ключа для дисковых секторов — не знаю. В старых реализациях (loop-AES) такой приём использовался.