Antes de empezar a marcar esto como un duplicado, leer conmigo. La otra pregunta tiene una (lo más probable) incorrecta aceptado respuesta.

No sé cómo .NET genera su Guid, probablemente sólo de Microsoft, pero hay una alta probabilidad de que simplemente llama a CoCreateGuid(). Esa función, sin embargo, está documentado que estar llamando a UuidCreate(). Y los algoritmos para la creación de un UUID son muy bien documentado.

Cortocircuito largo de la historia, sea como sea, parece que System.Guid.NewGuid(), de hecho, utiliza la versión 4 UUID algoritmo de generación de, porque todos los Guid se genera coincide con los criterios (ver por ti mismo, he intentado un par de millones de Guid, todos coincidían).

En otras palabras, estos Guid casi al azar, excepto por un par de conocidos bits.

Esto, de nuevo se plantea la pregunta – ¿cómo azar ES azar? Como todo buen poco programador sabe, una pseudo-aleatorio de algoritmo es tan aleatorio como su semilla (también conocido como entropía). Entonces, ¿qué es la semilla para UuidCreate()? Cómo se presenta especialmente es el PRNG re-sembrado? Es criptográficamente fuerte, o puedo esperar el mismo Guid para comenzar a verter si dos equipos accidentalmente llamada System.Guid.NewGuid() al mismo tiempo? Y puede que el estado de la PRNG adivinar si son lo suficientemente numerosos forma secuencial generado los Guid se reunieron?

Añadido: Para aclarar, me gustaría saber cómo aleatorio puedo confiar en ella y por lo tanto – ¿dónde la puedo utilizar. Por lo tanto, vamos a establecer un áspero «aleatoriedad» escala de aquí:

  1. Básicos de la aleatoriedad, tomando el tiempo actual como el de la semilla. Utilizable para barajar las cartas en Solitario, pero poco más como las colisiones son demasiado fáciles de encontrar, incluso sin tratar.
  2. Más avanzadas de la aleatoriedad, no solo en el tiempo, pero otros específicos de la máquina factores de semillas. Tal vez sembradas también sólo una vez en el inicio del sistema. Esto puede ser usado para la generación de Identificadores en un DB porque duplicados es raro. Aun así, no es bueno para la seguridad, porque los resultados se pueden predecir con suficiente esfuerzo.
  3. Cryptograhpically aleatoria, utilizando el dispositivo de ruido u otras avanzadas fuentes de aleatoriedad para semilla. Re-sembrado en cada invocación o al menos, bastante a menudo. Puede ser utilizado para los Identificadores de sesión, repartido a partes que no son de confianza, etc.

Llegué a esta pregunta, mientras que el pensar si es que se puede utilizar como DB IDs, y si el Guid.peine implementación del algoritmo junto con System.Guid.NewGuid() (como NHibernate no sería erróneo o no.

  • Puede que desee aclarar si su objetivo es: (a) generar pseudo-aleatoria de valores, o (b) generar un millón de millones de Guid y tener una idea de la probabilidad de colisión.
  • Si el azar es fundamental para usted, entonces estoy seguro de que estás mejor de usar algo que ha sido diseñado para la aleatoriedad en lugar de utilizar un GUID.
  • posibles duplicados de stackoverflow.com/questions/467271/…
  • Wow! Parece que leer muy bien, sobre todo la primera frase…
  • No importa si la aceptan respuesta es incorrecta, la pregunta sigue siendo la misma. Y sí, he leído las dos preguntas.
  • Bajo las cubiertas Guid.NewGuid() llamadas Win32Native.CoCreateGuid.

InformationsquelleAutor Vilx- | 2010-04-12

9 Comentarios

  1. 34

    La respuesta es: no debe Usted necesita saber esto. Como se dijo en respuesta a una una pregunta relacionada con la:

    Un GUID no ofrece garantías acerca de la aleatoriedad, hace que garantizan la unicidad.

    Aún más la declaración sobre la seguridad y la aleatoriedad se realiza en RFC4122, que speficies el UUID formato:

    No asuma que los Uuid son difíciles de adivinar; no deben ser utilizados
    como las capacidades de seguridad (identificadores cuya mera posesión de subvenciones
    acceso), por ejemplo. Una predicción de números aleatorios fuente
    agravar la situación.

    Nada, es un detalle de implementación (y podría ser objeto de cambio).

    Windows detalles

    A menudo, las personas afirman que el comportamiento en Windows está documentado y que por lo tanto, es garantizado que los Guid se criptográficamente seguro.

    La archivadas ahora [MS-SECO] de Seguridad de Windows vista general documento menciona en el Apéndice a:

    Aunque sólo una pequeña minoría de la versión 4 Guid requieren
    de cifrado de aleatoriedad, los bits aleatorios para todos los de la versión 4 Guid construido en Windows se obtienen
    a través de las Ventanas CryptGenRandom API criptográfica o el equivalente, en la misma fuente que se utiliza
    para la generación de claves criptográficas.

    Por otra parte, la sección 2.5.5 del mismo documento menciona explícitamente el uso de «secreto GUID» valores como nonce o autenticador.

    PERO: Este pedazo de comportamiento de la documentación no es una especificación que generalmente se puede basar la seguridad de su producto (en particular en el contexto de .NET).

    De hecho, el documento describe un detalle de implementación de un producto en particular.
    Incluso si la corriente de Windows y .NET Framework 4.x implementaciones de producir verdaderamente aleatorios versión 4 valores UUID en Windows, no hay ninguna garantía de que System.Guid.NewGuid lo harán en el futuro o en otras .RED de plataformas (por ejemplo, Mono, Silverlight, CF .NET Core, etc).

    Sólo como un ejemplo, el UUID algoritmo utilizado en versiones anteriores de .NET Core depende de la plataforma y que podría llegar una versión 1 UUID (BSD).

    • Buena respuesta en la seguridad de la vista. Confío GUID para ser únicos, para los identificadores de registro, pero no dependen de ellos para la determinación de la seguridad de la aplicación.
    • Es gracioso, consulte el RFC pero echo de menos la sección 4.4 y 4.5. Se afirma aquí que la V4 Uuid (que Windows 2000 y, posteriormente, usa) se basan en verdad-aleatorio o pseudo-aleatorio de números.
    • el RFC dice que puede generar los Uuid de fuentes aleatorias, no que todos V4 Uuid son verdaderamente aleatorios. Si la fuente utilizada para generar su V4 Uuid es pseudo-aleatorio y es predecible, usted todavía tiene el problema de que al azar v4 Uuid no pueden ser difíciles de adivinar.
    • Si no hay ningún requisito con respecto a la distribución al azar de los UUID de las secuencias, ¿cómo puede uno hacer significativas las declaraciones acerca de la probabilidad de que las secuencias de los Uuid generados por completo independiente de las entidades no contendrá algunos miembros compartidos? Para estar seguro, uno probablemente no necesita un total de 120 bits de entropía por GUID para evitar colisiones en escenarios realistas, pero uno necesita un poco de.
    • ¿qué quiere decir «compartir miembros»? ¿Te refieres a pedazos? Por qué crees que los Uuid no debe contener algunos (o muchos) compartido bits? El único requisito IIUC es que 2 Uuid no compartir todo bits. Por lo que vale me def no profesan ser un experto aquí.
    • Por «miembros» me refiero a cualquier tipo de datos, lo que contribuye a la UUID. El problema es que si dos entidades independientes, cada uno decide que un UUID debe consistir en alguna combinación fija de bits a lo largo de, por ejemplo, con un verdadero de 32 bits de números aleatorios, entonces si que el fabricante de dispositivos del problema nunca más de un par de cientos o miles de Uuid, la probabilidad de cualquier dispositivo UUID de chocar con cualquier otro UUID del mismo fabricante sería leve, pero si varios fabricantes de pasar a utilizar la misma fórmula, la probabilidad de colisión podría ser mucho peor.
    • Sólo preguntaba si tenía una fuente de la afirmación de que .NET 3.5 no es verdaderamente aleatorio GUID? Si es así, me he hecho una pregunta aquí: stackoverflow.com/questions/35366368/… pidiendo una respuesta canónica sobre el tema, que me gustaría invitar a usted a la respuesta.
    • Es más bien al revés. La documentación de no hacer ningún tipo de garantía sobre la aleatoriedad de la producción de valor, de modo que no podemos afirmar que se produce un «azar» de salida. Incluso es el resultado iba a cumplir algún bien definido criterios de aleatoriedad, este sería un detalle de implementación que no están respaldadas por el docs / RFC.
    • Lo siento downvote, pero no estoy de acuerdo que el RFC es más importante que la MS de la aplicación. Especialmente cuando MS de la aplicación está documentado (aunque bastante difícil de encontrar en MSDN). Consulte stackoverflow.com/a/50574817/284704.

  2. 19

    Algunas personas ya han insinuado que pero quiero repetirlo ya que no parece ser una idea errónea de lo que hay:

    La aleatoriedad y la singularidad son ortogonales conceptos.

    Datos aleatorios puede ser única o redundante, y de la misma manera única de datos puede utilizar un origen aleatorio o determinista de la fuente (creo que un contador global que está bloqueado y se incrementa en cada GUID jamás creado).

    Guid se han diseñado para ser único, no al azar. Si el .NET generador aparece el uso aleatorio de entrada, bien. Pero no confía en él como una fuente de aleatoriedad, ni para criptográfica, ni para otros propósitos (en particular, ¿qué función de distribución de hacer que usted espera conseguir?). Por otro lado, puede estar razonablemente seguro de que los Guid creado por .NET, incluso en grandes volúmenes, será único.

    • Eso es una gran explicación.
    • Lo siento, no estoy de acuerdo. Si es independiente de las máquinas en el mundo a crear Guid, la más mínima posibilidad de colisión puede lograr si cada máquina crea un verdaderamente aleatorios GUID (y que son lo suficientemente grandes, para hacer que la probabilidad de colisiones astronómicamente pequeña) – cualquier desviación de completar el azar, la voluntad de disminuir la entropía y aumentar la probabilidad de dos máquinas en las mismas condiciones de partida para producir el mismo GUID
    • Esto es cierto sólo si la máquina de partes específicas de la UUID tienen una mayor probabilidad de colisión de la entropía de la verdad al azar de los datos de la misma longitud en bits. — Esto es una advertencia importante. En la práctica, usted puede estar en lo cierto, y AFAIK la mayoría de los UUID de las implementaciones son, por tanto, el uso de una especificación que es puramente basado en datos aleatorios (versión 4). Pero esto es un detalle de implementación tan lejos como Uuid se refiere. Eso es lo que mi respuesta está señalando.
    • y yo simplemente no puede pensar una máquina parámetro dependiente, que incluso podría teóricamente proporcionan menos colisiones de verdadera aleatoriedad para la masa de la creación de identificadores en el mismo sistema, así como en diferentes sistemas. Parece imposible.
    • Isbn (libros) son un ejemplo de ello (de hecho, no son duplicar Isbn debido a que los productores son idiotas, pero que puede ser único con una nota adicional, por un total de al menos de un GUID de longitud). Otros ejemplos son las direcciones: tanto virtuales (IPs, Uri) y físico (postal).
    • todos estos necesitan un registro central, o la sincronización de la información a través de diferentes sistemas, o con bisagras muy limitado de parámetros (dirección postal posición). Cualquier número de sistemas (incluyendo copias idénticas de máquinas virtuales) debe ser capaz de generar un número arbitrario de Guid sin colisiones en todo el mundo. Ninguno de los ejemplos se acerque siquiera a la prestación de este. – Lo que significa que debe ser capaz de crear un millón de Guid en dos idénticos, pero desconectado de los servidores en el mismo lugar.
    • Funciona para servidores desconectados una vez que usted está de acuerdo en global único de prefijos. Que, de hecho, ¿cuántos de estos sistemas de trabajo, por ejemplo, Isbn, que no tienen ninguna global de sincronización de ningún tipo. De nuevo, no estoy argumentando que sería más fácil de azar Guid, simplemente que es posible.
    • Permítanos continuar esta discusión en el chat.

  3. 8

    Api que producen bytes aleatorios, pero que no están explícitamente documentados para producir criptográficamente fuerte bytes aleatorios no pueden ser de confianza para producir criptográficamente fuerte bytes aleatorios.

    Si usted necesita criptográficamente fuerte bytes aleatorios, entonces usted debe utilizar un API que es explícitamente documentados para producirlos.

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

    Estos Guid simplemente 128 bits de cifrado de aleatoriedad. Ellos no están estructurados, y no van a chocar.

    Ver este artículo para algunas de las matemáticas. El uso de «El General de Cumpleaños Fórmula», la reorganización da

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

    donde n es el número de elementos elegidos, T es el número total de elementos (2^128), y p es el destino probabilidad de que todos n elementos elegidos serán diferentes. Con p = .99, esto da *n = 2.61532104 * 10^18*. Esto significa que podemos generar un mil millones verdaderamente aleatorios Guid por segundo dentro de un sistema de un mil millones de segundos (de 32 años), y tiene más de 99% de probabilidad al final que cada uno es único dentro del sistema.

    • Esto podría producir pseude-valores aleatorios, pero pierdes la garantía de que el guid generado es único (aunque la probabilidad de una colisión tiene una baja probabilidad si sólo generar unos valores).
    • Lo que si puedo generar altos volúmenes de Guid en muchos equipos de la red? (Piensa: muy utilizado negocio de la aplicación que utiliza el Guid para todos sus claves principales en la DB).
    • Incluso si usted genera muchos Guid en muchos equipos de la red los valores son únicos, véase Raymond Chen post: blogs.msdn.com/oldnewthing/archive/2008/06/27/8659071.aspx (aunque si se cree suficiente muchas Guid usted va a obtener finalmente una colisión, pero supongo que el universo dejará de existir en ese punto en el tiempo).
    • que post los detalles de una antigua GUID algoritmo de generación (versión 1 UUID) que no ha sido utilizado por más de una década. Ver mi enlace de Wikipedia sobre el UUID y re-leer mi post. Y me estaba preguntando acerca de la unicidad de la anterior fragmento de código.
    • ¿Este fragmento de código generar Guid válido? No veo donde configurar los bits que indican el tipo de GUID.
    • Yo no creo que sea un requisito que el GUID debe tener los bits especiales. Algunos de los algoritmos de hacer eso (incluyendo la que Microsoft se incluye con Windows), pero no es incorrecto para crear completamente al azar queridos.
    • Editado por los comentarios adicionales y matemáticas.
    • De acuerdo a RFC4122 (tools.ietf.org/html/rfc4122), incluso UUID versión 4 versión bits 2 bit reservado.
    • Entonces este fragmento de código genera criptográficamente de bits aleatorios que llene un System.Guid struct y que se puede utilizar exactamente igual que todos los demás Uuid, pero que no es en sí mismo un UUID en cumplimiento con RFC4122. Yo no recuerdo nunca la necesidad de una compatible con RFC UUID, en lugar de simplemente un aleatoria de 128 bits o incluso de criptografía de números aleatorios.
    • Pedante: si todo lo que quieres son 16 bytes aleatorios, tal vez vale la pena dejar esto como un byte[16] en vez de ponerlo dentro de un Guid. Llamar a un Guid podría confundir a alguien que entiende las normas?
    • Sí, es absolutamente equivocado para establecer la reserva de bits de forma incorrecta.
    • Bueno, vamos a reducir la entropía de los 6 bits y fingir que tiene una versión 4 GUID mediante la asignación de los bits de forma estática en la «espera» de los valores. A continuación, el Guid generado aquí debe ser indistinguible de la plataforma de implementación, derecho? Después de todo, no al azar de origen puede realmente garantía cualquier singularidad, que el plano de la ilusión. No se ser una colisión, la única pregunta es cuándo, y es que la única suficiente para un determinado caso de uso. La única cosa que puede garantizar la unicidad es compartida contador, o el uso de un conjunto predefinido de valores y a la entrega de cada valor de una sola vez.

  4. 6

    La definición de Azar en ninguna manera se refiere a la definición de Global Único.

    Lanzar una moneda dos veces y llegar HH, HT, TH, TT son todas al azar. HH es tan aleatorio como HT.

    Voltear un «especial» de la moneda dos veces y garantizar que sólo obtendrá HT o TH es la singularidad.

  5. 2

    Según https://msdn.microsoft.com/en-us/library/bb417a2c-7a58-404f-84dd-6b494ecf0d13#id11, desde Windows 2000 en 1999,

    «los bits aleatorios para todos los de la versión 4 Guid construido en Windows se obtienen
    a través de las Ventanas CryptGenRandom API criptográfica o el equivalente,
    la misma fuente que se utiliza para la generación de claves criptográficas»

    Así que me gustaría considerar criptográficamente seguro-al menos en la medida de las 122 bits de entropía que proporcionan.

    Ver también https://stackoverflow.com/a/35384818/284704, donde Se Decano verificado a través de una depuración de paso que el CLR es llamar a la adecuada seguro OS generador de números aleatorios.

    • Muy interesante para leer esto. Mi preocupación es que no se puede garantizar la aplicación permanecerá de esta manera, ni se deriva de manera consistente a través de diferentes plataformas y versiones de framework. La mejor manera de seguir a una explícita CSPRNG.
    • Pero podemos garantizar que una aplicación no va a cambiar? Supongamos .NET 9.5 (o lo que sea) sale a la luz en el año 2030, y su generación de GUID (o Windows) se convierte en inseguro — en ese caso, sería sin duda la actualización de la documentación para reflejar el nuevo comportamiento. Nunca realmente puede garantizar nada acerca de las futuras versiones de una biblioteca/API, pero el hecho de que MS ha mantenido de generación de GUID criptográficamente segura durante casi 20 años debe ser un fuerte indicio de que los Guid siempre será de esa manera.
  6. 1

    Guid están diseñados para ser, en el número 2 en la escala, es decir, «puede ser utilizado para la generación de Identificadores en un DB porque duplicados es raro*.»

    Como los de seguridad, no es el problema «no es bueno para la seguridad, porque los resultados se pueden predecir con suficiente esfuerzo.». El problema es que nadie le da un documentado garantía de seguridad.

    En la práctica, de acuerdo a este comentario y este, la generación de GUID es implementadas en términos de un generador de números aleatorios criptográficamente segura (CryptGenRandom). Pero eso parece ser un indocumentado detalle de implementación. (Y no he verificado esto – es aleatorio comentarios en Internet, con un camión cargado de sal).

    (* Donde «poco probable» que significa algo así como «las posibilidades de nadie encontrar un GUID duplicado antes de la finalización del universo son menos las posibilidades de que usted personalmente ganar la lotería.» Implementación de errores de excepción, por supuesto.)

    • «En la práctica, de acuerdo con este comentario y esta, la generación de GUID es implementado en términos de un generador de números aleatorios criptográficamente segura» … no hay forma. Eso es confundir la singularidad (protección contra accidental duplicados) con la aleatoriedad (protección en contra de la predicción). Hay una diferencia entre búsqueda un GUID duplicado y buscando un duplicado GUID
  7. 0

    Son aleatorios por lo que es mathematcially comprobable que las colisiones no deberían producirse por un tiempo muy largo, por lo que se puede asumir que son únicos a nivel mundial. Sin embargo, son no criptográficamente fuertes, ya que esto requeriría una verdadera aleatoriedad, que realmente no es posible en los equipos sin necesidad de hardware dedicado.

    • Cierto, pero creo que dispositivo ruido que hace una muy buena fuente de entropía.
    • Errr….. criptográficamente fuertes generadores de números aleatorios no existen. Que se puede hacer en el 100% de software. (Aunque el soporte de hardware que hace que sea mucho más fácil de escribir, y mucho más fácil para probar la seguridad). En los Pc con Windows, CryptGenRandom() es el normal.
    • Así, sólo el hecho de que había problemas conocidos con ella hasta Windows Vista y que el algoritmo no es publicado y sólo toma en cuenta una lista muy larga de información específica para hacerla tan al azar como sea posible no significa que una repetición es imposible, al menos en un virtualizado entorno de laboratorio (lo que no significa que no es apta para su uso en el medio natural). en.wikipedia.org/wiki/CryptGenRandom
    • Si es matemáticamente demostrable de que las colisiones no debe ocurrir entonces, por definición, NO es al azar en todo! Eso es como decir que una mesa de ruleta es sólo azar si un número no tiene un segundo de tiempo hasta que todos los demás tienen.
  8. 0

    Centrándose en la cuestión de la el uso de GUID como identificadores de fila:

    GUID son para bases de datos orientadas hacia la replicación, o la generación de filas por delante de tiempo antes de agregarlos a la base de datos. Si usted no necesita GUID para resolver un problema en particular, trate de palo incremental de numeración. GUID complicar la depuración y prueba un poco.

    El PEINE método en el artículo que mencionas parece bastante grandes, en realidad. Nunca me di cuenta, gracias por que uno! (p.s. la versión impresa de que el artículo se lee mucho mejor)

    Así que si usted no necesita generar un GUID antes de tiempo, puede dejar que el identificador de base de datos la generación de GUID para usted. Las diferencias de velocidad que solo te aviso si usted comienza a añadir 10,000 de los registros de una sola vez, que usted no debe hacer de todos modos, eso es lo que a granel de importación es para.

    Tener también un vistazo a Jeff en ID vs 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
    • La necesidad de Guid en mi caso es complejo. Primero de todo, estoy usando NHIbernate ORM, y en segundo lugar me gustaría crear objetos en mi aplicación y, a continuación, dejar que el usuario decida si desea o no guardar los mismos (por ejemplo. si el usuario presiona ACEPTAR o Cancelar). Si he utilizado la IDENTIDAD de NHibernate tendría que insertar el registro tan pronto como fue creada para obtener el ID (que es lo que no quiero). Guid me permite crear Identificadores sin tocar la DB, y el PEINE se ocupa de los problemas de rendimiento. Pero puede fallar si Guid duplicados se generan debido a las sutilezas en la aplicación no se conoce por los autores originales.
  9. -1

    Leí en alguna parte que las posibilidades de ganar la lotería, sería el equivalente a 2 4-byte «Guid» chocar. El estándar de 16 bytes Guid iba a ofrecer mucho menos probabilidad de colisión.

Dejar respuesta

Please enter your comment!
Please enter your name here