Autor
|
Tema: k os parece este algoritmo de cifrado (Leído 6,772 veces)
|
xxxSpeedxxx
Desconectado
Mensajes: 1
|
He pensao con un amigo un algoritmo de cifrado sencillo y me gustaría saber si es lo suficientemente seguro, o por lo contrario, si sería facil de petar para comunicaciones entre dos puntos.
Se trata de coger por ejemplo cada byte de cada caracter de una frase que queremos cifrar , y sumarle a cada uno un byte aleatorio. Estos bytes aleatorios serían guardados, y sería nuestra clave igual de larga que la frase. Para descifrar, usariamos la operación inversa, en vez de sumar, restariamos a cada byte cifrado el byte correspodiente de la clave y tendriamos la original. Espero que se haya entendido xD
Entonces si quiero pasar la frase a otra persona en internet, le paso mi frase cifrada, el otro la recibe y la vuelve a cifrar con el mismo sistema pero con otros numeros aleatorios por supuesto. Tenemos ya la frase doblemente cifrada y entonces me la envia a mi.
Yo la cojo y la descifro una vez, aplicando la resta con mi clave que tenia guardada, y se la vuelvo a enviar, y por último el otro coge y descifra con su clave, con lo que le queda la frase original.
A cada frase se generaría una nueva ristra de numeros aleatorios, con lo que no podrían descubrir ningún patrón.
¿Es seguro este sistema? el problema que le veo es a la hora de generar nuemeros aleatorios, que no sean suficientemente aleatorios.
|
|
|
En línea
|
|
|
|
n0more
Desconectado
Mensajes: 43
|
Tu mismo lo has dicho, depende de la longitud del cifrado y de la aleatoriedad de la suma para los bytes.
Con los equipos que hay ahora y con los avances que está habiendo en computación cuantica, una criptografia, digamos, normal (con normal me refiero a la que solemos utilizar), para romper un sistema como el tuyo o como los actuales, la relación entre coste/tiempo no sería muy elevada.
Aún asi, para un chat para hablar con los colegas (por ejemplo xDD), me parece buen sistema (desde mi punto de vista).
Salu2!
|
|
|
En línea
|
|
|
|
APOKLIPTICO
Desconectado
Mensajes: 3.871
Toys in the attic.
|
Hola! Mirá lo que comentas se acerca bastante al método de "One Time Pad" u OTP, es un método en el cual la clave es del mismo tamaño que el plaintext, de esta manera, "Crackearlo" sería muy complejo, infeasible para todos los métodos actuales si la longitud del mensaje superase los 8 caracteres (tardarías aproximadamente 117 días). Estas son las ventajas que veo de tu algoritmo:
- No se envían en ningún momento las claves ni hace falta compartirlas por otros medios, ergo es invulnerable a un ataque de Man In The Middle no interactivo. - Si el string pseudoaleatorio (ya que la aleatoriedad en la computación no existe) es suficientemente aleatorio y tiene una semilla de igual tamaño, es infeasible crackearlo con un método de fuerza bruta.
Estas son las desventajas que veo de tu algoritmo:
- La clave es demasiado larga, aumentando el tiempo de cómputo de manera considerable y el volumen de datos al doble. Por otro lado, el pool de randomness que es necesario para una comunicación de bastante cantidad de datos, es considerable y necesario para mantener una verdadera aleatoriedad. - El algoritmo es vulnerable a un ataque Man In The Middle interactivo, ya que si "A" manda a "B" un mensaje "M" y hace A(M) una persona puede sustituir A(M) con C(M1) y cuando "B" le envía B(C(M1)), "C" puede conseguir la clave de "B". - El algoritmo es vulnerable a un known plaintext attack, si un MITM "C" sabe el mensaje "M", entonces cuando "A" envía A(M) C consigue la clave de A y luego cuando B envía B(A(M)) éste consigue la clave de B.
Aclaro que "A(M)" significa el texto cifrado del plaintext M utilizando la clave de "A".
Por otro lado, lo que vos decis de utilizar un generador pseudoaleatorio para crear una clave y aplicársela a un mensaje, esto ya existe, pero se aplica de la siguiente manera: Se utiliza como semilla de un generador pseudoaleatorio una clave, cuanto más larga la clave, más seguro será el algoritmo, incluso se puede pasar la clave por un algoritmo de "Key streching", esto lo que es en definitiva, es utilizar algún algoritmo de una vía (como un hash) para aumentar el tiempo de precómputo de la semilla del PRNG (Pseudo random number generator), entonces cuando alguien quiera tratar de crackear el cifrado con fuerza bruta, la complejidad será mucho mayor.
Una vez que se obtiene esta "semilla", se utiliza la salida del generador pseudoaleatorio (llamado keystream) para cifrar el mensaje, generalmente utilizando XOR en vez de una suma (o resta) con módulo que es lo que estabas planteando vos. La razón de esto es que el XOR es una sola operación, y la suma con módulo son dos (suma y luego módulo), lo que aumenta el tiempo de cómputo.
Esto resuelve el problema del known plaintext attack, ya que si alguien supiese el plaintext, y lo aplicase a "M" sólo obtendría el keystream de la clave, y no la clave en sí.
Para resolver otro de los problemas, deberías leer la parte de firma digital y third party authentification del taller de criptografía asimétrica desde cero. Utilizando un algoritmo de firma digital, se puede evitar que una persona pueda, mediante un MITM interactivo, sacar la clave o el mensaje.
Es un muy buen approach el que estás tomando y un muy buen comienzo, ya que ideaste un algoritmo que puede, con bastante seguridad, transferir un mensaje. Lee sobre los temas que te plantee arriba (XOR, MITM, known plaintext attack, firma digital, keystream, generador pseudoaleatorio y key stretching) y vas a aumentar de manera considerable la seguridad de tu algoritmo.
Un abrazo APOKLIPTICO.
|
|
|
En línea
|
AMD Phenom II 1075T X6 @ 290 Mhz x 11 (HT 2036 Mhz NB Link 2616 Mhz) 1.23 Vcore ASUS M4A89GTD-PRO/USB3 2x2gb G-Skill RipjawsX DDR3 1600 Mhz CL7 (7-8-7-24-25-1T) Seagate 500 Gb XFX HD4850 512Mb GDDR3. 650 Mhz/995 Mhz 1.1 Tflops.
|
|
|
pajaroplus
Desconectado
Mensajes: 2
|
Si no he entendido mal lo que dice APOKLIPTICO, si se genera una nueva ristra de número aleatorios para cada paquete de datos que se envía, en vez de usar siempre la misma, quedan resueltos los siguientes puntos:
MITM, known plaintext attack, keystream
Luego, se puede utilizar un algortimo potente como Mersenne twister (series de 2 elevado a 19.000 de largo) para generar la secuencia de numeros a usar. Lo importante en este caso sería inicializar el Mersenne twister con los parámetros mas aleatorios posible (¿audio desde el micrófono?).
|
|
|
En línea
|
|
|
|
APOKLIPTICO
Desconectado
Mensajes: 3.871
Toys in the attic.
|
Nono, me parece que no se entendió el concepto.
En un algoritmo de cifrado simétrico actual, se elige una clave, pero dicha clave no es aplicada diréctamente sobre el mensaje a cifrar, sino que se pasa por un PRNG (Pseudo random number generator) o mejor dicho CSPRNG (Cryptographically Secure Pseudo Random Number Generator), para generar un keystream, que luego se aplica en el mensaje, generalmente utilizando un XOR. Esto resuelve el ataque de Known Plaintext.
El ataque MITM puede ser interactivo (El atacante puede modificar los paquetes, aparte de verlos) o no interactivo (sólo puede verlos).
Un ataque MITM interactivo, es efectivo contra cualquier algoritmo de intercambio de claves que no posea una firma digital hecha por un trusted third party, Verisign es una conocida marca de firmas digitales.
Por otro lado, un ataque MITM no interactivo sólo va a ser efectivo cuando no se utiliza un algoritmo de intercambio de claves. Es decir, cuando las claves del cifrado, se envían sin cifrar por un canal inseguro.
Cuando se utiliza un algoritmo de intercambio de claves o algún algoritmo de cifrado asimétrico, se resuelve el problema del MITM no interactivo, pero sólo se puede resolver el problema del MITM interactivo utilizando un trusted third party o dando a conocer públicamente la firma digital para que cada persona que se conecta pueda verificarla antes de establecer la conexión segura.
Los que desean, comiencen a leer el taller de criptografía asimétrica desde cero, ahí está explicado con pelos y señales como funcionan los algoritmos de criptografía asimétrica. Desde la implementación hasta la parte mecánica o matemática del asunto (a un nivel relativamente comprensible).
Un abrazo APOKLIPTICO
|
|
|
En línea
|
AMD Phenom II 1075T X6 @ 290 Mhz x 11 (HT 2036 Mhz NB Link 2616 Mhz) 1.23 Vcore ASUS M4A89GTD-PRO/USB3 2x2gb G-Skill RipjawsX DDR3 1600 Mhz CL7 (7-8-7-24-25-1T) Seagate 500 Gb XFX HD4850 512Mb GDDR3. 650 Mhz/995 Mhz 1.1 Tflops.
|
|
|
pajaroplus
Desconectado
Mensajes: 2
|
Gracias APOKLIPTICO,
Ha quedad muy claro.
Saludos!
|
|
|
En línea
|
|
|
|
|
Mensajes similares |
|
Asunto |
Iniciado por |
Respuestas |
Vistas |
Último mensaje |
|
|
[SOURCE] Algoritmo de cifrado (35 MB/s)
Criptografía
|
El Benjo
|
4
|
4,727
|
2 Septiembre 2013, 09:01 am
por El Benjo
|
|
|
Algoritmo de cifrado
Dudas Generales
|
lash_jaki
|
1
|
2,340
|
9 Agosto 2015, 17:59 pm
por engel lex
|
|
|
¿Qué algoritmo de cifrado es este?
Criptografía
|
Joake6
|
4
|
5,555
|
12 Enero 2016, 00:39 am
por #!drvy
|
|
|
¿Que algoritmo de cifrado puede ser este?
Criptografía
|
in2c0de
|
1
|
3,153
|
14 Febrero 2016, 02:51 am
por WHK
|
|
|
Algoritmo de cifrado Polimórfico
Análisis y Diseño de Malware
|
MCKSys Argentina
|
2
|
5,235
|
20 Diciembre 2016, 23:35 pm
por Borito30
|
|