Ещё раз о шифровании ГОСТ 28147-89

[@milabs]

Гаммирование с обратной связью (CFB) — это потоковый режим работы блочного шифра. Это означает, что в таком режиме работы можно шифровать данные произвольной (байтовой и даже битовой) длины. В вашей реализации, как я вижу, с этим проблема — режим CFB не позволяет обрабатывать не кратные размеру блока.

[@Yaruson]

Действительно, в реализации я упустил этот момент, и зачем-то сделал проверку на длину исходного сообщения. На самом деле ограничение на размер блока актуально только для синхропосылки, которая шифруется в режиме простой замены, а для неполного последнего блока исходных данных просто используется не вся гамма целиком, а только необходимая часть. Спасибо за ценное замечание, поправил.

[@milabs]

Лучше, но всё-равно с ошибкой. Гамма должна проворачиваться только тогда, когда был обработан блок целиком. У вас тут Array.Copy(_encrypt ? result : dataBlock, _state, inputCount); вообще что-то непонятное выполняется. Проведите простой тест на корректность — зашифруйте 16 байтов в режиме CFB скармливая функции по одному байту и сравните с тем, что получается при шифровании 2-х блоков.

[@Yaruson]

Да, мне не пришло в голову, что можно TransformBlock можно попытаться использовать для неполного блока.
В случае с полными работает верно, не так ли?

Как по вашему мнению, стоит ли следить за количеством обработанных байт и проворачивать гамму только после отработки целого блока, или же просто запретить (плохо звучит, но всё же) обрабатывать TransformBlock неполные блоки?

[@milabs]

В случае с полными работает верно, не так ли?

Не знаю, я не проверял.

Как по вашему мнению, стоит ли следить за количеством обработанных байт и проворачивать гамму только после отработки целого блока, или же просто запретить (плохо звучит, но всё же) обрабатывать TransformBlock неполные блоки?

Это зависит от того, что Вы хотите получить и где использовать.

[@Yaruson]

В описании метода TransformBlock из MSDN ничего не сказано про обработку неполных блоков. Можно предположить, что этот метод предназначен исключительно для преобразования полных блоков, тем более, что с неполными работает TransformFinalBlock:

TransformFinalBlock is a special function for transforming the last block or a partial block in the stream. It returns a new array that contains the remaining transformed bytes. A new array is returned, because the amount of information returned at the end might be larger than a single block when padding is added.

В данной реализации последний блок теперь может быть неполным, это мы исправили в прошлый раз. Как я понимаю, под «partial block» имеется в виду последний неполный блок, а не любой неполный блок в исходном сообщении. Итого получается, что TransformBlock должен работать с полными блоками, а TransformFinalBlock — с полным или неполным.

Выходит, можно ограничиться проверкой размера блока в TransformBlock, чтобы формально соблюсти интерфейс ICryptoTransform.

Этот класс предполагается использовать в CryptoStream. К сожалению, я не знаю, как он работает внутри с ICryptoTransform, но полагаю, что он принимает во внимание свойства InputBlockSize и OutputBlockSize, определённые в интерфейсе.

[@milabs]

Здесь я Вам не советчик, руководствуйтесь MSDN.

[@milabs]

.

[@avssav]

FSB certified?

[@Yaruson]

К сожалению, нет. У меня даже нет лицензии на разработку, производство и распространение криптографических средств :)
Можно считать, что это исключительно из академического интереса.

[@vasiatka]

Ради интереса… Не хотите попробовать алгоритм «кузнечик»? Данный ГОСТ доживает последние дни, т.к. был теоретически взломан…

[@Yaruson]

Да, идея идея очень заманчивая, но смущает что стандарт на этот алгоритм пока что черновой и что-то (не знаю что) может поменяться. Вам случайно не известны «большие» его применения, реализованные уже сейчас?