openPGP в России / Разработки / Схема Lion

==Схема LION==

Использование блочного шифра в режиме CBC или CTR предполагает применение вектора инициализации (IV) или "nonce". Тем не менее, разработчики зачастую приносят безопасность в жертву простоте, и IV или nonce, ставшие обязательными атрибутами криптограчифески безопасной системы, становятся жалкими константами :) Следует ли говорить о том, насколько уязвимой становится такая система по отношению к атакам по словарю.

Здесь следует прояснить терминологию в том смысле, в котором её употребляет автор. Salt, или "соль", - это полностью случайные биты данных, конкатенируеые с паролем в системах парольной аутентификации для предотвращения атак по словарю. Nonce - это биты данных, используемые в криптографических протоколах и алгоритмах (в частности, MAC и некоторых режимах работы блочных шифров) в качестве уникального в каждый момент времени идентификатора и, как правило, состоящие из случайной части и счётчика, принимающего последовательные значения. В то время, как соль может выбираться на всё время жизни ключа, nonce должен постоянно изменяться. Наконец, Initialization Vector (IV) отличается от nonce тем, что должен принимать исключительно недетерминированные значения, т.е. не может содержать последовательностей изменяющихся по определенному закону битов. Недостаток IV по сравнению с nonce - задача защиты от атак с воспроизведением должна быть возложена на протоколы вышележащих уровней, тогда как в nonce за это ответственен счётчик.

Безопасное применение поточных шифров ставит обязательным условием применение nonce, но и здесь опасность очень высока в том случае, если nonce не изменяется каждый раз, когда меняются ассоциированные с nonce данные. Например, если производится шифрование блоков по 8КВ на диске, очередной nonce следует генерировать для каждого блока или же при шифровании блока с модифицированным содержанием. Грамотное использование nonce выгодно в случае шифрования на уровне раздела жесткого диска: так, при использовании постоянного nonce малейшее изменение одного блока ставит под угрозу конфиденциальность содержимого всего раздела. Следовательно, необходимо заново произвести шифрование раздела, сгенерировав новый nonce. Если же уникальный nonce применен на уровне каждого блока, потребуется гораздо меньший объем вычислений.

Теперь мы подходим к самому главному. Как известно, режим ECB не имеет явных противопоказаний к использованию в том случае, если размер открытого текста равен размеру блока примененного блочного шифра. Единственная слабость заключена в том, что каждая пара из ключа и открытого текста всегда сводится с одному и тому же шифртексту.

Схема LION предоставляет надёжный метод шифрования сообщений постоянной длины без использования IV или nonce. По сути своей, эта конструкция образует из поточного шифра и хэш-функции блочный шифр с произвольным размером блока, равным размеру шифруемого сообщения. Как вы уже догадались, блочный шифр в таком случае работает в режиме ECB, но, поскольку размер блока равен размеру открытого текста, какой-либо опасности это не представляет.

Разумеется, режим CBC или CTR со случайно выбранным вектором инициализации, или же более сложные режимы работы блочных шифров (CWC, OCB, CCM, GCM) заведомо более безопасны, но схема LION более проста и не обладает свойством расширения сообщения, присущим режимам, использующим IV.

Обязательным условием состоит то, чтобы размер сообщения превышал размер профиля, производимого Вашей хэш-функцией. Более того, ключ шифрования должен в два раза превышать размер профиля хэш-функции. Для генерации ключа уместным выглядит использование функции PBKDF2 (password-based key derivation function), определённой в PKCS #5. Напомним, что функция представляет собой способ генерации ключа требуемого размера на основе пароля.

Следующий код демонстрирует построение схемы LION, использующей лишь стандартные средства ~OpenSSL API. В обеих функциях аргументы in и out указывают соответственно на входной и выходной буферы, blklen - на размер блока, а key - на ключ шифрования.

%%
#include <stdio.h> 
#include <openssl/rc4.h> 
#include <openssl/sha.h> 
    
#define HASH_SZ   20 
#define NUM_WORDS (HASH_SZ / sizeof(int)) 
    
void lion_encrypt(char *in, char *out, size_t blklen, char *key) { 
  int     i, tmp[NUM_WORDS]; 
  RC4_KEY k; 
    
  /* Round 1: R = R ^ RC4(L ^ K1) */ 
  for (i = 0;  i < NUM_WORDS;  i++) 
    tmp[i] = ((int *)in)[i] ^ ((int *)key)[i]; 
  RC4_set_key(&k, HASH_SZ, (char *)tmp); 
  RC4(&k, blklen - HASH_SZ, in + HASH_SZ, out + HASH_SZ); 
    
  /* Round 2: L = L ^ SHA1(R) */ 
  SHA1(out + HASH_SZ, blklen - HASH_SZ, out); 
  for (i = 0;  i < NUM_WORDS; i++) 
    ((int *)out)[i] ^= ((int *)in)[i]; 
    
  /* Round 3: R = R ^ RC4(L ^ K2) */ 
  for (i = 0;  i < NUM_WORDS;  i++) 
    tmp[i] = ((int *)out)[i] ^ ((int *)key)[i + NUM_WORDS]; 
  RC4_set_key(&k, HASH_SZ, (char *)tmp); 
  RC4(&k, blklen - HASH_SZ, out + HASH_SZ, out + HASH_SZ); 
} 
    
void lion_decrypt(char *in, char *out, size_t blklen, char *key) { 
  int     i, tmp[NUM_WORDS]; 
  RC4_KEY k; 
    
  for (i = 0;  i < NUM_WORDS;  i++) 
    tmp[i] = ((int *)in)[i] ^ ((int *)key)[i + NUM_WORDS]; 
  RC4_set_key(&k, HASH_SZ, (char *)tmp); 
  RC4(&k, blklen - HASH_SZ, in + HASH_SZ, out + HASH_SZ); 
    
  SHA1(out + HASH_SZ, blklen - HASH_SZ, out); 
  for (i = 0;  i < NUM_WORDS;  i++) { 
    ((int *)out)[i] ^= ((int *)in)[i]; 
    tmp[i] = ((int *)out)[i] ^ ((int *)key)[i]; 
  } 
  RC4_set_key(&k, HASH_SZ, (char *)tmp); 
  RC4(&k, blklen - HASH_SZ, out + HASH_SZ, out + HASH_SZ); 
}
%%
{{showcomments}}

Ваше имя:
	Запомнить псевдоним (сохранить в cookie)
	OpenPGP-подписанный текст в кодировке Помощь
	Сохранить параметры OpenPGP в cookie

Для корректной работы разрешите в своем браузере показ изображений.

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

(осталось попыток на решение теста: 3)

Поддержка BBCode включена