Невозможность защищенной схемы "слепого HMAC" - аналога слепых подписей на основе HMAC - известна (я так понимаю, в основном из-за того, что пользователь не может проверить полученную подпись по открытому ключу для подписавшего, и, следовательно, невозможность убедиться, что подписывающая сторона не использует много ключей подписи, а затем «раскрыть» их, определив, какой из их ключей действителен для данной подписи).
Однако, с точки зрения производительности и размера подписи/MAC, HMAC часто предпочтительнее подписей, где приемлем верификатор, владеющий симметричным ключом подписывающей стороны.Например, подписи BLS (слепые или нет) в режиме минимального размера подписи с кривой BLS12-381. потреблять 384 бита с целью безопасности 128 бит - это, казалось бы, совсем коротко по сигнатурным меркам. В сравнении кажется, что, например, 128-битный хеш может обеспечить 128-битную защиту при использовании HMAC.
Будет ли в такой ситуации работать схема слепой аутентификации «полу-HMAC»? Что-то вроде:
- Пользователь генерирует и слепит сообщение с обычной схемой слепой подписи, отправляет подписывающему
- Подписывающая подписывает слепое сообщение и отправляет обратно пользователю
- Пользователь разблокирует ее и сверяет с открытым ключом подписавшего, как и с обычной слепой подписью — «слепой HMAC», как предложено и доказано небезопасно, на это не способен, но здесь это можно сделать, поскольку слепая подпись выполняется с помощью обычной асимметричной схемы слепой подписи, а аутентификация на основе хэша используется позже.
- Пользователь генерирует хэш сообщения и подписи (а не сообщения и ключа, как в HMAC) и прикрепляет его к сообщению.
- Пользователь отправляет сообщение и хэш верификатору
- Верификатор получает сообщение и независимо подписывает его закрытым ключом подписывающей стороны (совместно с верификатором, поскольку симметричные ключи используются в схемах HMAC).
- Верификатор сравнивает хэш, предоставленный пользователем, с тем, который он сгенерировал.
- Если хэши совпадают, пользователь подтверждает, что подписывающая сторона подписала сообщение, и на самом деле нет необходимости включать подпись длиннее, чем его хэш.
Похоже, что такая схема может уменьшить накладные расходы на хранение и передачу сравнительно длинных подписей верификатору.Кроме того, кажется, что требования к хэш-функции могут быть необычно малы — например, атака прообразом хэш-функции не представляет угрозы, поскольку обе стороны уже знают сообщение, использованное для ее создания, и атака, с помощью которой любая из сторон может сгенерировать коллизию хэшей (хэши используются только для доказательства того, что пользователь имеет действительную подпись для сообщения - пользователю необходимо знать хэш своего сообщения и действительную подпись для него, чтобы даже искать коллизию хэшей, приводящую к тому же хэшу, чтобы он соответствовал хешу, сгенерированному верификатором). На самом деле, хеш должен быть защищен только от того, что пользователь сможет успешно угадать хэш своего сообщения и действительную подпись без получения этой подписи, т. е. должно быть достаточно сложно взломать действительный хеш для сообщения «онлайн». , общение с верификатором. Перебор хэша в автономном режиме не кажется практичным, так как пользователь не может проверить предположение по хешу в своем сообщении в автономном режиме без также возможность преобразовать хэш в (гораздо более длинную, случайно действительную) подпись и проверить подпись по открытому ключу - им, вероятно, лучше попытаться подобрать действительную подпись или ключ подписи для базовой слепой подписи. схема, а затем сгенерируйте хэш этого.
Мне не удалось найти ссылки на какую-либо схему слепой аутентификации, которая работает подобным образом. Возможна ли такая схема? Есть ли в нем явные недостатки, безопасность или что-то еще?
TL; DR можно ли избежать известных недостатков безопасности слепой схемы HMAC без некоторых последствий размера подписи схемы слепой подписи, используя схему слепой подписи при подписании, но заставляя пользователя хэшировать подпись и повторно генерировать эту подпись и хэш на стороне верификатора с использованием закрытого ключа подписавшего, а затем сравнение хэшей?
