Я так изначально и предполагал, поэтому я и написал внизу первого поста о том,
что сами биткоины - не нужны для использования цифровой подписи.
Очевидно что. Но тогда зачем нам именно авторизация через криптовалюты, а не через внутренний ресурс сайта?
Как раз таки такое не вводят потому, что анонимность и есть возможность клепать мультов пачками.
Ведь в адресе, важна здесь - сама уникальность его, как идентификатора для пользователя (он же и есть адрес)
ну и соответствие идентификатора - какому-то пользователю (по ассоциативной хэш-таблице, на сервере, например).
Хорошо, опять вопрос: зачем тогда здесь криптовалюты? Аутентификация на основе ключевых пар и так давно уже придумана была, где то в конце 80х, ты немного опоздал.
Или тебе кажется что здесь сидят главы Гугл, Амазон и прочих, и ты такой "А давайте делать так" и мы такие "Ну давай" и сразу все поменялось?
Ну вот смотри, тут адрес не указан:
-----BEGIN BITCOIN MESSAGE-----
Comment: Signed by Bitcoin Armory v0.93.1
G+Nsln9uxFzy0320TCUS7StLw91Q/k18/XPTun7gP7DsWhlVHluT4rF2ITZJNLdy
Bdef2Jb7wN1WHLSZ7L1W5iRUaGlzIGlzIGFuIGV4YW1wbGUgb2YgYSBzaWduZWQg
bWVzc2FnZS4=
=VoOD
-----END BITCOIN MESSAGE-----
Однако если вставить это сообщение
сюда, то адрес - он извлекается из цифровой подписи.
Message verified to be from 1HZwkjkeaoZfTSaJxDw6aKkxp45agDiEzN (address wasn't specified)
А теперь впихни эту подпись сюда, например:
https://reinproject.org/bitcoin-signature-tool/ и получишь
"Message verified to be from (address wasn't specified)"А здесь и здесь вообще надо адрес и само тело сообщения (ну тело по сути не нужно, чтобы узнать кто подписывал)
-
https://btc.coin.space/messages/verify-
https://github.com/gregorvolkmann/coinig.comПритом, я тебе описал саму логику. У тебя есть два ключа, один ящичек закрывает, второй - открывает. Ты ложишь туда письмо, закрываешь и отправляешь мне. Если у меня нет ключа, который открывает, то я очевидно его не открою.
Поэтому, сама ЕЦП чаще всего не содержит никакой информации, кроме (по сути) зашифрованного (читай подписаного) сообщения. А вот какая хэш функция использовалась (ты же должен знать каким алгоритмом расшифровывать) и необходимый ключ чаще всего рассылает отдельно. И называется
сертификатА вот это глупо.
Во-первых, сервер будет знать приватный ключ, а значит, наверняка, и админчег сервака, и/или хацкеры залезшие туда, байты подменять.
Что мешает генерировать клиент сайд?
Что мешает подменить публичный адрес и также обломать тебе работу на сайте?
Мы здесь вроде бы не говорим о финансовых организациях, там все равно без паспорта и морды никакой другой аутентификации не будет. А вроде бы говорим об обычных сайтах.
Во-вторых, при передаче возможен перехват этих данных третьей стороной,
Опять таки, клиент сайд генерация и нет проблем.
в частности, может быть реализована
MITM-атака, даже в случае использования HTTPS.
Ключ должен знать только клиент, и если он его потеряет, то всё.
В твоем варианте она тоже может быть использована вполне. Ничего не мешает вредному прокси серверу получить сообщение на подпись, переслать тебе, потом получить готовую подпись, отослать серверу и все, вуаля.
Поэтому кстати как раз и должна быть клиент сайд генерация
новой ключевой пары и секьюрный обмен публичным ключом (отправить его на сервер чтобы он знал о нем) ну или просто сертификат серверу отправить свой, самоподписный.