Насколько разумны общепринятые взгляды на криптографию?
Моя компания, IronCore Labs, создает решения для сквозного обмена зашифрованными данными. Таким образом, мы очень чувствительны к ожиданиям относительно того, как криптографические функции реализованы и используются. Мы хотим, чтобы пользователи и эксперты согласились, что мы сделали свою работу правильно.
Принято считать, что криптографические библиотеки звучат примерно так: «НЕ ни при каких обстоятельствах пытайтесь реализовать свой собственный криптографический код. Вы все испортите. Используйте библиотеки, которые существуют и изучаются годами. Они все правильно понимают ».
Я на 100% согласен ... до последнего утверждения: Они понимают это правильно. Любой, кто играл с криптовалютой, знает, что сделать это правильно сложно. Есть много способов ошибиться, даже если вы не реализуете свою собственную горячую новую версию лучшей криптографической техники, rot13. (Старожилы это поймут. Молодежь, позвольте мне погуглить для вас.) Вы можете объединить принятые примитивы таким образом, чтобы это привело к уязвимостям безопасности - действительно запутанным, неочевидным, почти непостижимым уязвимостям. Вы можете создать возможности для неприятных атак по стороннему каналу, которые трудно предсказать. Но если они там есть, какой-нибудь коварный гений через вашу криптовалюту вскроет ваши данные в кратчайшие сроки. Итак, да, вам следует использовать библиотеки, реализующие алгоритмы, которые доказали свою безопасность, правильно собраны и проверены на наличие уязвимостей.
Используйте библиотеки, которые существуют и изучаются годами.
Но насколько хороши эти библиотеки? Другая часть общепринятого мнения гласит, что открытый исходный код лучше, потому что на него обратили внимание гораздо больше. Наверное, это правда. Однако «лучше» не обязательно «хорошо». Серьезные уязвимости OpenSSL по-прежнему обнаруживаются регулярно. Более 17 лет людей, пробирающихся через этот код, не смогли избавиться от всех ошибок. Напротив, эти 17 лет издевательств над людьми - большая часть проблемы.
Недавно у меня была возможность подробно изучить библиотеки OpenSSH, OpenSSL и GPG. Это был чрезвычайно болезненный опыт. Мы в IronCore Labs решили добавить сквозное шифрование во вездесущую утилиту sftp в качестве небольшого быстрого проекта, чтобы любой желающий мог легко воспользоваться преимуществами лучшей безопасности и простого, безопасного файла. обмен. Казалось, отличный план. Я взял проект openssh-portable и начал его просматривать. Хм - весь код на C, но это было неплохо. Я взламывал код C дольше, чем хотел бы признаться, и не было похоже, что изменения будут слишком обширными.
Напротив, эти 17 лет издевательств над людьми - большая часть проблемы.
Мы решили использовать криптографию с эллиптическими кривыми для нашего шифрования с открытым ключом. У него есть большие преимущества перед RSA и другими старыми алгоритмами с открытым ключом. OpenSSH полагается на библиотеку OpenSSL в своих криптографических процедурах, но поддержка эллиптических кривых в OpenSSL все еще находится в стадии разработки, поэтому я взял криптобиблиотеку Sodium (libsodium). Действительно простой интерфейс, отличная производительность - что не понравилось? Мне действительно не нужно было много копаться в коде OpenSSL, что, честно говоря, было большим облегчением после того, как я провел первоначальную разведку. Этот код старше и хитрее, чем код OpenSSH. Отчасти и следовало ожидать - именно здесь живет вся сложная криптовалюта. В любом случае, я не возражал против возможности там нырнуть. Я собрал быстрое подтверждение концепции с помощью libsodium и клиента OpenSSH sftp. Все было хорошо.
Затем мой коллега Патрик Уолш сказал: «Эй, не лучше ли использовать стандартный формат файла для зашифрованных файлов? Мы могли бы сделать все совместимым с PGP ». «Конечно», - сказал я. «Это звучит как отличный план. Использование стандартного формата никогда не бывает плохим, и люди могут использовать gpg для расшифровки наших файлов, если захотят ». Такой невинный разговор. Мало ли я знаю …
Процесс добавления совместимости с GPG в нашу новую утилиту ironsftp был долгим и трудным. Для болезненно фанатичных людей я написал отдельное послание, в котором подробно описал некоторые испытания и невзгоды на этом пути:
Достаточно сказать, что это был болезненный процесс разгадывания бородавок и крысиных гнезд в библиотеках почти без комментариев кода C, некоторым из которых более 15 лет, которые неоднократно взламывались на протяжении многих лет. (Должен признать, что временами я использовал язык, который заставил бы моряка покраснеть.) Неудивительно, что ошибки скрываются неоткрытыми годами. Код просто не способствует пониманию. Я не единственный, кто находит аспекты этих пакетов такими же привлекательными, как жонглирование тухлыми яйцами, обернутыми колючей проволокой! Я нашел этот обмен в обсуждении безопасности:
›Не могли бы вы дать рекомендации за или против использования GPG, поскольку это наиболее распространенный подход к асимметричным подписям?
Избегайте, если возможно. Код был написан колонией пьяных обезьян в эпоху, когда никто не понимал основ современной криптографии; Я действительно не уверен, что хуже между gnupg и OpenSSL. Конечно, GPG является стандартом для зашифрованной электронной почты, так же как SSL / TLS является стандартом для веб-сайтов, поэтому у вас может не быть выбора ...
Чтобы я не казался слишком резким, я понимаю, что для этого есть много причин. C - не идеальный язык для написания краткого безошибочного кода, но что вы собирались использовать в конце 90-х для криптографических реализаций? И любая кодовая база с годами немного разложится, особенно по мере добавления новых функций. Это неизбежно. И любой, кто работал над программным обеспечением, знает, что как только вы выпускаете что-то на волю, вы застреваете с этим навсегда. Я искренне сочувствую разработчикам этих библиотек; поддержание обратной совместимости может стать тяжелым бременем. Они обременены существованием данных, которые могли быть зашифрованы или подписаны в 1998 году с использованием алгоритмов, которые больше не актуальны. Приятно иметь программу, которая все еще может получать эти данные, но этот багаж имеет серьезные последствия для ремонтопригодности и безопасности кода, который мы действительно, действительно хотим быть твердым как скала.
Может быть, пора заморозить старый код, переименовать его в «устаревший» и начать с чистого листа. Используйте новую актуальность для хеширования, подписи и шифрования новых данных. Используйте современные языки и парадигмы, которые могут обеспечить хорошую производительность без самоуничтожения. Документируйте код, пока мы работаем над ним. Вы знаете, сделайте одолжение нашему будущему.
Приятно иметь программу, которая все еще может получать эти данные, но этот багаж имеет серьезные последствия для ремонтопригодности и безопасности кода, который мы действительно, действительно хотим быть твердым как скала.
Другие делают шаги в этом направлении. Оба проекта LibreSSL и BoringSSL удаляют старый код из OpenSSL. Они отказались от поддержки старых платформ, поэтому они могут воспользоваться преимуществами современных ОС, библиотек и функций компилятора для повышения безопасности. Престижность - я надеюсь, что мы увидим хорошее внедрение этих библиотек!
Мораль этой истории? Наверное, несколько. Во-первых, краткосрочное самосохранение: если кто-то на работе говорит: «Эй, давайте сделаем наш формат данных совместимым!», Бегите с криком. Действительно. Кричите громко, чтобы ваш коллега понял, что вы настроены серьезно. Более глубокая, более философская мысль: общепринятая мудрость, достойная своей соли, основана на достоверных идеях. Однако мы всегда должны быть готовы пересмотреть наши исходные данные и пересмотреть наши предположения. Мы достигли предела своего доверия к этим старым криптографическим библиотекам. Мудрость придерживаться проверенного и верного следует соизмерять с риском тех гор технического долга.
Может быть, пора заморозить старый код, переименовать его в «устаревший» и начать с чистого листа.
Пришло ли время заменить наши старые криптоинструменты на новые блестящие? Учитывая мои недавние приключения в программировании, я довольно сильно склоняюсь к "Определенно!" Как посоветовал друг: «Сбросьте все ядерное оружие с орбиты. Это единственный способ убедиться ». Или, как метко заметил другой друг:
Хотя мы, как отрасль, уважаем и ценим вклад наших предков OSS-криптографии, мы должны требовать нового старта для продвижения к более безопасному общению.
Я не мог с этим согласиться. В IronCore Labs мы работаем над тем, чтобы начать с нуля и повысить безопасность. Посетите домашнюю страницу нашей утилиты ironsftp с открытым исходным кодом или исходный код, который мы опубликовали на GitHub.
