RC5-Блочный алгоритм. Как обрабатывать невыровненный «хвост»?

Возьми из 9797-1 какой-нибудь метод

RFC2040

7.6 Final block processing

This step handles the last block of plaintext. For RC5-CBC, this step just performs error checking to ensure that the plaintext length was indeed a multiple of the block length. For RC5-CBC-Pad, padding bytes are added to the plaintext. The pad bytes are all the same and are set to a byte that represents the number of bytes of padding. For example if there are eight bytes of padding, the bytes will all have the hexadecimal value 0x08. There will be between one and BB padding bytes, inclusive.

Оно?

Может быть, есть какие-то другием методы обработки некратных хвостов, описание которых я не нашел?

Да. Стандартный метод, называется «гаммирование». Более того - все блочные шифры _положено_ использовать в режиме гаммы в промышленном режиме :-)

Кстати как я понял для бинарніх данніх єто не применимо ?)

This step handles the last block of plaintext. For RC5-CBC, this step just performs error checking to ensure that the plaintext length was indeed a multiple of the block length. For RC5-CBC-Pad, padding bytes are added to the plaintext. The pad bytes are all the same and are set to a byte that represents the number of bytes of padding. For example if there are eight bytes of padding, the bytes will all have the hexadecimal value 0x08. There will be between one and BB padding bytes, inclusive.

Я не могу этот адский текст перевести.

«Этот шаг используется на последнем блоке исходного текста. Для режима RC5-CBC, на этом шаге просто проверяется кратность исходного текста длинне блока. Для режима RC5-CBC-Pad, дополнительные байты добавляются в исходный текст. Эти добавочные байты все такие же и представляют собой количество байт, которые добавляются. Например, если добавляется восемь байт, все байты будут иметь шестнадцатеричное представление 0x08. Они могут принимать значение от 1 до BB дополнительных байт включительно.»

Что все это значит?

Длина блока 8 байт. У нас «хвост» в 3 байта - 1Ah, 2Bh, 3Ch. Нужно добавить 5 байт, и эти байты должны быть 05h? То есть, блок перед шифровкой будет выглядеть:

1Ah, 2Bh, 3Ch, 05h, 05h, 05h, 05h, 05h

Так чтоли?


И вопрос - получается, таки нужно где-то хранить длину исходных данных, чтобы после расшифровки откинуть лишнее?

Я не спец, сразу говорю, просто сразу подумал почему-то, что в RFC должно быть написано.

Я понял вышепроцитированное как «если выравнивание блоков данных по 8 байт, то в конец хвоста дописываем столько, сколько не хватает до длины блока - 8-ми байт (в твоём случае пять байт), и во все байты пишется число байт выравнивания, то есть восемь»

То что ты написал о 5 и 0x05 неверно, ведь тогда получается бред - в RFC пишут о выравнивании по 8-м байт и дописывают 0x08. Ксли рассуждать как ты то получается длина хвоста 0. Бред.

И да, раз с английским плохо, первое-проконсультируйся с каким-то преподом по защите инфы, второе-учи английский.

Мне не с кем проконсультироваться. Поэтому и пишу на лор.

Вообще, в RFC совершенно не написано обоснование, почему нужно именно такие байты добавлять в конец. По мне так вообще без разницы, какие байты будут добавлены, на расшифровку это никак не повлияет.

И вопрос, нужно ли хранить длину исходного сообщения, остается открытым.

>И вопрос - получается, таки нужно где-то хранить длину исходных данных, чтобы после расшифровки откинуть лишнее?

Храни в последних байтах длину дополнительных данных.

Да, походу с добавлением 0x05, если дополняются 5 байт, я был прав:

BB - This is the block size for RC5 measured in bytes.

padLength = BB - pAlg->inputBlockIndex;
for (j = 0 ; j < padLength ; j++)
 {
  pAlg->inputBlock[pAlg->inputBlockIndex]=(unsigned char) padLength;
  pAlg->inputBlockIndex++;
 }

> для расшифровки нужно хранить в открытом виде _длинну_ сообщения.

Почему в открытом? Длина может быть зашифрована, например, в начале первого блока или в конце последнего или в любом другом заранее определённом месте. Так или иначе, зашифрованное сообщение будет длиннее исходного.

Храни в последних байтах длину дополнительных данных.

То есть, последний байт не учитывать при расшифровке, и в нем писать сколько байтов было дополнено? Так?

Я читал это:
http://www.ietf.org/rfc/rfc2246.txt
http://rfc2.ru/2246.rfc - русский перевод

Не могу сказать, что я в этом разобрался.

Пункт 6.2.3.2

block-ciphered struct {
opaque content[TLSCompressed.length];
opaque MAC[CipherSpec.hash_size];
uint8 padding[GenericBlockCipher.padding_length];
uint8 padding_length;
} GenericBlockCipher;

Иначе говоря:
block-ciphered struct {
Данные[TLSCompressed.length];
Хэш[CipherSpec.hash_size];
Заполнение[GenericBlockCipher.padding_length];
Длина заполнения padding_length;
} GenericBlockCipher;

Здесь есть отдельное поле - длина заполнения.

Ну и отлично. Я и не вчитался и не дошло просто.
Так действительно логичней даже. Я как понимаю, расшифровка идёт в обратном порядке, верно? Там случайно не получается, что эти добавленные байты сами того?
Может ты всё-таки прочитаешь восьмой раздел в RFC. Я глянул - там как раз написано что-то о двух последних блоках при декрипшене и описан алгоритм. К тому же на первые два вопроса ты сам себе ответил, вчитавшись в RFC. Так что ничего кроме RTFRFC не могу посоветовать :) Удачи