Я думаю, что это проблема XY, и на самом деле ее следует опубликовать на Программная инженерия SE. Задача, описанная в OP, генерация идентификаторов пользователей, может быть решена без какой-либо криптографии.
1. Масштабирование
Масштабирование актуально, когда нагрузка может существенно увеличиться за короткое время. Но новый идентификатор пользователя необходим только для новых пользователей. Одному пользователю обычно требуется от 1 до 5 минут для регистрации. Таким образом, у вас будет не более 1 нового идентификатора на пользователя в минуту.
Многие базы данных предоставляют генераторы идентификаторов. PostreSQL, MariaDB, Oracle предоставляют генераторы, называемые «последовательностями». MySQL предоставляет автоинкрементный идентификатор. Мало того, что это быстро при прямом использовании, эти базы данных обеспечивают дополнительную оптимизацию производительности, например пулы идентификаторов. Такие платформы, как Java и C#, хорошо интегрируются с этими генераторами идентификаторов. По сути, генерация нового идентификатора означает просто увеличение целого числа, а запросы к базе данных требуются очень редко.
Пример: Предположим, вы используете PostgreSQL и последовательность с пулом из 10 000 идентификаторов.Предположим, что запрос от приложения к базе данных для обновления диапазона пула занимает 10 мс. Таким образом, вы можете генерировать 1 000 000 новых идентификаторов в секунду для каждого экземпляра приложения (т. е. для каждого узла кластера, для каждого модуля Kubernetes и т. д.). Этот генератор произведет за 2 часа столько удостоверений личности, сколько людей во всем мире.
Очевидно, что использование такого стандартного генератора идентификаторов пользователей не будет узким местом.
2. Укорочение
Сколько данных вы собираетесь хранить на пользователя? 1К, 10К, 100К? Предположим, у вас есть 1 КБ данных на пользователя. Предположим, у вас столько же пользователей, сколько Facebook или Twitter. Таким образом, 4 байта для идентификатора будет достаточно. Усечение SHA-256 с 32 до 4 байт экономит 28 байт на пользователя, что составляет менее 3% экономии места в хранилище. Таким образом, сложность найти алгоритм преобразования SHA-256 в 4 байта без большого количества коллизий, усилия по его правильной реализации, усилия по реализации обработки случаев, когда происходят коллизии, усилия по исправлению ошибок и, следовательно, общие затраты такого решения может быть намного выше, чем затраты на 3% сэкономленного хранилища. Вычислите его, и тогда вы будете знать, имеет ли это смысл в вашем случае.
