Blind Signature

При обычном заверении эмитент может записать номер ваучера вместе с его получателем. Когда магазин вернёт ваучер, записи можно связать. Чаум объяснял слепую подпись конвертом с копировальной бумагой: наружная печать переносится на лист внутри, номера которого эмитент не видит. Вынутый лист несёт действительное заверение. Это наглядная аналогия, а не безопасная инструкция с бумагой и печатью. Настоящий протокол использует числа и математику, чтобы такое разделение работало между компьютерами. [7] [1]

Анна хочет цифровой ваучер на 100 sats. Sats — мелкие единицы Bitcoin. Кошелёк — приложение для хранения этих ваучеров и оплаты ими — создаёт непредсказуемое секретное значение, отличающее ваучер, и математически маскирует его другим случайным значением. Это называют ослеплением. Эмитент получает скрытое сообщение, а не исходный секрет. Кошелёк сохраняет данные для последующего снятия маскировки. Переименовать файл или удалить имя недостаточно: ослепление должно обладать строго определёнными криптографическими свойствами. Для простоты мы используем один ваучер; настоящий кошелёк может составлять нужную сумму из нескольких ваучеров разных номиналов. [8] [2]

Слепая подпись не означает бесплатного подписания чего угодно для любого человека. Эмитент может сначала проверить платёж Анны или списать нужную сумму с её баланса. Он знает запрошенную стоимость 100 sats, но ему не нужен скрытый номер ваучера. Ключ подписи — секретное числовое значение, с помощью которого программа эмитента создаёт подписи. Стоимость можно связать с отдельным ключом подписи для данного номинала; изменение цифры в файле не создаст более дорогой ваучер. Эмитент подписывает скрытый ввод и возвращает результат. Так разделяются право Анны получить ваучер и способ распознать именно этот ваучер позднее. [7] [8]

Анне не нужно раскрывать исходный секрет эмитенту. Кошелёк сам удаляет случайную маскировку из полученного результата. Этот шаг называют unblinding. Правильно построенная процедура оставляет действительное заверение начального сообщения, не передавая кошельку приватный ключ подписи эмитента. Пользователь видит новую сумму, а математическая упаковка и распаковка происходят в фоне. Полученный цифровой документ часто называют токеном. Это не отдельный биткоин в блокчейне (общем реестре биткоин-транзакций), а требование к его эмитенту. [2] [8]

Проверка выясняет, соответствует ли заверение сообщению и правильному ключу эмитента. Для слепых подписей на основе криптосистемы RSA достаточно публичного ключа; другим конструкциям может понадобиться дополнительное доказательство или участие эмитента. Это не доказывает, что ваучер ещё не потрачен, что никто его не скопировал или что у эмитента достаточно резервов. Это три отдельных вопроса. Как настоящий, но уже использованный билет не даёт второго входа, так и криптографически действительный документ может не годиться для нового платежа. [2] [10]

Анна отправляет ваучер Петру. Поскольку это данные, она может сохранить такую же копию. Слепая подпись не удаляет файлы с её устройства. В обычной онлайн-системе кошелёк получателя поэтому предъявляет токен эмитенту. Он проверяет подлинность токена и выясняет, не был ли токен с тем же секретом уже потрачен. Приняв токен, он отмечает старый как использованный и может выдать Петру новый токен с помощью той же процедуры слепого подписания. Нового секрета Петра Анна не знает. Повторную попытку потратить старую копию отклонят по записям. Повторная трата тех же средств называется double spend, или двойной тратой; её предотвращение — другая часть платёжной системы. [9] [8]

Защита нужна и в обратную сторону: клиент не должен из разрешённых подписаний получать дополнительные действительные документы с новыми секретами. Это неподделываемость. Для слепых подписей отдельно изучают one-more unforgeability: может ли атакующий после определённого числа взаимодействий предъявить ещё одну новую действительную пару сообщения и подписи сверх этого числа? Копирование той же пары — предыдущая проблема. Правильная криптография также не заменяет серверные проверки прав, сумм и разрешённой структуры токенов. Вместе эти проверки могут предотвратить несанкционированный выпуск электронных денег. [2] [3]

Эмитент может знать, когда Анна получила токены и на какую сумму. При погашении ему могут быть известны время, сумма или сетевой адрес получателя. Это метаданные — сведения, сопровождающие платёжный документ. В небольшой группе пользователей необычная сумма или немедленный следующий платёж облегчают установление связи. Важны и общие проверенные ключи: ключ только для одного человека мог бы его пометить. Слепота протокола защищает конкретную связь подписи с выдачей, а не все окружающие сведения. Она также не исправит взломанный кошелёк и не заставит эмитента выполнить обязательства. [7] [2]

Идея Чаума лежит в основе электронных наличных, исторически связанных с DigiCash. Сегодня её используют Cashu и Fedimint в среде Bitcoin; связи с Lightning Network (сеть для быстрых биткоин-платежей) облегчают ввод и вывод средств. Однако их конструкции — не RSA. Базовый Cashu проверяет токен секретным ключом эмитента; NUT-12 добавляет доказательство для проверки подписи публичными данными, но не доказательство неизрасходованности токена. Fedimint распределяет управление между операторами. В обоих случаях пользователь держит требование к эмитенту и зависит от хранения им средств и его доступности. GNU Taler, например, сочетает приватность покупателя с прослеживаемостью доходов продавцов. [5] [6] [10] [4]

Упрощённую схему описывают несколько уравнений. Сообщение безопасно кодируют числом m; публичный ключ содержит n и e, приватную часть обозначают d. Заявитель выбирает случайное r с мультипликативным обратным r⁻¹ по модулю n и отправляет m′ = m·r^e mod n. Mod n означает вычисления с остатками от деления на n. Подписывающий возвращает s′ = (m′)^d mod n, а заявитель получает s = s′·r⁻¹ mod n. При проверке получается s^e mod n = m. Множитель r⁻¹ снимает маскировку. Эти соотношения объясняют механизм, но не являются готовой безопасной программой. RFC 9474 также определяет подготовку сообщения, схему RSA-PSS с безопасным кодированием, проверку входных данных и разделение ключей подписи. Важны случайность и правильный вариант протокола. [2] [3]