id: Гость   вход   регистрация
текущее время 22:33 28/03/2024
Владелец: АндрейПогребенник (создано 14/09/2006 22:50), редакция от 27/08/2006 21:18 (автор: SATtva) Печать
Категории: криптография, алгоритмы, симметричное шифрование, разное, сообщество
создать
просмотр
редакции
ссылки

Схема 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 – на ключ шифрования.




 
— unknown (22/02/2007 12:39, исправлен 22/02/2007 12:54)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
"Two practical and Provably Secure Block Ciphers: Bear and Lion" Ross Anderson and Eli Biham

"Provably secure and efficient block ciphers" Pat Morin

"Both these ciphers are constructed from a stream cipher, S, and a hash function, H, using a construcion, similar to those of Luby and Rackoff"

"A crititique of BEAR and LION" Pat Morin

"The partial decryption attack on BEAR of section 4.1 shows that although this system is provably secure in their model, only half the key bits are needed to decrypt most of the ciphertext. Perhaps a more useful model would be to assume that the hash function and stream cipher are secure and use this to show that recovering (part of) the plaintext from a ciphertext requires knowledge of (part of) the key.
By showing how to construct block ciphers from stream ciphers and hash functions Anderson and Biham have completed the set of elementary reductions.
Finally, we note that the existence of meet-in-the-middle attacks on these ciphers is not a good sign. While the complexity of these attacks makes them largely theoretical, the fact that they exist shows that these ciphers are not as strong as a cipher with a 256+ bit key size could be. In fact it appears as if very little security is gained by using two subkeys and it may be possible to produce a cipher with nearly the same security using only a 128 bit key. Such a cipher could be nearly as strong, have a shorter key, and if designed correctly have better performance than both BEAR and LION. This will be the subject of a later paper."
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3