id: Гость   вход   регистрация
текущее время 20:48 28/03/2024
Автор темы: ssashas, тема открыта 25/02/2013 16:48 Печать
Категории: криптография, симметричное шифрование, управление ключами
https://www.pgpru.com/Форум/Криптография/ВопросПоАлгоритмуГОСТ28147-89
создать
просмотр
ссылки

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


Здравствуйте, подскажите пожалуйста новичку, как часто следует менять ключ шифрования в алгоритме ГОСТ 28147-89, и определяется ли это какими-либо государственными стандартами РФ.


 
На страницу: 1, 2 След.
Комментарии
— unknown (25/02/2013 17:25, исправлен 25/02/2013 17:55)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

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


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

— ssashas (04/03/2013 14:59)   профиль/связь   <#>
комментариев: 1   документов: 1   редакций: 0
И как часто следует менять ключи учитывая размеры блока и ключа?
— unknown (04/03/2013 15:39, исправлен 04/03/2013 15:39)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

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

— Гость (05/03/2013 23:19)   <#>

unknown, ваши ставки падают. Тут вы писали, что 232 ≈ 32Гб. Какому из ваших постов верить? :)
— Гость (06/03/2013 00:19)   <#>
Вообще-то, 232 бит – это 512Мбайт.
— Гость (06/03/2013 00:21)   <#>
Наш Гигабайт, как хотим, так и меряем.
— Гость (06/03/2013 00:48)   <#>
Э, BlowFish'ем в OpenBSD можно шифровать только пол гига? Не, ну это совсем несерьёзно.
— unknown (06/03/2013 09:49, исправлен 06/03/2013 10:25)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Thus even when used with a proper encryption mode (e.g. CBC or OFB), only 232 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)•232 ≈ 32 гиг. Но это самый максимум, если с запасом, то и нескольких сотен мегабайт нежелательно.


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

Bytes AcquiredProbability
1 MB = 1'048'5760.0000000005
16 MB = 16'777'2160.0000001
128 MB = 134'217'7280.00001
512 MB = 536'870'9120.0001
1 GB = 1'073'741'8240.0005
32 GB = 34'359'738'3680.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.
— Гость (06/03/2013 11:19)   <#>
Вот здесь посчитали вероятность утечки данных для 64-битных блоков в зависимости от объёма шифруемых данных:


Для режима CBC? Так ведь в ГОСТе его нет..
— Гость (06/03/2013 11:25)   <#>
На самом деле, в старом моём посте верно указан размер, но не правилен расчёт, надо учитывать размер блока не только в показателе степени, но и в множителе: (8 B)•232 ≈ 32 гиг


Возможно, Вы имеете ввиду 2^30*4*8 бит, что эквивалентно 4-м гигабайтам (гибибайтам)?
— unknown (06/03/2013 11:36, исправлен 06/03/2013 12:05)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

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


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



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

— Гость (06/03/2013 14:00)   <#>

А если использовать более продвинутый режим шифрования (XTS?), то даже малая длина блоков (64) будет не страшна?
— unknown (06/03/2013 14:21)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
XTS стандартизирован только для AES. В линукс-ядре с другими 128-блочными шифрами работает, но выдаёт предупреждение о невозможности проверки тестовых векторов. Можно ли его запустить с 64-блочным шифром — не в курсе. Если в этом режиме необходимы операции с полиномами в GF(2128), то скорее всего — никак.
— Гость (06/03/2013 14:26)   <#>
Хорошо, но вопрос был не столько про XTS, сколько в принципе: «Лечится ли эта проблема подбором соответствующего режима шифрования, или единственный способ — увеличивать длину блока?». Наверное, как-то можно продумать шифрование больших блоков данных даже с помощью BlowFish'а, но это поди всё равно бессмысленные костыли будут.
— unknown (06/03/2013 15:05)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
В OpenBSD применяется схема (как впрочем, должен уже быть и XTS), похожая на CBC-ESSIV, которая достаточно безопасна, она и с 64-блочными шифрами должна работать адекватно. Правда, если меняется только IV, но не ключ, то, возможно, от атаки утечки это не защищает.

Применяется ли в дисковом шифровании смена не только IV, но и ключа для дисковых секторов — не знаю. В старых реализациях (loop-AES) такой приём использовался.
На страницу: 1, 2 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3