Версии 1 и 2 имеют дополнительное поле Clock sequence, которое защищает от ненадёжного течения времени.
Насколько защищают? Гарантированно защищают или «чуть-чуть» защищают? Можете предоставить качественное сравнение, скажем с UUID4?
Чем данный ритуал принципиально отличается от случайной генерации MAC, кроме того, что полагается на благоразумность производителя, требует финансовых затрат и бесмысленных усилий?
Каким образом такой подход защищает от ситуации, когда админ скопирует MAC системы, на которой выполняется генерация (или клонирует виртуальную машину)?
Смысл ритуала в том, чтобы завести систему, в памяти которой MAC, которого больше нигде нет. Вариант «админ скопирует» нужно давить организационно, для этого и условие «за пределы системы его не сообщать».
Если при этом в системе ещё и отследить любые переводы часов назад, и на каждом такому переводе увеличивать счётчик, помещаемый в Clock sequence, то получается UUID, которые действительно 100% не будут повторяться, пока счётчик не переполнится. В Clock sequence 14 бит.
Разумеется, это затратная штука. И, очевидно, уязвимая на практике. Простому разрабу обычно ничего этого не нужно. Но… жизнь сложная и разнообразная, и иногда попадаются, скажем так, особенные заказчики и ситуации. Поэтому, по-моему, не стоит забывать про такое использование версии 1, хотя бы чтобы не изобретать велосипеды, если вдруг.
Подскажите, а зачем вам воспроизводимость идентификаторов? Точнее, зачем вам идентификаторы, которые необходимо воспроизводить? Можно ли значения, которые необходимо воспроизводить, называть идентификаторами?
Зачем? Чтобы поместить в общее пространство идентификаторов UUID нечто частное, что обычно идентифицируется строками, так что у людей в сознании есть только строки. UUIDы при этом зачем-то технологически нужны, но получается так, что map строк в UUID некому отслеживать. А новые строки время от времени появляются.
UUID – universally unique identifier. Это значит, что он должен быть глобально уникальным, а не только в рамках некоторой системы. Хеш, взятый от простой строки, нельзя считать уникальным. Как планируете гарантировать глобальную уникальность?
Версия 4 не гарантирует глобальной уникальности, а даёт её только с некоторой вероятностью. Это как-то никому не мешает.
Вероятность коллизий невелика
Какая?
Обычная для хеша. Раз используется 122 бита от хеша, значит, 2^-61. Это хуже, чем версия 4, и обычно лучше к этому не прибегать. Это костыль, он несколько портит глобальную уникальность, но за счёт него можно состыковать сценарии и данные, с которыми иначе не получается.
И да, пока в тупик никто не загнал, пользуйтесь только версией 4. Я с этим не спорю, только хочу заметить, что у других есть свои, очень узкие и ненормальные сферы применения. Количественные оценки у всех версий есть, но с учётом затрат у версии 4 они почти всегда лучше.
Версии 1 и 2 имеют дополнительное поле Clock sequence, которое защищает от ненадёжного течения времени. Оно заполняется рандомом либо отслеживается в системе и инкрементируется, когда часы сдвигаются назад.
Что до ненадёжности MAC, то даже от этого в принципе есть кое-какое средство: купить отдельную сетевую карту от приличного производителя, записать её MAC, уничтожить её физически, генерить UUID с записанным MAC и за пределы генерящей системы его не сообщать. Конечно, затратно. Но с таким MAC, нормальными часами и Clock sequence версия 1 даёт хотя бы призрачный шанс сделать UUID действительно 100% уникальным для тех, кому это по странному ТЗ действительно надо.
Что касается версий 3 и 5, они, строго говоря, не для ввода UUID от пользователей или внешних источников. Они годны лишь для специальных сценариев – есть, представим, стандартная библиотека .NET, и надо каждому классу в ней назначить UUID. Причём чтоб он не менялся между версиями и правками. Руками создавать их и вставлять в код муторно, есть немаленький шанс ошибки copy+paste. Но можно из имён классов (вместе с namespace) их сгенерить именно в виде хеша. Хеш даст повторяемость. Использование стандартного UUID позволит их смешивать с редкими назначенными вручную (уже версии 4). Вероятность коллизий невелика, и от них даже можно защититься. Криптографически стойкая необратимость тут даром никому не нужна.
Так что на разные задачи подойдут разные версии. На типовой уникальный идентификатор – да, версия 4 лучше всего, качественный генератор случайных чисел – обязателен.
Если при этом в системе ещё и отследить любые переводы часов назад, и на каждом такому переводе увеличивать счётчик, помещаемый в Clock sequence, то получается UUID, которые действительно 100% не будут повторяться, пока счётчик не переполнится. В Clock sequence 14 бит.
Разумеется, это затратная штука. И, очевидно, уязвимая на практике. Простому разрабу обычно ничего этого не нужно. Но… жизнь сложная и разнообразная, и иногда попадаются, скажем так, особенные заказчики и ситуации. Поэтому, по-моему, не стоит забывать про такое использование версии 1, хотя бы чтобы не изобретать велосипеды, если вдруг.
Зачем? Чтобы поместить в общее пространство идентификаторов UUID нечто частное, что обычно идентифицируется строками, так что у людей в сознании есть только строки. UUIDы при этом зачем-то технологически нужны, но получается так, что map строк в UUID некому отслеживать. А новые строки время от времени появляются.
Версия 4 не гарантирует глобальной уникальности, а даёт её только с некоторой вероятностью. Это как-то никому не мешает.
Обычная для хеша. Раз используется 122 бита от хеша, значит, 2^-61. Это хуже, чем версия 4, и обычно лучше к этому не прибегать. Это костыль, он несколько портит глобальную уникальность, но за счёт него можно состыковать сценарии и данные, с которыми иначе не получается.
И да, пока в тупик никто не загнал, пользуйтесь только версией 4. Я с этим не спорю, только хочу заметить, что у других есть свои, очень узкие и ненормальные сферы применения. Количественные оценки у всех версий есть, но с учётом затрат у версии 4 они почти всегда лучше.
Версии 1 и 2 имеют дополнительное поле Clock sequence, которое защищает от ненадёжного течения времени. Оно заполняется рандомом либо отслеживается в системе и инкрементируется, когда часы сдвигаются назад.
Что до ненадёжности MAC, то даже от этого в принципе есть кое-какое средство: купить отдельную сетевую карту от приличного производителя, записать её MAC, уничтожить её физически, генерить UUID с записанным MAC и за пределы генерящей системы его не сообщать. Конечно, затратно. Но с таким MAC, нормальными часами и Clock sequence версия 1 даёт хотя бы призрачный шанс сделать UUID действительно 100% уникальным для тех, кому это по странному ТЗ действительно надо.
Что касается версий 3 и 5, они, строго говоря, не для ввода UUID от пользователей или внешних источников. Они годны лишь для специальных сценариев – есть, представим, стандартная библиотека .NET, и надо каждому классу в ней назначить UUID. Причём чтоб он не менялся между версиями и правками. Руками создавать их и вставлять в код муторно, есть немаленький шанс ошибки copy+paste. Но можно из имён классов (вместе с namespace) их сгенерить именно в виде хеша. Хеш даст повторяемость. Использование стандартного UUID позволит их смешивать с редкими назначенными вручную (уже версии 4). Вероятность коллизий невелика, и от них даже можно защититься. Криптографически стойкая необратимость тут даром никому не нужна.
Так что на разные задачи подойдут разные версии. На типовой уникальный идентификатор – да, версия 4 лучше всего, качественный генератор случайных чисел – обязателен.