Esto va a depender de su entorno. Las instantáneas, los clones y las imágenes de copia dorada causan problemas simplemente porque están utilizando grupos de entropía idénticos para generar RNG para el sistema. VMWare ofrece controladores virtio que permiten que la entropía se actualice desde el núcleo del núcleo, pero no creo que esto exista para Windows.
En este caso, un reinicio refresca el grupo de entropía pero también tiene una ventana muy pequeña de problemas potenciales por debajo del umbral de entropía que su referencia también analiza. Esto se evita fácilmente NO permitiendo las funciones RNG para OpenSSL u otras necesidades de Keygen hasta que el sistema se haya iniciado completamente.
La tercera opción y, en mi opinión, la alternativa adecuada es confiar en un hardware externo rng para actualizar su grupo de entropía y luego extraerlo. Eso te permite:
- Fuentes True Entropy para completar todos los PRNGS en cada virtual
- La capacidad de monitorear el grupo de entropía de cada clon y actualizar cuando se alcanzan los umbrales de entropía (rellenando hasta 4k)
- No te preocupa que estés usando grupos de entropía duplicados de todas las imágenes de clonación
Ninguno si este es un problema a menos que tenga un requisito de cumplimiento y / o tenga necesidades de keygen que saturen el grupo de entropía de cada vm y realmente causen un potencial para escenarios de números conocidos. En esos casos, vaya hardware RNG.
TL; DR
- Dado el tiempo suficiente, el grupo de entropía se agita y este problema se vuelve discutible
- Si confía en Windows o Linux para las necesidades reales de SSL, no confíe en las agrupaciones de entropía del kernel y elija un método NIST 800-90 (A / B) aprobado; hardware a través de API o programación personalizada
- Actualice su aplicación en Windows: enlace