Mensajes

"Mi nombre es Sam" Película tristísima...



Esta no es facil jejeje, a ver si la adivinan.

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.

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

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.

Bueno, yo tengo algo parecido, pero están pegados a los laterales de los discos. Me bajan 20º la temperatura de los discos.

Justamente, "en una buena torre", la mia no es una buena torre...

Jaja, deberías ver lo que es mi gabinete...
Tengo dos ventiladores de 12 dando directamente a los discos, que sino, estarían rondando los 50º

Aparte de que vas a gastar una pequeña fortuna que podrías usar para renovar tu computadora.

En realidad probablemente el problema de que tu "grabadora" no "grave" es que no es un ente destinado a imponer impuestos, quizas quisiste decir que no "graba".
En cuanto a tu problema, las grabadoras que están viniendo, son muy malas, yo tengo un cementerio de grabadoras que no graban nada.
Tu solución: comprar una nueva y usar el laser de la vieja para hacer un arma laser jeje.

Ojo con el HDsentinel, es un excelente programa, pero hay debilidades que son graves y otras que no. Podrías postear lo que te decía?