¿Por qué hay pocas bibliotecas de cifrado fáciles de usar (ninguna)?

Porque el cifrado es complejo . Hay muchos escollos que deben evitarse y consecuencias terribles que pueden suceder si lo hace mal. Las respuestas a una de mis preguntas exploran algunas de las razones bastante bien. ¿En qué nivel de abstracción debería trabajar un desarrollador con respecto a la criptografía?

Dicho esto, hay algunas bibliotecas criptográficas bien resumidas por ahí. La biblioteca de Fernet proporciona una interfaz fácil de usar para el cifrado simétrico en Ruby y Go . La biblioteca Keyczar también tiene implementaciones en varios idiomas. Por último, un complemento personal para un proyecto en el que estoy involucrado, la biblioteca cryptography para python tiene como objetivo proporcionar recetas criptográficas de alto nivel y primitivas de bajo nivel con amplia documentación sobre las mejores prácticas.

Estoy de acuerdo con usted hasta el punto de que no hay soluciones fáciles. Un ejemplo reciente famoso es la incapacidad de Edward Snowden para enseñar a Glenn Greenwald a usar una herramienta de cifrado de clave pública.

El paisaje se ha vuelto más traicionero por las puertas traseras deliberadas (?). Apple, Linux y RSA han estado en las últimas noticias últimamente por criptografía rota.

  

Entonces, para todos los desarrolladores que desean cifrar información, estamos   prácticamente destinado a hacerlo mal.

No estoy de acuerdo. Si bien no hay soluciones fáciles, hay muchas soluciones. El mundo de Java ha incorporado bibliotecas criptográficas probadas y reales, así como bibliotecas de terceros como Bouncy Castle (que incluye HMAC).

Cita falta de verificación de integridad de mensajes en la biblioteca que encontró. La integridad del mensaje (autenticación criptográfica) es un problema estrechamente relacionado pero separado de la comunicación cifrada. Muchas bibliotecas hacen ambas cosas. Si una biblioteca criptográfica no lo admite y usted lo necesita, entonces se puede encontrar en una biblioteca separada. La página de wikipedia sobre HMAC tiene una lista de implementaciones en muchos idiomas.

Me gustaría señalar que implementar la verificación de la integridad del mensaje siguiendo los métodos establecidos no es lo mismo que inventar los suyos. Al igual que si escribiera un código Java que implementara un SHA-256 por mi cuenta, no contaría como el mío. El algoritmo es la verdadera invención comprobada y probada aquí, no la implementación.

Como usted y los demás señalaron, el cifrado es complejo. Pero lo que es más importante, la seguridad es compleja; y los problemas no son todos técnicos, y no todos se pueden resolver con cifrado. Los algoritmos de cifrado son solo una pequeña parte del rompecabezas de seguridad. Por sí mismo, el cifrado resuelve solo un atributo de seguridad: la confidencialidad. Existen otros factores, entre los que se incluyen la integridad, la disponibilidad, la autorización y el no repudio.

Para ser útil, el cifrado debe realizarse en el contexto de un protocolo. El protocolo especifica exactamente qué bytes van aquí y qué bytes van allí. Si obtiene el cifrado correcto pero el protocolo es incorrecto, puede fallar en la protección de la integridad del mensaje. El protocolo puede diseñarse para proteger la integridad del mensaje, pero no es lo mismo que el cifrado. Si el sistema es tan complejo que sus usuarios en cualquiera de los extremos no pueden hacerlo funcionar, no está disponible. Y la administración de claves sigue siendo el mayor problema: si se resuelven el cifrado, los protocolos y la complejidad, pero falla en la administración de claves o la distribución de claves, falla en la protección de la autorización, el no rechazo e incluso la integridad y la confidencialidad. No existe una biblioteca de cifrado que aborde con éxito todos estos aspectos.

Otra parte del problema es que la seguridad se define por la ausencia de ataques exitosos: demostrar que un sistema es seguro es casi imposible, porque es imposible demostrar que es negativo. Puede probar el comportamiento correcto, pero no puede probar cada posible instancia de comportamiento incorrecto. Los nuevos ataques a los protocolos provienen de la reproducción de mensajes fuera de secuencia, el cambio de ciertos bytes, el cambio de órdenes de operaciones, el cambio de los números de versión de los mensajes, la reorganización de campos, etc. Y habrá más ataques. Ningún sistema está perfectamente probado contra lo desconocido.

Una gran parte del problema es que hay intereses en juego: si vendo "SecuriFoo 2000, su solución de seguridad todo en uno", tengo pocos incentivos económicos para que sea compatible con "Protect-O-Matic 8.1 ", mi competidor directo en el negocio (piense en iMessage). Existe un mosaico de leyes de cifrado en todo el mundo que prohíbe ciertos tipos de cifrado en ciertos lugares. Y hay agencias gubernamentales que tienen un gran interés en mantener el mercado tan complejo y fragmentado que la mayoría de las personas comunes no pueden seleccionar y usar adecuadamente las comunicaciones protegidas, dejando grietas inseguras en los mensajes que pueden ser interceptados.

El campo es simplemente inmaduro. Los practicantes aprenden cosas nuevas todos los días, pero los atacantes también intentan cosas nuevas todos los días. Siempre que se pueda derivar valor de romper la seguridad, la gente seguirá intentando romperla.

Esta no es una respuesta completa, pero un punto que parece haber sido omitido por las otras respuestas (John Deters lo toca, pero lo aborda desde un ángulo muy diferente) aquí es:

Por lo general, el punto de cifrado es empaquetar cierta información que se puede descifrar o verificar. Es muy posible escribir una biblioteca que sea muy fácil de usar y que ofrezca instalaciones de cifrado y descifrado. Vea, por ejemplo, thia Javascript TEA implementación que tiene 2 funciones: cifrar y descifrar y 2 argumentos: una contraseña y algunos datos.

Pero en muchos casos no controlamos el software que realiza ambos al final de la operación, para acomodar diferentes estándares y protocolos, la API con la que el desarrollador debe interactuar se vuelve mucho más complicada. / p>

También hay problemas sobre cómo se representan los datos para el almacenamiento y la transmisión.

Usar HTTPS.

HTTPS es el Nginx del cifrado. La mayoría de los idiomas tienen una biblioteca que puede hacerlo sin configuración. Simplemente funciona. Si tiene que configurar un servidor, SSL Labs puede indicarle si lo ha hecho bien. Podría ensuciarse las manos y usar TLS directamente, pero eso ya está llegando a un territorio difícil.

La razón por la que no encuentra bloques de construcción convenientes en un nivel más bajo que TLS es que es imposible usarlos correctamente. Incluso TLS 1.2, la sexta y actual versión del protocolo, contiene errores importantes conocidos .

Por supuesto que estoy engañando un poco, porque en realidad no dijiste para qué necesitabas el cifrado. Tal vez usted no está haciendo el transporte en absoluto? En cualquier caso, HTTPS es un ejemplo de cómo se ven las soluciones a este tipo de problema.