Привет colinistheman,


Это хороший вопрос. Я должен начать с упоминанием, что Питер Wuille, автор libsecp256k1, был связан с Bitcoin Ядром с 2010 года и к этому моменту написал что-то вроде половины своего текущего кода. Так что, если он скомпрометирован, у нас есть гораздо более серьезные проблемы. Кроме того, libsecp256k1 настоящего времени используется только для подписания, а не проверок, и в этом случае его подпись всегда сверить другую реализацию --- так по крайней мере, на сегодняшний день это не является большим вектором атаки. Больше глаза всегда лучше, так что если вы беспокоитесь об этом, я призываю вас, чтобы просмотреть код сейчас, прежде чем она используется в большей степени.

Все, что сказал, я не думаю, что есть какая-то причина для беспокойства.

Я после libsecp256k1 с сентября прошлого года, вскоре после его зачатия, когда его главная цель экспериментировал с улучшением скорости более OpenSSL. Я никогда не способствовал код, но я прочитал почти все это в какой-то момент. Я также написал Ржавчина привязок, которые имеют много модульных тестов, которые я написал совершенно независимо от исходного кода. (Я не случайный прохожий, кстати, я программировал на протяжении почти 20 лет, в ходе на доктора философии в области криптографии, был связан с Bitcoin с 2011 года, и думали о цифровых подписей специально для более в год.) Я также сделал тщательные проверки на некоторых сильно алгебраические части libsecp256k1 кодовых. (Разработчики Bitcoin попросили меня сделать это несколько раз, в частности, из-за мою математическую экспертизу, однако, я могу сказать, что там не так много знаний, необходимых, вам просто нужно не быть аллергией на символы).

Я более уверен, что libsecp256k1 свободен от бэкдоров (умышленное или случайно через внутренняя хрупкость ECDSA), Чем я о реализации OpenSSL о ECDSA. Причины довольно общие: код libsecp256k1 является проще и чище; он разработан специально для ECDSA, так что это очень намного меньше кодовая (меньше места для ошибок и рецензентов могут выглядеть более внимательно на конкретный код ECDSA); его тестовое покрытие более тщательно. Код также записывается в виде модулей с явной целью быть легко проанализировать. Некоторые части даже написаны алгебраические инварианты комментируемых на каждой линии, обеспечивая математическое доказательство правильности работы. (Доказательство можно проверить, запустив на любой линии и проверять инварианты в обоих направлениях, пока не упрутся концы функции.)

С технической точки зрения также очень мало места для backdooring. До сих пор самый простой способ бэкдора реализации ECDSA это влияет на случайный нонс поколения. Тем не менее, libsecp256k1 берет свое временное значение в качестве вклада в его API, и с этого момента подписания и проверки являются детерминированными функциями. Любой перекос нонса должен произойти в коде Bitcoin, который вызывает в libsecp256k1; Однако, с ноября Nonce поколение было детерминированной, а также (с использованием RFC6979). Этот код был проверен и повторен себя и другими; это также протестированы. Поэтому я не считаю, что есть какие-либо Nonce перекоса атаки здесь.

Альтернативные средства backdooring могут быть, чтобы добавить явные ветви (которые были бы очень заметны аудиторам), умные алгебраических трюки (также заметных аудиторами, учитывая, насколько просто правильная алгебра), эксплуатацию поведения за пределами C спецификации, такие как использование неинициализированного память (которая будет отображаться в таких инструментах, как Valgrind). Я также не считаю, что есть какие-либо из них по причинам, только что. К последней категории бэкдор может быть использование sidechannels. Явное использование sidechannel, такие как сохранение вещи на диск будет сразу видны в коде, избегая при этом неявные sidechannels, например, времени CPU или энергопотребления является преднамеренной целью libsecp256k1 и что-то мы проверяем на в ходе проверок. Кроме того, эти sidechannels измеримы по определению, и эти виды измерений являются то, что разработчики очень заинтересованы.


Андрей