java - ver - ves significado
SecureRandom: init una vez o cada vez que sea necesario (7)
Nuestro equipo está utilizando un SecureRandom para generar una lista de pares de claves (el SecureRandom se pasa a KeyPairGenerator). No podemos estar de acuerdo con cuál de las siguientes dos opciones usar:
Crea una nueva instancia cada vez que necesitemos generar un par de claves
Inicializa una instancia estática y úsala para todos los pares de claves
¿Qué enfoque es generalmente mejor y por qué ?
AGREGADO: Mi instinto es que la segunda opción es más segura. Pero mi único argumento es un ataque teórico basado en la suposición de que la pseudoaleabilidad se deriva de la marca de tiempo actual: alguien puede ver el tiempo de creación del par de claves, adivinar las marcas de tiempo en el intervalo de tiempo circundante, calcular las posibles secuencias pseudoaleatorias y obtener el material clave
AGREGADO: Mi suposición sobre el determinismo basado en una marca de tiempo fue incorrecta. Esa es la diferencia entre Random y SecureRandom. Entonces, parece que la respuesta es: en términos de seguridad, realmente no importa.
¿Por qué querrías crear una nueva instancia cada vez? No es que eso sería más aleatorio. Creo que lo mejor sería inicializar una vez y usarla para todos los pares.
A diferencia de la clase java.util.Random, la clase java.security.SecureRandom debe producir resultados no deterministas en cada llamada. Lo que eso significa es que, en el caso de java.util.Random, si recreara una instancia con la misma semilla cada vez que necesitara un nuevo número aleatorio, esencialmente obtendría el mismo resultado cada vez. Sin embargo, se garantiza que SecureRandom NO hará eso; por lo tanto, crear una sola instancia o crear una nueva cada vez no afecta la aleatoriedad de los bytes aleatorios que genera. Por lo tanto, desde el punto de vista de buenas prácticas de codificación normales, ¿por qué crear demasiadas instancias cuando una hará?
Cada generación de SecureRandom proviene de algún grupo de entropía. Dependiendo del SO utilizado, este podría ser el conjunto de entropía mantenido por el OS como / dev / random en Linux, o podría ser algo que la JVM cocine. En algunas implementaciones anteriores, Sun JVM solía engendrar una cantidad de hilos y usaba sus datos de sincronización para crear la semilla. La creación de un nuevo SecureRandom en cada llamada puede provocar la ralentización de la aplicación, ya que la creación de la semilla podría estar bloqueando. Es mejor volver a utilizar la instancia creada estáticamente, pero asegúrese de volver a sembrarla después de extraer un número fijo de bytes aleatorios. Puede querer crear un contenedor sobre un securerandom que cuente el número de bytes extarcted en la llamada nextBytes o generateSeed y después de un número de bytes, reseje el securerandom interno utilizando el grupo de entropía del sistema. Sin embargo, esto no es posible en Java en Linux ya que el SecureRandom que obtienes del nuevo SecureRandom () no es más que un contenedor en / dev / random y cada llamada para nextBytes o generateSeed realmente drena el pool de entropía del sistema operativo. En Linux y Solaris, es mejor usar un proveedor de JCE para la creación de SecureRandom.
Inicializa una instancia estática y úsala para todos los pares de claves. No será más o menos aleatorio.
No confiaría en que SecureRandom fuera otra cosa que un PRNG criptográficamente seguro. La cita completa que Gowri está usando de los javadocs es:
Además, SecureRandom debe producir resultados no deterministas y, por lo tanto, se requiere que el material semilla sea impredecible y que la salida de SecureRandom tenga secuencias criptográficas fuertes, como se describe en RFC 1750: Recomendaciones de aleatoriedad para la seguridad.
No es claro a partir de esto cuál es la expectativa real: RFC 1750 detalla el uso de hardware para mejorar la generación de números aleatorios, pero los javadocs dicen "por lo tanto, se requiere que el material de semilla sea impredecible", lo que parece contradecir esto.
La suposición más segura para trabajar es que su implementación de SecureRandom es simplemente un PRNG criptográficamente seguro y, por lo tanto, sus claves no son más seguras que la semilla aleatoria que utiliza. Por lo tanto, inicializar un nuevo SecureRandom con una nueva semilla (única, verdaderamente aleatoria) para cada clave sería la apuesta más segura.
Para SecureRandom , debería considerar la resiembra ocasionalmente ( utilizando la entropía del sistema en la mayoría de los casos ) a través de una llamada como esta:
mySecureRandom.setSeed(mySecureRandom.generateSeed(someInt));
para dar a un posible atacante algo menos que tiempo ilimitado para descubrir su clave.
Hay algunos excelentes comentarios sobre esta consideración en el blog de la Liga de la Justicia .
Una vez debería ser suficiente. Mi experiencia también ha sido que la inicialización de los generadores de tipo SecureRandom a veces puede ser lenta también (debido a la forma en que se logra la aleatoriedad), por lo que debe tener esto en cuenta.