¿Cuánto podemos confiar en las implementaciones de código abierto de las bibliotecas criptográficas (de seguridad)?

Tiene tres ventajas y desventajas: PBKDF vs otro algoritmo, fuente abierta vs cerrado, y la disponibilidad de vectores de prueba.

SCrypt o BCrypt pueden darle algo más de seguridad que PBKDF2. Por otro lado, si hay un error de implementación en el código (como ocurrió a Ashley Madison) entonces obtienes mucha menos seguridad.

En la medida en que el código sea examinado, tales fallas pueden ser notadas, y aquí es donde ocurre el intercambio de código abierto. En teoría, cualquiera puede mirar el código. En la práctica, hay que preguntar cuántos expertos han mirado. La oferta de analistas criptográficos voluntarios es bastante escasa, como lo demuestran las fallas de OpenSSL. Con el código MS PBKDF, puede esperar que alguien que no sea el codificador haya realizado el control de calidad, y el código criptográfico recibe relativamente más atención en el ciclo de vida del desarrollo de la seguridad. A falta de otros indicadores de pruebas de seguridad, un nugget .NET utilizado por 100 personas probablemente tenga menos análisis que un componente de Microsoft.

Por último, si la memoria sirve, PBKDF tiene vectores de prueba, y los otros no, lo que hace que probar la implementación correcta de PBKDF sea más fácil que probar las implementaciones de scrypt o bcrypt.

Debería mencionar, hace años que rastreé las bibliotecas criptográficas gratuitas y luego, más tarde, trabajó en el equipo del ciclo de vida de desarrollo de seguridad de Microsoft, pero ya no lo hace. No creo que haya una respuesta simple a tu pregunta.

  

¿Cuánto podemos confiar en las implementaciones de código abierto de las bibliotecas criptográficas (de seguridad)?

Mucho mejor que la implementación de código cerrado.

Cuando se trata de la seguridad que realmente importa, debe seguir el principio "confiar pero verificar". Confíe en que es más probable que las implementaciones populares de código abierto sean correctas y suficientes globos oculares para detectar errores, pero verifique / audite el código usted mismo si realmente le importa.

Con la implementación de código abierto, puedes verificarlo tú mismo si realmente te importa. Con la implementación de código cerrado, solo tiene la palabra del proveedor.

En todo caso, la desconfianza sobre las bibliotecas de seguridad de código abierto es algo bueno; hace que algunas personas comiencen a auditarlos antes de usarlos, en lugar de confiar ciegamente en una implementación porque son populares.

Nunca codifique las bibliotecas de cifrado o hash, sino que utilice las ya existentes. Los que ya existen están hechos por personas que a menudo se especializan en ello.

Además de eso. El mejor para usar debe ser de código abierto en primer lugar. Al ser de código abierto, más expertos en seguridad / personas tienen la oportunidad de encontrar errores o errores, y por eso se solucionan más problemas. Lógicamente, el que es el más usado es a menudo también el más revisado. Mayor probabilidad de que se hayan solucionado más problemas en esa.

Realmente no puedes controlarte a ti mismo si es seguro. Encontrar errores en tal algoritmo es difícil. Ejemplos rápidos . Un experto en seguridad probablemente no los encontrará a todos, así que tampoco confíe en los de código cerrado porque su código no llegó a tantos ojos como el de código abierto.