Каковы последствия подписей Schnorr?

Adam Back (adam3us), объясненный в марте 2014 года , но это все математика. Тем не менее еще одна короткая почта с преимуществами .

Этот ответ на crypto.SE утверждает, что Биткойн рассмотрел использование Ed25519, основанный на подписях Schnorr, но решил против этого. Даже если он не будет использоваться, я все равно хочу знать последствия.

запрос на перенос, добавляющий их в libsecp256k1 .

Гэвин упомянул их на своем списке пожеланий для биткойнов .

21 голос | спросил Janus Troelsen 5 Jam1000000amMon, 05 Jan 2015 05:16:16 +030015 2015, 05:16:16

3 ответа


30

Предупреждение: я никогда не работал с сигнатурной схемой Schnorr. следующий мой анализ основан на чтении Wikipedia статью , ed25519 страница , а также некоторые обсуждения между разработчиками в # bitcoin-dev .

Возможные изменения

  1. Изменено поведение кода op: нам понадобится код op для проверки Подписи Schnorr. С жесткой вилкой мы можем переопределить op_checksig и op_checksigverify, чтобы также проверить подписи Schnorr. С мягким fork, мы можем переопределить один из зарезервированных кодов op-op-op для проверки Подписи Schnorr.

  2. Увеличение использования P2SH (возможно): Я думаю, что это маловероятно что будет введен новый формат адреса, чтобы сделать то же самое для скриптов pubkey, которые публично открывают ключи Schnorr, P2PKH для Открытые ключи ECDSA. Это означает, что люди, которые хотят использовать адрес Schnorr даже с одним ключом (не мультисигсом) придется использовать P2SH. Конечно, для приложений, которым не нужны адреса (например, для добычи или использования BIP70 протокол оплаты), они могут просто использовать op_checksigverify_schnorr (или независимо) непосредственно в скриптах pubkey .

  3. Меньшие мультисайговые транзакции: один из наиболее широко распространенных преимуществами схемы Schnorr является то, что она может допускать множественные подписывают, чтобы объединить свои подписи в одну подпись, которая может быть аутентифицированным против одного открытого ключа, созданного всеми уполномоченных сторон. Это делает то же самое текущее биткойн multisig делает, но использует меньше байтов. Это может быть особенно полезно, если требуются десятки или сотни подписей, например, в фоновая ситуация. Примечание: если я правильно понимаю, это также возможно также с ECDSA, но менее гибким способом. (Примечание к 2018 году: теперь есть документ, в котором подробно описывается, как сделать сценарии без сценариев на ECDSA , в том числе 2-из-2 многоязычных)

  4. Немного меньше для всех транзакций: , предполагая, что биткойн использует ed25519 кривая, имеющая аналогичный ключ силы для secp256k1 Кривая ECDSA Биткойн в настоящее время использует, сжатые Schnorr открытые ключи и подписи будут (соответственно) 32 байта и до 64 байтов по сравнению с текущим сжатым биткойном Secp256k1 открытые ключи и (несжатые) подписи, которые составляют 33 байтов и до 75 байт.

  5. Правдоподобная отрицательность для multisig: , используя Schnorr порог подписи it может быть легче предотвратить, когда несколько подписывающих лиц или сторонних лиц узнают, кто еще подписан или не подписывался. Это потому, что отдельные подписи объединены в единую подпись, которая напрямую не показывает, кто подписали его. Это можно использовать в ситуациях, когда подписывающие лица боясь репрессий за то, что тратит средства определенным образом.

  6. Правдоподобная недопустимость авторизированных сторон , используя сторонний организатор (которому не нужно доверять конфиденциальным ключей), можноне позволять подписывающим лицам знать, закрытый ключ является частью набора ключей подписи. Хотя нет непосредственно относящихся к транзакциям Биткойн, я, кажется, вспоминаю [1] Грег Максвелл говорит, что он хотел бы видеть это свойство, используемое для распространения модерация форума: выберите группу старших участников форума, получите открытый ключ от каждого из них, создать пороговый открытый ключ из некоторые из отдельных открытых ключей, а затем пусть люди подают подпись, когда они считают, что сообщение должно быть удалено. сторонний организатор (возможно, автоматизированная программа) объединит подписи без утечки, чья подпись действительно способствовала для достижения порога. Если никто не знает, чья подпись на самом деле имеет значение, и пул возможных модераторов велик, эффективные репрессии против модераторов становятся очень дорогими. [1]: #bitcoin IRC около 4 месяцев назад; к сожалению, в чате нет публично регистрируется.

  7. Теоретические улучшения свойств безопасности: эксперты согласны с общим Подписи Schnorr имеют лучшую теоретическую безопасность свойства чем эквивалентные подписи ECDSA. Наиболее примечательные из них улучшения в том, что хэш-функция, используемая в Schnorr, не нужна как устойчивость к столкновению, как функция хэша, используемая в ECDSA. (Биткойн, вероятно, будет использовать ту же функцию хэш-функции для Schnorr, что она использует для ECDSA: SHA256.) Кроме того, страница ed25519, связанная выше описывает несколько способов устойчивости к побочным атакам, которые может позволить аппаратным кошелькам безопасно работать в менее безопасных сред.

  8. Быстрая проверка подписи: , скорее всего, потребуется меньше циклов процессора для проверки подписи ed25519 Schnorr, чем ECDSA secp256k1 подпись. Вероятно, это лишь небольшое улучшение для биткойнов: Bitcoin Core проверяет подписи перед добавлением транзакции к ее mempool. Когда блок получен, содержащий транзакции, уже находящиеся в местный mempol, Bitcoin Core не переутверждает эти транзакции, до тех пор, пока локальный узел и узел добычи идентичны мэппи, никаких проверок подписи не требуется. (Вспомните coinbase не имеет подписи.) Однако подпись проверка в настоящее время является ограничивающим фактором для узлов во время начального blockchain download (предполагая высокоскоростное соединение и биткойн Core 0.10.0), поэтому «быстрее было бы лучше».

  9. Multi-crypto multisig: с двумя (слегка) разными криптосистемы на выбор, пользователи с высокой степенью защиты могут создавать 2-из-2 multisig pubkey, которые требуют как ECDSA, так и Schnorr подписи, поэтому их биткойны не могут быть украдены, если только один криптосистема нарушена. Если мы не ввернемся в Шнорр (см. Пункт № 1), они не смогут использовать стандартный op_checkmultisig --- но они могут сделать что-то вроде <ecdsa pubkey> OP_CHECKSIGVERIFY <schnorr pubkey> OP_CHECKSIGVERIFY_SCHNORR

Неопределенности (для меня)

  1. Возможно, изменены TXID: Я недостаточно знаком с Schnorr подписи, чтобы знать, как они могут быть податливыми (изменяемыми на третьих сторон, не признавая их недействительными), но криптозащитник Адам Кажется, что кажется, что прошлое назад было бы довольно податливым. Его решение заключалось бы в изменении того, как TXIDs вычисляются из хэша hash(<whole transaction>) до hash(<almost everything except the signature>). Это позволит исправить некоторые текущие проблемы проблемы с переносимостью , такие как медленные канал микроплатежа ,но это также крупная жесткая вилка, которая эффективно влияет на все программное обеспечение Bitcoin. Последняя вилка этого масштаба --- soft-fork реализация P2SH --- по-прежнему не поддерживает его со всех программ Bitcoin после трех лет обсуждения, двух лет реализации и довольно широкого использования.
  • Восстановление общедоступного ключа из подписей: Я не знаю, может ли открытый ключ Schnorr быть восстановлен из подписи Schnorr, как может быть выпущен паблик ECDSA из подписи ECDSA. Это может быть важно: биткойн Core verifymessage RPC использует ключевое восстановление для проверки сообщений, подписанных с signmessage RPC или посредством реализации знакового сообщения другого клиента. (Примечание: этот пункт остался ненумерованным, потому что он был добавлен после первоначальной публикации.)

Non-изменения

Чтобы быть ясным, вот некоторые вещи, которые не меняются.

  1. Детерминированные подписи: произошел переход к детерминированные подписи ECDSA в программном обеспечении Bitcoin. Например, Bitcoin Core начнет использовать их в предстоящем выпуске 0.10.0. Подписи Schnorr также могут быть генерируемых детерминированным образом. С детерминированными сигнатурами вы не нужен высококачественный источник энтропии (случайности) для создания защищенные подписи. Однако вам по-прежнему нужна высококачественная энтропия для генерации секретных ключей или корневых семян (см. пункт ниже).

  2. HD кошельки: мне кажется, что иерархическая детерминированная (HD) протокол будет работать для пар ключей Schnorr с небольшими изменениями. Вы может даже использовать одно и то же корневое семя как для ECDSA, так и для Schnorr Иерархии.

  3. Повторное использование ключа (адреса): , как с правильно реализованной ECDSA, это можно надежно создать несколько подписей Schnorr для разных транзакции, то есть безопасно получать несколько выходов на тот же адрес или открытый ключ. Это контрастирует с некоторая подпись схем , которые только позволяют вам безопасно использовать одну подпись для каждого открытого ключа. Однако повторное использование ключей все еще может быть менее безопасным, чем использование уникальных ключей для каждой транзакции, и повторное использование ключей будет всегда менее конфиденциальным для вас и вашего торговых партнеров.

Приоритет

Как раз мое мнение: Schnorr, кажется, дает некоторые приятные преимущества перед ECDSA для опытных пользователей, но никто, кажется, не просит для этих функций - поэтому добавление подписей Schnorr, вероятно, является низким приоритет. Я предполагаю, что поддержка подписи Schnorr может быть одной из первые улучшения, которые будут полностью протестированы в sidechain (PDF link) перед тем, как портироваться к биткойну.

P.S. Извините за длинный пост, но спасибо, что задали такой забавный вопрос!

ответил David A. Harding 8 Jam1000000amThu, 08 Jan 2015 03:39:17 +030015 2015, 03:39:17
9

Да, вы можете сделать восстановление с открытым ключом с помощью EC Schnorr. Рассмотрим

R = kG, [r = R.x, s = k + H(r, m)d], Q = dG

проверить:

sG = ?R + H(r, m)Q

восстановления:

sG = kG + H(r, m) dG = R + H(r, m)Q

так

Q = 1 / H(r, m) * (sG - R).

(И для вычисления R из r, если R точечно сжат, R = (r,f(r)) R' = (r,-f(r)) и попробуйте как R, так и R', проверив, является ли подпись действительной с результирующим открытым ключом ).

ответил Adam Back 16 AMpThu, 16 Apr 2015 06:06:46 +030006Thursday 2015, 06:06:46
3

Основная цель проекта DSA заключалась в том, чтобы не нарушать патент Schnorr. Теперь, когда патент истек, нет никаких хороших математических причин для перехода с DSA. С Schnorr алгоритм и анализ проще и часто более эффективны. Также проще разделить частные ключи Schnorr, создать пороговые варианты и т. Д. Однако DSA и ECDSA являются стандартами и были на некоторое время. В результате реализации библиотек повсюду. Вы можете найти поддержку модуля безопасности оборудования и т. Д. Когда-нибудь это будет либо Ed25519, либо какой-либо другой вариант Schnorr. Люди вряд ли стандартизируют новые варианты DSA. Но на данный момент ECDSA по-прежнему является алгоритмом для использования, если вы хотите что-то стандартное и широко поддерживаемое.

ответил user3188445 16 AMpThu, 16 Apr 2015 09:06:23 +030006Thursday 2015, 09:06:23

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132