Crackear WPA de modems Infinitum

Como ejercicio mental estuve pensando en el tiempo y costo que tomaría crackear la contraseña de mi router Infinitum que tiene cifrado WPA en modo PSK y la contraseña viene escrita en 10 caracteres hexadecimales en la etiqueta del aparato. Cabe recordar que antes de 2012 todos venían con cifrado WEP de 40 bits.

Para algunas marcas de estos modems, como Thomson y Huawei, existen herramientas disponibles al público (Router Keygen) que permiten calcular la contraseña sin mayor esfuerzo, esto se debe a que sus contraseñas por defecto vienen derivadas del BSSID (MAC Address del router). También existen otros ataques fáciles de realizar para routers con el protocolo WPS (muchos Infinitum lo traen), una herramienta para esto es reaver.

Para los casos en los que esto no funciona y la única opción es la fuerza bruta nos enfrentamos a dos cosas: (1) tenemos que obtener un handshake entre el modem y un cliente (tablet, laptop, etc.) conectado y (2) tratar de encontrar la clave a través de ese handshake. Para la primera parte se puede hacer un ataque con aircrack. Para la segunda parte vamos a suponer que ya tenemos nuestro handshake propio capturado, que contiene el Pairwise Master Key (PMK), y de donde vamos a recuperar la contraseña WPA original (ver nota final).

Existen dos herramientas principales para hacer lo más rápido posible el cálculo de PMKs, la primera es coWPAtty y la segunda pyrit. La ventaja de pyrit es que funciona sobre tarjetas gráficas (en la página vienen los benchmarks de PMK/segundo por modelo de tarjeta). En Amazon EC2 podemos rentar instancias de GPU y según alguien que ya hizo las pruebas llegó hasta 50,000 PKM/segundo, con un costo de $2.10 dólares por hora. En una hora se pueden calcular un total de 180 millones de PMK (aprox 2^{27.42}).

Si quisiéramos realmente probar todas las claves posibles, que en este caso son 2^{40}, nos tomaría con una sola instancia un total de 6,109 horas a un costo de $12,821 dólares. No quiere decir que nos tardaríamos meses porque este proceso es completamente paralelizable y con 36 instancias simultáneas en una semana se hace el cracking total.

Podemos concluir que es un costo demasiado elevado y aunque no es una seguridad perfecta está muy fuera del alcance de un cracker de medio pelo pero no para un gobierno. Este análisis también sugiere el tiempo/costo necesario para crackear una contraseña TrueCrypt de 8 caracteres alfanuméricos, que es equivalente a una de 41.3 bits (log_2(36^8)), sólo tomaría poco más del doble de tiempo y recursos. Así que si la NSA quisiera podría cracker fácil una contraseña así y por eso TrueCrypt recomienda contraseñas de 20 caracteres, para al menos lograr una seguridad de 103 bits.

Nota: El handshake WPA contiene la contraseña pero no en texto plano, lo que contiene es la derivación de esa llave (Pairwise Master Keys) a partir del algoritmo PBKDF2. Dicho pronto y mal para WPA se aplica 4096 veces SHA1 sobre la contraseña y utiliza como salt el SSID (nombre de la red), por lo que probar una clave no es tan trivial como calcular sólo un SHA1, además que el salt evita tener tablas universales precalculadas.

Inseguridad Telmex

Estaba yo navegando por la página de El Universal, cuando veo un anuncio enorme en donde Telmex ofrece servicios de seguridad perimetral en redes. Sé que muchos ya estarán riéndose de esto, pero algunos pensarán que como es una empresa grande (que gana mucho dinero) alguna calidad deben tener sus servicios y algún otro tal vez hasta piense contratar esto para su empresa ¡cuidado!

Es bien sabido que Telmex es la principal empresa proveedora de enlaces a internet en este país y en el mundo de la seguridad (sobre todo para los amantes de aircrack) es además bien sabido que son la principal empresa que instala sus modems preconfigurados con la insegura y obsoleta tecnología WEP para proteger el acceso a las redes inalámbricas de cada punto de acceso. Para decirlo pronto y claro, cualquier persona con un pequeño entrenamiento puede colarse a la red inalámbrica de tu casa si es que tienes Infinitum.

Con esta información, da mucha risa que ofrezcan estos servicios de “seguridad” cuando sería trivial colarse a la red local de una empresa que tenga contratado un Infinitum, por más firewall, VPN e IPS que tengan configurado. Una vez dentro de la red local “de ahí pal real” con todas las máquinas Windows que tengan, recursos compartidos en red, conversaciones en MSN, passwords que viajen en texto plano (sin https), etc.

Al final es triste recordar la incultura en seguridad que se tiene en el mundo empresarial, las pésimas políticas que se adoptan y los engaños de marketing que les cuelan. Lo peor es que no se limita a México, sino en todo el mundo es lo mismo.

Si quieren verdadera seguridad para sus servicios, ahí les dejo nuestro enlace.

P.D. Dado que no quiero darle referencias de este blog a esa abominación de empresa llamada Telmex usé la etiqueta rel=”nofollow” para el enlace.

Vulnerabilidad LNK

El 17 de junio de 2010 se descubrió una vunerabilidad 0-day que afecta a todas las versiones de Windows. Lo terrible del asunto es que se descubrió después de que ya estaba siendo explotada por un troyano cuyo fin era el espionaje industrial.

La noticia saltó a los medios especializados el 16 de julio. Los primeros detalles indicaban que la vulnerabilidad permitía a un atacante ejecutar automáticamente código al insertar un medio extraíble en el sistema. La crónica y más detalles se puede encontrar aquí:

Interesante (y peligroso) troyano que aprovecha un interesante (y peligroso) 0 day en Microsoft Windows

Ahora el código es público y ni lentos ni perezosos ya lo incluyeron en la archiconocida suite MetaSploit. Aunque ya es posible mitigarlo mediante una Directiva de Seguridad Local, Microsoft no ha publicado aún ningún parche.

Gracias a Un informático en el lado del mal por la recopilación de fuentes.

Autenticación segura sin SSL/TLS

Muchas veces no es necesario o es demasiado cifrar toda la comunicación entre el cliente y el servidor, por razones de performance o por el sobrecosto de implementar un esquema de PKI (Public Key Infraestructure) para usar SSL/TLS. Pero siempre hay algo que es necesario proteger por seguridad: las credenciales de autenticación del usuario. Por lo que en este post explicaré cómo se puede hacer una autenticación sin enviar esa información (no, no es telepatía).

Protocolos de conocimiento cero (ZKP)

Sabemos que sin un esquema de cifrado de llave pública es trivial para un atacante interceptar la información que se envía entre el cliente y el servidor, pero el sistema debe tener alguna manera de autenticar a los usuarios del sistema. Necesitamos enviar algo que si un atacante intercepta no pueda utilizar para autenticarse. Esto se conoce como un protocolo de conocimiento cero (Zero-knowledge proof), y en palabras coloquiales significa: “probar que poseemos cierta información sin revelar esa información”.

Como comúnmente la única información que queremos “probar que poseemos pero no queremos revelar” es la contraseña, voy a explicar el esquema que usa MySQL para implementar su autenticación de usuarios. Los detalles no están explicados de manera formal en la documentación de MySQL pero alguien se tomó el tiempo de leer el código fuente y explicar cómo funciona (MySQL 4.1.x authentication internals).

¿Cómo se almacenan las contraseñas?

Lo primero que hay que tener en cuenta es que, siguiendo los principios básicos de almacenamiento seguro de contraseñas, éstas se almacenan en el sistema sólo como un hash criptográfico. Que tiene la propiedad de ser prácticamente irreversible y prácticamente único. Por lo que esta es la primera parte del ZKP, ya que sólo quien conozca la contraseña podrá generar el hash criptográfico que le pertenece.

Desde MySQL 4.1 las contraseñas de usuario están almacenadas en la tabla “mysql.user” en la columna “Password” de la siguiente manera: SHA1(SHA1(password)). Donde SHA1 es el hash criptográfico SHA-1.

La transmisión

Si cada vez que el cliente se quiera autenticar sólo transmitiera SHA1(SHA1(password)), cumpliría con el principio de no revelar la contraseña, pero un atacante podría capturar y enviar después SHA1(SHA1(password)) para autenticarse exitosamente aún sin conocer la contraseña. Por lo que necesitamos agregar más cosas al protocolo para que la información que transmite el cliente sólo sea útil para un intento de autenticación.

Este sería el esquema cliente-servidor para la transmisión:

  1. Se inicia el intento de autenticación
  2. El servidor genera una cadena aleatoria salt y se la transmite al cliente.
  3. El cliente calcula S_1 = SHA1(pass), S_2 = SHA1(S_1) y S_3 = SHA1(salt+S_2) (aqui + significa concatenación).
  4. Finalmente el cliente transmite M = S_3 \oplus S_1. (aquí \oplus significa bitwise XOR)

Autenticación

El servidor sólo conoce H = SHA1(SHA1(password)), que está almacenado en la tabla de usuarios, y salt. Para autenticar hace lo siguiente:

  1. Calcula S'_3 = SHA1(salt+H).
  2. Calcula S'_1 = M\oplus S'_3.
  3. Calcula S'_2 = SHA1(S'_1).
  4. Sólo si H=S'_2 la autenticación es exitosa.

Observaciones

Nunca se transmite S_2 ni S_1, por lo que la fortaleza está en que este ZKP verifica que el cliente conoce SHA1(password)) y SHA1(SHA1(password)) pero sin revelar esa información, y que sería casi imposible que un atacante poseyera sin conocer password.

También hay que observar que salt es una cadena única por cada intento de autenticación, o sea que esa cadena siempre está cambiando.

Implementación

Próximamente trabajaremos en una implementación de este esquema para aplicaciones web usando JavaScript y PHP, que publicaremos bajo licencia LGPL.

Tutorial de exploits y shellcodes

Normalmente cuando uno busca información sobre exploits y shellcodes es frustrante darse cuenta que mucha de la información está bastante desactualizada y muchas veces no se explican a detalle ciertos pasos que para un novato son un reto resolver cuando se quiere llevar a la práctica lo aprendido.

Hoy encuentro una serie de posts referentes a un exploit en concreto en donde explican con cierto grado de detalle los pasos concretos a seguir y los conceptos que hay detrás de un exploit por stack overflow para la aplicación Easy RM to MP3 Conversion Utility.

Exploit writing tutorial part 1 : Stack Based Overflows

Exploit writing tutorial part 2 : Stack Based Overflows – jumping to shellcode

Exploit writing tutorial part 5 : How debugger modules & plugins can speed up basic exploit development

Exploit writing tutorial part 3 : SEH Based Exploits

Exploit writing tutorial part 6 : Bypassing Stack Cookies, SafeSeh, HW DEP and ASLR

Exploit writing tutorial part 3b : SEH Based Exploits – just another example

Exploit writing tutorial part 4 : From Exploit to Metasploit – The basics

Exploit writing tutorial part 7 : Unicode – from 0×00410041 to calc

Y sigue actualizándose.

Port Knocking : Evita ataques masivos a tu puertos

El port knocking se refiere a una combinación de puertos que debemos “tocar” para que el servidor nos de acceso a un servicio. Por ejemplo, cuando alguien establece una conexión por ssh implícitamente va un paquete al puerto 22 intentando iniciar la conexión, y esto sería “tocar” el puerto 22.

¿Para qué?

Si tenemos un servidor accesible desde internet, es común que recibamos ataques automáticos por diccionario contra nuestro servidor; esto es así porque hay muchas botnets que realizan ataques masivos contra todo lo que encuentren en internet. Pero al implementar port knocking estas botnets ignorarán nuestro servidor, y además los escaneos de puertos no podrán ver abiertos los puertos sensibles, aunque nosotros sí tengamos acceso a ellos.

Por otro lado, cuando un servicio como ssh o mysql están recibiendo un ataque por diccionario, la política automática por defecto es aumentar el tiempo de espera para hacer login, por lo que empezaríamos a notar comportamientos extraños en nuestro servidor (lentitud al realizar operaciones que requieran conexión a esos servicios).

Funcionamiento

El funcionamiento es simple: lo que va a pasar es que aparecerá cerrado el puerto 22, pues se está esperando a que le mandemos una combinación de puertos, supongamos la combinación 1200, 234, 654, 4509, 12; y, una vez enviada la combinación podremos establecer la conexión al puerto 22 (el del ssh).

Ya en la práctica tendríamos lo siguiente:

      Intentamos entrar al puerto 22 (aparece cerrado)
      Abrimos una conexión con el puerto 1200 (responderá que esta cerrado) pero el servidor sigue en espera de las demás conexiones
      Abriimos una conexión con el puerto 234 (nos aparece cerrado) el servidor ya sabe que tenemos las primeras dos combinaciones bien
      Abrimos una conexión con el puerto 654, luego 4509 y luego el 12
      Ahora tenemos 5 segundos para iniciar la conexion por ssh
      Iniciamos la conexión exitosamente

El port knocking es como si metieramos a una caja fuerte nuestra laptop, y aún después de poner la combinación se tendrían que poner el password de la computadora. Esto obviamente aumenta la seguridad en una forma considerable.

Hay que recordar que esto a pesar de ser una buena forma de asegurar un puerto, necesita tener dentrás una buena contraseña y unas buenas políticas, pues si para alguien que estuviera analizando nuestro tráfico sería trivial obtener la combinación de puertos.

Implementación con iptables

Con ayuda de iptables podríamos hacerlo suponiendo la combinacion 100, 200, 300, 400, ssh(22):

HOST_IP="12.34.56.78"

/sbin/iptables -N INTO-PHASE2
/sbin/iptables -A INTO-PHASE2 -m recent --name PHASE1 --remove
/sbin/iptables -A INTO-PHASE2 -m recent --name PHASE2 --set
/sbin/iptables -A INTO-PHASE2 -j LOG --log-prefix "INTO PHASE2: "

/sbin/iptables -N INTO-PHASE3
/sbin/iptables -A INTO-PHASE3 -m recent --name PHASE2 --remove
/sbin/iptables -A INTO-PHASE3 -m recent --name PHASE3 --set
/sbin/iptables -A INTO-PHASE3 -j LOG --log-prefix "INTO PHASE3: "

/sbin/iptables -N INTO-PHASE4
/sbin/iptables -A INTO-PHASE4 -m recent --name PHASE3 --remove
/sbin/iptables -A INTO-PHASE4 -m recent --name PHASE4 --set
/sbin/iptables -A INTO-PHASE4 -j LOG --log-prefix "INTO PHASE4: "

/sbin/iptables -A INPUT -m recent --update --name PHASE1

/sbin/iptables -A INPUT -p tcp --dport 100 -m recent --set --name PHASE1
/sbin/iptables -A INPUT -p tcp --dport 200 -m recent --rcheck --name PHASE1 -j INTO-PHASE2
/sbin/iptables -A INPUT -p tcp --dport 300 -m recent --rcheck --name PHASE2 -j INTO-PHASE3
/sbin/iptables -A INPUT -p tcp --dport 400 -m recent --rcheck --name PHASE3 -j INTO-PHASE4

/sbin/iptables -A INPUT -p tcp -s $HOST_IP --dport 22 -m recent --rcheck --seconds 5 --name PHASE4 -j ACCEPT

Y para hacer el knocking sería de esta forma:

$telnet 10.1.1.1 100 ; telnet 10.1.1.1 200 ; telnet 10.1.1.1 300 ; telnet 10.1.1.1 400 ; ssh 10.1.1.1

Luego presionamos Ctrl+C 4 veces y listo.

(Fuente: Debian Administration)

Prey: rastrea tu laptop robada (OSX, Linux, Unix)

Navegando por malas aguas me he encontrado con una solución de seguridad muy buena de un desarrollador al que le robaron su laptop, que al no soportar el coraje de lo sucedido realizo este script que nos ayuda de manera muy completa quien fue, como y donde recuperarla.

Dandonos información valiosa como:

Información de red

  • La dirección IP pública y privada de donde esté conectado el PC.
  • El IP del gateway de la red que está usando para salir a Internet.
  • La dirección MAC de la tarjeta o controlador de red por el cual esté conectado a la red.
  • El nombre e ESSID de la red WiFi a la que esté conectado, en caso que lo esté.
  • Un listado de conexiones activas en el momento en que se ejecute el programa.

Información interna del PC

  • Cuánto tiempo lleva encendido el aparato.
  • Número de usuarios logeados.
  • Un listado con los programas en ejecución.
  • Un listado con los archivos modificados en la última hora (o el número de minutos que tú definas).

Información del ladrón

  • En caso que el PC tenga una webcam, una foto del impostor.
  • Un pantallazo del escritorio, para que veas qué está haciendo.
  • El tatuaje indistinguible de nuestro nuevo amigo.

¿Como Funciona?

Cada cierto intervalo de tiempo (default = 10 minutos) el programa se ejecuta y revisa si en la configuración pusiste una URL de checkeo o no. En caso que no lo hayas hecho, o que lo hayas hecho y la URL sí exista, el programa hará el proceso de recolección y envío de datos. Si definiste una URL que no existe, el programa se apagará para volver a ejecutarse en 10 minutos más.

Ejemplo

Para instalarlo:

  • Bajamos el siguiente paquete
  • Abrimos la grandiosa terminal y ejecutamos lo siguiente:

$ wget http://bootlog.org/downloads/prey-0.1.zip

$ unzip prey-0.1.zip

$ cd prey-0.1

$ chmod +x install.sh

$ ./install.sh

  • Seguimos las instrucciones como muestro a continuacion:
    prey

One-Time Pad el cifrado perfecto

Hay quienes creen que no existe un método de cifrado perfecto, o un cifrado que te pueda garantizar seguridad absoluta y se equivocan.

El método de cifrado de One-Time Pad, que fue inventado en 1917 por el Mayor Joseph Mauborgne y Gilbert Vernam de AT&T. Claude Shannon, 25 años después, se encargó de demostrar con la teoría de la información que este cifrado cumple con ser un secreto perfecto, lo que quiere decir que el contenido del mensaje no puede aportar nada de información a un atacante.

Es un método que sin importar el poder computacional que se tenga o si se haya inventado la computadora cuántica o si los extraterrestres de Andrómeda vengan a la tierra con sus métodos computacionales inimaginables, aún asi será seguro.

Preliminares

Necesitamos una llave de la misma longitud que el mensaje, la cual deberá ser de verdad aleatoria y no pseudo aleatoria. Además esta llave se supone que las dos partes la deben conocer (problema de intercambio de llaves) y cuando una parte cifre el mensaje debe destruir esa llave de alguna forma que no pueda recuperarse y luego enviar el mensaje cifrado, luego la otra parte va a descifrarlo y al terminar de hacerlo debe destruir la llave de nuevo.

Es primordial que no se vuelva a usar la misma llave dos veces pues un criptoanalista podría romper el cifrado sabiendo dos mensajes diferentes que se encriptaron con la misma llave.

¿Cómo funciona?

Es algo muy simple de entender, teniendo el texto:

Teniendo la llave:

El texto cifrado sería:

Porque:
A + R mod 26 = S
M + F mod 26 = S
A + T mod 26 = U

Suponiendo que A vale 1 y R vale 17: 1+17 = 18 y 18 / 26 nos daría como residuo 18, entonces el 18 corresponde a la letra S.

Es importante ver que no puede romperse incluso si pudieramos calcular todas las posibilidades y buscar mensajes coherentes, pues al decifrarlo podría decir SIVOY como NOVOY entonces es imposible saber cual es el mensaje cifrado sin saber la llave. Según dicen, los Rusos cifraron algunos mensajes con este método y siguen hasta la fecha sin poderse descifrar, y así seguirán para siempre.

El problema con este método y en general con cualquier método de cifrado simétrico es el intercambio de llaves, pues ¿cómo podrías intercambiar la clave del One Time Pad de una manera segura?

Fin

Si quieren profundizar más en el tema podrían leer en la página 15 del libro Applied Cryptography escrito por Bruce Schneier que explica con un poco más de detalle este algoritmo.

Con este código en javascript podríamos obtenerlo:

var charCodeCero = ("A".charCodeAt(0))-1;
function oneTimePad(mensaje, llave) {
	mensaje = mensaje.toUpperCase();
	llave = llave.toUpperCase();
	var cifrado = "";
        for(var i = 0; i < mensaje.length; i++) {
		cifrado += String.fromCharCode((( mensaje.charCodeAt(i) - charCodeCero +
                                                 llave.charCodeAt(i) - charCodeCero 
                                                 ) % 26) + charCodeCero);
	}
	return cifrado;
}

Desmitificando RSA de 1025 bits

Cuando se habla de RSA, se suele especular o fantasear sobre supuesta tecnología ultrasecreta que pudieran tener las agencias de seguridad de los gobiernos de naciones poderosas como Rusia, China o EEUU. Sobre todo se especula que los módulos de 1024 bits podría ya ser factorizables en tiempos razonables. Por lo que muchos, incluyéndome, se preguntan ¿entonces de cuántos bits debería generar mis llaves si mis temores fueran ciertos?

El NIST, la agencia encargada de definir los estándares tecnológicos para las agencias federales de EEUU, establece que la información con vigencia menor a 2010 debe usar al menos 1024 bits, con vigencia menor a 2030 deberá usar al menos 2048 bits y con vigencia mayor a 2030 deberá usar 3072.

Bruce Scheiner por otro lado en 2002 ratificó una tabla publicada anteriormente por él mismo en donde establece los bits recomendados según seas un individuo, una corporación o el gobierno. Ahí estipula que para 2005 los individuos ya deberían usar llaves de 1280 bits, y el gobierno ya debería estar usando 2048 bits.

Algunos más “inteligentes” que los anteriores, dicen que todos exageran, y recomiendan 1025 bits, razonando superfluamente que eso duplica la complejidad de la factorización. Ese razonamieto surge de pensar que el mejor algoritmo de factorización es por “fuerza bruta” sobre los posibles factores, probando todos los números entre 2^{511} y 2^{512}-1 para factorizar un módulo de 1024 bits, pues sus factores primos son de 512 bits.

La realidad es otra, y desde hace tiempo, desde Fermat de hecho, existen métodos sublineales de factorización de enteros respecto al tamaño del entero y los mismos algoritmos son subexponenciales respecto al número de bits del entero. Por lo que aumentar un bit la llave no es tan drástico como aumentarlo en otros algoritmos como AES, como no es tan drástico multiplicar por dos el tamaño del entero, pues eso no duplicaría el tiempo necesariamente. ¿Pero qué tanto aumenta el tiempo un bit más?

Criba General de Campos Numéricos (GNFS)

GNFS es el mejor algoritmo de factorización de enteros, conocido a la fecha, para enteros de 130 digitos al menos (que son aproximadamente 432 bits). En 2005 el algoritmo se utilizó para romper el récord de factorización RSA para un entero de 640 bits, hazaña que fue llevada acabo por un equipo de investigación alemán. Lo interesante de este algoritmo es su complejidad, y en base a ella voy a realizar algunos cálculos para esclarecer qué tan fuerte es aumentar un bit más a un módulo RSA.

La complejidad del algoritmo está dada por

O\left(\displaystyle e^{\displaystyle \left(c+o(1)\right)ln (n)^{1/3}ln(ln(n))^{2/3} }\right)

donde c es una constante dada por la heurística utilizada en el algoritmo y n es el número a factorizar (no los bits del número). Carl Pomerance, creador del segundo mejor método de factorización, indica que en este caso c = \left( {\frac{64}{9}}\right)^{1/3} . Por otro lado tenemos que o(1) es una función asintótica que tiende a cero, por lo que para los cálculos se va a considerar como cero, pues Pomerance así lo toma.

Teniendo eso, lo que se puede hacer ahora es calcular el tiempo del algoritmo para factorizar un número de 1024 bits y comprarlo respecto al tiempo para factorizar uno de 1025 bits. Por lo que vamos a denotar T_{1024} al tiempo de 1024 bits y T_{1025} al tiempo de 1025 bits.

Sabemos que un número de 1024 bits se aproxima a 2^{1024} y uno de 1025 bits a 2^{1025}, por lo que se van a tomar esas aproximaciones para simplificar la exponenciación. Tenemos entonces que

\displaystyle\dfrac{\displaystyle T_{1025}}{\displaystyle T_{1024}} = \displaystyle\dfrac {k e^{\displaystyle c (ln (2^{1025})^{1/3}ln(ln(2^{1025}))^{2/3}) } } {k e^{\displaystyle c (ln (2^{1024})^{1/3}ln(ln(2^{1024}))^{2/3}) }}

donde k es la constante de la notación asintótica.

Por lo tanto tenemos que

\frac{T_{1025}}{T_{1024}} = 1.0259

Que es muy poco. Pues si el gobierno de algún país contara con los recursos para romper un módulo de 1024 bits en 24 semanas (6 meses), entonces romper uno de 1025 bits les llevaría casi 25 semanas. Esto en el mejor caso, puesto que la complejidad del algoritmo está dada en notación O, así que el algoritmo podría comportarse aún mejor de lo estimado y ser más rápido.

Si hacemos lo mismo y comparamos un módulo de 1024 respecto a uno de 1280, tenemos que \frac{T_{1280}}{T_{1024}} = 447.43. Que es bastante decente, y suponiendo que se pudiera factorizar el módulo de 1024 en una semana, entonces tardarían 8 años y medio en factorizar el de 1280; lo que le da bastante más confiabilidad a ese módulo que a uno de 1025. Aunque un cálculo más correcto sería considerando una ecuación diferencial porque la capacidad de cálculo no va a permanecer 8 años igual, va a ir aumentando.

Pragmáticamente hablando

Seguramente alguno va a desconfiar de este análisis, y necesitará una prueba más terrenal, sin tanta matemática. En ese caso lo invito a bajar un paquete que tenga implementado el algoritmo y factorice un número de unos 450 bits, que se puede hacer en un tiempo bastante decente (unos minutos) y vaya aumentando de bit en bit, para comparar los tiempos. Implementaciones hay varias y se pueden encontrar en la página de la wikipedia sobre GNFS.