Криптография – увлекательный предмет на стыке чистой математики и информатики, который за последние несколько лет стал почти повсеместным. Подобно функциональному программированию, криптография представляет для меня особый интерес из-за чисто математических связей, и моя работа в области разработки программного обеспечения для обеспечения безопасности вернула меня к этой теме за последний год или около того. Погрузившись в стандартные API-интерфейсы криптографии Java, я быстро обнаружил путаницу странных соглашений об именовании и плохо документированных криптографических примитивов. Было написано множество научных работ, изучающих широко распространенное явление неправильного использования API-интерфейсов криптографии Java, и, проведя с ними немного времени, я легко могу понять, почему это так. Java, стремясь оставаться низкоуровневой и универсальной, часто предоставляет чрезмерно сложные API, которые, будучи гибкими для использования на низком уровне, предлагают очень мало рекомендаций по их правильному использованию. Отчасти это может быть связано с типичной чрезмерной разработкой, характерной для API Java до Java 8, но этот конкретный API больше похож на API C, перенесенный непосредственно на Java. На самом деле, этому есть довольно безобидное объяснение: это один и тот же базовый шаблон, присутствующий в большинстве исторических криптографических библиотек, большинство из которых действительно написаны на C учеными, мало заботящимися о технике. В сочетании с историческим багажом, связанным с необходимостью иметь дело с криптографическим экспортным контролем в 1990-х и начале 2000-х годов, API криптографии Java, как и большинство криптографических программ, написанных до ослабления экспортного контроля, страдал от уязвимостей в системе безопасности по своей конструкции.
Многое было написано и открыто с тех мрачных дней, хотя большинство программ все еще борется с устаревшими методами криптографии и неправильным использованием. Чтобы помочь разработчикам программного обеспечения внедрить надежную криптографию в свои приложения, необходимо приложить усилия для создания и использования компонентов криптографического программного обеспечения, которые одновременно просты в использовании и трудны для неправильного использования. Одним из самых продолжительных проектов с аналогичной философией является Операционная система OpenBSD , которая по умолчанию включает надежную криптографию и безопасность в течение последних 25 лет. Этот проект, не ограниченный американским контролем за экспортом криптографии на своей родине в Канаде, стал одним из замечательных примеров повсеместного использования криптографии и безопасного дизайна во всей своей кодовой базе. Благодаря упрощенному контролю за экспортом, особенно для бесплатного программного обеспечения с открытым исходным кодом, эта философия должна расширяться и способствовать повышению безопасности, конфиденциальности и безопасности программного обеспечения, которое мы все пишем.
Используя совокупность алгоритмов общественного достояния и криптографических знаний, я запустил O(1) Проект криптографии где я разрабатываю самоуверенную библиотеку криптографии, которая должна быть простой в использовании и трудной для неправильного использования. O(1) Криптография – это библиотека Java и C, которая объединяет новейшие передовые методы в криптографии, предоставляя абстракции для распространенных вариантов использования криптографии. Название является каламбуром идеи о том, что криптографические алгоритмы, как правило, должны выполняться в постоянном времени и с минимальной дифференциацией в наблюдаемом состоянии. Эти свойства кажутся несколько современными для криптографии в том смысле, что компьютеры сейчас достаточно быстры и мощны, чтобы статистически дифференцировать криптографический алгоритмический вывод с непостоянным временем, хотя они не были такой большой проблемой на рубеже 21 века, когда AES была стандартизирована. На самом деле, большая часть стандартизированной криптографии до недавнего времени разрабатывалась почти полностью оторванной от реальности, что однажды некриптографам, возможно, тоже придется использовать этот материал. Просто не существует достаточного количества криптографов, чтобы писать собственные криптографические процедуры для каждого приложения, которое в этом нуждается, а старые криптографические библиотеки не были предназначены для неспециалистов. Возможно, вы слышали о различных аббревиатурах прошлых лет, таких как AES, DES, RC4, RSA, DSA, MD5, SHA1 и многих других. Некоторые из этих примитивов все еще полезны и безопасны, но у всех у них есть проблемы в той или иной форме. В частности, все они не проходят двусторонний тест на простоту использования и трудность неправильного использования.
Например, AES сложно использовать: поскольку он был стандартизирован до того, как сформировался консенсус о том, что аутентифицированное шифрование было правильным решением, он требует сопряжения с алгоритмом аутентификации, который обычно забывается на практике. Разработчикам AES не рекомендуется писать различные оптимизации, которые приводят к утечке информации о базовом ключе шифрования. Довольно легко злоупотреблять AES как со стороны разработчика, так и со стороны приложения. Будучи блочным шифром, для шифрования данных, длина которых превышает длину ключа шифрования, необходимо указать режим работы, и многие обычно реализуемые режимы имеют свои собственные уязвимости безопасности, помимо отсутствия аутентификации. Другим примером является RSA, пара алгоритмов подписи и асимметричного шифрования, которые часто используются неправильно и неправильно реализованы. Из-за большого размера ключа во многих реализациях на протяжении всей истории возникали соблазны срезать углы. Недопонимание в использовании симметричного и асимметричного шифрования привело к тому, что люди использовали RSA для прямого шифрования данных, прямого использования общего секретного результата Диффи-Хеллмана для шифрования, дублирования ключей и многих других сбоев в системе безопасности.
В период с 2005 по 2010 год/| проф. Даниэль Дж. Бернштейн в Университете Иллинойса в Чикаго опубликовал несколько работ, которые составляют основу для большинства базовых криптографических примитивов, занимающих центральное место в O(1) Криптография. В частности, за это время было подробно описано семейство потоковых шифров Salsa20/ChaCha20 и расширенные версии nonce, одноразовый аутентификатор Poly1305 и эллиптическая кривая Curve25519. Более подробный список этих различных основополагающих документов приведен в вики O(1) , хотя общая тема, лежащая в основе выбора примитивов для этой библиотеки, заключается в том, что они также разработаны с учетом философии, согласно которой они должны быть просты в использовании и трудны для неправильного использования. Еще одна интересная тема заключается в том, что многие из этих вариантов алгоритмов были включены в различные стандарты IETF, такие как TLS 1.3 и SSH, поэтому их использование явно стало гораздо более распространенным, чем в первые годы.
Естественно, я не первый, кто разрабатывает такую библиотеку, и есть предшествующий уровень техники, который вдохновляет эту библиотеку. Общая идея создания криптографической библиотеки, которая проста в использовании и трудно злоупотреблять является ли центральное понятие полиглота Криптографический фреймворк Themis . На выбор представленных алгоритмов сильно повлиял проф. Старая библиотека NaCl Бернштейна, которая легла в основу libsodium , основной библиотеки C с аналогичной философией (или, по крайней мере, такой же простой в использовании, как C, учитывая, что это C). Особая благодарность Фрэнку Денису, сопровождающему libsodium и разработчику большей части стандартной криптографической библиотеки zig , за дальнейшее расширение кроличьей норы криптографических примитивов для изучения и поддержки, особенно в области облегченной криптографии.
Эта библиотека все еще находится в стадии интенсивной разработки, особенно в области документации и API более высокого уровня. Большая часть основных криптографических примитивов была перенесена на Java, где это необходимо, и также доступны собственные реализации. В то время как основная задача состоит в том, чтобы сначала разработать Java API, в связи с возможным включением кода C из проекта криптографии Fiat для формально проверенных функций эллиптической кривой, я также рассматриваю, для каких других языков имеет смысл предоставлять фасады, особенно для не-JVM, которые больше выиграли бы от собственного кода. Все доступные версии алгоритмов на чистом Java, в качестве опции также предоставляются оптимизированные собственные версии. Подобно Apache Log4j, возможно, имеет смысл создать API-интерфейсы Scala и Kotlin, но в настоящее время они выходят за рамки первоначального выпуска.
Оригинал: “https://dev.to/jvz/introducing-the-o-1-cryptography-project-487m”