Публично подтвердите, что билет был выдан органом, содержащим около 8 цифр.

Я создаю серверную часть для веб-приложений, чтобы мы могли продавать билеты на наши мероприятия. Мероприятия колеблются от 100-700 гостей.

Мы продаем билеты онлайн, и мы хотели бы иметь возможность сканировать билеты на входе. Это делается с помощью штрих-кода-128. Но в случае, если невозможно отсканировать код, нужно иметь возможность ввести код и проверить его таким образом. Таким образом, код не должен быть длиннее примерно 12 цифр.

Поскольку в каком-то месте у нас нет интернета, перед фестивалем должна быть возможность скачать что-то вроде открытого ключа.

Я немного исследовал и нашел это. Что казалось прекрасным решением. Просто возьмите два идентификатора, такие как идентификатор события и заказа (возможно, хешируйте их), подпишите их и возьмите только первые или последние 5 цифр подписи и добавьте их к строке. Затем верификатор может проверить подпись. Но это означает, что проверка либо должна содержать закрытый ключ. Генерировать всю подпись и сравнивать только ее часть, иначе подпись будет очень длинной. Я прав? Мне это не нравится, потому что верификатор должен быть независим от продавца.

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

Потом я нашел это что кажется прекрасным. Но мне интересно, не слишком ли легко сломать FPE, поскольку контрольная сумма составляет всего от 5 до 8 цифр, и это не так много энтропии.

Должен ли я беспокоиться об этом? Или у кого-то есть другая, лучшая идея? Мои познания в криптографии очень ограничены. Может я что-то не так понял.

Шифрование с сохранением формата будет работать нормально. Изменение, которое я бы сделал, заключается не в том, чтобы использовать его как «контрольную сумму», а вместо этого просто взять номер билета (который может быть значением от 0 до, скажем, 699) и FPE зашифровать его как 12-значное число). Таким образом, вам не нужно беспокоиться об «ограниченной энтропии», потому что для ее взлома потребуется либо угадать ключ (что, если он 128 бит или больше, слишком сложно), либо случайным образом угадать и надеяться, что вы нажмете действительный ключ. штрих-код - в этом случае, если вы выдаете 1000 действительных билетов (и поэтому принимаются только значения, которые расшифровываются от 0 до 999), вероятность правильного угадывания равна $10^{3-12}$, то есть один на миллиард - не очень хорошие шансы.

Единственная проблема, которую я вижу с FPE, заключается в том, что нет общих реализаций (это позор - я считаю, что FPE - это в целом полезный инструмент).

Тем не менее, есть общедоступная альтернатива, которая будет работать так же хорошо — Коды аутентификации сообщений (МАК).

MAC работает как подпись, за исключением того, что нет отдельных ключей для подписи и проверки — вместо этого один ключ выполняет обе операции. Вы должны сгенерировать случайный ключ и передать его как эмитенту билетов, так и сканеру билетов (точно так же, как в идее FPE).

Что бы вы сделали, так это чтобы первые три цифры билета были серийным номером 000-999 (или 699, если у вас 700 гостей). Остальные цифры будут MAC первых трех цифр, преобразованных в десятичные (и усеченные соответствующим образом). Чтобы проверить билет, сканер возьмет первые три цифры, вычислит MAC (используя известный ему ключ) и проверит его до последних 9 цифр.

Это обеспечивает ту же безопасность, что и идея FPE, а реализации MAC легко доступны. Конечно, с FPE вам не нужно беспокоиться о преобразовании значений в десятичные числа (FPE могут работать непосредственно с десятичными значениями); стандартные MAC-адреса работают в двоичном формате, поэтому, чтобы сделать их десятичными, потребуется какое-то базовое преобразование; однако базовый код преобразования намного проще, чем рабочий код FPE.

Доступно несколько типов MAC; Я бы держался подальше от MAC с IV и придерживался HMAC, KMAC и CMAC.

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