Поиск симметричного алгоритма шифрования, оптимизированного для короткого и удобочитаемого зашифрованного текста

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

Но иногда пользователь ДОЛЖЕН использовать приложение в автономном режиме, И кэш данных поврежден, поэтому он не может войти в систему. Нет возможности доступа в Интернет, даже через точку доступа мобильного телефона, но по-прежнему критически важно быть в состоянии запустить приложение, и нет времени идти куда-то и пытаться найти подключение к интернету.

Поэтому мне было поручено внедрить метод входа в систему в автономном режиме, чтобы пользователь мог позвонить в службу технической поддержки со стационарного телефона на объекте и устно получить код, который они могут ввести, и программное обеспечение распознает его и обработает как действительную аутентификацию. Поскольку передача осуществляется с помощью человеческого голоса, этот код должен быть достаточно коротким и понятным для человека (т.не 100-символьная строка в кодировке base64).

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

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

Как это можно сделать?

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

Более подробно: вопрос требует (одноразовой) аутентификации, где

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

Основная проблема, которую я вижу, заключается в том, что «кеш данных поврежден»: чтобы проверить ввод, алгоритм должен сравнить результат с другим вводом.

Например, рассмотрим упрощенную процедуру входа в систему на основе хэша: Пользователь предоставляет пароль. Алгоритм принимает в качестве входных данных пароль вместе со строкой, предоставленной кешем данных; вычисляет хэш пароля и сравнивает его со строкой.

Если нет кеша данных, то алгоритм может использовать только жестко закодированный значения, то есть значения, поставляемые вместе с приложением и не зависящие от пользовательского ввода.

Комментарии: "чтобы текущая дата могла работать как одноразовый блокнот."

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

Вне области, поскольку это не считается безопасным, или в рамках вопроса ОП:

Если вам нужно жестко закодированное значение для определенного дня, самым простым способом для этого было бы жестко закодировать изображения односторонней функции (созданной с помощью криптографической хеш-функции) в приложении. Затем служба технической поддержки может предоставить удобочитаемую парольную фразу (см. Stackexchange: длинная фраза-пароль словаря, Stackexchange: зачем использовать случайные символы в pw? ), где у техподдержки есть "действующая кодовая фраза" на каждый день. Парольная фраза может быть введена пользователем; изображение которого будет сравниваться с жестко закодированными значениями, связанными с тем днем. Однако это небезопасно по нескольким причинам:

(1) Жестко закодированные значения

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

(2) Дата на самом деле не добавляет безопасности, за исключением того, что злоумышленник должен знать, что разные дни имеют разные парольные фразы.

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