Можно ли доказать право собственности на хэш открытого ключа без открытого ключа?

Я создаю систему, в которой я хотел бы, чтобы пользователь указывал хэш открытого ключа кошелька, которым он управляет, в случае чаевых, возмещений и / или иной необходимости отправить им значение обратно.

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

Если я правильно понимаю, они могут доказать это, подписав сообщение, которое я им отправляю, а затем они могли отправить подпись обратно мне вместе с открытым ключом.

Однако я также понимаю, что раскрытие вашего открытого ключа считается далеко не идеальным .

Итак, мне любопытно, есть ли где-нибудь решение, которое позволит мне подтвердить право собственности только на основе хешированного адреса без использования открытого ключа.

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

Достаточно ли просто указать где-нибудь в пользовательском интерфейсе, что этот процесс проверки никоим образом не сохранит открытый ключ? Все это предполагает HTTPS-соединение, но, конечно, риск заключается в том, что, поскольку злоумышленники узнают, что открытые ключи передаются, это открывает еще один потенциальный вектор возможной атаки.

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

Допустимо ли использование центрального органа?
Конечно, @DavidSchwartz, пожалуйста, поделитесь. Я новичок в этом пространстве и заинтересован в изучении различных подходов. Поскольку это будет мой первый проект, он, вероятно, будет иметь гибридный подход, поэтому некоторые элементы будут центральными.

Ответы (2)

Простой ответ - нет.

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

Однако есть один аспект, который может оказаться полезным. Для подписей сообщений биткойн использует пользовательскую кодировку (по сравнению с закодированной подписью DER, используемой в транзакциях).

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

Если вы хотите протестировать пользовательские закодированные подписи, они возвращаются функцией «signmessage» в клиенте ядра биткойн. Затем их можно проверить с помощью функции «verifymessage» или нескольких онлайн-инструментов, таких как этот: https://blockexplorer.com/messages/verify .

1) Создайте случайный закрытый ключ, чтобы использовать его для подтверждения права собственности.

2) Создайте сообщение с соответствующим открытым ключом для ключа, сгенерированного на первом шаге, и открытого ключа, право собственности на который вы хотите подтвердить.

3) Подпишите его обоими закрытыми ключами.

4) Отправьте его в центральный орган.

5) Получите от центрального органа подписанное заявление о том, что владелец открытого ключа, соответствующего закрытому ключу, сгенерированному вами на шаге 1, принадлежит учетной записи, право собственности на которую вы хотите подтвердить.

6) Теперь вы можете использовать ключ, сгенерированный на шаге 1, чтобы подтвердить право собственности на учетную запись, не раскрывая никому открытый ключ учетной записи, поскольку подписанное заявление от центрального органа привязывает ключ, сгенерированный на шаге 1, к учетной записи, доказывая общий контроль. .

Хорошо, я думаю , что в основном я зациклен на этом, @david-schwartz. Спасибо за предоставленный рабочий процесс. Моя путаница во 2-м шаге. Следует ли читать «и хэш открытого ключа , право собственности на который вы хотите подтвердить»? Если пользователь отправляет открытый ключ рассматриваемой учетной записи, он все еще использует свой открытый ключ для подтверждения права собственности на хешированный адрес, чего я пытаюсь избежать. Или здесь подразумевается/предполагается, что этот подписанный оператор должен быть где-то сохранен пользователем для использования в более поздние сроки, например, в этом сценарии?
@Mike-EEE Пользователь должен предоставить свой открытый ключ центральному органу, иначе центральный орган не сможет проверить подпись в запросе. Но предоставляя доказательства другим, они могут просто использовать заявление от органа власти без необходимости раскрывать открытый ключ.