Respuestas criptográficas de la derecha

Estamos menos interesados ​​en empoderar a los desarrolladores y somos mucho más pesimistas sobre las perspectivas de hacer bien estas cosas.

Existen, en la literatura y en los sistemas modernos más sofisticados, respuestas “mejores” para muchos de estos artículos. Si está construyendo sistemas embebidos de baja huella, puede usar STROBE y una pila de cifrado autenticada, sólida y moderna, completamente de una sola construcción de esponja tipo SHA-3. Puede usar NOISE para construir un protocolo de transporte seguro con su propio AKE. Hablando de AKE, hay, como 30, diferentes contraseñas de contraseñas que puedes elegir.

Pero si eres un desarrollador y no un ingeniero de criptografía, no deberías hacer nada de eso. Debe mantener las cosas simples y convencionales y fáciles de analizar; “Aburrido”, como diría la gente de Google TLS.

Respuestas criptográficas de la derecha

Cifrado de datos

Percival, 2009: AES-CTR con HMAC.

Ptacek, 2015: (1) valor predeterminado de NaCl / libsodium, (2) ChaCha20-Poly1305 o (3) AES-GCM.

Latacora, 2018: KMS o XSalsa20 + Poly1305

Le importa esto si: está ocultando información de los usuarios o la red.

Si está en condiciones de utilizar KMS, el tiempo compartido del Módulo de seguridad de hardware de Amazon (o Google), use KMS. Si puede usar KMS pero el cifrado es solo un divertido proyecto de fin de semana y puede ahorrar algo de dinero al minimizar su uso de KMS, use KMS. Si solo está encriptando secretos como tokens API para su aplicación al inicio, use SSM Parameter Store, que es KMS. No tiene que entender cómo funciona KMS.

De lo contrario, lo que desea idealmente es “AEAD”: cifrado autenticado con datos adicionales (la opción para encabezados autenticados de texto sin formato).

La forma principal de obtener el cifrado autenticado es usar un cifrado de flujo (generalmente: AES en modo CTR) compuesto por un MAC polinomial (un CRC criptográfico).

El problema con el que te encontrarás con todas esas opciones principales es nonces: quieren que vengas con un número único (generalmente aleatorio) para cada flujo que nunca se puede reutilizar. Es más simple generar nonces a partir de un generador seguro de números aleatorios, por lo que desea un esquema que lo haga fácil.

Los nonces son particularmente importantes para AES-GCM, que es el modo de cifrado más popular. Desafortunadamente, es particularmente complicado con AES-GCM, donde apenas-pero-tal vez-no-está al borde de la seguridad de usar nonces aleatorios.

Por lo tanto, le recomendamos que use XSalsa20-Poly1305. Esta es una especie de construcciones “ChaPoly”, que, juntas, son las construcciones de cifrado más comunes fuera de AES-GCM. Obtenga XSalsa20-Poly1305 de libsodium o NaCl.

La ventaja de XSalsa20 sobre ChaCha20 y Salsa20 es que XSalsa admite una versión extendida; es lo suficientemente grande como para que simplemente generes un gran al azar aleatorio largo para cada transmisión y no te preocupes por la cantidad de transmisiones que cifras.

Hay planes de “NMR” o “MRAE” en la tubería que prometen cierto grado de seguridad, incluso si nonces se manejan mal; estos incluyen GCM-SIV (todos los SIV, en realidad) y el finalista del concurso CAESAR Deoxys-II. Son interesantes, pero nadie realmente los apoya o los usa aún, y con una licencia extendida, la seguridad gana es algo marginal. No son aburridos. Mantente aburrido por ahora.

Evite: AES-CBC, AES-CTR por sí mismo, cifra de bloques con bloques de 64 bits, especialmente Blowfish, que es inexplicablemente popular, modo OFB. Nunca use RC4, que se rompe cómicamente.

Longitud de clave simétrica

Percival, 2009 : usa claves de 256 bits.

Ptacek, 2015 : usa claves de 256 bits.

Latacora, 2018: adelante y use claves de 256 bit.

Te importa esto si: estás usando criptografía.

Pero recuerde: su clave AES es mucho menos probable que se rompa que su par de claves públicas, por lo que el último tamaño de clave debería ser más grande si se va a obsesionar con esto.

Evite: construcciones con teclas enormes, “cascadas” de cifrado, tamaños de clave inferiores a 128 bits.

“Firmas” simétricas

Percival, 2009 : usa HMAC.

Ptacek, 2015 : Sí, usa HMAC.

Latacora, 2018: aún HMAC.

Te importa esto si: estás asegurando una API, encriptando cookies de sesión o encriptando datos de usuarios pero, en contra de consejos médicos, no usando una construcción AEAD.

Si está autenticando pero no está encriptando, como con las solicitudes de API, no haga nada complicado. Existe una clase de errores de implementación de cifrado que surge de la forma de alimentar los datos a su MAC, por lo que, si está diseñando un nuevo sistema desde el principio, Google “cripto canonicalization bugs”. Además, use una función de comparación segura.

Si usa HMAC, las personas sentirán la necesidad de señalar que SHA3 (y los valores hash SHA2 truncados) pueden hacer “KMAC”, lo que quiere decir que puede concatenar la clave y los datos, controlarlos y protegerlos. Esto significa que, en teoría, HMAC está haciendo un trabajo adicional innecesario con SHA-3 o SHA-2 truncado. ¿Pero a quién le importa? Piense en HMAC como un seguro barato para su diseño, en caso de que alguien cambie a SHA-2 no truncado.

Evite: construcciones de “hash con clave” personalizadas, HMAC-MD5, HMAC-SHA1, MAC polinomiales complejos, hashes cifrados, CRC.

Algoritmo Hashing

Percival, 2009 : use SHA256 (SHA-2).

Ptacek, 2015 : usa SHA-2.

Latacora, 2018: Todavía SHA-2.

Te importa esto si: siempre te preocupas por esto.

Si puede salirse con la suya: use SHA-512/256, que trunca su salida y elude los ataques de extensión de longitud.

Todavía creemos que es menos probable que actualice de SHA-2 a SHA-3 que de que actualice de SHA-2 a algo más rápido que SHA-3, y SHA-2 todavía se ve muy bien, así que siéntase cómodo y tierno con SHA-2.

Evitar: SHA-1, MD5, MD6.

ID aleatorias

Percival, 2009 : usa números aleatorios de 256 bits.

Ptacek, 2015 : usa números aleatorios de 256 bits.

Latacora, 2018: usa números aleatorios de 256 bits.

Te importa esto si: siempre te preocupas por esto.

De / dev / urandom

Evite: generadores de números aleatorios del espacio de usuario, OpenSSL RNG, havaged, prngd, egd, / dev / random.

Manejo de contraseña

Percival, 2009 : scrypt o PBKDF2.

Ptacek, 2015 : en orden de preferencia, utilice scrypt, bcrypt, y luego, si nada está disponible, PBKDF2.

Latacora, 2018: en orden de preferencia, use scrypt, argon2, bcrypt, y luego, si nada está disponible, PBKDF2.

Le importa esto si: acepta contraseñas de los usuarios o, en cualquier lugar de su sistema, tiene claves secretas inteligibles para el ser humano.

Pero, en serio: puedes tirar un dardo a la pared para elegir uno de estos. Técnicamente, argon2 y scrypt son materialmente mejores que bcrypt, que es mucho mejor que PBKDF2. En la práctica, lo más importante es que uses un hash de contraseña real y seguro, y no tanto el que usas.

No construyas esquemas elaborados de agilidad de contraseñas.

Evitar: SHA-3, SHA-2 desnudo, SHA-1, MD5.

Encriptación asimétrica

Percival, 2009 : utilice RSAES-OAEP con SHA256 y MGF1 + SHA256 bzzrt pop ffssssssst exponente 65537.

Ptacek, 2015 : use NaCl / libsodium (box / crypto_box).

Latacora, 2018: use Nacl / libsodium (box / crypto_box).

Te importa esto si : necesitas encriptar el mismo tipo de mensaje a muchas personas diferentes, algunas de ellas extrañas, y deben poder aceptar el mensaje de forma asincrónica, como si fuera un correo electrónico de almacenamiento y reenvío, y luego descifrarlo está fuera de línea. Es un caso de uso bastante limitado.

De todas las “respuestas correctas” criptográficas, esta es la que es menos probable que obtenga por su cuenta. No cifre la clave pública de forma independiente, y no use una biblioteca de cifrado de bajo nivel como OpenSSL o BouncyCastle.

Aquí hay varias razones por las que debe dejar de usar RSA y cambiar a la curva elíptica:

  • RSA (y DH) lo arrastra hacia la “compatibilidad hacia atrás” (es decir, compatibilidad de ataque a la baja) con sistemas inseguros.
  • RSA le ruega a los implementadores que encripten directamente con su primitiva de clave pública, que generalmente no es lo que usted desea hacer
  • RSA tiene demasiados mandos. En los sistemas modernos de curvas, como Curve25519, todo está preconfigurado para la seguridad.

NaCl usa Curve25519 (la curva moderna más popular, cuidadosamente diseñada para eliminar varias clases de ataques contra las curvas estándar NIST) junto con un esquema ChaPoly AEAD. Su idioma tendrá enlaces (o, en el caso de Go, su propia implementación de biblioteca) a NaCl; usalos, usalos a ellos. No trates de armar esto tú mismo.

No use RSA.

Evitar: Sistemas diseñados después de 2015 que usan RSA, RSA-PKCS1v15, RSA, ElGamal, no sé, mochilas Merkle-Hellman. Solo evita RSA.

Firmas asimétricas

Percival, 2009 : utilice RSASSA-PSS con SHA256 y luego MGF1 + SHA256 en orientación de silicato sistémico tricolor.

Ptacek, 2015 : usa Nacl, Ed25519 o RFC6979.

Latacora, 2018: use Nacl o Ed25519.

Te importa esto si : estás diseñando una nueva criptomoneda. O bien, un sistema para firmar Ruby Gems o imágenes Vagrant, o un esquema de DRM, donde la autenticidad de una serie de archivos que llegan en momentos aleatorios debe ser verificada fuera de línea con la misma clave secreta. O bien, está diseñando un transporte de mensajes cifrados.

Las alegaciones de la respuesta anterior se incorporan aquí como si se indicaran en su totalidad.

Los dos casos de uso predominantes en los últimos 10 años para las firmas asimétricas son las criptomonedas y el acuerdo de clave secreta a futuro, como con ECDHE-TLS. Los algoritmos dominantes para estos casos de uso se basan en curvas elípticas. Tenga cuidado con los nuevos sistemas que usan firmas RSA.

En los últimos años, se ha producido un cambio importante con respecto a las firmas DSA convencionales y hacia esquemas de firma “deterministas” resistentes al uso indebido, de los cuales EdDSA y RFC6979 son los mejores ejemplos. Puede pensar en estos esquemas como respuestas “a prueba de usuarios” a la falla de ECDSA de Playstation 3, en la que se reutiliza un número aleatorio de claves secretas filtradas. Utilice firmas deterministas con preferencia a cualquier otro esquema de firma.

Ed25519, el valor predeterminado de NaCl / libsodium, es de lejos el esquema de firma de clave pública más popular fuera de Bitcoin. Es resistente al uso indebido y está cuidadosamente diseñado de otras maneras también. No deberías freelance esto tampoco; obténgalo de NaCl.

Evitar: RSA-PKCS1v15, RSA, ECDSA, DSA; realmente, especialmente evite DSA y ECDSA convencionales.

Diffie-Hellman

Percival, 2009 : opere sobre el grupo # 2048 de 2048 bits con un generador de 2.

Ptacek, 2015 : Probablemente todavía DH-2048 o Nacl.

Latacora, 2018: Probablemente nada. O usa Curve25519.

Te importa esto si: estás diseñando un sistema de transporte o mensajería cifrado que un extraño utilizará algún día, por lo que las claves AES estáticas no funcionarán.

La versión 2015 de este documento confundió a todos.

Parte del problema es que nuestras “Respuestas correctas” son una respuesta a “Respuestas correctas” de Colin Percival, y la suya incluía una respuesta “Diffie-Hellman”, como si “Diffie-Hellmanning” fuera algo que los desarrolladores hacen rutinariamente. En realidad, los desarrolladores simplemente no deberían utilizar sus propios transportes cifrados. Para tener una idea de la complejidad de este problema, lea la documentación del Noise Protocol Framework. Si está realizando un intercambio de claves con DH, probablemente desee un intercambio de clave autenticada (AKE) que resista la suplantación de compromiso clave (KCI), por lo que la primitiva que utiliza para DH no es la única preocupación de seguridad importante.

Pero lo que sea.

Sigue siendo el caso: si solo puede usar NaCl, use NaCl. Ni siquiera tiene que importar lo que hace NaCl. Ese es el punto de NaCl.

De lo contrario: use Curve25519. Hay bibliotecas para prácticamente todos los idiomas. En 2015, nos preocupaba animar a las personas a escribir sus propias bibliotecas Curve25519, con visiones de implementaciones de Javascript bignum bailando en nuestras cabezas. Pero en realidad, parte del punto de Curve25519 es que toda la curva fue cuidadosamente elegida para minimizar los errores de implementación. ¡No escribas el tuyo! Pero realmente, solo usa Curve25519.

No haga ECDH con las curvas NIST, donde tendrá que verificar cuidadosamente los puntos de la curva elíptica antes de calcular con ellos para evitar la filtración de secretos. Ese ataque es muy simple de implementar, más fácil que un oráculo de relleno de CBC, y mucho más devastador.

El documento de 2015 incluía una cláusula sobre el uso de DH-1024 con preferencia a las bibliotecas de curvas incompletas. ¿Sabes que? Ese sigue siendo un punto válido. Válido y estúpido. La forma de resolver el problema “DH-1024 frente a la biblioteca de curvas incompletas” es la misma que la del problema “¿Debería usar Blowfish o IDEA?”. No tienes ese problema Usa Curve25519.

Evitar: DH convencional, SRP, J-PAKE, apretones de manos y negociación, elaborar esquemas clave de negociación que solo utilicen cifras de bloque, srand (time ()). *

Seguridad del sitio web

Percival, 2009 : usa OpenSSL.

Ptacek, 2015 : Restos: OpenSSL, o BoringSSL si puedes. O simplemente use AWS ELBs

Latacora, 2018: utilice AWS ALB / ELB o OpenSSL, con LetsEncrypt

Te importa esto si: tienes un sitio web.

Si puede pagarle a AWS para que no se preocupe por este problema, le recomendamos que lo haga.

De lo contrario, hubo un período oscuro entre 2010 y 2016 donde OpenSSL podría no haber sido la respuesta correcta, pero ese momento ya pasó. OpenSSL ha mejorado y, lo que es más importante, OpenSSL está al alcance de la mano con la divulgación y respuesta de vulnerabilidades.

Usar cualquier cosa además de OpenSSL complicará drásticamente su sistema con un beneficio de seguridad pequeño, nulo o incluso negativo. Así que solo mantenlo simple.

Hablando de simple: LetsEncrypt es gratis y automatizado. Configure un trabajo cron para recuperar certificados regularmente y pruébelo.

Evite: bibliotecas TLS poco convencionales como PolarSSL, GnuTLS y MatrixSSL.

Seguridad de la aplicación cliente-servidor

Percival, 2009 : usa OpenSSL.

Ptacek, 2015 : Restos: OpenSSL, o BoringSSL si puedes. O simplemente use AWS ELBs

Latacora, 2018: utilice AWS ALB / ELB o OpenSSL, con LetsEncrypt

Le importa esto si: las recomendaciones anteriores sobre criptografía de clave pública fueron relevantes para usted. *

Parece un poco loco recomendar TLS dada su historia reciente:

  • El ataque de negociación Logjam DH
  • El ataque de cifrado de exportación FREAK
  • El ataque del oráculo CBC POODLE
  • El fiasco de RC4
  • El ataque de compresión CRIME
  • El Lucky13 CBC relleno ataque oráculo sincronización
  • El ataque de BEAST CBC encadenado IV
  • Heartbleed
  • Renegociación
  • Triple apretones de manos
  • CA comprometidas
  • DROWN (aunque personalmente estamos deformados y la oportunidad de jugar con ataques como DROWN estaría en nuestra columna “pro”)

A continuación, le explicamos por qué debería seguir utilizando TLS para su problema de transporte personalizado:

  • En los protocolos personalizados, no tiene que (y no debe) depender de CA de terceros. Ni siquiera tiene que usar CA (aunque no es difícil configurar su cuenta); solo puede usar una lista blanca de certificados autofirmados, que es aproximadamente lo que SSH hace de manera predeterminada, y lo que usted podría crear por su cuenta.
  • Como está haciendo un protocolo personalizado, puede usar las mejores suites de cifrado TLS posibles: TLS 1.2+, Curve25519 y Chapoly. Eso elimina la mayoría de los ataques a TLS. La razón por la que todo el mundo no hace esto es porque necesitan compatibilidad con versiones anteriores, pero en los protocolos personalizados no es necesario.
  • Muchos de estos ataques solo funcionan contra los navegadores, ya que dependen de que la víctima acepte y ejecute JavaScript controlado por el atacante para generar repetidos planos conocidos / elegidos.

Evite: diseñar su propio transporte cifrado, que es un problema de ingeniería realmente difícil; usando TLS pero en una configuración predeterminada, como, con “curl”; usando “curl”, IPSEC.

Copias de seguridad en línea

Percival, 2009 : Usa Tarsnap.

Ptacek, 2015 : Usa Tarsnap.

Latacora, 2018: guarde los archivos de arco cifrados con PMAC-SIV en S3 y guarde las huellas dactilares de sus copias de seguridad en una cadena de bloques compatible con ERC20.

Te importa esto si: te molestas en respaldar las cosas.

Es una broma. Aún deberías usar Tarsnap.

Lee mas

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.