¿Debe usar SecureRandom.getInstance () con o sin un proveedor?

Question

¿Debe usar SecureRandom.getInstance () con o sin un proveedor?

#1 de A. Hersean (3 votos)
#2 de Maarten Bodewes (0 votos)

1

Por lo tanto, soy nuevo en criptografía y estaba aprendiendo sobre SecureRandom y todas las formas en que llama implementaciones con o sin proveedores.

Cuando busqué información en algunos sitios, dice que no use proveedores porque si el proveedor no está actualizado o no está disponible en un sistema, la aplicación debe estar preparada para manejar una excepción.

Sin embargo, muchos dicen que utilizan proveedores para superar el riesgo de elegir una implementación incorrecta como una bloqueada.

En los documentos de Java, leí que cuando especifica un proveedor en particular, incluso si el marco tiene proveedores de mayor prioridad que ofrecen la misma implementación, solo irá al proveedor mencionado para obtener la implementación. Aunque eso no suena atractivo.

Entonces, ¿debería el usuario getInstance() con los proveedores o no? ¿Cual es mejor?

cryptography java random

pregunta Daisetsu 05.10.2018 - 08:25

fuente

2 respuestas

Lea otras preguntas en las etiquetas cryptography java random

¿Una clave pública permanece igual cuando se renueva un certificado? [duplicar] ¿Cómo pudieron los hackers alterar el texto de mis páginas sin un formulario o una cadena de consulta?

score 3 · Answer 1

Esta es una pregunta inherente a la confianza de una API criptográfica, y no es realmente específica de SecureRandom. Seguiré formulando mi respuesta en torno a SecureRandom ya que es un buen ejemplo ilustrativo.

¿En quién confías más, las personas que escribieron el código de la API y lo documentaron, o los comentarios al azar en la web? Los desarrolladores tomaron decisiones para que usted no tenga que tomarlas, ya que tienen una mejor comprensión de los aspectos y problemas que el usuario común de su API. En aras de la flexibilidad de su API, los desarrolladores permitieron a los usuarios anular sus decisiones de implementación. Debe hacerlo solo si está seguro de saber mejor que ellos.

SecureRandom intenta utilizar la mejor fuente disponible, generalmente una proporcionada por el sistema operativo. Como no tiene la experiencia para hacer una mejor elección (de lo contrario, no tendría que hacer su pregunta), debe continuar con el valor predeterminado y manejar las excepciones de manera adecuada (por ejemplo, al negarse a proporcionar un servicio inseguro).

score 0 · Answer 2

No especifique un proveedor. Definitivamente no haga hardcode a un proveedor. Si no está presente, su aplicación simplemente no se ejecutará.

La única razón para configurar un proveedor es cuando los valores aleatorios de una implementación específica por parte de un proveedor ofrecen propiedades que no están presentadas por las predeterminadas. Incluso entonces, debería preguntarse si ese particular no debería usarse en otros lugares, en cuyo caso podría poner al proveedor al azar en la parte superior de la lista.

Hay lugares donde esto no es posible: un problema notable podría ser la velocidad del RNG. Por ejemplo, podría imaginar que desea utilizar una tarjeta inteligente o un generador de números aleatorios de un TPM para generar claves de larga duración. Ese tipo de generador de números aleatorios no es algo que desee utilizar para todas y cada una de las sesiones de TLS. Ahora este sería un buen caso para especificar tanto el algoritmo como el proveedor.

Incluso entonces, ingresaría la opción utilizando un archivo de configuración (firmado) en lugar de codificar la solución en la fuente. Recompilar una solución solo por una actualización de hardware generalmente no se considera OK (especialmente cuando se trata de Java / bytecode).

Tenga en cuenta que los algoritmos de software son deterministas y deben ser sembrados por el sistema operativo. Por lo tanto, no puede evitar el bloqueo si el generador de números aleatorios de los sistemas se bloquea cuando se proporciona la semilla. Por lo tanto, puede elegir cualquier tipo de proveedor de software, pero igual bloquearía el sistema hasta que haya más entropía disponible.