¿Por qué se recomienda no implementar crypto usted mismo? ¿Por qué usar el cifrado proporcionado en las bibliotecas estándar?

Permítanme tomar una perspectiva diferente a la respuesta (aludida en un par de respuestas). Una buena criptografía requiere dos verdades de alto nivel.
1- el algoritmo mismo resiste los ataques que debilitan la protección proporcionada y,
2- la implementación es correcta.

Para el algoritmo, piense en el administrador de contraseñas de que en realidad solo se validó con los primeros 8 caracteres de la contraseña. Por un breve momento, la gente pensó que era más seguro usar contraseñas más largas hasta que se reveló que el algoritmo real (que intentó mantener en privado) solo usó los primeros 8 caracteres. Eso redujo drásticamente el espacio de ataque y el tuvo que revisar su esquema de protección con contraseña. El mal algoritmo creó una vulnerabilidad fácilmente explotada.

Tenga en cuenta que dije “intenté mantener la privacidad”, los algoritmos de cifrado deberían ser lo suficientemente fuertes como para resistir el escrutinio público. Piensa en una llave y cerradura. El principio de cómo funciona no debilita la protección que ofrece. Es el número de vasos y el número de posiciones de los vasos (implementación) lo que hace que el bloqueo sea difícil de levantar. Los algoritmos criptográficos no le brindan ninguna ventaja a un atacante si el atacante conoce el algoritmo pero no tiene las “claves”. Asumiendo que la implementación es correcta.

La implementación correcta es importante porque los desarrolladores de software no siempre entienden el matiz de un algoritmo matemático complejo. Un ejemplo que una vez identifiqué fue un algoritmo que desplazó bits a la derecha. El desarrollador utilizó una operación de turno común. El problema era que era un desplazamiento circular a la derecha, por lo que el bit menos significativo se volvió más significativo y con el número correcto de desplazamientos resultó en el valor original. El algoritmo desarrollado por el matemático requería un relleno izquierdo aleatorio durante la operación. Fácilmente reparado una vez descubierto, pero costoso de descubrir y luego parchear.

La mayoría de las criptomonedas ahora implica matemáticas complejas y no todos los desarrolladores de software están tan bien entrenados. Las revisiones de código y la comprensión profunda son importantes junto con muchas pruebas y validaciones. Si está vendiendo su implementación, necesita alguna forma de demostrar que la implementó correctamente; y si lo estuviera comprando optaría por uno ya examinado y aprobado por alguien como una Agencia de Seguridad Nacional (aunque algunos pueden tener otras opiniones sobre esto; que están fuera del alcance de esta respuesta).

He hecho un algoritmo Sha en el pasado y, para ser sincero, aunque ese método de hash es relativamente simple, sigue siendo una tarea compleja. Cualquier error puede hacer que su algoritmo falle. Es mucho trabajo y requiere muchas pruebas, por lo que es más fácil (y más barato) usar las soluciones existentes.

Una cosa más que la gente tiende a olvidar: para que una criptografía sea segura, ¡el método debe ser lento, no rápido! ¡La mayoría de los desarrolladores están aprendiendo a optimizar la velocidad para comprar mejoras de criptografía al ser lentas! ¿Por qué? Porque el método criptográfico se usará durante un ataque de fuerza bruta. Si el método tarda 10 milisegundos en finalizar, ¡un ataque bruto podría hacer 6,000 intentos por minuto! Si el método dura 1 segundo, el ataque de fuerza bruta se reduce a solo 60 por minuto. Mucho más lento, por lo que llevará más tiempo agrietarse de esta manera.

La seguridad de las TIC es un campo especial en informática que tiende a ser contra-intuitivo. Por ejemplo, ¡es una de las pocas veces en que se puede alentar el uso de declaraciones Goto en C solo para convertir el código en espagueti! ¡Es donde aprendes a escribir código lento! Se trata de hacer las cosas más difíciles en lugar de hacer las cosas más fáciles. Es por eso que es algo para algunos expertos y no para desarrolladores en general.

Por cierto, también escribí un algoritmo de triple DES y algunas otras variantes, pero todavía soy demasiado inexperto para llamarme un experto en criptografía …

Pongámoslo de esta manera. Algunos algoritmos criptográficos requieren multiplicar grandes números. Resulta que si usa el algoritmo de multiplicación normal en estos algoritmos criptográficos; un atacante puede adivinar qué tan grande es la clave (como en [matemática] 2.6 × 10 ^ {11} [/ matemática] o [matemática] 3.4 × 10 ^ {11} [/ matemática]) observando el consumo de energía de el ordenador. Lo que hace que la clave sea mucho más fácil de adivinar. Por lo tanto, para mantener la seguridad, debe usar un algoritmo de multiplicación especial que usa exactamente la misma cantidad de potencia sin importar el tamaño de los números que se multiplican.

Esto se llama un “ataque de canal lateral” y defenderse de ellos … es difícil. Sin mencionar que la salida de algoritmos criptográficos es indistinguible de aleatoria por diseño. Es bastante difícil probar que realmente está implementando el algoritmo correcto, y no algo ligeramente diferente, pero mucho menos seguro. Excepto comparando su salida con una implementación de referencia.

Cuando un algoritmo es nuevo, generalmente lo probaría en una máquina para una carga específica en parámetros mucho más específicos.

Esto no siempre revelará las vulnerabilidades que podría tener el algoritmo, los agujeros de bucle que podría revelar o cómo funciona bajo estrés, diferentes ataques o en combinación de diferentes algoritmos.

Los estándares se prueban contra ataques conocidos, vulnerabilidades. También se actualizan constantemente en caso de nuevas amenazas.

La de las bibliotecas estándar se ha probado exhaustivamente para que las vulnerabilidades sean del algoritmo en sí y no de la implementación.

Solo se necesita un pequeño error en la implementación en la biblioteca de cifrado para hacer que su aplicación sea completamente insegura.