Выбор стандарта шифрования

Если вы спросите мое мнение относительно самого значительного вклада в криптографию за последние несколько лет, то мой ответ вовсе не будет напрямую относиться к криптографии. Это не потоковый шифр (stream cipher), не групповой шифр (block cipher), не хэш функция (hash function) или протокол. В действительности это вовсе не то, что мы используем в качестве потребителей для безопасности. Однако, это нечто, что является основой того, что мы используем – это криптографическая конкуренция. Такая конкуренция – это процесс отбора, в который включены шифровальщики со своими идеями. Эти проекты были придуманы многими шифроаналитиками. Кроме тщательного изучения аспектов безопасности проектов, вводятся различные метрики и критерии для определения их производительности и эффективности во многих программных и аппаратных средах. Потенциальный стандарт, очевидно, должен быть безопасным, но также очень важно, чтобы он выполнялся хорошее время и снизил стоимость процесса. В противном случае он не подходит. Даже сильной безопасности не достаточно, чтобы реализовать неэффективный и плохо выполняющийся криптографический проект.

Некоторым из вас может показаться, что они уже сталкивались с такой ситуацией ранее. Вот подсказка: «У кого больше кубиков, чем у Тетриса и Лего?» Нет, не в статистике карьеры Дэвида Робинсона. Хотя не плохой вариант. Но если вы ответите: «А как насчет процесса выбора расширенного стандарта шифрования (Advanced Encryption Standard)?», то вы будете правы. Наш текущий стандарт группового шифрования – Belgian, спроектированный 128-битной SPN или Substitution Permutation Network, “Rijndael,” был чемпионом этого соревнования. Этот пятилетний процесс продемонстрировал результаты открытого соревнования. Результат ошеломляющий, и есть серьезные основания верить в этот стандарт. Ко всему прочему он пережил атаку большинства безжалостных групп шифровальщиков, когда-либо собиравшихся вместе. К тому же он жив и сейчас. Если этого не достаточно, то скажу, что он привлек внимание большего количества шифровальщиков, чем любой другой групповой шифр (block cipher), включая двух финалистов - Twofish и Serpent.

Соревнование от начала до конца очень похоже на песочницу для проектных методологий. Вы собираете лучших шифровальщиков вместе и подбрасываете им различные Feistels, SPNs, et cetera, основываясь на множестве различных проектных стратегиях, полагаясь на безопасность и производительность реализации, и вы получаете идеальные условия для выделения хорошего, плохого и ужасного. Вы можете не только выделить то, что небезопасно, и что плохо выполняется, вы также можете начать строить метрики того, что будет безопасным, хорошо выполняющимся групповым шифром в программных и аппаратных средах, где ограничения к производительности и к памяти могут быть очень значительными. Это необходимо для практической криптографии. В теории, когда условия произвольны и идеализированы, можно сконцентрироваться на одной безопасности. На практике все гораздо сложнее – выигрывает не просто безопасный проект, а полезный проект.

Я бы хотел заказать hash browns

Теперь, когда мы немного узнали о том, как выбрать стандарт шифрования (cryptographic standard), что мы должны делать теперь? В результате выясняется, что нам нужен другой стандарт, и в этот раз он, вероятно, будет не просто запутанным процессом. Как многие из нас знают, хэш функции (hash function) переживали достаточно сложные времена в последние несколько лет. За достаточно короткий период времени увеличилось количество шифровальщиков для различных хэш функций. Вместе с этим появилось множество мнений относительной реализаций. После лишь краткого взгляда на эти обзоры становится очевидным, что большинство из них имеют очень ограниченное понимание того, что происходит. Другими словами, пока некто изучает криптографию в стенах академии, у них нет никакого понятия.

Основное наблюдение, которым я хочу поделиться, касается проектной стратегии основного семейства (т.e. семейства MD4) традиционных хэш функций (hash function). Это семейство состоит из MD4, MD5, HAVAL, RIPEMD, SHA-1, SHA-2 и соответствующих их расширений, где это возможно. В основном, в семействе MD4 хэш функций (hash function) мы имеем дело с общей структурой, которая является превращением группового шифра (block cipher) одностороннюю хэш-функцию, используя упреждающую конструкцию Дэвиса-Мейера (Davies-Meyer feedforward construction). Эти функции можно подытожить, как представление структуры UFN или Unbalanced Feistel Network, тяжеловесной и гетерогенной. За последние несколько декад, до недавнего времени мы видели, что лишь немногие шифровальщики занимались этими функциями, включая Biham, R. Chen, Chabaud, Joux, Dobbertin, Wang, Yu, Yin, Feng, H. Chen, Lai, Van Rompay, Biryukov, Preneel, Vandewalle, Hawkes, Paddon, Rose, et cetera.

С момента снижения настраиваемого уровня сложности SHA-1 с 2^80 до 2^63, пресса стала незваным катализатором для абсурдного мышления. Многие предположения вращаются вокруг паники ускорения перевода инфраструктуры на поддержку SHA-2, и свертывание использования SHA-1. Перед тем, как продолжить, я хочу коротко рассказать о важности не ускорять криптографию на уровне реализации – нет ничего более вредного для безопасности, чем изменение криптографии на уровне реализации (implementation level). Именно на этом уровне эффективность криптографии диктуется больше всего.

Во-первых, это [переход к большим результатам хэш функций] должно быть подвергнуто обработке гораздо преждевременно. Стандартной практикой должна стать по крайней мере 128-битный уровень безопасности. Во-вторых, в то время как SHA-256, например, должен быть достаточным для удовлетворения этому требованию 128-битной безопасности, это не окончательное решение. В лучшем случае оно временное, и вот почему. Недавно шифровальщики представили улучшенные методологии и дополнения, которые тем или иным образом можно применить для каждой конструкции внутри семейства MD4. Не время использовать функции внутри этого семейства, который поддерживают более длинный результат; пришло время изучить путь проектирования хэш функций, которые не только поддерживают более длинный результат, но также поддерживают совершенно новые проектные стратегии. Пришло время проанализировать другие стратегии для конструирования безопасных хэш функций.

Под другими стратегиями мы просто рассмотрим нечто отличающееся от UFN, которая используется в большинстве существующих традиционных хэш функций (hash function). На мой взгляд, существует одна специфическая стратегия, которая может быть идеальной точкой интереса в этом случае. Эта стратегия wide trail strategy (стратегия широкого следа). Звучит знакомо? Базисные элементы, лежащие в основе AES, Rijndael, являются дочерними элементами этой стратегии, как и множество других шифров из этого семейства. Винсент Риджмен (Vincent Rijmen), “Rij” в “Rijndael,” совместно с Пауло Баррето (Paulo Barreto) дали нам Whirlpool. Это очень интересный проект, который использует усиление множества Меркле-Дамгарта (Merkle-Damgard ) и хэш конструкции Miyaguchi-Preneel в групповом шифре, который очень похож на Rijndael. Эта 512-битная хэш функция основана также на стратегии широкого следа (wide trail strategy), и должна стать моделью для направления, или направлений, в которых необходимо двигаться дальше. Другой эффект, прямой и косвенный, это тот факт, что такое решение привлечет новых шифровальщиков к стратегии широкого следа. А это не только увеличит доверие к этой стратегии, как методологии для конструирования безопасных хэш функций, а также обеспечит подробное рассмотрение основных принципов Rijndael.

Реальная проблема и правильная атмосфера

В заключение, я чувствую, что проблема на ладони – реальная проблема – гораздо глубже, чем простое увеличение результата хэш функции (hash function). Мне кажется, что это дело структурной значимости, когда нам нужно распределять наши аналитические успехи на другие стратегии, кроме UFN и состава семейства MD4, чтобы не оказаться в положении, каждая конструкция в единственном семействе, которое у нас есть, станет восприимчивым к атакам, которые потенциально могут стать более эффективными. Обратите внимание, я ни в коем случае не говорю, что UFN небезопасна. Я просто предлагаю изменение в проектной политике, так сказать. Посмотрите на это, как на способ подхода к дизайну хэш функции.

Ограничения стандарта обеспечивают правильную атмосферу для сильных анализов, которые гарантируют, что критерии будут сбалансированы между компромиссом и консерватизмом. Благодаря этому мы увеличим требования, при которых функция будет пригодна для реализации, при этом обеспечивать криптографическую безопасность, которую мы ожидаем от такой функции.

Говорить «Прощай» SHA-1 уже давно поздно. Ему на смену давно должен прийти SHA-256 до 2011 года, когда мы ожидаем появление нового стандарта для хэш функции (hash function). Начиная с 2008 года, мы встаем на длинный путь к пониманию, вероятно, самой многогранной функции шифрования (cryptographic function). Мы им очень обязаны. Также как и с процессом выбора AES, мы увидим совместную работу лучших из лучших. Благодаря NIST, и всем участвующим шифровальщикам, пришло время разделить некоторый оптимизм. Понимание проекта хэш функции, которое мы получим в результате этого процесса, будет великим, как и выбранный стандарт. Без сомнения это будет одним из самых важных этапов в криптографии. Пусть начнется эта разработка.