Autor
|
Tema: vector contra rijndael (AES) con algunos datos conocidos? (Leído 4,032 veces)
|
AlbertoBSD
Programador y
Moderador Global
Desconectado
Mensajes: 3.705
🏴 Libertad!!!!!
|
Conozco el tipo de datos que se están cifrando, y el método de cifrado, tengo acceso a la salida cifrada.
El dato que se esta cifrando es un numero secuencial de 128 bits.
Esto es primero es 1, luego es 2 y asi... aunque no conoco el estado actual de este numero podria ser 1000, 100000 o 8439948 o cualquier otro numero.
La llave es aleatoria y aun que no conozco cual es esta llave, se o creo que esta misma llave es usada para cifrar el siguiente numero. Comento que creo por que no estoy seguro si internamente el algoritmo la cambie.
El Cifrado es rijndael (AES) a 128 bits en modo ECB.
Tengo acceso a una muestra de 65536 Bloques de 128 bits cifrados y los mismos corresponden a los numeros en secuencia de uno en uno.
Alguna idea de conseguir la llave?
Saludos!
|
|
|
En línea
|
|
|
|
Serapis
|
Es impráctico, necesitarías ejecutar el algoritmo del orden de 2^127 veces para asegurarte que el el texto en claro coincide con el texto cifrado, o lo que es lo mismo, probar todas las claves posibles. Fuerza bruta pura.
Yo no descarto que el algoritmo sea débil frente a su aparente fortaleza... pero yo no lo trataría desde la perspectiva texto en claro, texto cifrado, si no desde la s-Box (que además podría ser cambiada, si hubiere sospechas).
Para mi un sistema que usa XOR en cantidades pares, de alguna forma está retirándole la entropía que le dió la vez anterior. Al ser las rondas de la segunda etapa en número par (tanto para 128bits, como 192 y 256), cae en ese detalle (para mi revelador)...
|
|
|
En línea
|
|
|
|
AlbertoBSD
Programador y
Moderador Global
Desconectado
Mensajes: 3.705
🏴 Libertad!!!!!
|
Gracias por responder, si me imagino que seria infeasible, por eso preguntaba si existia algun vector conocido para abordar este tema. Aunque parece mas feasible que crackear una clave de 64 bytes (512bits) como lo muestro en https://foro.elhacker.net/criptografia/crackear_geli_infeasible-t474506.0.htmlEl algoritmo que describi es la salida de /dev/random en Sistemas FreeBSD con el algoritmo FORTUNA. Internamente cambia la clave para cifrar los datos antes de mandarlos a /dev/random pero los datos que cifra son los numeros secuenciales de 1 en 1 hasta completar los 128 bits. Ademas dicho contador se reinica cada que reinicias el equipo por cual si se me hace un poco debil el algoritmo.
|
|
|
En línea
|
|
|
|
Serapis
|
Hasta donde yo sé, si sé que ha habido buenos intentos y algunos otros que son ismples comentarios sin demasiados detalles, por los que por cautela conviene obviar.
El algoritmo, al menos en apariencia es fuerte. Toma cada 16 bytes (128 bits), los connsidera en una cuadrícula de 4x4, y a partir de ahí, realiza varias operaciones en 3 fases, la fase intermedia es un bucle. Modifica los bits, modifica las filas y modifica las columnas por lo que resite análisis de frecuencias (lineales y no lineales) para intentar revertir (vamos que básicamente las operaciones son irreversibles). También se ha tomado precauciones para evitar operaciones del tipo n(x) = n ó -n (para cualquier x, jamás será igual a n).
Sin embargo, no hace intercambio de bloques, esto es, los bytes 0-15 del texto en claro, siguen siendo los bytes 0-15 del cifrado, por lo que hay esperanzas de algún hallazgo. Por eso te decía que yo lo intentaría estudiando a fondo las s-Box. Haciendo una implementación del algoritmo y probar a fondo como queda todo alterado tras 1,2,3...x rondas si la s-Box, le otorgo valores secuenciales, el mismo valor para toda, etc... y ver si tras ello queda algún rasgo rastreable (probando por ejemplo un texto en claro sencillo como 'xxxxxxxxxxxxxxxx' y una clave como 'aaaaaaaaaaaaaaaa'...
Otro punto flaco para mi, es que el tamaño de los datos a la entrada no se ve alterado a la salida. Lo que siempre otorga capacidad para intentarlo...
Aunque está muy bien diseñado podría salta rla sorpresa de que sea fácilmente rompible. Un problema de los algoritmos es que cualquier estudio en profundidad, jamás abaracará lo absoluto por lo que la certeza absoluta, no puede tenerse y el algoritmo más complejo podría tener una fácil solución para romperlo.
Tira por las s-Box, o analiza a fondo las 4 operaciones en que se basa, pero descarta la fuerza bruta, contra eso si que está probado...
Por supuesto otra cosa es que un proveedor de claves, ande chapuceando con dar claves que son un incremento unitario de la previa. Ahí estás pillando la clave, por negligencia del proveedor de claves (vamos que es lo mismo que si eligen 0123456...). Personalmente veo más que interesante que incluso el mismo texto en claro con la misma clave, generen cada vez un cifrado distinto y de distinto tamaño.
|
|
|
En línea
|
|
|
|
|
Mensajes similares |
|
Asunto |
Iniciado por |
Respuestas |
Vistas |
Último mensaje |
|
|
Eliminar datos de un vector
Programación C/C++
|
gatusko
|
1
|
13,007
|
16 Septiembre 2010, 12:25 pm
por satu
|
|
|
[C] Mostrando datos de un vector de enteros
Programación C/C++
|
Rockmore
|
0
|
3,084
|
5 Diciembre 2010, 20:44 pm
por Rockmore
|
|
|
Mozilla tomará medidas contra algunos add-ons
Noticias
|
wolfbcn
|
0
|
1,632
|
3 Abril 2011, 21:58 pm
por wolfbcn
|
|
|
Eliminar datos de un VECTOR en C++
Programación C/C++
|
deibenK
|
3
|
2,496
|
10 Marzo 2014, 05:06 am
por leosansan
|
|
|
Encriptador de C++ Rijndael ayuda
Programación C/C++
|
Kaxperday
|
5
|
4,286
|
24 Agosto 2015, 01:04 am
por Kaxperday
|
|