¿ Os parecen realmente seguros los cifrados actuales ?

[zettabit]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Acabo de cambiar recientemente de nick, y me he registrado en el foro. Quería comentaros que ultimamente
ando algo paranoico en cuanto a criptografía, en base a los siguientes puntos:

1) El algoritmo SHA-1 está diseñado por la NSA, y se han hecho estudios que indican que este algoritmo va a seguir la misma suerte que el difunto MD5

2) La seguridad de OpenPGP ( o de una de sus implementaciones, por ejemplo gnupg ), no se sustenta solo sobre el algoritmo RSA. RSA se utiliza para cifrar la clave simétrica que cifrará con AES el mensaje. AES funciona mediante una serie de rondas que hacen un buen batiburrillo de bits, y ya se han desarrollado ataques contra versiones reducidas de AES con un número de rondas poco por debajo del real de AES. Esto no afectaría solo a gnupg, sino que también afectaría a openssl por ejemplo ( da igual el método que uses para el intercambio de claves, si la clave simétrica AES ( o peor aún, RC4 ) que se usa para cifrar la transmisión no es segura, mal vamos. También afectaría a LUKS ( un sistema para cifrar el disco duro bajo linux ).

3) ¿ Por qué quitaron en gnupg la posibilidad de usar elgamal tanto para cifrar como para firmar ?. Pues porque elgamla es un cifrado maleable y como en gnupg se usan los mismos datos ( números aleatorios, primos y demás ) en ambas claves, pues con que alguien firmase con elgamal se le podía reventar la clave principal, debido a ciertas relaciones matemáticas.

4) El algoritmo DSA ( firma digital ) también está diseñado por la NSA. He estado investigando en la web los fundamentos del DSA y no me gusta ni cala. Es un algoritmo muy limitado a ciertos tamaños de firma para determinados hashes y no tiene pinta de ser demasiado robusto que digamos ...

Por todo lo expuesto, usando el modo experto de GPG, he creado mi clave actual, con Elgamal para cifrar y RSA para firmar. El proceso es el siguiente :

1) Creamos una clave en modo RSA Sign Only ( solo firmar )

Cuando termina de generar la clave, nos avisa de que solo vale para firmar y que podemos generar una subclave con el propósito de cifrar, de forma que con :

2) gpg --edit-key identificador

Podemos editar esa clave y con el comando addkey crear una subclave, y ya en este modo nos da una opción antes bloqueada : Usar Elgamal el solito, solo para cifrar, SIN usar esa patata de DSA para firmar. De forma que ahora tengo una clave ELGAMAL-4096/RSA-4096.

A partir de ahora, voy a ir firmando todos mis mensajes en el foro con la clave RSA. Eso sí, una cosa que he notado, es que cuando se hace una firma OpenPGP Armor, obviamente depende del charset que se use, porque por ejemplo este mensaje que va firmado desde un linux, si alguien lo copy-pastea en un fichero en windows y trata de verificarlo, no le va a funcionar porque los saltos de línea en windows tienen otros bytes, eso cambia el hash y por tanto la firma. Supongo que habrá alguna opción en gpg que permita sortear esto especificando el charset en alguna cabecera, pero todavía no la he encontrado.

Saludos !!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJVBIPCAAoJELaXTTOvSgvr6x0P+gPwSSGNqZv+zHt4Ey3CIgO5
XMnXS3Bb/aTTjnHxQiNCZjC+QIaUOkmpmJhnPG3AbWZXdSZhiiYkeavZn6uaf0C+
Y/A3Q3g/sSQBpX/74kiVA1keamQjergps5TgBUpD8VU6vmT1XGNOEdmReoFPT/fJ
yEY8FHrq3QwXG/P8CJZRKK5uF1xXTD8+FMIbsNWBofPLu0GjAXLwW6XCYM7cnzeB
m9UL1LIMxB7YsMl7GB2/VNq/+xT6WQwhO+GyUS1I+kg2Tf2P2UKrtWulX4/ENRXX
M09ETr6HaNwydMX+Ay8G4SbUUSeUOb6mUyU0KUSI5EQq46gMq1Ce7IIhEOZg79sz
oCgu1kVnT1Ojn8AFEYOyjzjtbmogL6bbQqwEk5oJ3WqdqYfIaWvj6z4XwPto9Vz2
C7Tvgc1ljF5vYLhUc6ZLktXr3rxx+IyFiYxBFpKnVaCz2QnikFpJhgYsGbUw/TcL
2fu6Pea0e1MM3V3VAqx862dAo+mIhHZ2e12fJVl3iHbWsei+PcRf4hlwj3EzdqkY
7pW/l6CBtBOnLMXhfcsx+Hy76LciXU1Y8FglbleF50Mi06gd5Y/SBUrsm6Ica3gC
3kFHC/4zXynicg/ER6DlsdMD9byNZJttrw+DdsIBOYQb1cZ52QIxR7MrQOXpDBTV
E668lfGabvkJ7nMIfJnP
=5r56
-----END PGP SIGNATURE-----

[engel lex]

por puntos...

1) aunque está diseñado por la nsa, es codigo abierto, por lo tanto, muy resisado y testeado... dandole poca oportunidad e escoder un backdoor... sobre el destino de MD5 el defecto es la colisión... a medida que las computadoras aumenten la potencia, el tiempo para generar una colisíon disminuye... ahorita lo más que han logrado acortar el proceso de a 2⁶⁹ operaciones para lograrlo, decir 590.295.810.358.705.651.712 operaciones... es decira 1.000.000.000 de hash/s (un numero dificil tomando en cuenta lo complejo del algoritmo) tardarías 18.718 años en colisionar

el MD5 su defecto es su largo

2)

RSA se utiliza para cifrar la clave simétrica que cifrará con AES el mensaje

correción... RSA se usa para generar el par de de claves, no para cifrar la contraseña

(aquí un tema que hice con un poquito de explicación y aplicación en python)

y ya se han desarrollado ataques contra versiones reducidas de AES con un número de rondas poco por debajo del real de AES

basicamente hablas de DES y TDES... si, son vulnerables... pero toma en cuenta esto... cada ciclo de aes aumenta la seguridad dificultad en 16bits de la contraseña... es decir, la aumenta no es un ciclo igual, sino en un cilco con data diferente... mas un ciclo final... es decir, si logras 7 de 10 rondas en 1 hora, las otras 3 rondas te puede tomar 4096 veces ese tiempo... es decir, romper 7 rondas en una hora no te asegura que vaya a ser viable (5 meses para el resto)

4) reviso DSA y te puedo decir, si DSA es vulnerable, poco queda para RSA, ya que DSA es una version "alargada" de un proceso similar a RSA... y puedo decirte que RSA es bastante solido... que sea limitado para tamaños de firma y demás, no lo hace malo, en ese aspecto AES es limitado, solo te permite 3 largos de contraseña y el mensaje debe ser multiplo de 16...

[kub0x]

Buen tema del que hablar, llevo unos meses estudiando detenidamente el extenso campo de la criptografía, pero lo que más me llama la atención es PKI (certificados X.509v3, CAs...), SSL/TLS, generadores de números aleatorios, funciones de resumen para verificación de mensajes, algoritmos de intercambio de clave y algoritmos simétricos.

De primeras creo que todos sabemos que se considera inseguro el uso de criptografía asímetrica basada en curvas elípticas segun en que plataforma suceda el intercambio de claves. Cuando el NIST introdujo los estándares para módulos criptográficos entre todas las funcionalidades aprobadas definieron cuatro algorítmos criptográficos de generación de números aleatorios (CRNGs).

Unos ingenieros de Microsoft se percataron de que el algoritmo Dual_EC_DRBG (generador de números aleatorio determinista para curvas elípticas) era totalmente reversible ya que el estándar proporcionaba ciertas constantes ("hardcodeadas") que permiten al propietario obtener el estado del mismo, de esta forma es muy fácil determinar el valor de salida final. De aquí se armaron muchas polemicas entre ellas que la NSA pagó a RSA para que conviertiera en predeterminado dicho algoritmo. Todo esto es debido a que la NSA revisa los estándares antes de ser aprobados por el NIST.
Se recomienda migrar a cualquiera de los tres algoritmos CRNG restantes, si es que la plataforma lo soporta.

Os dejo una lista de todas las plataformas que incluyen los algoritmos de generación de números aleatorios deterministas aprobados por el NIST.
Lista: http://csrc.nist.gov/groups/STM/cavp/documents/drbg/drbgval.html
Info de algoritmos soportados en Windows + docu de uso y parametrización de la API -> http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1891.pdf
Info de modulos de criptográficos de Windows aprobados por el FIPS -> https://technet.microsoft.com/en-us/library/security/cc750357.aspx#_CNG_Validated_Cryptographic

Sí, entre ellos destacan Cisco, BSAFE, OpenSSL y Windows, como no. Lo mejor de esta lista es que la documentación es descargable y puedes examinar que modulos de user-mode y kernel-mode hacen uso de dichos algoritmos. El predeterminado en Windows en la funcion BCryptGenRandom() es CRT_DBG (AES-256 counter mode).

Cito de la MSDN concretamente la funcion BCryptGenRandom()

The default random number provider implements an algorithm for generating random numbers that complies with the NIST SP800-90 standard, specifically the CTR_DRBG portion of that standard.

He de decir que la entropía proporcionada por la función del kernel SystemPrng() para la generación de la seed es bastante buena, podeis revisarlo en uno de los pdfs de la lista del NIST, el relacionado al driver CNG.sys. Mas info en -> Pág. 19 de http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1891.pdf

A partir de aqui entra la paranoia y el riesgo del espionaje por parte de ya sabemos quien. Hay muchas funciones en la documentación de Windows que no están explicadas al 100%, mucha nube negra. Mi humilde opinión al respecto es utilizar librerías que no implementen Dual_EC_DRBG, curiosamente OpenSSL falló al implementarlo así que permaneció inmune. Eso o hookear el sistema para verificar el paso de parámetros y las llamadas a la Crypto API.

Otra historia es como la gente utilice la criptografía para proteger las comunicaciones en sus plataformas, sólo el 18% de las páginas de internet se consideran seguras o no son vulnerables a ataques conocidos. Sólo decir que uno recoge lo que siembra... Mas info en: https://www.trustworthyinternet.org/ssl-pulse/

Cambiando de tema, con esto no quiero decir que las curvas elípticas sean vulnerables ni mucho menos, son superiores a los métodos de intercambio de claves actuales ya que proveen de perfect forward secrecy, constan de un tamaño de clave inferior a Diffie-Hellman, DSA o RSA pero la complejidad computacional que requieren es similar a la de los algoritmos ya citados. Simplemente deben de utilizarse correctamente.

Sobre DSA parece limpio pero no lo he estudiado a fondo, prefiero RSA para la autenticación ya que lo tengo estudiado. Analicé la entropia en Windows sobre la generación del par de números primos (p,q) para RSA y está perfecta, guardan una distancia suficiente grande que no facilita para la posibilidad de hacer criba para rebajar el problema de factorización.

Sobre PKI que decir, mil cosas, los certificados han tenido problemas desde su inicio y el estándar apenas ha mejorado en consideración con sus orígenes. Si os interesa el tema buscad sobre los ataques a: Basic Constraints, Null-Prefix attacks, MD5 Collision & rogue root CA y mi favorito -> http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf. Este último pdf simplemente habla de desastres en librerías criptográficas muy extendidas en pasarelas de pago como PayPal, apps de Android, iOS etc Como dije antes uno recoge lo que siembra. Quien rompe PKI rompe TLS, ya que el cliente aceptaría el certificado presentado por el atacante y se establecería la conexión con el mismo (MITM).

Para terminar, sólo decir que de aquí puede salir un buen debate jeje.

Saludos!