Duda sobre el progreso en la seguridad de las comunicaciones

[arget]

# By Arget, en Madriz, España ~ 22-03-2016 #

[ INTRODUCCIÓN ]
A raíz de las revelaciones de Snowden (temed pronunciar el nombre del innombrable, acabaré en un manicomio gritando "no estoy loco").

[Sí, esto era la introducción, suelo ser más bien escueto.]

[ PRÓLOGO ]
Es posible que las referencias te interesen más que yo, están al final
Si te intereso pero no todo lo que tengo que decir léete la conclusión del final
Gran prólogo mejor persona.

Desde que empezó la criptografía fuerte abierta al público (dejando de lado el lenguaje de manos que se inventaron mis compañeras de colegio y que no era lenguaje de sordos), durante esta década casi y media hemos ido viendo la aparición de errores en nuestras vidas, y no me refiero a la marcha atrás o al alcohol, hablo de errores tales como FREAK, CRIME, LOGJAM, POODLE, y ahora DROWN (HeartBleed te lo añadimos al carrito por tan solo un euro más), fijaos, ya no solo les asignamos un número de CVE, sino que les ponemos nombre e incluso hasta logo, cosas del cariño que no se pueden evitar :')
Yo personalmente después de HeartBleed no me esperaba más vulnerabilidades, sin embargo ahí tenemos DROWN sonriente como el puto niño que sonríe ante sus desgraciados padres mientras señala con un dedo marrón la pared llena de manchas de chocolate (debo aclarar que DROWN es el puto niño, los padres nosotros, y la NSA algo indefinido, como el chocolate o la pared, estilo Slenderman: está pero no está). Y aquí tengo que pausar la peli para hacer una reflexión, nosotros estamos empezando a perfeccionar nuestro propio sistema mientras que los de ahí arriba lo acabaron y perfeccionaron hace tiempo dejándonos encerrados dentro de dicho puto sistema. Es como el Matrix, nos rodea, lo ves en todo momento, está en el aire que respiras, está ahí cuando bajas la basura, cuando pagas tus impuestos, lo ves al bajar a la calle, no puedes escapar de él, solo a él - Es una definición similar a la de Morfeo.
Pero no vengo a hablar aquí de mis filias, más bien de mis fobias.
No nos olvidemos de quien es el mayor contratante de matemáticos del mundo, no soy yo precisamente, tampoco mi empresa (inexistente) ni a la que voy todas las mañanas, ni siquiera se encuentra en mi país (España), ni en el país de al lado (¿Suecia?). Creo que ya sabemos a quién nos referimos, y no solo al país, sino a qué agencia. En un principio la NSA era capaz de salir a decir que no existía, cosa carente de sentido ya que si no existes tampoco existes para decir que no existes, no hace falta ser un filósofo existencialista (¿pillas el chiste? XD) para darse cuenta del insulto, ahora sin embargo son capaces de ir y en tus narices meter la mano en el sobre que acabas de meter al buzón. Solo tengo una palabra que decir, señoría: descaro.
Veamos el panorama un poco más completo, no es necesario coger el helicóptero, basta buscarse una silla. Antiguamente se entraba por ejemplo a Google, uno iba muy contento sin poner en duda la seguridad de SSL. Ahora te enteras de que no necesitaban siquiera descifrarlo -que podrían-, les basta con pedirlo a Google y otros tantos servicios (Saludad Mark!, Billy!), incluso ya les supone suficiente conseguir los metadatos ("muchos datos y muy datos", gracias, Rajoy, por tu legado a la literatura española), que pueden obtener fácilmente porque los cables de casi toda Internet hacen parada en USA, los caminos ya no conducen a Roma: todos los cables conducen a Guantánamo, supongo. Igualmente, mediante GoogleAds (que están everyweaaar) Google sabe las páginas que visitas, no es necesario que les des la información ni que vengan ellos a cogerla a tu casa, basta con que la tires por la calle. Y existen mil métodos más, que si las cámaras, que si las cuentas bancarias, que si etc... y no tan evidentes: los routers WiFi de las tiendas de la calle pueden registrar las MACs de los móviles que pasan por delante, localizándote finalmente, como ves, esos matemáticos contrataditos se han puesto las botas, al fin y al cabo "Pitágoras no sería un genio sin catetos" (HardGZ). Resulta que al final, todos tus datos, por mucho que los hayas protegido, han acabado en su base de datos en Putah... digo Utah (el corrector... ya sabes), EEUU. Pero obviémoslo. Podemos abrir un debate sobre si usar Google o la oposición libre (of course not Bing!), e incluso dentro de la oposición tendríamos peleas, que si DuckDuckGo, que si Disconnect.me, que si StartPage... Pero como digo, por un momento, metámosnos en la piscina, hundámosnos al fondo, donde todos los sonidos dejan de existir, para fijarnos solo en la criptografía. Finjamos que no pueden obtener los datos ni los metadatos de otra forma que no sea descifrando.
¿Qué tenemos aquí? Hablemos sobre los cifrados que aparecen en nuestra vida a diario: normalmente RSA y Diffie-Hellman.
En este momento aparece uno de los peores niños malos de la familia, FREAK. FREAK permite que una conexión RSA segura de 1024 bits o mayor se rebaje a una de 512 bits. Está comprobado que es posible atacar claves de hasta 768 bits, por tanto esto resulta insuficiente. Este error ya no es solo praxis, también se contempla desde la teoría. Y aún así cabe pensar que si siguiéramos el manual de instrucciones se lo pondríamos más difícil, si algo nos han dado los suecos del maldito IKEA es aprender a seguir las instrucciones. ¿Qué sugiere el manual de instrucciones? Emplear una clave RSA diferente para cada conexión, con esto, para cada conexión esos cabrones tendrían que factorizar la clave restándoles tiempo. Sin embargo, para el servidor esto resulta pesado, generar una clave de un tamaño seguro para cada conexión exige mucho rendimiento y sobre todo tiempo. Por esto emplean una clave para todas sus conexiones, de esta manera, esos cabrones de ahí arriba solo tienen que atacar una clave por servidor para espiar a todos los clientes del mismo. Gracioso, ¿verdad? Yo me estoy partiendo el culo.
Muy cierto, es fácil criticiar, hay que aportar soluciones. Yo no me considero un experto en rendimiento de ordenadores, pero supongo que en los momentos en los que un servidor tiene menos carga de servidores (los servidores de España a las 3 a.m. -hora de España, naturalmente- no deben de tener demasiada carga) puede generar el número de claves que considere necesaria para aguantar durante la jornada, todo en función del número de peticiones que recibe normalmente, no sé, se me ocurre a mí ahora así en frío.
FREAK tiene su hermano mellizo, LOGJAM, que ha salido a su hermano. Hace con Diffie-Hellman lo que FREAK hacía con RSA. Lo expongo:
Diffie-Hellman necesita un número primo de considerable longitud y con ciertas características no debilitantes. Actualmente se suelen emplear primos de minimísimo 1024 bits, pero del mismo modo que en FREAK se puede hacer que se rebaje la seguridad a 512 bits (toda esta ***** por compatibilidad con sistemas de los 90's).
Bien, el ataque consta de dos fases, la primera consiste simplemente en precalcular ciertas operaciones (con un primo de 512 bits en una universidad se tardó dos semanas, con lo de "simplemente" hablo relativamente) con el primo p usado. La segunda fase corresponde con el número aleatorio usado para cada conexión, el proceso es este, una vez tienes toda la primera fase completá', te dedicas a interceptar, una vez interceptas unos cuantos miles de millones de conexiones (ná' eh) coges lápiz y papel y en un minuto, o al menos un minuto es lo que tarda un computador. El caso reside en que existen pocos primos de un tamaño específico (que además estos hinfosmáticos siempre piden que sea una potencia de 2, incomprensible, ¿te lo puedes creer?) y que encima cumplan dichas características "no debilitantes" (estos criptógrafos tan tiquismiquis, ya solo porque un número acaba en 6 no es primo, impresionante, y ahora dirán que 2+2 no da decimales y 3/2 sí), por tanto y como la especificación en el RFC del algoritmo DH no dice nada en contra, se utilizan y reutilizan los mismos pocos primos. Como dice Arturo (en las referencias de abajo) el 80% de los servidores que implementan DH son Apache, todos los Apache emplean el mismo, pero no juzgueis, esta vez no es negligencia, no como en RSA, simplemente que según el estándar no es necesario (ni posible) conseguir un primo distinto de determinada medida para cada conexión. De modo que normalmente se emplean primos del RFC 3526.
Yo ahora quisiera entrar en las paranoias más profundas pero con fundamento. Diffie-Hellman se basa en la conjeturada imposibilidad de resolver el problema de los logaritmos discretos. Como digo es conjeturada, no se ha demostrado que sea realmente imposible, en realidad es igual que factorizar números, _que sepamos_ solo se ha llegado a factorizar un número de 768 bits, no sabemos ni de qué tamaño son los folios de la NSA, y menos aún la potencia de sus ordenadores, como dice alguien de las referencias de abajo (no recuerdo quién) "recordemos que no miden sus ordenadores en FLOPS, sino en hectáreas". Del mismo modo, no sabemos si la NSA es capaz de resolver el problema del logaritmo discreto, aún así, admito que tardarían bastante tiempo y no les sería rentable, pero oye, pongamos TODO sobre la mesa.
Por cierto, de parte del banco acaba de llegar otro regalo junto a las sartenes... no, no, no es otra hipoteca... no, no, no es una carta de deshaucio... ¡que no!, tampoco te piden un riñón ni un ojo, ya te los quitaron sin que te dieras cuenta. Los investigadores ya han expresado su preocupación de que sea posible realizar la fase de precomputación (la primera fase se llama así) para primos de 1024 bits.

No hay que olvidar nunca que los gobiernos trabajan para las multinacionales y para sí mismos. En este momento a ambos les interesa mantenernos vigilados y espiados. Llegarán muy lejos para preservar sus intereses.
Ya que hablamos de hasta dónde llegarían las empresas y de números primos, miraos un segundo esta noticia, como diría Iker: "inquietante".
http://unaaldia.hispasec.com/2001/10/un-numero-puede-ser-ilegal.html
Sí, es del 2001, no es una noticia fresca, pero sí realmente graciosa.

[ CONCLUSIÓN ]
No pretendo dar una imagen apocalíptica de la inutilidad de la criptografía. La criptografía está ahí, funciona y sirve, el problema es que debemos aplicarla de manera segura. Además, para comunicaciones entre dos partes no públicas (i. e. no un servidor), siempre nos quedará la esteganografía.
Mi duda es, ¿realmente hemos logrado avanzar algo en estos años? Hemos reparado brechas como FREAK, pero nadie nos dice que no puedan con las de 1024, ¿hemos fijado el mínimo en 2048 al menos? Para mí el mínimo debería ser 3072, mejor que mejor 4096. ¿Hemos realizado una limpieza de implementaciones de SSL y demás? "Sí, LibreSSL está >libre< [jajá] de DROWN", ya, pero no hablo de eso, LibreSSL tampoco ha sido creada "from scratch". Necesitamos un OpenSSL/LibreSSL estilo qmail o djbdns [ http://unaaldia.hispasec.com/2009/03/existen-programas-sin-fallos-de.html ].

He dicho.

Arget
El anonimato es el mayor de los paraísos. Yo me llamo Ralph!

[ REFERENCIAS ]

http://www.securityartwork.es/2016/03/21/la-historia-del-ermitano/
https://freakattack.com/
https://weakdh.org/
http://naukas.com/2015/10/21/la-nsa-consiguio-desactivar-la-criptografia-internet-primera-parte/
http://naukas.com/2015/10/23/la-nsa-consiguio-desactivar-la-criptografia-internet-segunda-parte/
http://unaaldia.hispasec.com/2015/05/logjam-el-hacedor-de-llaves-en-el-reino.html
http://unaaldia.hispasec.com/2015/03/freak-un-nuevo-ataque-ssltls.html
http://www.set-ezine.org/ezines/set/38/0x06.txt     # Anonimato: Fantasmas en la red  ~ Blackngel
http://www.set-ezine.org/ezines/set/36/0x02.txt     # TOR - Una verdad a medias       ~ Blackngel
http://www.set-ezine.org/ezines/set/36/0x04.txt     # HTTP Fingerprinting             ~ gcode
http://www.set-ezine.org/ezines/set/31/0x0F.txt     # Fingerprinting pasivo           ~ ca0s
http://www.set-ezine.org/ezines/set/13/0x05.txt     # Si alguien llama a tu puerta... ~ Paseante
http://www.set-ezine.org/ezines/set/26/0x0A.txt     # Esteganografía, el poder oculto ~ GRRL
https://www.youtube.com/watch?v=fDPpzG6u-as         # Nothing to hide?                ~ Cryptoparty

[engel lex]

Hay algo que no se debe tomar a la ligera y evitar interpetar mal...

Un cifrado no es necesariamente mas seguro con mas bits al igual que , el bajar de 1024 a 512 no lo hace viablemente vulnerable..

[arget]

Es cierto que yo, con mi Intel Celeron, no puedo con 512 bits ni con 128, ni con 56, pero es seguro que la NSA sí, y otro tema preocupante (lo meto con calzador) es también si grupos no gubernamentales ni empresarios, como las mafias y otros tipos de delincuentes lograrían la misma capacidad computacional para lograrlo.
Por otro lado discrepo, la cantidad de bits si aumenta la seguridad.
Es una proporción simple:
Si aumenta la cantidad de bits, aumenta la cantidad posibles valores, al aumentar esto se requiere más tiempo para recorrer todos los valores, a niveles de tiempo de 1024 bits podríamos hablar de años, de 2048 de décadas, a 3072 siglos y 4096 milenios, piensa que esto es exponencial.

[engel lex]

Digo que no, porque se hab dado ya los casos que al aumentar la cantidad de bits, los bits adicionales terminan siendo relleno y completamente reversibles o peor, terminan creando un patron que causa la perdida de la seguridad del trabajo criptografico

Entiendo tu punto de la seguridad, pero sabiendo tuno poco de matemática, tambien sabes que tan seguro es

[arget]

Ya, pero yo no hablo de cifrados de hash ni simétricos. Hablo de claves, y en el caso de un tamaño de clave SIEMPRE será en su TOTALIDAD, sea del tamaño que sea, ALEATORIA o pseudoaleatoria.
Al ser mayor el número más fastidioso es factorizar la clave pública. ¿Quién tiene más factores, el 4 o el 304? En el caso de DH igual, con un primo de 1024 bits es necesario hacer más operaciones que con uno de 512, con uno de 2048 ni hablemos, esto es exponencial... Pero en ningún momento se establece ningún tipo de relleno.

Y normalmente los rellenos se realizan de manera segura si es que son necesario (repito que en este caso no), son rellenos aleatorios (salvo en el caso de funciones de hash como MD5) que se distinguen del mensaje mediante unos caracteres específicos que los separan.
Yo creo que te confundes con los modos de los cifradores de bloques, específicamente con ECB.

Todo esto sin intentar dar clases de nada ni ofender de ninguna manera

[kub0x]

No sé si serás tú el autor del texto (por el formato), pero supongo que tienes los conocimientos necesarios. No estaría mal que leyeras mi "análisis" sobre ECC, PKI y variantes de hace un año -> https://foro.elhacker.net/criptografia/iquest_os_parecen_realmente_seguros_los_cifrados_actuales-t431759.0.html

El problema es el mismo que con los protocolos iniciales de internet, la subversión. No es lo mismo buscar un bug en una libería criptográfica que romper el principio Gaussiano de su Disquisitiones, cosa que todavía no he visto en ningún lado. Tienes algoritmos que rebajan el coste (pollard's, baby-giant, lattices etc), pero nada que factorice o nos dé el índice de la modular exponencial en un tiempo razonable.

Cómo bien dices POODLE y ahora DROWN son cagadas similiares, basadas en el puro principio de Bleichenbacher sobre los Oracles. Con FREAK y LOGJAM sufrimos la tontería de los algoritmos de exportación de los años 90, donde la NSA obligaba a empresas extranjeras a usar tamaños de clave inferiores, facilitando el desciframiento de las comunicaciones. Pero tu hablas de fallos de Padding (DROWN, POODLE), Compresión (CRIME), Downgrade (FREAK, LOGJAM) y reutilización de primos en DH, esto último muy viejo ya que casi todos los servers utilizan varios grupos multiplicativos modulares, no uno hardcodeado (crypto efímera, DHE).

El NIST y la NSA van de la mano, el NIST crea la NSA revisa, todo ello cumpliendo el FIPS. En el tema de las ECC de arriba queda bien claro. Pero piénsalo, el problema REAL vendrá cuando los problemas en los que se basa criptografía pura, y no los protocolos subyacentes (TLS/SSL-PKI), comience a ser rebajada a un problema de parbulitos. Todos sabemos que PKI+TLS es inseguro, pero lo subyacente lleva más de 40 años perdurando.

Saludos!

[arget]

Lo primero, y por tanto menos importante (XD) es que sí, lo he escrito yo, no sé a qué te refieres con el formato, a mi parecer se ve igual que cualquier otro post, solo que no me gusta escribirlo en el textarea de elhacker.net y lo escribo en gedit para luego copiar y pegar.

Me he leído el tema que dices, sinceramente me parece más interesante tu respuesta a Engel Lex que el primer post jajaja.
Solo decir una cosita a Engel Lex, RSA también incluye el algoritmo de cifrado, el que sea una simple potencia no quiere decir que ya solo especifique el algoritmo de generación de contraseñas.
Es cierto que la NSA ha realizado sus intervenciones a los estándares (por eso siempre me he fiado más del RFC que del FIPS, NIST, y otras diabluras que rimen con "chip", aunque sea rima asonante). Tenemos también la intrusión al CVS de Linux para introducir un backdoor [ http://www.securitybydefault.com/2010/10/hackeos-memorables-la-backdoor-en-el.html ], el testimonio de Linux Torvalds diciendo que se lo han pedido directamente, la presencia omnipresente de SELinux (creado por la NSA) que yo siempre desactivo (¿si tanto nos atacan por qué iban a hacer un software para protegernos?, sí, ya sé que en ciertas experiencias de laboratorio ha evitado ciertos errores [ https://www.youtube.com/watch?v=8_Bc0n70Erc ]) y la petición para poner un backdoor en los... ¿cómo se llamaban estos trastos? Siempre me han sonado a BlackBerry... Raspberry. Incluso el descubrimiento del Equation Group (también de la CIA o la NSA o de esta gente) sobre cómo introducir virus en el firmware de un usb, etc. ¿Pero llegar a decir que el AES en inseguro? Yo lo considero totalmente seguro, a 256 bits, mediante el modo CBC o incluso el CTR basta, perfecto. Puedes decir que el que la contraseña sea de 256 bits como máximo te limita, yo particularmente lo soluciono aplicándole primero un SHA-256. Ah, espera, que como también es de la NSA ya no vale. SHA-2 lleva ya casi tanto tiempo en juego que la PS2 y si no se ha publicado nada, yo me callo la boca (no es lo mismo que SELinux). E igualmente confío plenamente en RSA. Y ya, para que me crucifique la comunidad criptográfica, digo que RC4 bien implementado (como casi todo menos el cifrado de César) es plenamente seguro, es cierto que el one-time-pad directamente implementado mola más y es más seguro, pero no es viable, lo siento.
Si no te gustan vete a tu esquinita a usar IDEA, Blowfish, RC5, Serpent, SHARK, Xenon y hasta el cifrado francmasón, por lo menos podrás comunicarte con la pared.

Y ya para acabar, es eso justo lo que digo, la criptografía como tal funciona, el problema son las implementaciones que usamos, y por eso digo que haría falta un qmail o djbdns de la criptografía, que se ha tardado más de una década en encontrarles apenas una diminuta pega de seguridad.
Dejando a un lado la conspiranoia que suelto al final de si serían capaces de resolver los logaritmos discretos y tal...

Y ahora sí, para terminar, la reutilización de primos no lo digo como algo malo ("no es negligencia"), es simplemente que no se considera dañina la reutilización de primos. Sin embargo, repito que el 80% (82% en realidad) de servidores que implementan DH son servidores Apache, y estos emplean todos el mismo primo.

No sé, propondría hacer aquí, en elhacker.net nuestra propia implementación de TLS y ver hasta dónde llegamos, pero creo que con la pereza que al final se respira en estos foros no llegaríamos ni a escribir el #include <stdio.h>

[kub0x]

Lo primero, y por tanto menos importante (XD) es que sí, lo he escrito yo, no sé a qué te refieres con el formato, a mi parecer se ve igual que cualquier otro post, solo que no me gusta escribirlo en el textarea de elhacker.net y lo escribo en gedit para luego copiar y pegar.

Mil perdones, no vi el encabezado del mensaje, ahí puedo apreciar que es de tu autoría.

¿Pero llegar a decir que el AES en inseguro? Yo lo considero totalmente seguro, a 256 bits, mediante el modo CBC o incluso el CTR basta, perfecto. Puedes decir que el que la contraseña sea de 256 bits como máximo te limita, yo particularmente lo soluciono aplicándole primero un SHA-256. Ah, espera, que como también es de la NSA ya no vale. SHA-2 lleva ya casi tanto tiempo en juego que la PS2 y si no se ha publicado nada, yo me callo la boca (no es lo mismo que SELinux). E igualmente confío plenamente en RSA. Y ya, para que me crucifique la comunidad criptográfica, digo que RC4 bien implementado (como casi todo menos el cifrado de César) es plenamente seguro, es cierto que el one-time-pad directamente implementado mola más y es más seguro, pero no es viable, lo siento.
Si no te gustan vete a tu esquinita a usar IDEA, Blowfish, RC5, Serpent, SHARK, Xenon y hasta el cifrado francmasón, por lo menos podrás comunicarte con la pared.

Supongo que intentarás esclarecer la situación actual. Espero que nadie de aquí diga lo contrario, es verdad que el órgano que regula la crypto en su mayor parte es la NSA, junto a los ya nombrados FIPS y NIST. ¿Los RFC de dónde crees que sacan sus especificaciones? No hay RFC si no se revisa y se aprueba el protocolo primero por estos órganos. Que decir que todos los módulos criptográficos, incluyendo los hardware (amazon y demás) cumplen con el FIPS-140 (y el 180) https://en.wikipedia.org/wiki/FIPS_140 cosa que se puede llegara desactivar, para utilizar otras versiones alternativas también aprovadas por el NIST. Si he llegado a este punto es por ver que implementaciones corren en nuestras máquinas a diario. Toda la info es pública, puedes ver que algoritmos CSPRNG, simétricos, asimétricos, parametrización, etc se utiliza en los susodichos módulos incluso a nivel de kernel, como generan la entropía y demás. Desde 2001 el PRNG estándar está contaminado, pero eso ya lo hablé en el otro post.

Como bien dices, el problema son las implementaciones, no la matemática subyacente, si el PRNG está contaminado ni AES se salva. A RSA se le pagó 1millon de $ para hacerlo estándar en sus módulos criptográficos (alavado sea Bruce Schneier por hablar sin tapujos). A TLS se le encuentran fallos de downgrade porque permite suspender el handshake temporalmente dando pie a crackers a computar la clave de sesión, para así completar el "finished". A mi eso me parece una aberración. A parte, sino, se le encuentran fallos de compresión, de padding, como bien dices, de reutilización de grupos modulares, a esto último le llaman DHE (ephemeral), vale, que seleccionan un exponente arbitrario cada vez, ¿pero y el módulo primo? Si no se cambia este último cualquier centro de cómputo puede llegar a computar la mayoría de índices (log. discreto) sobre el mismo grupo rompiendo así la crypto (LOGJAM).

Ahora los medios sensacionalistas e ingorantes dicen que ya se está factorizando a nivel cuántico (que si aplicando Shor etc), si leyesen el paper del MIT, se darían cuenta que están en pañales, pero no se molestan en verificarlo (el número en cuestión es el semiprimo 15). Ni siquiera resolviendo la hipotesis de Riemann se podría romper RSA, eso sí, podría darse el caso que resolviéndola se generara un nuevo algoritmo de factorización que cambiara las cosas.

No sé, propondría hacer aquí, en elhacker.net nuestra propia implementación de TLS y ver hasta dónde llegamos, pero creo que con la pereza que al final se respira en estos foros no llegaríamos ni a escribir el #include <stdio.h>

¿Cuántos usuarios crees que son capaces de comprender las entrañas de un tema tan extenso como la crypto? Llevo cosa de 2 años centrado en esto y no es moco de pavo. Me veo capaz, pero el foro de crypto pasó a mejor vida me da.

[arget]

Bueno, me has dado donde más me duele. El RFC depende de tres instituciones, la IAB que proporciona ideas a las otras organizaciones y "vigila" su trabajo, el IETF que es quien realiza el desarrollo de la ingeniería (también está el IRTF -no es un impuesto, aunque lo parezca-), y el IESG, encargado de seleccionar los trabajos de la IETF, IRTF... (pongo puntos suspensivos porque no sé si hay más). El IAB empezó como parte del DoD, de acuerdo, sin embargo en ese momento era joven e inexperto, no podemos culparlo, ni siquiera era IAB, estaba todavía en la infancia: Internet Configuration Control Board se llamaba. Evolucionó, maduró y se hizó público. "as part of the Internet's transition from a U.S.-government entity to an international, public entity." (Wikipedia). Esto fue en 1992, desde entonces el DoD no ha tenido poder para manipular nada dentro de ellos.
El IETF empezó como parte del "US government" (todo suena más serio dicho en inglés). Pero desde 1993 pertenece a la Internet Society, completamente no gubernamental.
Finalmente, la (o "el", no sé) IESG es quien lleva el proceso de estándares de Internet. Está formado puramente por el presidente de la IETF y directores del mismo y por tanto, al ser la IETF independiente de ningún gobierno, solo depende del IS (pero hasta tal punto que el IS y el IETF se puedan considerar uno), este también es independiente de ningún gobierno, solo depende de la IETF.
Dentro de la IETF todo es voluntario, se participa en grupos de trabajo y quien quiera cuando quiera puede publicar algo y dejarlo como "borrador de internet". Quien quiera puede revisarlo y realizar observaciones sobre el mismo. Mientras está como borrador (6 meses máximo, si después de 6 meses no ocurre nada, el grupo de trabajo puede publicar una revisión del anterior) la IESG lo puede convertir en RFC.


Dejando esto de lado, que yo sepa, el PRNG no tiene nada que ver con AES, ¿no? No sé, nunca he estudiado a fondo fondo el AES, pero sabiendo sus principios (y medios)... no lo veo.

Y ya, bueno, es que no sabemos qué tecnología usan ahí arriba. Pueden tener ordenadores cuánticos o no. No lo sabemos, del mismo modo que no sabemos si nosotros descubrimos el cifrado asimétrico a la vez que ellos, de todas formas yo te digo que estoy muy seguro de cuál es la respuesta (entre otros porque por una vez hasta la NSA lo ha dicho, si bien no lo demuestra).
De todas formas, si no tienen cuánticos, casi, el segundo ordenador más potente del mundo es Titan, en US, no diría los FLOPS para no deprimir al personal, pero puesto que defiende mi tesis me veo obligado a decirlo: 50 petaFLOPS. 50 petaFLOPS. No hace falta tener una licenciatura para saber que es más de un Billón de FLOPS (bastante más). Como si los FLOPS se regalaran.

[kub0x]

Buenas arget,

me refería a los RFC sobre estándares criptográficos. Obviamente las instituciones que he nombrado anteriormente no componen dichos documentos, pero fíjate que dichas instituciones son las que revisan y aprueban las primitivas criptográficas contenidos en dichos documentos (RFCs), así que para mi casi es lo mismo (por eso tiendo a generalizar).

Bueno los PRNG si tienen una tendencia (bias) su internal state puede ser determinado y de esta manera determinar su salida al completo, pudiendo recuperar por ejemplo la clave generada para un cifrado en AES (o cualquier otro). En el caso que expuse Dual_EC_DRBG sirve para el mismo propósito. Gracias a dios Win$ no utiliza el susodicho PRNG, todo ello bien documentado en el documento del FIPS-140 asociado a sus módulos criptográficos.

En lo de los FLOPS me has pillado, ¿puedes darme algo de docu para enterarme cuantos FLOPS tiene un equipo convencional y cuantos FLOPS son necesarios por ejemplo para factorizar un semiprimo con NFS o criba cuadrática? Lo único que se sobre el cómputo de la NSA es que un día Utah saldrá por los aires si eso explota

Para concluir, supongo que nadie enterado sobre estos temas se fía de las implementaciones privativas, lo mejor sin duda es utilizar alternativas libres, revisándo el código y ajustándolo a tus gustos.

Saludos!