Vosotros mandais, yo aquí ni pincho ni corto, era una sugerencia solo.
Probablemente en ese foro estaríamos muy pocos, pero para qué quieres a más? Todos los lammers que no tienen ni idea y que su único interes por la criptografía se reduce a descifrar un zip de fotos porno me sobran.

Mi idea era la de publicar artículos y abrir líneas de opiniones sólo de calidad. Hacer del foro un punto de referencia en la red para esta temática. Siempre puedo postear en seguridad, pero se van a quedar desperdigados, y al final se pierden.

Y cuando veamos a alguien que postea semejante gilipollez como lo del cifrado a 80 bits para que la NSA lo rompa (que viniendo la noticia de donde viene ya me imagino el nivel general que hay sobre la materia), no le podremos decir, vete a criptografía y lee, que hay mucha calidad

Bueno, esto es fácil, si a algún usuario del foro le interesa que lo pida también, que no me voy a mojar yo solo

Salu2.

Buenas,
Me gustaría empezar un hilo explicativo sobre el protocolo SSL y a la vez dejar varios puntos en el aire para que podamos participar todos.
Esto lo pongo aquí. Si finalmente se abre temática de Criptografía, lo moveis allí, y sino pues a donde corresponda.

Empezaré haciendo un resumen sin entrar mucho en detalles del protocolo SSL (Secure Socket Layer) para la gente que quiera participar y no lo tenga del todo claro.

SSL.

Secure Socket Layer es un sistema de protocolos de caracter general diseñado por Nestcape Communcations, con el propósito de conseguir un canal seguro de comunicación a través de Internet. Está basado en la aplicación conjunta de Criptografía Simétrica (por su rapidez, para el cifrado de datos), Criptografía Asimétrica (de llave pública, para el intercambio de la clave simétrica), certificados digitales y firmas digitales.

La identidad del servidor web seguro (y a veces también del usuario cliente) se consigue mediante el Certificado Digital correspondiente, comprobando su validez, y de la integridad de los datos intercambiados se encarga la Firma Digital mediante funciones hash y su comprobación.

Estableciendo la comunicación.
Lo primero es que el cliente y el servidor realicen un proceso de reconocimiento mutuo y de petición de conexión, conocido como Handshake.
El protocolo comienza con el saludo del cliente al servidor, Client Hello, por el que se informa al servidor de que se deséa establecer una comunicación segura con él.
Junto con este saludo inicial, el cliente envía al servidor información de la versión de SSL que tiene implementada, de los algoritmos de cifrado que soporta, las longitudes de clave máximas que admite para cada uno de ellos y las funciones hash que puede utilizar. También se le solicita al servidor el envío de su Certificado Digital X.509, con objeto de verificar el cliente la identidad del mismo y recoger su clave pública. En este momento se asigna un identificador a la sesión y se hace constar la hora y fecha de la misma.
A continuación, el servidor SSL responde al cliente, Server Hello, enviándole su Certificado Digital (con su llave pública) e informándole de su versión de SSL, de los algoritmos y longitudes de clave que soporta. Generalmente se obtiene el conjunto de algoritmos, longitudes de clave y funciones hash soportados por ambos, eligiéndose entonces los más fuertes. Si no hay acuerdo con los algoritmos a usar se envía un mensaje de error.
Como medida adicional de seguridad, el cliente genera una clave aleatoria temporal y se la envía al servidor, que debe devolvérsela cifrada con su clave privada. El cliente la descifra con la llave pública y comprueba la coincidencia, con lo que está totalmente seguro de que el servidor es quién dice ser.
Si todo está correcto el cliente genera un número aleatorio que va a servir para calcular una clave de sesión correspondiente al algoritmo de cifrado simétrico negociado antes, conocida con el nombre de clave maestra, que es enviada al servidor de forma segura cifrándola asimétricamente con la llave pública de su Certificado Digital. Esta clave maestra se usará para generar todas las claves y números secretos utilizados en SSL. Con esto servidor y cliente se han identificado y tienen en su poder todos los componentes necesarios para empezar a transmitir información cifrada simétricamente.
Así y todo, para que empiecen las transmisiones de datos protegidos se requiere otra verificación previa, denominada Finished, consistente en que cliente y servidor se envían uno al otro una copia de todas las transacciones llevadas a cabo hasta el momento, cifrándola con la llave simétrica común. Al recibir esta copia, cada host la descifra y la compara con el registro propio de las transacciones. Si las transacciones de los dos host coinciden significa que los datos enviados y recibidos durante todo el proceso no han sido modificados por un tercero. Se termina entonces la fase Handshake.

Luego vienen otras operaciones como determinar el modo de encapsulamiento de los datos en las que no me voy a meter, y ya por fín se establece la comunicación.

Ataque a SSL.
Como vemos, toda la información que capturemos está cifrada. Si todo está en orden y usamos algoritmos de cifrado simétrico sin errores de implementación, lo único que nos queda es la fuerza bruta (no consideraremos inyecciones SQL, ni robos de cookies, etc, porque no sería un ataque contra SSL).

Aquí es dónde empezaremos la disertación e intentaremos concretar mitos y realidades.

Pero primero apunto dos consideraciones a tener en cuenta.
1.- Cifrar al doble de 64 bits no es cifrar a 128, es cifrar a 65.
2^64 * 2^1 = 2^(64+1) = 2^65.
Por esta razón, si miramos en www.distributed.net, comprenderemos porque para romper un RC5 de 56 bits tardaron 250 días y para la de 64 casi tres años. Con la de 72 lleván ya un par y lo que les queda.

1.- Tiempo de ruptura de cifrado a 128 bits.
Vamos a poner todo a favor del atacante al cifrado haciéndo suposiciones inverosímiles, para simplificar cáculos.
* Supongamos que tenemos un Earth Simulator/5120 Nec con una potencia teórica (nunca a llegado a tanto) de 40960 billones de operaciones por segundo.
* Supongamos que en cada operación es capaz de áplicar un número al algoritmo de cifrado y ver si es el bueno (serían cientos de operaciones).
Cifrando solo a 128 bits, que es el cifrado máximo de SSL existen:
2^128 = 340.282.366.920.938.592.532.472.206.020.233.786.982 claves posibles.

 340.282.366.920.938.592.532.472.206.020.233.786.982 / 40.960.000.000.000.000 =    8.307.674.973.655.724.205.649 Segundos.
 8.307.674.973.655.724.205.649 /60 = 138.461.249.560.928.736.761 Minutos
 138.461.249.560.928.736.761 / 60 = 2.307.687.492.682.145.612 Horas
 2.307.687.492.682.145.612 / 24 = 96.153.645.528.422.734 Días
 96.153.645.528.422.734 / 365 = 263.434.645.283.350 Años.

Ahora que ya sabemos un poco de la teoría, me gustaría abrir un debate sobre los cientos de noticias que podemos leer en cualquier sitio, del estilo, por ejemplo, esta: http://www.galeon.com/maty/nautopia_old/nautopiaX.htm

"Hablando de cifrado, recordemos la debilidad intrínseca del sistema implementado por MICROSOFT en sus productos (IE sin ir más lejos).
En su día aumentaron de 56 -cifrado débil- a 128 bits ¿cifrado fuerte?. Pues no, ya que realmente utiliza 80 y pocos bits. Y con los restantes, la NSA y otras agencias norteamericanas pueden romperlo fácilmente."

Pregunta:
Antes de leer este post, daríais como buena esta afirmación?
Y después de leerlo?
No digo que no sea cierto, vete a saber las diabluras que pueden hacer estos americanos, y el potencial tanto en recursos como en conocimiento que tienen, pero a mí así sin pensarlo mucho se me ocurre que:
Esos "y pocos" cuántos son? como hemos visto cada bit adicional de esos "y pocos" está duplicándo el tiempo de ruptura del cifrado.
Con 80 y pocos bits de cifrado, qué quieren decir cuando dicen "facilmente".?
La información que se supone que se guarda en los bits restantes hasta el 128, cual es? como acceden a ella estando solo en el cliente y en el servidor (el intercambio se realiza con el cifrado asimétrico)?

Si os he hecho dudar, algo hemos avanzado. De cualquier forma, espero que alguien exponga su opinión y posibles formas de hacer lo que en la noticia dicen.

Salu2.

Así a bote pronto, sin haberlo probado y basandome en la teoría, yo haría una copia del directorio mysql dentro de data llamándole como quieras. Luego copias/sobreescribes dentro de él los ficheros user.* que tienes y accedes a la tabla user de la nueva bbdd que has creado desde phpmyadmin.

Ahí tendras los usuarios de la bbdd de la que "conseguiste" esos archivos.

La password no la tendrás, tendrás su hash. No estoy seguro pero creo que en las versiones anteriores a la 4.0 inclusive es un hash md5, y las posteriores un sha1.
Si tienes 16 bytes, es (no te lo aseguro) unmd5, y si tienes 20, un SHA1.
Luego pues a crackear.

Ya te digo, hablo sin haberlo probado antes.
Creáte un usuario con una pass corta y pásale crackeadores a ver si rula, cuando lo tengas claro, ya se los metes a los otros users.

Ya nos contarás.

Salu2.

Te da igual el calcular un nuevo hash, porque luego deberías firmarlo, y no tienes la clave privada.
El proceso lógico que debería hacer esa protección es el siguiente.
El programa (o quien sea) calcula un hash de parte del código o de la licencia, luego descifra con la pública el hash que tiene almacenado de su código original (la firma) y los compara. Si no coincide es que algo a cambiado.
Ahí es donde tienes que atacar, y saltarte la condición que compare los hashes.

Si esto es una movida porque lo compara el SO directamente o algo así, tb puedes generarte una pareja privada/publica, realizar las modificaciones, calcular luego el hash (según los bytes y las cabeceras sabes que algoritmo usa), cifrarlo con tu privada, guardarlo encima del anterior y cambiar la pública del componente, que ya la conoces.

En cualquier caso, si lo consigues, coméntamelo, porque no debe de ser nada fácil.

Estimados todos,

Creo, y estoy convencido, de que el futuro (ya presente) de la seguridad tele/informática va a venir si no lo es ya de la criptografía.

Es un campo muy interesante, cifrados simétricos, asimétricos, mixtos, estandar x.509, firma electrónica, certificados, vulnerabilidades en cifrados wifi, blutooth, tiempos de ruptura, algoritmos, etc.

Aplicando esta tecnología correctamente (y no limitándose solo a la transferencia, como se hace hasta ahora, podeis ver un ejemplo práctico en http://www.seguridad0.com/index.php?b3ef09e4789cddce67cb4627adf90c54&tim=27-11-2004&ID=1003), se puede alcanzar un nivel de seguridad del 100% (dependiendo exclusivamente el porcentaje del grado de imbecilidad del usuario).

Me gustaría proponer un apartado específico para esta temática, que en serio, da mucho más juego del que imaginais, y va a ser imprescindible para toda la gente aficionada y profesional de la seguridad (incluso en leyes, adaptación ley SOX, LOPD, etc).

Mi tiempo es limitado, supongo que como el de todos, pero si el impedimento va a ser falta de moderadores en esta temática, estoy dispuesto a presentarle mis credenciales a quien corresponda, y que evalue si mi preparación es la suficiente. Si lo es me comprometo a alimentar el foro con contenidos de alto nivel y a responder a todas las dudas en las que esté capacitado (siempre dentro de mis posibilidades, no soy Dios ).

Bueno, yo lanzo el guante con toda mi buena fé, y quedo a vuestra disposición.

Gracias y un saludo a todos.