UUID v3 небезопасен для генерации суррогатных ключей для API, поскольку он основан на MD5?

Question

Справочная информация: Я хочу создать суррогатные / альтернативные ключи в моей базе данных, чтобы я мог публично представить их в качестве моих идентификаторов ресурсов в моих конечных точках API следующим образом: GET /resources/{id}

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

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

Если данные имеют значениехранится в базе данных SQL Server.

Вопрос: Безопасно ли использовать UUID v3 / 5 таким образом, поскольку они основаны на MD5 / SHA-1?

Answer 1

Версия 3 устарела по причине.Нет никакого известного способа (кроме грубой силы) вернуться от UUID к названию, но у MD5 действительно есть проблемы, и атаки со временем только улучшаются.Если используемая вами библиотека еще не поддерживает версию 5, получите такую, которая ее поддерживает.

Для них обоих, если объем данных, попадающих в хеш, мал, то грубая сила может быть реальнойзабота о обеих версиях.Ответ заключается в том, чтобы использовать больше входных данных, т. Е. Достаточно, чтобы грубая сила больше не возможна.Точные параметры будут зависеть от того, что у вас есть в наличии, и насколько это вероятно