¿Es el código abierto una buena opción para las bibliotecas de criptografía? [cerrado]

El principio clave detrás del software de código abierto es revisión por pares . La idea es que muchas personas (expertos y aficionados por igual) revisarán el código a lo largo del tiempo y ese proceso de revisión conducirá a un código mejor y sin errores. Entonces, en mi opinión, los algoritmos criptográficos de código abierto son mejores que los algoritmos de código abierto solo por este hecho. Sin embargo, ambos sistemas siguen siendo vulnerables a Zero-days y similares, aunque con algoritmos de código abierto usted es potencialmente menos vulnerable debido a la cantidad de revisión por pares.

Cualquier respuesta a esto será pura especulación: no hay una respuesta correcta.

Dicho esto, mi opinión es que OpenSSL es al menos tan bueno como cualquier biblioteca criptográfica de código cerrado. Considere que github enumera 175 contribuyentes al proyecto openssl y 1,442 bifurcaciones, mientras que Google Scholar encuentra 17,400 documentos académicos para " openssl ". Vaya y encuentre una biblioteca criptográfica de código cerrado que haya recibido tantas horas de desarrollo y tanto control académico como eso.

El argumento habitual a favor de la criptografía de código cerrado es que, si bien es casi seguro que hay más errores y vulnerabilidades, espera que queden sin descubrir. Para mí, eso no es muy tranquilizador.

También dices:

  

¿Pero qué hay de los códigos maliciosos que podrían entrar?

Yo diría que en realidad es más fácil insertar puertas traseras en el código de código cerrado. El gobierno paga (o las órdenes judiciales) a una empresa, el software de puerta trasera se distribuye. El único ejemplo de esto que conozco (porque estaba expuesto) es escándalo EC ECBG Dual EC de RSA Security , según corresponda a wikipedia:

  

Según el artículo de Reuters que reveló el acuerdo secreto de $ 10 millones entre RSA Security y NSA, BAFE de RSA Security fue el distribuidor más importante del algoritmo [Dual_EC_DRBG]. 2

Por el contrario, el kernel de Linux tenía un famoso intento de puerta trasera en 2003 donde un atacante robó las credenciales del servidor de control de fuente backup y presentó un cambio de código con la esperanza de que volaría por debajo del radar y entraría en producción. Esto es mucho más esfuerzo que simplemente pagarle a una empresa, y se capturó en 24 horas , con una de mis mensajes favoritos de la lista de correo de todos los tiempos:

  

parece un intento de hacer una puerta trasera al kernel, ¿no es así?

     

Seguro que sí. Tenga en cuenta "current- > uid = 0", no "current- > uid == 0".   Buenos ojos, echaba de menos eso. Esta función es sys_wait4 () por lo que al pasar   __WCLONE | __WALL eres root. Qué bonito.