Некоторые криптографические алгоритмы , в частности хеш-функции (которые используются в HMAC), определены для работы с произвольной последовательностью битов. Однако на реальных физических компьютерах и с большинством протоколов данные представляют собой последовательность октетов : число битов кратно восьми, и биты могут обрабатываться группами по восемь битов. Группа из восьми битов номинально является «октетом», но термин «байт» встречается чаще. Октет имеет числовое значение от 0 до 255 включительно. В некоторых языках программирования (например, Java) числовое значение подписывается (между -128 и +127), но это та же концепция.
Обратите внимание, что в контексте языка программирования C (как определено в стандарте ISO 9899: 1999, он же «стандарт C»), байт определяется как элементарная адресуемая единица памяти, воплощенный по типу unsigned char. sizeof возвращает размер в байтах (таким образом, sizeof(unsigned char) обязательно равен 1). malloc() принимает размер в байтах. В C число битов в байте определяется макросом CHAR_BIT (определенным в <limits.h>) и больше или равно восьми. На большинстве компьютеров в байте C содержится ровно восемь битов (то есть байт C является октетом, и каждый называет его «байтом»). - это некоторые системы с большими байтами (часто с встроенным DSP), но если бы у вас была такая система, вы бы ее знали.
Таким образом, каждый криптографический алгоритм, который работает с произвольными последовательностями битов, фактически определяет, как биты внутренне интерпретируются в октеты (байты). Спецификации AES и SHA делают все возможное, чтобы сделать это правильно, даже в глазах придирчивых математиков. Для каждой практической ситуации ваши данные уже представляют собой последовательность байтов, и предполагается, что группировка битов в байты уже произошла; так что вы просто передаете байты реализации алгоритма, и все в порядке.
Следовательно, с практической точки зрения, криптографические алгоритмы реализации ожидают последовательность байтов в качестве ввода и производят последовательности байтов в качестве вывода.
Endianness (неявно на уровне байтов) - это соглашение о том, как многобайтовые значения (значения, для кодирования которых требуется несколько байтов) разбиты на последовательности байтов (т. Е. Какой байт идет первым) , UTF-8 является нейтрально-байтовым в том смысле, что он уже определяет это расположение: когда символ должен быть закодирован в несколько байтов, UTF-8 указывает, какой из этих байтов идет первым, а какой последним. Вот почему UTF-8 является «нейтральным порядком байтов»: преобразование символов в байты является фиксированным соглашением, которое не зависит от того, как локальное оборудование предпочитает лучше читать или записывать байты. Порядковый номер чаще всего связан с тем, как целочисленные значения записываются в памяти.
О кроссплатформенном программировании: Ничто не заменит опыт. Таким образом, примерка нескольких платформ является хорошим способом. Вы уже многому научитесь, сделав свой код 64-битным чистым, то есть, если один и тот же код будет правильно работать на 32-битной и 64-битной платформах. Любой недавний ПК с Linux будет соответствовать всем требованиям. Системы с прямым порядком байтов в настоящее время довольно редки; вам понадобится старый Mac (с процессором PowerPC) или один из нескольких видов рабочих станций Unix (на ум приходят системы Sparc или Itanium под HP / UX). Более новые дизайны, как правило, принимают конвенцию little-endian.
О порядке байтов в C: Если ваша программа должна беспокоиться о порядке байтов, то есть вероятность, что вы делаете это неправильно. Endianness - это преобразование целых чисел (16-битных, 32-битных или более) в байты и обратно. Если ваш код беспокоится о порядке байтов, то это означает, что ваш код записывает данные в виде целых чисел и читает их как байты, или наоборот. В любом случае, вы делаете «псевдонимы типов»: доступ к некоторым частям памяти осуществляется через несколько указателей различных типов. Это плохо . Он не только делает ваш код менее переносимым, но также имеет тенденцию ломаться, когда просит компилятор оптимизировать код.
В правильной программе на C порядковый номер обрабатывается только для ввода-вывода, когда значения должны записываться или считываться из файла или сетевого сокета. То, что ввод / вывод следует протоколу, который определяет порядок использования порядка байтов (например, в TCP / IP часто используется правило с прямым порядком байтов). «Правильный» способ - написать несколько функций-оболочек:
uint32_t decode32le(const void *src)
{
const unsigned char *buf = src;
return (uint32_t)buf[0] | ((uint32_t)buf[1] << 8)
| ((uint32_t)buf[2] << 16) | ((uint32_t)buf[3] << 24);
}
uint32_t decode32be(const void *src)
{
const unsigned char *buf = src;
return (uint32_t)buf[3] | ((uint32_t)buf[2] << 8)
| ((uint32_t)buf[1] << 16) | ((uint32_t)buf[0] << 24);
}
void encode32le(void *dst, uint32_t val)
{
unsigned char *buf = dst;
buf[0] = val;
buf[1] = val >> 8;
buf[2] = val >> 16;
buf[3] = val >> 24;
}
void encode32be(void *dst, uint32_t val)
{
unsigned char *buf = dst;
buf[3] = val;
buf[2] = val >> 8;
buf[1] = val >> 16;
buf[0] = val >> 24;
}
Возможно, сделайте эти функции "static inline" и поместите их в заголовочный файл, чтобы компилятор мог встроить их по желанию в вызывающий код.
Затем вы используете эти функции всякий раз, когда хотите записать или прочитать 32-разрядные целые числа из буфера памяти, только что полученного из (или вскоре записанного в) файла или сокета. Это сделает ваш код не зависящим от порядка байтов (следовательно, переносимым) и более понятным, что облегчит чтение, разработку, отладку и обслуживание. И в крайне редкой ситуации, когда такое кодирование и декодирование становится узким местом (это может произойти, только если вы используете платформу с очень слабым ЦП и очень быстрым сетевым подключением, то есть вообще не ПК) вы все равно можете заменить реализацию этих функций некоторыми макросами, специфичными для архитектуры, возможно, встроенной сборкой, без изменения остальной части вашего кода.