Taller: Criptografía asimétrica.

[MasterPunk]

Yo estoy igual que bitboy.. me he ido de puente y no he podido mirar los nuevos post. Tengo para rato. Cuando acabe postearé mis dudas.

[WestOn]

Yo estoy leyendo lo que puso freeze, por lo demás ok.

Saludos

[soplo]

Un hilo muy interesante apokalipto.

Pongamos el caso de que yo deseo establecer una relación segura (tipo ssh) con otra máquina osea que A desea establecer una relación segura con B.

La primera vez que establezco la conexión tengo que encontrar la forma de enviarle una clave de un sistema simétrico. Esa clave no se puede enviar en una transmisión abierta porque podría ser conocida por una tercera parte (man in the middle)  y por tanto podría conocer cualquier cosa al conocer la clave de cifrado.

Así que los pasos a seguir son:

1. Conexión a la máquina B.
2. Envío de mi clave pública.
3. Recepción de su clave pública.
4.  cifro un mensaje en el que está la clave dei algoritmo simético que usaré. La cifro con su clave pública.
5. Cuando B recibe mi mensaje puede descomprimirlo porque ha sido codificado con su clave pública y el tiene su clave privada. Al leer ese mensaje conoce la clave que usará para leer mensajes

Las demás veces ya no necesitaré todo eso pues tanto A como B conocen la clave de abrir mensajes

En todo esto, un posible man in the middle no ha podido obtener ninguna información válida porque no tiene la clave privada de A ni la de B.

Ahora bien estas son mis dudas:

Todo esto para poder enviarle una clave de un protocolo simétrico que es mas seguro y eficiente; sin embargo ya pude enviar un mensaje seguro utilizando un sistema asimétrico así que ¿para qué quiero el simétrico? Osea ¿en que casos merece la pena dar estos pasos para enviar a otra parte una clave de un protocolo simétrico?

Supongo que si yo tuviera que tener una clave distinta para cada posible interlocutor necesitaría muchas claves y eso lo resuelvo mejor con la clave/privada/pública. Sin embargo con el sistema simétrico puedo tener una sola clave para datos particularmente importantes y común a todos los interlocutores. El riesgo de esto es que el conocimiento de esa clave abre el sistema por completo y por tanto hay que tener especial cuidado en donde se almacenan (igual que donde se guarda la clave privada).

Al final de todo esto lo que estoy haciendo es un certificado propio ¿no es así?



Por otra parte en mi modesta opinión quien quiera introducirse en criptografía debe hacerse cargo que el código va en C o en ensamblador y que todo es pura matemática. Por esa razón aquellos que realmente se interesen en estos temas deberían darse un paseo por el foro de C. Por poder se puede implementar en vb o php si se quiere, pero este es el reino de C y de ensamblador.

Para quien no lo sepa eso que dije de "man in the middle" es una técnica hack que se usa para conocer los mensajes que una parte dirije a otra. En la práctica es oir lo que A dice a B y por tanto parece lo mas adecuado para intentar averiguar claves de códigos cifrados.

[APOKLIPTICO]

Un hilo muy interesante apokalipto.

Gracias! Y es "APOKLIPTICO". jeje

Pongamos el caso de que yo deseo establecer una relación segura (tipo ssh) con otra máquina osea que A desea establecer una relación segura con B.

La primera vez que establezco la conexión tengo que encontrar la forma de enviarle una clave de un sistema simétrico. Esa clave no se puede enviar en una transmisión abierta porque podría ser conocida por una tercera parte (man in the middle)  y por tanto podría conocer cualquier cosa al conocer la clave de cifrado.

Así que los pasos a seguir son:

1. Conexión a la máquina B.
2. Envío de mi clave pública.
3. Recepción de su clave pública.
4.  cifro un mensaje en el que está la clave dei algoritmo simético que usaré. La cifro con su clave pública.
5. Cuando B recibe mi mensaje puede descomprimirlo porque ha sido codificado con su clave pública y el tiene su clave privada. Al leer ese mensaje conoce la clave que usará para leer mensajes

Las demás veces ya no necesitaré todo eso pues tanto A como B conocen la clave de abrir mensajes

En todo esto, un posible man in the middle no ha podido obtener ninguna información válida porque no tiene la clave privada de A ni la de B.

1) Se dice "Clave de cifrado" no de "cifrado".
2) De hecho, el algoritmo Diffie-Hellman está específicamente diseñado para intercambio de claves, no es un algoritmo de cifrado per se.
3) Un ataque MITM es posible siempre y cuando este MITM pueda modificar los paquetes que van y vienen. (Crea su propio par de claves pública y privada y reemplaza la pública real).

Ahora bien estas son mis dudas:

Todo esto para poder enviarle una clave de un protocolo simétrico que es mas seguro y eficiente; sin embargo ya pude enviar un mensaje seguro utilizando un sistema asimétrico así que ¿para qué quiero el simétrico? Osea ¿en que casos merece la pena dar estos pasos para enviar a otra parte una clave de un protocolo simétrico?

1) El cifrado simétrico es mucho más rápido, eficiente y seguro con claves más pequeñas que el asimétrico, por ejemplo RSA:
Yo cifro m^e mod n = c
(m = plaintext, e = exponente público, n = módulo y c = ciphertext).
Y descifro c^d mod n = m
(m = plaintext, d = exponente privado, n = módulo y c = ciphertext).
Ahora, la cantidad de ciclos que son necesarios para correr esta rutina:

Código (cpp) [Seleccionar] Expandir

long modpow(long modulus, long base, long exponent)
{
    long Output = 1;
    for(int i = 1; i <= exponent; i++)
    {
        Output = (Output * base)%modulus;
    }
    return Output;
}

Son muchisimos más que por ejemplo, un XOR para el RC4 del plaintext con el keystream.

Es por esto que conviene casi siempre utilizar un cifrado híbrido simétrico-asimétrico.

Supongo que si yo tuviera que tener una clave distinta para cada posible interlocutor necesitaría muchas claves y eso lo resuelvo mejor con la clave/privada/pública. Sin embargo con el sistema simétrico puedo tener una sola clave para datos particularmente importantes y común a todos los interlocutores. El riesgo de esto es que el conocimiento de esa clave abre el sistema por completo y por tanto hay que tener especial cuidado en donde se almacenan (igual que donde se guarda la clave privada).

Al final de todo esto lo que estoy haciendo es un certificado propio ¿no es así?

En realidad, podés utilizar una clave distinta simétrica para cada interlocutor, osea, las claves simétricas son muchísimo más faciles de generar que las asimétricas (son simplemente un número aleatorio, no tiene que pasar tests de primalidad, ni ser generador como en ElGamal, no hay que calcular Phi).

Por otra parte en mi modesta opinión quien quiera introducirse en criptografía debe hacerse cargo que el código va en C o en ensamblador y que todo es pura matemática. Por esa razón aquellos que realmente se interesen en estos temas deberían darse un paseo por el foro de C. Por poder se puede implementar en vb o php si se quiere, pero este es el reino de C y de ensamblador.

Opino lo mismo, aunque raul338 ha probado que compilando los codigos en VB y haciendo buen uso de los tipos de datos, la diferencia de velocidad no es tanta.

[soplo]

Y es "APOKLIPTICO"

Mucho gusto conocerte.

Un ataque MITM es posible siempre y cuando este MITM pueda modificar los paquetes que van y vienen. (Crea su propio par de claves pública y privada y reemplaza la pública real

Efectivamente.

El problema es que si quieres usar criptografía simétrica tendrás que enviar al receptor la clave para que pueda leer lo que le enviarás. Si el envío de esa clave lo haces por medio de criptografía asimétrica aseguras que quien recibe esa clave es quien debe ser y nadie mas. Si no lo haces así no puedes tener la seguridad de que esa clave no haya caído en malas manos. Si de lo que se trata es de seguridad es un factor a tener en cuenta. De hecho tengo que verlo mas profundamente pero ¿no es eso en definitiva lo que hace ssh?

Por cierto para temas de test de primalidad y semillas tengo una lista de los 10.000 primeros números primos si a alguien le interesa que me lo haga saber.

Un saludo

[APOKLIPTICO]

Se puede evitar el ataque MITM con certificados, firmas digitales, cosas que veremos más adelante.

[soplo]

Ya pero es que al final ¿no estas haciendo una forma primaria de certificado?

Porque al utilizar criptografía asimétrica estas creando una relación de confianza entre ambas partes que te lleva a dar una clave que otorga al receptor en un espacio de confianza adicional. Los certificados son mas elaborados, pero en lo básico estamos en eso.

De todas formas creo que te estoy desviando el interesante hilo así que me callo y leo que tengo mucho que aprender je je je

[APOKLIPTICO]

El tema es que los certificados, pueden asegurar quien es el emisor, es la base del PKI (public key infraestructure), son sistemas criptográficos que cuando los veamos, vamos a tener que ampliar a Hashes y criptografía asimétrica, ya que el PKI integra esas tres tecnologías.

[MasterPunk]

Hola. Lo primero que haré será disculparme por haber tardado tanto en leer el segundo tema; no he tenido tiempo hasta ahora.

Hice una prelectura encuanto fue publicado el tema, pero, como me faltaban muchos conocimientos en matemáticas como para comprenderlo, no entendí nada =S

Hoy me puse enserio con el tema y, a base de google, wikipedia, y mucha paciencia he llegado a entender (más o menos) estos algoritmos.

¿Es esto suficiente como para pasar al siguiente tema, o debo sabermelos como la tabla de multiplicar? Es decir, el siguiente capítulo (y sus posteriores) parten de la base de este tema o esto ha sido solo una explicacion para poder comprender lo importante que viene detrás.

(creo que no soy el único que quiere saber esto )

[APOKLIPTICO]

No hace falta que se los sepan, como vos decis "como la tabla de multiplicar", es simplemente para saber de qué estamos hablando y de tener una referencia. No les voy a tomar prueba jajajaj.
Lo que pasa es que uno no puede hablar x ejemplo de PKI, sin entender RSA y diffie-hellman.