Насколько Случайный Система. Гуид. NewGuid ()? (Возьмите два),

Определение «Случайное» никоим образом не связано с определением «Глобально уникальное».

Дважды подбросить монету и получить HH, HT, TH, TT - все случайным образом. HH так же случайен, как и HT.

Подбросить «особую» монету дважды и гарантировать, что вы получите только HT или TH, - это уникальность.

Некоторые люди уже намекали на это, но я хочу повторить это, поскольку здесь, похоже, есть неправильное представление:

Случайность и уникальность - ортогональные концепции.

Случайные данные могут быть уникальными или избыточными, и точно так же уникальные данные могут использовать случайный источник или детерминированный источник (подумайте о глобальном счетчике, который заблокирован и увеличивается на единицу для каждого когда-либо созданного GUID).

GUID были разработаны так, чтобы быть уникальными, а не случайными. Если кажется, что генератор .NET использует случайный ввод, ничего страшного. Но не полагайтесь на него как на источник случайности ни в криптографических, ни в каких-либо других целях (в частности, какую функцию распределения вы ожидаете получить?). С другой стороны, вы можете быть уверены, что GUID, созданные .NET, даже в больших объемах, будут уникальными.

Я где-то читал, что шансы выиграть в лотерею будут эквивалентны столкновению двух 4-байтовых "GUID". Стандартные 16-байтовые GUID будут иметь гораздо меньше шансов на столкновение.

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

Идентификаторы GUID должны иметь номер 2 в вашей шкале, т.е. «могут использоваться для генерации идентификаторов в БД, поскольку дублирование маловероятно *.»

Что касается безопасности, проблема не в том, что «это не подходит для безопасность, потому что результаты можно предсказать, приложив достаточно усилий ». Проблема в том, что никто не дает вам документально подтвержденной гарантии безопасности.

На практике, в соответствии с этим комментарием и этим , генерация GUID реализуется в терминах криптографически безопасного RNG ( CryptGenRandom ). Но это, похоже, недокументированная деталь реализации. (И я это не проверял - это случайные комментарии в Интернете, возьмите с собой тучу соли).

(* Где «маловероятно» означает что-то вроде «шансы любого найти дублированный GUID до конца вселенной меньше, чем шансы лично выиграть в лотерею». За исключением ошибок реализации, конечно.)

Сосредоточение внимания на вашем вопросе с использованием GUID в качестве идентификаторов строк :

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

Метод COMB в упомянутой вами статье на самом деле кажется довольно хорошим. Я так и не понял, спасибо за это! ( p.s. версия этой статьи для печати гораздо лучше читается )

Так что, если вам не нужно заранее генерировать GUID, вы можете позволить базе данных обрабатывать генерацию GUID за вас. Различия в скорости вы заметите, только если начнете добавлять 10 000 записей за один раз, чего в любом случае делать не следует, для этого и нужен массовый импорт.

Также взгляните на Джеффа по ID и GUID

create table #temp ([id] uniqueidentifier primary key default(newid()), [name] varchar(20))
insert into #temp (name) values ('apple')
insert into #temp (name) values ('orange')
insert into #temp (name) values ('banana')
select * from #temp
drop table #temp

id                                   name
------------------------------------ --------------------
911B0CBD-4EED-4EB0-8488-1B2CDD915C02 banana
56CF3A80-A2DE-4949-9C9B-5F890824EA9C orange
5990B9FD-143D-41B0-89D1-957B2C57AB94 apple

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

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

public Guid CreateCryptographicallyStrongGuid() {
    var rng = new System.Security.Cryptography.RNGCryptoServiceProvider();
    var data = new byte[16];
    rng.GetBytes(data);
    return new Guid(data);
}

Эти идентификаторы GUID представляют собой просто 128 битов криптографической случайности. Они не структурированы и не будут сталкиваться.

См. эту статью для некоторых математических расчетов. Используя «Формулу общего дня рождения», перестановка дает

n = sqrt (-2T * ln (p))

, где n - количество выбранных элементов, T - общее количество элементов (2 ^ 128), а p - целевая вероятность того, что все n выбранных элементов будут разными. При p = 0,99 это дает * n = 2,61532104 * 10 ^ 18 *. Это означает, что мы можем сгенерировать миллиард действительно случайных GUID в секунду в системе в течение миллиарда секунд (32 года), и в конечном итоге с вероятностью более 99% каждый из них будет уникальным в системе.