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:
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.
Autor
En línea
)
