Здравствуйте, подскажите пожалуйста новичку, как часто следует менять ключ шифрования в алгоритме ГОСТ 28147-89, и определяется ли это какими-либо государственными стандартами РФ.
Такие вещи зависят от конкретного протокола и реализации (сеансовое, дисковое, многопользовательское шифрование и др.), но практически не зависят от того, какой шифр используется, хоть ГОСТ, хоть AES. Все шифры должны условно считаться неотличимыми от идеальных или выводиться из использования. Из конкретики в случае ГОСТ может быть только учтён размер блока (64 бит) и размер ключа (256 бит).
Если предположить, что в стандартах на этот счёт может быть другое мнение (насчёт чего совершенно не в курсе), то было бы интересно узнать, чем оно обосновано.
— ssashas (04/03/2013 14:59) И как часто следует менять ключи учитывая размеры блока и ключа?
От такого размера ключа ничего не зависит, а вот в соответствии с размером блока для всех 64-битных шифров в некоторых режимах шифрования не рекомендуется шифровать более 232 бит ≈ 1 гигабайт на одном ключе.
— Гость (05/03/2013 23:19)
> не рекомендуется шифровать более 232 бит ≈ 1 гигабайт
unknown, ваши ставки падают. Тут[link1] вы писали, что 232 ≈ 32Гб. Какому из ваших постов верить? :)
— Гость (06/03/2013 00:19) Вообще-то, 232 бит – это 512Мбайт.
— Гость (06/03/2013 00:21) Наш Гигабайт, как хотим, так и меряем.
— Гость (06/03/2013 00:48) Э, BlowFish'ем в OpenBSD можно шифровать только пол гига? Не, ну это совсем несерьёзно.
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.
В вики[link2] тоже путаются в показаниях :) В разных работах тоже есть разброс.
Всё легко проясняется.
На самом деле, в старом моём посте верно указан размер, но не правилен расчёт, надо учитывать размер блока не только в показателе степени, но и в множителе: (8 B)•232 ≈ 32 гиг. Но это самый максимум, если с запасом, то и нескольких сотен мегабайт нежелательно.
Вот здесь[link3] посчитали вероятность утечки данных для 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.
— Гость (06/03/2013 11:19)
Вот здесь посчитали вероятность утечки данных для 64-битных блоков в зависимости от объёма шифруемых данных:
Для режима CBC? Так ведь в ГОСТе его нет..
— Гость (06/03/2013 11:25)
На самом деле, в старом моём посте верно указан размер, но не правилен расчёт, надо учитывать размер блока не только в показателе степени, но и в множителе: (8 B)•232 ≈ 32 гиг
Возможно, Вы имеете ввиду 2^30*4*8 бит, что эквивалентно 4-м гигабайтам (гибибайтам)?
Короче, считайте всё в битах на степенях двойки, тогда точно не запутаетесь :) Если 8•232 бит шифровать нельзя, то Гугл-калькулятор подсказыавет, что это
8 * (2^32) bit = 4.2949673 десятичных гигабайта.
Или всё-таки 8 * 8 * ((2^32) bit) = 34.3597384 десятичных гигабайта. Потому что в показателе имеется в виду количество блоков, а в множителе их размер — 64 бита.
>Для режима CBC? Так ведь в ГОСТе его нет..
И для режима CFB.
— Гость (06/03/2013 14:00)
>> Для режима CBC?
> И для режима CFB.
А если использовать более продвинутый режим шифрования (XTS?), то даже малая длина блоков (64) будет не страшна?
— unknown (06/03/2013 14:21) XTS стандартизирован только для AES. В линукс-ядре с другими 128-блочными шифрами работает, но выдаёт предупреждение о невозможности проверки тестовых векторов. Можно ли его запустить с 64-блочным шифром — не в курсе. Если в этом режиме необходимы операции с полиномами в GF(2128), то скорее всего — никак.
— Гость (06/03/2013 14:26) Хорошо, но вопрос был не столько про XTS, сколько в принципе: «Лечится ли эта проблема подбором соответствующего режима шифрования, или единственный способ — увеличивать длину блока?». Наверное, как-то можно продумать шифрование больших блоков данных даже с помощью BlowFish'а, но это поди всё равно бессмысленные костыли будут.
— unknown (06/03/2013 15:05) В OpenBSD применяется схема (как впрочем, должен уже быть и XTS), похожая на CBC-ESSIV, которая достаточно безопасна, она и с 64-блочными шифрами должна работать адекватно. Правда, если меняется только IV, но не ключ, то, возможно, от атаки утечки это не защищает.
Применяется ли в дисковом шифровании смена не только IV, но и ключа для дисковых секторов — не знаю. В старых реализациях (loop-AES) такой приём использовался.
— Гость (16/03/2013 08:53) CBC-ESSIV, XTS.. Господа, вы отвлекаетесь) ГОСТ 28147-89 определяет только 4 режима работы: ECB, CM, CFB и MAC. Все что иное – уже не ГОСТ)
— Гость (17/03/2013 01:09)
ГОСТ 28147-89 определяет только 4 режима работы: ECB, CM, CFB и MAC
На этом форуме слабый хромой поломанный нагнутый натянутый опущенный ГОСТ никого не интересует. :)
— Гость (17/03/2013 10:13)
На этом форуме слабый хромой поломанный нагнутый натянутый опущенный ГОСТ никого не интересует. :)
И это вы говорите в теме с таким названием...))
— Гость (17/03/2013 19:26)
И это вы говорите в теме с таким названием
Здесь темы даже про винду есть, и что с того?
— unknown (17/03/2013 20:44) Да ладно, сделан классически, в учебных целях объяснять на нём с чего начинались блочные шифры удобнее чем на DES.
— Гость (17/03/2013 21:57)
Здесь темы даже про винду есть, и что с того?
А то, что если ЧТО-ТО обсуждается, значит это кого-то интересует ;)
Тем более, что текущий опрос показывает, что Windows не используют лишь треть респондентов.
P.S. Ах да, я ошибся, RFC 4357 описывает CBC-режим для ГОСТ 28147-89.
— Гость (17/03/2013 22:25)
Да ладно, сделан классически, в учебных целях объяснять на нём с чего начинались блочные шифры удобнее чем на DES.
unknown, а у вас есть опыт преподавания курса криптографии в вузе? :))
— Гость (17/03/2013 22:28) В некоторых приложениях, таких как ViPNet, сессионный ключ каждый раз генерируется для отдельного пакета. Непонятно зачем так сделано, ведь кроме уменьшения скорости работы это ничего не дает.
— unkonwn (18/03/2013 01:25)
unknown, а у вас есть опыт преподавания курса криптографии в вузе? :))
Такие вещи зависят от конкретного протокола и реализации (сеансовое, дисковое, многопользовательское шифрование и др.), но практически не зависят от того, какой шифр используется, хоть ГОСТ, хоть AES. Все шифры должны условно считаться неотличимыми от идеальных или выводиться из использования. Из конкретики в случае ГОСТ может быть только учтён размер блока (64 бит) и размер ключа (256 бит).
Если предположить, что в стандартах на этот счёт может быть другое мнение (насчёт чего совершенно не в курсе), то было бы интересно узнать, чем оно обосновано.
И как часто следует менять ключи учитывая размеры блока и ключа?
От такого размера ключа ничего не зависит, а вот в соответствии с размером блока для всех 64-битных шифров в некоторых режимах шифрования не рекомендуется шифровать более 232 бит ≈ 1 гигабайт на одном ключе.
unknown, ваши ставки падают. Тут[link1] вы писали, что 232 ≈ 32Гб. Какому из ваших постов верить? :)
Вообще-то, 232 бит – это 512Мбайт.
Наш Гигабайт, как хотим, так и меряем.
Э, BlowFish'ем в OpenBSD можно шифровать только пол гига? Не, ну это совсем несерьёзно.
В вики[link2] тоже путаются в показаниях :) В разных работах тоже есть разброс.
Всё легко проясняется.
На самом деле, в старом моём посте верно указан размер, но не правилен расчёт, надо учитывать размер блока не только в показателе степени, но и в множителе: (8 B)•232 ≈ 32 гиг. Но это самый максимум, если с запасом, то и нескольких сотен мегабайт нежелательно.
Вот здесь[link3] посчитали вероятность утечки данных для 64-битных блоков в зависимости от объёма шифруемых данных:
Для режима CBC? Так ведь в ГОСТе его нет..
Возможно, Вы имеете ввиду 2^30*4*8 бит, что эквивалентно 4-м гигабайтам (гибибайтам)?
Короче, считайте всё в битах на степенях двойки, тогда точно не запутаетесь :) Если 8•232 бит шифровать нельзя, то Гугл-калькулятор подсказыавет, что это
8 * (2^32) bit = 4.2949673 десятичных гигабайта.
Или всё-таки 8 * 8 * ((2^32) bit) = 34.3597384 десятичных гигабайта. Потому что в показателе имеется в виду количество блоков, а в множителе их размер — 64 бита.
И для режима CFB.
А если использовать более продвинутый режим шифрования (XTS?), то даже малая длина блоков (64) будет не страшна?
XTS стандартизирован только для AES. В линукс-ядре с другими 128-блочными шифрами работает, но выдаёт предупреждение о невозможности проверки тестовых векторов. Можно ли его запустить с 64-блочным шифром — не в курсе. Если в этом режиме необходимы операции с полиномами в GF(2128), то скорее всего — никак.
Хорошо, но вопрос был не столько про XTS, сколько в принципе: «Лечится ли эта проблема подбором соответствующего режима шифрования, или единственный способ — увеличивать длину блока?». Наверное, как-то можно продумать шифрование больших блоков данных даже с помощью BlowFish'а, но это поди всё равно бессмысленные костыли будут.
В OpenBSD применяется схема (как впрочем, должен уже быть и XTS), похожая на CBC-ESSIV, которая достаточно безопасна, она и с 64-блочными шифрами должна работать адекватно. Правда, если меняется только IV, но не ключ, то, возможно, от атаки утечки это не защищает.
Применяется ли в дисковом шифровании смена не только IV, но и ключа для дисковых секторов — не знаю. В старых реализациях (loop-AES) такой приём использовался.
CBC-ESSIV, XTS.. Господа, вы отвлекаетесь) ГОСТ 28147-89 определяет только 4 режима работы: ECB, CM, CFB и MAC. Все что иное – уже не ГОСТ)
На этом форуме слабый хромой поломанный нагнутый натянутый опущенный ГОСТ никого не интересует. :)
И это вы говорите в теме с таким названием...))
Здесь темы даже про винду есть, и что с того?
Да ладно, сделан классически, в учебных целях объяснять на нём с чего начинались блочные шифры удобнее чем на DES.
А то, что если ЧТО-ТО обсуждается, значит это кого-то интересует ;)
Тем более, что текущий опрос показывает, что Windows не используют лишь треть респондентов.
P.S. Ах да, я ошибся, RFC 4357 описывает CBC-режим для ГОСТ 28147-89.
unknown, а у вас есть опыт преподавания курса криптографии в вузе? :))
В некоторых приложениях, таких как ViPNet, сессионный ключ каждый раз генерируется для отдельного пакета. Непонятно зачем так сделано, ведь кроме уменьшения скорости работы это ничего не дает.
Хотите предложить ставку преподавателя?
abuse detected!)
amuse, confuse and misuse detected!)