Зіткнення UUID [закрито]

Хто-небудь проводив реальне дослідження щодо ймовірності зіткнень UUID, особливо з версіями 4 (випадкових) UUID, враховуючи, що генератори випадкових чисел, які ми використовуємо, не є справді випадковими, і що ми можемо мати десятки чи сотні однакових машин, що працюють з тим самим кодом генерування UUID?

Мої співробітники вважають тестування на зіткнення UUID повним марнуванням часу, але я завжди ввожу код, щоб вийняти з бази даних дублікат ключових винятків і повторити спробу з новим UUID. Але це не вирішить проблему, якщо UUID походить від іншого процесу і посилається на реальний об'єкт.

У Вікіпедії є деякі деталі:

http://en.wikipedia.org/wiki/Universally_unique_identifier

http://en.wikipedia.org/wiki/Universally_unique_identifier#Random_UUID_probability_of_duplicates

Але ймовірність має місце лише в тому випадку, якщо біти є абсолютно випадковими. Однак RFC http://tools.ietf.org/html/rfc4122#page-14, пов'язаний в іншій відповіді, визначає це для версії 4:

"4.4. [...] Версія 4 UUID призначена для генерації UUID з справді випадкових чи псевдовипадкових чисел. [...] Встановіть усі інші біти на випадково (або псевдо випадковим чином) обрані значення."

Це в значній мірі дозволяє все, від випадкового генератора xkcd http://xkcd.com/221/ до апаратного пристрою, що використовує квантовий шум. Міркування безпеки в RFC:

"6. Розподілені програми, що генерують UUID на різних хостах, повинні бути готові покладатися на джерело випадкових чисел у всіх хостів. Якщо це неможливо, слід використовувати варіант простору імен."

Я читаю це як: Ти сам. Ви несете відповідальність за свій випадковий генератор у власній програмі, але це та все інше базується на довірі. Якщо ви не довіряєте своїй власній здатності правильно розуміти та використовувати випадковий генератор, який ви обрали, то справді корисно перевірити наявність колізій. Якщо ви не довіряєте програмісту інших процесів, перевірте наявність колізій або використовуйте іншу версію UUID.

Ви, безумовно, повинні виявити, якщо трапиться зіткнення, і ваша програма повинна викинути виняток, якщо це сталося. Наприклад, якщо UUID використовується в якості основного ключа в базі даних, тоді база даних повинна видавати помилку під час вставки ідентифікатора, що стикається.

Однак я вважаю, що написання коду для створення нового UUID у випадку зіткнення та спроби знову бути марною тратою часу. Шанс виникнення зіткнення настільки малий, що кидання винятку було б цілком розумним способом боротьби з ним.

Пам'ятайте, що це не лише витрата власного часу на написання коду, але й робить його складнішим, ускладнюючи читати наступну людину, бо майже не отримує жодної вигоди.

Це дуже гарне запитання. Я не вірю, що належним чином було розглянуто поспіх використовувати UUID скрізь. Я не знайшов жодного ґрунтовного дослідження.

Пропозиція: дуже уважно ступайте тут і добре знайте свою криптографію. Якщо ви використовуєте 128-розрядний UUID, "ефект від дня народження" говорить нам про те, що зіткнення вірогідне після того, як ви створили приблизно 2 ^ 64 ключі, за умови, що у вас є 128 біт ентропії в кожній клавіші .

Насправді досить складно забезпечити, що це так. Справжня випадковість може бути породжена (a) радіоактивним розпадом (b) випадковим фоновим радіо шумом, часто забрудненим, якщо ви не обережні (c) належним чином обраний електронний шум, наприклад, взято з реверсивно зміщеного стабілітрону. (Я грав з останнім, і це працює як шарм, BTW).

Я б не довіряв вимовам на кшталт "Я цього не бачив за рік використання", якщо користувач не створив щось, що наближається до клавіш 2 ^ 64 (тобто приблизно 10 ^ 19), і не перевірив їх один на одного, a нетривіальна вправа.

Проблема в цьому. Скажімо, у вас всього 100 біт ентропії, порівнюючи ваші ключі з усіма іншими ключами, які всі інші генерують у загальному просторі клавіш. Ви почнете бачити зіткнення приблизно в 2 ^ 50, тобто. приблизно 10 ^ 15 клавіш. Ваші шанси побачити зіткнення, якщо ви заселили свою базу даних лише у 1000 мільярдів ключів, все ще незначні. І якщо ви не перевірите, то пізніше ви отримаєте несподівані помилки, які прокрадаються у вашу базу даних розміром з п'яти рядками. Це могло б сильно вкусити.

Сам факт наявності декількох підходів до створення таких UUID повинен викликати миттєвий спазм занепокоєння. Коли ви усвідомлюєте, що мало хто з генераторів використовує «справді випадкові» процеси з достатньою ентропією для UUID типу 4, ви повинні надто хвилюватися, якщо ви ретельно не вивчили вміст ентропії генератора. (Більшість людей цього не зробить і навіть не знає, як це зробити; ви можете почати з набору DieHarder). НЕ плутати генерацію псевдовипадкових чисел із справжнім генерацією випадкових чисел.

Важливо, що ви усвідомлюєте, що введена вами ентропія - це ентропія, яка у вас є, і просто збурення ключа, застосовуючи криптографічну функцію, не змінює ентропію. Можливо, не очевидно, що якщо весь мій простір містить цифри 0 та 1, вміст ентропії такий самий, як у наступних двох рядків, за умови, що вони є єдиними двома варіантами: "Це дійсно дійсно складний рядок 293290729382832 * ! @@ # & ^% $$) ,. m} "та" І СЕЙЧАС ДЛЯ НЕЩОГО ПОЛІЗНОГО РІЗНОГО ". Є ще лише два варіанти.

Випадковість складна, щоб виправитись, і просто вважати, що "експерти це подивилися, тому це нормально" може бути недостатньо. Експертні криптографи (а їх мало хто з тих, хто справді досвідчений) першими визнають, що вони часто помиляються. Ми довіряли сердечному сервісу, DigiNotar тощо.

Я думаю, що Пол Томблін проявляє відповідну обережність. Мій 2с.

Проблема у вас полягає в тому, що якщо ви використовуєте "Генератор випадкових чисел" і не знаєте, наскільки випадковий цей генератор, то ймовірність зіткнення насправді невідома. Якщо генератори випадкових чисел якимось чином співвідносяться, ймовірність зіткнення може різко зрости - можливо, багато, багато порядків або величини.

Навіть якщо у вас дуже мала ймовірність зіткнення, у вас є принципова проблема: Ймовірність НЕ 0. Це означає, що зіткнення ВИКОНУТЬСЯ, вони просто не трапляться дуже часто.

Чим частіше ви генеруєте та використовуєте UUID, тим швидше буде помічено зіткнення. (генерувати 1 рік на рік означає довший час очікування, ніж генерувати мільйон в секунду; всі інші речі рівні).

Якщо ця ймовірність є кінцевою, невідомою, і ви використовуєте багато UUID, тоді вам потрібно врахувати наслідки зіткнення. Якщо неприйнятно кидати виняток і закривати діловий додаток, тоді не робіть цього! (Приклади вгорі голови: "Добре вимкнути веб-сервер посеред оновлення перевірки бібліотеки ... це не траплятиметься часто" і "Це нормально, щоб закрити систему оплати праці в середині ведення оплати праці ". Ці рішення можуть бути кроками, що обмежують кар'єру.)

У вас може бути гірший випадок, знову ж таки, залежно від вашої заявки. Якщо ви перевірите наявність UUID (тобто зробите пошук), а потім зробите новий, якщо його ще немає - що є досить поширеною справою, - ви можете виявити, що ви зв'язуєте записи або встановлюєте зв’язки , насправді ви підключаєте дві речі через UUID, які не слід підключати. Це щось, коли кидання винятку нічого не вирішить, і у вас десь створений нерозбірливий безлад. Це та річ, яка призводить до витоку інформації і може бути дуже незручною. (наприклад: Увійдіть у свій банк і знайдете, що ви бачите залишки на рахунку когось іншого! Погано!)

Підсумок: вам потрібно врахувати спосіб використання ваших UUID та наслідки зіткнення. Це визначає, чи слід подбати про виявлення та уникнення зіткнень, вчинити прості дії у разі зіткнення чи нічого не робити. Просте, єдине, універсальне рішення, за певних обставин, ймовірно, буде недоцільним.

Є два питання:

1. Якість генераторів випадкових чисел, які використовуються.

2. Кількість UUID, які можуть бути створені.

"Випадковий" UUID має 122 випадкових біта. Якщо припустити ідеальну випадковість, ви можете очікувати першого зіткнення приблизно в 2 ^ 61 породжених UUID (це квадратний корінь 2 ^ 122). Якби всі на цій землі генерували UUID в секунду, це 10 000 000 000 * 365 * 24 * 60 * 60 = 315360000000000000 UUID на рік, що досить близько до 2 ^ 58. Тобто через кілька років у вас виникнуть перші зіткнення. Якщо ваша програма не опиниться поблизу цих номерів, ви можете бути впевнені, що ви не зіткнетесь, якщо ваш випадковий генератор гідної якості.

Якщо говорити про генератор випадкових чисел: Якщо ви використовуєте стандартні генератори бібліотек С (безпосередньо, опосередковано або подібні генератори), ймовірно, висіваючи їх з часом, ви закручуєтесь. Вони не можуть мати достатню кількість ентропії, щоб уникнути зіткнень. Однак якщо ви користуєтесь Linux, просто прочитайте 16 байт даних з /dev/urandom: Це спирається на пул ентропії, який перемішується ядром, який має доступ до деяких реальних випадкових подій. Якщо ви зазвичай не генеруєте UUID, дійсно, дуже рано послідовність завантаження /dev/urandomповинна поводитись як справжнє випадкове джерело.

Я тестував це один раз, використовуючи досить просту (грубу силу) програму, яка генерувала 10 мільйонів UUID -ів, і я не зазнав зіткнення.

UUID RFC каже , що UUID не просто купа (псевдо) випадкових чисел.