PreData: Se lee mejor el ejemplo visto en formato NotePad (courierNew) ya que queda todo alineado como en una tabla pero bueno... Dadle a leer la versión completa del post para leer todo.
Buenas! Soy nuevo en el foro; me pareció interesante ingresar aquí, xq de aquí recogí bastantes ideas. Estoy desarrollando un programa con la intención de que sea algo muy muy gordo :D
Mi programa está escrito en ANSI C; con la idea de que sea multiplataforma. Y a parte porque es el lenguage que mejor controlo. De momento he aprendido a cifrar archivos bajo una clave de entre 6'5 y 1666 BITs (longitud de 1 a 256 caracteres de entre un alfabeto de 91).
Actualmente cifra así: (esto es solo una analogía)
Alfabeto 0: abcdefghijklmnñopqrstuvwxyz_
CLAVE ----> hola
Alfabeto 1_: hijklmnñopqrstuvwxyz_abcdefg
Alfabeto 2_: opqrstuvwxyz_abcdefghijklmnñ
Alfabeto 3_: lmnñopqrstuvwxyz_abcdefghijk
Alfabeto 4_: abcdefghijklmnñopqrstuvwxyz_
MENSAJE CLARO: mi nick es strapping
CLAVE--------: holaholaholaholahola
ALFABETO-----: 12341234123412341234
MENSJ CIFRADO: swknoqu lgks flpwwvg
Está clara la técnica verdad? Pues la idea es aplicar el concepto en vez de para alfabeto de "a" a "_", haciendolo en valores de byte, de 0 a 256.
Mi programa simplemente hace una sustitución polialfabetica en función de la clave... pero tiene el gran fallo en archivos que no contengan textos; ya que, según he podido observar gracias a un programita que he creado para leer los primeros 100 bytes de cada archivo en valores de byte; me fijado, que son permanentes; es decir; que todos los archivos .DOC de determinada versión empiezan igual; y a parte muchos ejecutables, tienen largas cadenas de byte 0, donde se puede ver a primera vista la clave. Ya que para una secuencia "00000000000" se puede leer en la misma posición en el cifrado "aholaholahol"... lo cual tira por el suelo todo el sistema...
Por otra parte se me ocurrió aplicar la tecnica de difusión; también de manera dinámica (dependiente de la llave); para así al cambiar de sitio todo, todo vaya cambiando... y tras investigar y leer mucho; he leido algo sobre S-Box...
De momento mi programa trabaja con bloques de 65535 bytes; y en mi ordenador lo he conseguido depurar alcanzando los 34 MB/s para cifrar y descifrar archivos...
Me podríais ayudar? Alguna idea para el asunto de andar aplicando la técnida de difusión (alteración del orden de la secuencia del bloque).
Visitaré frecuentemente el Foro; pero de todas formas si alguien quiere ponerse en contacto directo conmigo aquí tenéis mi e-mail: strapping_83@hotmail.com
UN FUERTE ABRAZO! GRACIAS A TODOS!
Partes De Un CriptoSistema
Strapping12 Agosto 2005 - 12:28pm
Yo creo que se podría apuntar más gente a aportar ideas en la elaboración de un competidor del AES :)
Ya que un criptosistema tiene varios módulos, se podrían aportar ideas posibles con buenas explicaciones, algoritmos, para modulos determinados.
Los módulos que yo identifico básicamente son 2:
A) Expansor / Transformador de la Clave introducida por el usuario.
B) Algoritmo de Cifrado / Descifrado
y tal vez tb: Algoritmo de Compresión/Descompresión ultrarrápido que evite secuencias seguidas de igual valor de byte...
A parte el exo de definir buenos atakes para irlo mejorando tb, es una buena colaboración, es decir, avisar de posibles atakes.
Gracias A Todos :)
Tal como yo lo identifico,
DamyMr13 Agosto 2005 - 11:54am
Tal como yo lo identifico, las partes de un criptosistema son:
Estructura: indica el recorrido que seguirán los bits dentro del algoritmo. Frecuentemente se utiliza una red de Feistel.
Funciones: las funciones que se encargan de crear la confusión y la difusión a partir fragmentos de los datos y las claves.
Clave: se divide en varias partes como
Esto es sólo como yo lo enfoco; el compresor no me parece una parte del sistema criptográfico sino un paso previo que puede ser aplicado sólo si el usuario decide aplcarlo a los datos. En un sistema criptográfico bueno, las secuencias de bits idénticos no deberian representar un problema y esgrimir esta razon como excusa lo único que consigue es aumentar los requerimientos del sistema en cuanto a memoria y reducir la velocidad, amén del costo extra de portar el sistema a otras plataformas.
Análisis de la idea de RavenHeart
Strapping9 Agosto 2005 - 11:29am
Hola compañero, he exo una pekeña reproducción a escala en papel y lapiz, analizando la aplicación de tu codigo a un bloque de datos, independientemente de los demás bloques.
RESULTADOS:
Estos son los resultados; dadas dos bloques de secuencias exactamente iguales excepto en N elementos, obtenemos de N a 2N diferencias entre los bloques codificados, por cada vez que aplicamos la sustitución a la RavenHeart.
Conclusiones:
Si hacemos
- Sustitución de alante a atrás tipo RH
- Sustitución de atrás a alante tipo RH
- Reordenación
- Sustitución de alante a atrás tipo RH
- Sustitución de atrás a alante tipo RH
Pues para 1 elemento diferente en original, obtenemos hasta 8 elementos diferentes en los respectivos codificados.
Dado que el tamaño máximo de mis bloques son 65500 elementos requeriría 36250 ; esto haría necesarias 16 vueltas al algoritmo para una eficiencia optima.
2^(16-1) = 32768 elementos diferentes = 50'0008 % de elementos distintos. Esto me dijo DamyMr que era lo ideal. Un 50%.
A la vez, esto es para 1 único elemento diferente entre dos bloques sin cifrar; imaginaos que los elementos diferentes son 2; esto podria producir unas diferencias del hasta del 100% del bloque. Me pregunto si esto es algo positivo...
PROS de la Sustitución RetroAlimentada a la RavenHeart:
1 diferencia = 50% del bloque diferente
2 diferencias o más = 100% del bloque diferente
con una vuelta más lograriamos que con 1 sola diferencia, ya tubieramos el 100% del bloque diferente.
CONTRAS de la Sustitución RetroAlimentada a la RavenHeart:
Requiere una aplicación mínima de vueltas dado un tamaño de bloque definido siguiendo la regla: Numero de Vueltas = [ logaritmo de "tamaño del bloque" en base 2 ] - 1
Por tanto para un bloque de 64 KB, requerimos de 15 vueltas. Y está claro que a mayor cantidad de vueltas, menor cantidad de bytes codificados por segundo dentro de una misma máquina.
PD: Bueno Raven, como ves, no te he robado la idea, te he mencionado en cada línea, jejejeje, espero no haber rozado la pesadez; simplemente quería matizar que era tu proposición, aunque yo la haya adaptado y desarrollado a mis necesidades.
PPD: ¿Que te parece ahora el resultado de esta técnica DamyMr?.
A=Sustitución RH, B=Sustitución RH', C=Permutación:
Algoritmo "Strapping + DM + RH" = [(ABCAB)x15vueltas]
No kero calcular ahora los costes en ram, pues siempre hay maneras de economizar; y los resultados a primera voz respecto a un estudio, pueden variar mucho. Eso si, este algoritmo claramente será más lento que una "ACB", pues supone 25 veces más de operaciones... yo quería más velocidad... aunque puede que este algoritmo resulte aún así rápido al trabajar sobre RAM...
Perdido!!
DamyMr9 Agosto 2005 - 3:44pm
Sinceramente, me he perdido cuando hablas de la sustitucion de Ravenheart, tengo la cabeza demasiado saturada y leyendo sus post pues como que no lo veo... te refieres a lo de la sustitucion polialfabética utilizando (clave+textoplano)??? Sin entender esto no lo puedo analizar.
De todas formas hay un error en tu razonamiento, es una cosa que aprendí hace muxo por mi mismo y a la que siempre le saco provecho: Si haciendo una modificación obtienes un 50% de diferencias (estadísticamente, es decir, según una normal) haciendo dos modificaciones obtendras un 50% de diferencias que a su vez es un 50% diferente de sólo una modificación (hablando estadísticamente, te lo recuerdo, ya que debe de haber modificaciones grandes que den lugar a diferencias pequeñas pero que serán las menos). Realmente nunca me he parado a demostrar esta afirmación pero puedes estar seguro de ella.
Imagina una pintura que cuando das dos veces en el mismo sitio simplemente desaparece (es imaginativo pero un XOR por ejemplo trabaja así). Si pintas un 50% al azar de una pared, habrá unas diferencias del 50% respecto al estado original. Si pintas de nuevo un 50% al azar, habrá unas diferencias de un 50% a como estaba hace un momento, pero tb de un 50% de como estaba originalmente. Es como que el azar tiende al caos, a no poder diferenciar, al 50% de las diferencias.
No se si este pensamiento es más filosófico que matemático, o es un poco de basura mental, pero a mi me funciona.
PD: Puesto que estais ambos interesados en el proyecto cifrador, os propongo crear un nuevo algoritmo, que sea muy resistente, desde el principio para no ir tapando baches. Con unas características similares a los profesionales y donde cada decisión sea discutida desde un principio para conseguir lo mejor posible. Lo propongo a ambos pero también a todo aquel que quiera sumergirse en un debate constructivo para aportar todos nuestras mejores ideas.
A DamyMr y RavenHeart
Strapping8 Agosto 2005 - 6:48pm
Hola compis; pues no esque me molestase que me agregáseis a vuestros messengers, sino que me gustaría, para así poder intercambiar ideas y razonamientos con mayor agilidad :)
CHAT: strapping_83 @ hotmail.com
MAIL: strapping @ gmail.com
Nos Vemos En La Red
GRACIAS POR EL ATAKE DAMYMR; realmente por eso no me dedicado de lleno a implementar el algoritmo directamente; sino a primero comerme el coco con papel y lapiz, de como pulirlo... imaginate la de horas "perdidas" que habría tenido si habria implementado el algoritmo... por eso lo implementaré solo cuando haya probabilidades de que sea realmente duro...
GRACIAS POR LAS IDEAS RAVENHEART, serán muy tenidas en cuenta a la hora de anular ataques diferenciales como el explicado por DamyMr :)
Gracias a todos :)
Romper un criptosistema
DamyMr8 Agosto 2005 - 3:53pm
Te voy a detallar un ataque que sería factible de efectuar en tu algoritmo, tiene algo que ver con criptoanálisis diferencial salvo que es más sencillo de efectuar. Utilizaré una version más reducida del algoritmo.
Alfabeto: a b c d e f g h
Clave: becada
Primera y segunda sustitucion:
a b c d e f g h -- alfabeto
----------------
b | b c d e f g h a
e | e f g h a b c d
c | c d e f g h a b
a | a b c d e f g h
d | d e f g h a b c
a | a b c d e f g h
|
--- clave
La trasposición como el método que proponias tenia algún que otro defecto, me la invento de forma aleatoria:
5 8 1 4 3 7 6 2 : el caracter 5 pasa a ser el 1, el caracter 2 pasa a ser el 8, ...
Cifraremos varios mensajes: (vaya no he metido el espacio, pero weno, el ataque es igual solo que no puedo usar mensajes con sentido)
abacgehh -- chdcfafb
cfagbcha -- fafgfadf
acbhbdhc -- fcdhgaec
(Son mensajes en claro y su correspondiente cifrado, hecho a mano)
Veamos cómo podemos debilitar el sistema si conocemos parejas de mensajes como los mostrados. Nos centraremos en obtener la permutación:
Miremos el primer y segundo mensaje: coinciden dos caracteres (lo he hecho a posta para que sea más complicado, estadísticamente debería coincidir un caracter de cada 8)
abacgehh -- chdcfafb
| | ||
cfagbcha -- fafgfadf
Un caracter fijo en un lugar fijo, irá a parar al mismo lugar con la misma codificación. Hay dos clases de permutaciones para el mensaje anterior: xxxx37xx y xxxx73xx
Ahora con la segunda y la tercera palabra:
cfagbcha -- fafgfadf
| | | |
fcbhbdhc -- fcahgaec
Corresponde a las permutaciones: 5xxxx7xx y 7xxxx5xx, para corresponder con lo anterior, la permutacion es
5xxx37xx.
Con el primer y tercer mensaje:
abacgehh -- chdcfafb
| | | |
acbhbdhc -- fcdhgaec
Corresponde a las permutaciones xx1xx7xx y xx7xx1xx, y para tenga sentido con lo anterior, debe ser 5x1x37xx.
Con más mensajes se puede sacar mucha más información, y se pueden hacer estimaciones si se producen más coincidencias en el mensaje cifrado que en el original (no se si se producirian). En tu forma con alfabetos de 256 caracteres, en permutaciones de 65536 elementos, habría estadísticamente 256 coincidencias, considerando archivos al azar (que puesto que irian comprimidos, se pueden considerar). Entre dos mensajes diferentes habrá 256/256 = 1 coincidencia. Aplicando teoría de grafos, si tienes n parejas de textos fuente y sus correspondientes cifrados, habrá:
n (n-1)
------------- Concidencias entre todas las parejas de mensajes
2
Para deducir la permutación completa harían falta como mínimo 363 bloques (paradoja del cumpleaños) pero no muchos más. Y eso es considerando todas las permutaciones posibles, si nos limitamos a un subconjunto de ellas como has llegao a proponer, se pueden obtener ecuaciones para deshechar muchas permutaciones conocidos unos datos fijos. Queda patente la facilidad para romper la SSB.
Continuando con el ejemplo, supongamos que ya tenemos la suficiente información y hemos roto la SSB, obteniendo su valor: 58143762. El cifrado polialfabético que propones, tiene estructura de grupo, una característica poco deseable de esto es que por cada caracter cifrado, puedo volver a cifrarlo con otra clave para obtener el original. Otra de las características poco deseables, y de la que haré uso, es que cifrar una vez con una clave, y cifrar otra vez con otra clave (dos sustituciones polialfabéticas) es como cifrar una sola vez con una tercera clave.
De uno solo de los bloques cifrados puedo obtener una clave equivalente de 8 caracteres de longitud:
abacgehh -- chdcfafb // que deshaciendo la permutación queda así:
abacgehh -- dbfccfah // (1) a lo manda a d, (2)b lo manda a b, ...
Construyo la siguiente tabla:
a b c d e f g h -- alfabeto
----------------
1 | d e f g h a b c
2 | a b c d e f g h
3 | f g h a b c d e
4 | a b c d e f g h
5 | e f g h a b c d
6 | b c d e f g h a
7 | b c d e f g h a
8 | a b c d e f g h
|
---Clave para la sustitucion polialfabética única
Con esta clave, ya no hace falta conocer la clave original, comprobemos cómo ya se puede descifrar cualquier mensaje:
cfagbcha -- fafgfadf (original y cifrado)
De todos modos, aun podemos hallarla resolviendo el sistema de ecuaciones siguiente, considerando que cada letra es un número, y sustituir es sumar o restar una cantidad: (a=0, b=1, c=2, d=3, e=4, f=5, g=6, h=7)
clave: m n o p q r s t, Trabajamos módulo 8
m + q = 3
n + t = 0
o + m = 5
p + p = 0
q + o = 4
r + s = 1
r + s = 1
t + n = 0
Donde hay ecuaciones que sobran, esto indica que hay más información de más, información repetida. Nos
deshacemos de las dos últimas ecuaciones, la clave mínima debe ser de 6 caracteres:
m + q = 3
n + t = 0
o + m = 5
p + p = 0
q + o = 4
r + s = 1
8 variables para un sistema de 6 ecuaciones, es un sistema indeterminado, y tenemos mucha libertad para buscar la clave, conociendo el sistema para generar la SSB a partir de la clave, ya podemos obtener la clave utilizada, aunque repito que no es importante porque podemos descifrar los mensajes sin conocerla.
Así pues el sistema que propones es roto con facilidad cuando poseemos la suficiente cantidad de mensajes, aproximadamente la raiz cuadrada de la longitud de la SSB. Aumentar dicha longitud no sería eficiente.
Si dieras más vueltas, después de ver esta demostración, concluirás que viene a ser lo mismo, equivale a una permutación y a una sustitución, con lo cual te recomiendo que hagas modificaciones en tu algoritmo.
Lamento darte estas malas noticias, pero es mejor descubrir los fallos ahora que después de tener mucho más avanzado el proyecto.
Estoy disponible para cualquier duda que tengas.
Nuevas Ideas Para El Proyecto Cifrador
Strapping7 Agosto 2005 - 2:28pm
1.180 lecturas ya! La verdad esque me alegra ver que hay seguidores interesados en el desarrollo de este algoritmo.
Novedad 1:
Veamos, he diseñado ya el algoritmo expansor de clave; el cual es valido para todo tipo de claves; con el consigo secuencias de 1024 bytes, de valores de 0 a 255, siendo la entrada una secuencia de 1 a 256 elementos, de valor byte cualquier valor... lo cual anula el limite de 91 elementos, expandiendolo a los 256 que usan las máquinas :).
Con esta clave de 1.024 elementos, diseño la SSB, la cual ya tiene una gran variabilidad: 1666 BITs para claves humanas (1 a 256 caracteres) y 8192 BITs por cada KB de un ficheroclave lo que convierte en una llave de 1 MegaBIT un tipico fichero foto de 123 Kilobytes.
Novedad 2:
El Concepto de RETROALIMENTACION dentro del algoritmo, me supone bastante caro en tiempo, ya que tendria que diseñar una nueva SSB tras codificar cada bloque, con la cantidad de operaciones que ello supone. A parte, esta idea incrementaría la cantidad de RAM reservada al programa, pasando de unos 150 KB a puede que algo más de 256 KB. Y no se si esto limitaría su portabilidad a dispositivos poco potentes... limitando el algoritmo a su funcionamiento en computadoras.
El algoritmo tal como está diseñado ahora mismo, consigue mantener una agilidad grande, 1 cuarto de millón de operaciones para 64 KB, consiguiendo grandes velocidades cercanas al copiado de fichero, en ordenadores nuevos (2.5 GHz).
La idea de agregar retroalimentación aumentaría el tiempo de cifrado, y además debería de consumir más RAM... por otra parte, estoy seguro de que una retroalimentación aumentaría enormemente la variabilidad del conjunto; ya que se conseguiría que con un solo byte diferente entre dos ficheros, el segmento fuese completamente diferente, al alterarse totalmente la SSB y las sustituciones. Y esto creo que es lo que me dijo DamyMr que sería bueno para dar seguridad al algoritmo, conocidos el ORIGINAL y CIFRADO de dos ficheros con 1 solo byte diferente. ¿Estoy en lo cierto?.
ESPERO RESPUESTAS!! ANIMAOS!!
PD: Muchas Gracias Por Vuestras Aportaciones! DamyMr, Ravenheart, InMemoriam, Envite y nk2701. ¡A ver si se anima más gente a aportar algo nuevo! :) Es posible que en un futuro, el mundo pueda contar con algoritmos de cifrado totalmente seguros gracias a nuestras aportaciones jejejeje.
¿Como averiguo colisiones?
Strapping3 Agosto 2005 - 4:07am
Veamos, creo que por las reglas por las que me rijo, las colisiones son cero, siempre y cuando permutaciones posibles de SSB sea un numero mayor a las claves aplicables en el mismo.
Ya que si permutaciones < claves, para determinadas parejas de claves se usaría casualmente la misma SSB, y entonces se crearía una colisión respecto a la SSB, pero aún así, al aplicarse una doble sustitución diferente totalmente, seguiría siendo bastante dificil poder analizarlo.
Es importante este punto pa mi, ya que al trabajar en bloques de tamaño variable, supongamos un archivo de 65635 bytes => los ultimos 100 KB serían tratados bajo una matriz de: 10 x 10, que obviamente tendría 100! = 9'3 e157 que es mucho menos que 3'2 e501. En este caso particular, se usaria la misma SSB en muchos casos de clave diferente, pero pese a esto, al darse una capa de sustitución anterior y posterior a la SSB, yo encuentro que la posibilidad de dar con la clave, sigue siendo 2^(-1666) (0.3 e-501)
En fin. Es mi cuestión del día. Colisiones de mi sistema = 0? :D
PD: DamyMr contestame cuando puedas al post ese de (- http://www.kriptopolis.org/node/737#comment-3003 -) que exo de menos tus análisis :)
PPD: Si más gente me analiza me sentiré alegrado :D
Un par de ideas
Ravenheart5 Agosto 2005 - 10:12pm
Yo estuve haciendo algo parecido hace unos años. Para evitar que hubiera textos claros muy obvios, y a la vez complicar mucho (creo) la fuerza bruta, se me ocurrió lo siguiente:
El texto se dividía en bloques de 128 bits.
El programa tenía una rutina principal que hacía varias sustituciones y varias operaciones aritmético-lógicas (más, menos, xor).
Antes de aplicar la rutina principal a cada bloque, hacía un xor con el bloque anterior, ya cifrado, y con una constante.
Después, hacía otro xor con el bloque siguiente, sin cifrar, y con otra constante.
Otra cosa que se me ocurrió - no recuerdo si lo llegué a implementar - fue, una vez terminado de cifrar todo el texto claro, volver a hacer lo mismo pero empezando por el final. Para no aumentar mucho la complejidad - y por tanto el tiempo empleado en cifrar - se puede dividir el número de iteraciones por dos, ya que la rutina se ejecuta dos veces.
Es interesante ver lo que hace con un texto claro consistente en una ristra larga bits todos en el mismo estado...
Saludos.
Un pequeño inconveniente
DamyMr8 Agosto 2005 - 7:47pm
Tu forma de codificar está bien y promete tener resistencia, pero hay un pequeño inconveniente: para poder decodificar hace falta tener todos los bloques desde el primero hasta el último de forma que:
Los algoritmos no son sólo para codificar archivos, y un algoritmo en el que para decodificar un fichero de 1Gb, si hay que empezar por el final malo, y si hay que dar doble vuelta peor. Una vuelta por el final es malo pero no es para tanto, dos vueltas significa el doble de transacciones con un dispositivo "lento" comparado con la memoria y el procesador.
Por cierto, una sorpresa el nuevo look de kriptopolis, y Strapping, te he agregado al messenger pero las discusiones e ideas proncipales prefiero dejarlas en el foro para que algún interesado pueda sacar provecho de ellas.
Bueno...
Ravenheart8 Agosto 2005 - 10:31pm
Lo diseñé para cifrar algunos de mis propios archivos, nada más.
Vamos, no lo hice para vendérselo a nadie ni para transmisiones codificadas. La verdad es que ni se me pasó por la cabeza.
Sin embargo, esto se podría solucionar tal como decía Strapping, aplicando la doble vuelta a cada bloque de unos cuantos kb, y no a todo el fichero de golpe.
Ahora que me acuerdo, otra opción que daba era una lista de formatos para cifrar con lo que se saltaba la cabecera. En un BMP, por ejemplo, cifraba a partir de la lista de colores con lo que se podía seguir abriendo la imagen pero no se veía más que basurilla. Con eso evitaba los famosos ataques por conocimiento de parte del mensaje.
Aclaro mis palabras
DamyMr9 Agosto 2005 - 3:47pm
Lo de saltar la cabecera me parece buena idea, como ya he comentado en otro mensaje, es preferible contar con 64 bytes menos (por decir algo) a que nuestro atacante cuente con 64 bytes conocidos más. Y respecto a lo que te dije en el otro mensaje, yo no me referia a que tu sistema no fuera útil (tu lo hiciste con unos objetivos que cumpliste) sino que para la idea de Strapping, de crear un sistema muy general, no es aplicable.
El Par De Ideas
Strapping6 Agosto 2005 - 12:35pm
Bueno, lo primero, no soy ningún experto. Y bien recibida es tu idea. Entiendo la primera parte de tu algoritmo.
TEXTO PLANO: A,B,C.
Clave: X.
1º A' = A cifrado = A u X
2º B' = B u A'
3º C' = C u B'
Ahora TEXTO PLANO: A',B',C'. Y es ahora donde reciframos pero esta vez de atrás a alante.
1º C" = C' u X
2º B" = B' u C"
3º A" = A' u B"
¿Es correcta mi comparación?. De esta manera lo que leo si le encuentro reversibilidad, es decir, que se puede descifrar sabiendo la clave correcta.
Este modo de cifrado, el de cifrar un bloque con el contenido del anterior, y con una segunda vuelta empezando por atras, me parece un modo de crear cierta dependencia interna de los datos.
===================================0
Al final el primer apartado se reduce a esto:
TEXTO PLANO: HOLAKRIPOTOPOLIS
CLAVE: STRAPPING
CLAVE EXPANDIDA: STRAPPINGHOLAKriptopolis
para codificar "H...S" necesitamos 16 elementos, de S a K los hay. Y se encuentra la inversibilidad conque la clave tenga simplemente un elemento. Esta retroalimentación ya me la comentaron hace tiempo en este mismo hilo :)
Lo de aplicar la segunda vuelta del cifrado de atrás a adelante, creo que es una buena idea para blindar el archivo, ya que para poder supongamos, analizar los primeros bytes del archivo, se debe descifrar el archivo entero en cada ensayo, ya que el ultimo bloque depende del primero, y es del ultimo del que depende el primero tb. Creandose algo como una cadena, en la que o obtienes todo o no obtienes nada.
Esta idea supongo que podria aplicarse directamente a cada bloque en vez de tomando todo el archivo completo; ya se que se miniaturizaria el poder de este recurso, pero 64 KB que es la salida de bloque de cada algoritmo, no es una cantidad con la que poder realizar millones de ensayos por segundo. Aunque por otro lado, dado que aplicasemos una doble vuelta, me daría lo mismo hacerlo por bloque que por archivo, pues tardaría tiempos parecidos...
PD: Ravenheart ¿eres otro super forofo del tema este de la criptografía? Me alegraria que fueses un visitante y posteador regular de este hilo... a ver si entre todos creamos un criptosistema moderno :)
A ver...
Ravenheart8 Agosto 2005 - 6:33pm
El cifrado sería más o menos así - al menos la idea general - aunque el caso contrario era algo diferente:
La contraseña, X, se va modificando en cada iteración, pero es independiente del texto claro. Cada bloque se cifra con la contraseña X modificada. Al llegar a un bloque, antes de cifrarlo, se aplicaría una función dependiente del bloque anterior, y después de cifrarlo se aplicaría otra función dependiente del bloque siguiente (en caso de que los haya, claro).
Pero bueno, son detalles. Lo de hacerlo por bloques en tu caso parece buena idea pero en el mio los bloques eran de 128 bits así que, como que no...
La única desventaja que le veo es que si alguien obtiene un trozo de mensaje cifrado mayor de 64 kb podría descifrarlo y obtener un trozo del mensaje. Haciendolo con el mensaje completo esto sería imposible, en teoría al menos.
Fui un "superforofo del tema este" cuando estaba en bachillerato, pero ahora entre unas cosas y otras lo tengo bastante dejado, aunque no me importaría volver a cogerle el gustillo.
Tampoco yo soy ningún experto, ni mucho menos, por cierto, pero se hará lo que se pueda.
¿Te importa que te agregue al messenger?
Sds.
Contraseña X
eb4bgr (no verificado)14 Agosto 2005 - 2:31pm
Ravenheart,
haciendo referencia a tu comentario "A ver...", del 8 de agosto, me parece fácilmente comprensible que el cifrado se valga del bloque anterior para obtener un valor nuevo que actualice la Contraseña X. El cifrado que yo diseñé (ejemplos del Cifrado PSA en www.kriptopolis.org/node/704) también usa ese método (bueno, en realidad es más complicado que eso porque no depende sólo de actualizar el valor de la Contraseña X, sino que actualiza toda la matriz de Contraseñas X para cifrar o descifrar el nuevo bloque).
Lo que no veo posible es cambiar el valor de la Contraseña X tomando como referencia el bloque siguiente, ya que al cifrar dispones del bloque siguiente en "formato original", sin cifrar, pero al descifrar, el formato del bloque siguiente está cifrado y es distinto del valor original que se tomó para cifrarlo.
Un saludo.
[eb4bgr@yahoo.es]
Re: Analisis Del Algoritmo :)
Strapping31 Julio 2005 - 6:50pm
Inicialmente, pensé en la generación de un verdadero CUBO, que produjera una SSB (como hemos bautizado a las cajitas estas, deribadas de las S-Boxes), de 3 Dimensiones, aplicando la clave.
La fuerza del algoritmo reside en la generación de una potentísima SSB, y lo de las capas anteriores y posteriores de sustitución, no es más que un pekeño refuerzo, para generar confusión.
Se lo que se dice en seguridad, que un sistema es tan debil en la realidad, como así lo sea su parte más debil. Pero dado que dentro de los algoritmos rápidos no se me ocurre uno más fuerte, pues por eso elegí ese.
Lo de que la caja cuente con 65.536 se trata de que al ser programado en ANSI C, y que un "unsigned int" (el tipo de numero que mayor rango de valores trabaja siendo a la vez la variable numerica que menos ocupa en la RAM) recoge valores de 0 a 65535, pues de ahí el motivo. La funcion lectura me devuelve la cantidad de elementos leidos, y leo en bloque de hasta 65535 elementos, ya que llegados al final del archivo, la funcion lectura devolvera un 0.
En el mini ejemplo propuse algo así:
Lo que seria a decir que simplemente expando la clave a 4 veces si misma, aplicandola en circulo en el sentido de las agujas del reloj. Esta regla no es así en la realidad, realmente afino un poco mejor... Pero tengo demasiadas ideas buenillas y no se muy bien entre cuales decidirme o si aplicar directamente todas.
Lo que si está claro es que lo mejor es modificar la SSB por los cuatro costados, de este modo creo que se consigue una protección heredada... no se como decirlo, pero kiero decir que así es más dificil encontrar la clave original.
Eso si, la expansión de clave, no se limita a repetir la clave hasta rellenar las 1024 posiciones posibles :D estaría bueno... hasta yo se que es un poco pobre. Había pensado en su lugar en una "EXPANSION" de la clave, de los elementos que tubiese (n), a 1024, para los casos en que la clave fuese una secuencia de chars del usuario y no un fichero (en caso de fichero, con usar el fichero en bloque de 1024 valdria). Si quieres podriamos meditar sobre esta sección pues creo que es lo poco que queda por decidir del algoritmo, para aprobechar al maximo la clave.
Inicialmente está pensado para trabajar a 1666 bits = 91^256 (91 = cantidad de elementos distintos en el alfabeto de elementos posibles, 256 = longitud maxima de la clave). Pero tengo dudas sobre que Super SBox es la más economica, es decir, cual tamaño es el mínimo que me permite seguridad sin tener "fugas" de seguridad?... (orientado a llegar a aplicaciones para telefonia movil por ejemplo, que cuentan con muy pocos recursos de trabajo).
DATOS CON QUE CONTAMOS:
Variabilidad De Claves (Frase Clave) = 91^256 = 2^1666 = 3.28 e501 claves
Variabilidad De Claves (Fichero) = 256^[Bytes de archivo] = de 256 a WOW
En una SSB de 16x16 = 256, 256! = 8.57 e506 = 2^1684
En una SSB de 32x32 = 1024, 1024! = 5.41 e2639 = 2^8769
...
En una SSB de (256x256)-1 = 65535! = 7.87 e287188
Conclusiones De Datos:
Está claro que conseguir un: permutaciones - claves = 0 es imposible; o al menos a mi no se me ocurre una manera. Pero si se puede lograr que sea lo más cercano a 0 posible. Pero no estoy muy seguro de que la cercania a 0 implique seguridad y la lejania debilidad.
Tal como yo lo veo, cuanto mayor sea la caja, dadas las vueltas a lo "Cubo de Rubic" que se le aplican a la SSB, más dificil me parece el análisis, sea cual sea la clave introducida, si se realiza una buena "Expansión".
Había pensado otra manera de generar una SSB dura, era una manera en que la unica forma de recuperar el orden original era introduciendo EXACTAMENTE la clave verdadera, ya que en cualquier otro caso, solo se conseguia un orden "caotico", pongamos un ejemplo miniaturizado:
Si clave = 8,5,11,25 y sabiendo que los valores son modulo 100.
METODO 1 = Expansión de clave a 65535 mediante regla:
8,5,11,25,0,[100-8],[100-5],[100-11],[100-25],0,8+1,5+1,11+1...
Ahora con estos valores realizamos un intercambio de posiciones en la SSB así:
Posición indicada en 1 cambiar con la indicada en 8.
Posición indicada en 2 cambiar con la indicada en 5.
Posición indicada en 3 cambiar con la indicada en 11.
... En este punto la SSB empiza como 8,5,11,... PERO fijaos que hay 65535, por lo que es seguro que en las tres primeras posiciones de la SSB se hayan realizado cientos de vueltas, con lo que se ha logrado una gran mezcla de posiciones.
METODO 2 = Expansión de clave mediante la regla de METODO1 o mediante cualquier otra manera (lo de la expansión recuerdo que está sin decidir).
Ahora imaginemos que tenemos una secuencia de 65535 valores. Entonces generamos una segunda lista de valores de la siguiente manera:
Valor 1 = SUMATORIO de valor 1 hasta ultimo MODULO 65535.
Valor 2 = SUMATORIO de valor 2 hasta ultimo MODULO 65535.
... Ahora si que es realmente imposible determinar que valores obtendrá al final la SSB, ya que cada valor depende no de 1 caracter de la clave, sino del conjunto total de la clave, teniendo en cuenta cada letra, la longitud de la misma, etc.
Luego dada esta lista de valores, realizamos lo de los intercambios matizados en el METODO 1.
Ahora que hemos elaborado esta SSB bastante bien, vamos al tratamiento desde sus 4 lados.
ULTIMAS CONCLUSIONES:
Las técnicas actuales yo veo que se centran demasiado en darle decenas de vueltas al mismo algoritmo. Yo creo que se consigue una velocidad extraordinariamente superior, mediante centrar como objetivo la generación de una SSB a partir de la clave, ya que luego leer un bloque, aplicar 2 sustituciones y 1 SSB es una operación muy comoda y rápida hasta para la más lenta computadora. Codificar 1 Byte = 3 operaciones. Esta proporción consigue un altisimo rendimiento. Podriamos ampliar a 4 operaciones por Byte, haciendo un [ +1 modulo 65535 ] a la SSB, con lo que se iría manteniendo la seguridad ampliandose el bloque de analisis de 64 KB a aproximadamente 4095 Gigas. Y ya podréis perdonarme, pero creo que es un poco intratable incluso para un macrocluster de computadores trabajar bloques de ese tamaño... Se que hace "pocos" años los PCs tenian 4 MB y ahora trabajan con 2 GB. Pero hasta los 4.095 GB creo que nos quedan muchos años.
PD: Creo que la tontería del proyecto al final va a ser algo eficiente y digna de concurso con un buen pulido... dispondre de unos 4 meses para terminarlo...
PPD: Mi desekilibrio neuronal me hace crear ideas interesantes con solo pararme a pensar en algo con concentración. Estas ideas aki expuestas unas estaban ya pensadas y otras me han salido sobre la marcha.
PPPD: Podria retroalimentar las SSB en vez de con un +1, usando la SSB anterior... MILLONES de formas se me ocurren, así que aki termino el POST
MUCHISIMAS GRACIAS A QUIEN CONSIGUIO LEERME
MUCHISIMAS GRACIAS A DAMYMR POR LAS CONSTRUCTIVAS RESPUESTAS Y ANALISIS!! :D
Un Fuerte Abrazo A Todos!
Aportando nuevas ideas
DamyMr31 Julio 2005 - 10:53pm
De nuevo me han gustado tus ideas y de nuevo te vengo a rebatir algunas, pero creo que lo que sigue te va a gustar muxo más.
Te he demostrado que tu idea de hacer los cuatro movimientos no funcionaba, aun utilizando 4 fragmentos diferentes (si usas solo uno tienes de partida un máximo de 256^256 sin descontar las colisiones (que lógicamente son menores al tener menos libertad para poner valores a la clave).
Lo negativo de las colisiones es que en un supuesto ataque por fuerza bruta, da igual encontrar una clave u otra si el resultado de la permutación es el mismo. Lo ideal es que el número de permutaciones generadas y el número de claves sean el mismo (función biyectiva) pero dices que es complicado...
Pues no, entre tus propuestas y mi análisis tengo una forma válida:
Según mi análisis la función dada llevaba el par (x,y) a (x+P-Q, y+R-S), si quitamos Q y S ya no se producirá ninguna colisión, hemos conseguido mantener toda la información de la clave haciendo sólo dos movimientos. Sin embargo, en apariencia, esto puede dejar el sistema un poco cojo, las permutaciones no son demasiado barullantes.
Y puesto que aplicar otro movimiento más es a todas vistas desperdiciar información de la clave... no podemos tocar más las dimensiones x e y. Dimensiones, sí, si queremos hacer más movimientos podemos añadir dimensiones, y esa es la clave de la idea que te planteo ahora. Imagina un hipercubo (¿chungo eh?), un cubo de cuatro dimensiones (elijo 4 por ser potencia de 2 y porque no quiero imaginarme 8 dimensiones o más).
Imagina un hipercubo de dimensión 16, (para tu querido bloque de 65536 elementos) al que le hacemos un desplazamiento según cada una de las dimensiones. Se deduce inmediatamente que los desplazamientos afectan a todos los elementos pero que un desplazamiento no puede anular el efecto de otro... no hay colisiones. La clave a utilizar sería de 16 elementos para cada dimensión = 64 elementos (como son bits, 512 bits) que es una clave muchísimo más pequeña pero de la que aprovechamos absolutamente todo, dando 256^64 = 1,34e+154 posibilidades diferentes.
Creo yo que la fortaleza del esquema que te doy no es para nada desdeñable.
Respecto a utilizar una clave de un alfabeto de 91 caracteres yo no estoy de acuerdo. Dá libertad al usuario de elegir la clave como desee, si es necesario con dígitos hexadecimales, no restrinjas eso pues debilitas el sistema hasta conseguir 2,39e+125, un sistema aprox 50000000000000000000000000000 más débil.
Para lograr una buena expansión de la clave te recomiendo un generador de congruencias lineal (ahora mismo no los recuerdo muy bien) que te generan una secuencia pseudoaleatoria a partir de una semilla que puede ser la clave.
Por último un consejo para evaluar la calidad de un método de cifrado por bloque: cuando varíes un elemento de la entrada (byte en tu caso) debe variar un 50% de los elementos de la salida, estadísticamente, de esta forma puedes protegerte un poco más frente a un criptoanálisis diferencial.
Espero que esto te sirva de ayuda, creo que lo de aprovechar al máximo la clave puede servirte o al menos inspirarte. De todas formas, viendo como va el algoritmo me atrevo a sugerirte que des más de una vuelta, por muy fuerte que sea la SSB el ataque descrito la rompe (si estás interesado en que te detalle más ese ataque, dímelo).
Gracias a todos por leer y a Strapping por evitar que se me oxiden las neuronas.
Re: Aportando News Ideas
Strapping1 Agosto 2005 - 2:20am
Ese Proyecto de Cifrador!!! que está ganando al menos lectores! (ver nº de visitas).
Habría sido tal vez más directo una comunicación bilineal por e-mail, y puede que más rápida, pero manteniendo este dialogo constructivo entre el gran DamyMr y yo, conseguimos seguramente enseñar a gente algo :D
=====
Veamos, Nota 1: ahora mismo son casi las 2 de la madrugada; Nota 2: dentro de menos de 7 horas me he de levantar para descargar un camión a pulso, tarea que conlleva unas 3 horitas... así q imaginaos las condiciones en q trabaja mi mente... XD ¡kiero vacaciones ya!!! :D
=====
Este mensaje es más bien privado para DamyMr, y mencioné antes como EL GRAN DAMYMR por lo siguiente... pese a mi creatividad... ¡me siento mu tonto! jajajaja! me cuesta entender esas formulas, de las cuales supongo que descubres lo de las colisiones, y algunos conceptos de métodos tb me resultan alienígenas; pues mi conocimiento matemático no es demasiado extenso... aunque por "pensamiento inverso" puedo hacerme ideas generales de algunas cosillas.
Primeras Cuestiones:
1º Si concibo en mi mente un entorno tetradimensional; de exo, paralelamente al conocimiento de esas teorias, desarrolle una idea que facilita su comprensión. 1 dimension = (X), 2 dimensiones (Y)(X), 3 dimensiones (Z)(Y)(X),... digamos que las dimensiones no son más que agrupamientos, [x,y,z,a,b,c,...] ekivalentes a por ejemplo: portal, calle, edificio, barrio, ciudad, país, continente, planeta, sistema, galaxia,... Trasladado así podemos comprender y manejar con relativa facilidad entornos virtuales multidimensionales. ¿A que si?.
2º El alfabeto de 91 elementos sencillamente incluye la casi totalidad de valores ASCII cuyo valor byte oscila entre 0 y 128. He desechado los acentos, y ciertos signos "anormales", porque busco cierta portabilidad a cualquier lugar... 91 caracteres = mayusculas, minusculas, numeros, espacio y los siguientes signos: !"#$%&'()*+,-./:;<=>?{}[\]_@
me atrevo a decir que he puesto un limite bastante grande poniendo a disposicion del usuario estos 91 elementos y un espacio de 1 a 256 elementos. Bastante duro es para mí, un patriota espaÑol, tener que eliminar la Ñ, pero en fin, hay que hacer ciertos sacrificios :D.
3º Entiendo que encuentres inicialmente colisiones de SSB-s porque si comprendo que 2 claves distintas puedan dar lugar a la misma SSB, pero aún así, puesto que antes de ese reordenamiento se les a aplicado 1 sustitución, y posterior a esa SSB se les aplico otra sustitución, es IMPOSIBLE que 2 claves habran el mismo cerrojo, porque aunque coincidan en SSB no coincidirian en las 2 sustituciones... (pienso yo).
4º No comprendo con exactitud lo de "función biyectiva", pero haciendome una idea por contexto, opino que cojas el tamaño que cojas, al menos en dimensiones cuadradas, es imposible que roces ni de lejos el tamaño de posibles permutaciones creando pocas colisiones. *Puede que de ahí lo de la matriz de 4 dimensiones.
5º Pienso que se reducirían la cantidad de colisiones aplicando la clave (dentro de mi algoritmo original me refiero, no confundir con la proposicion de 4 dimensiones), a simplemente dos caras perpendiculares, es decir, arriba y a un lado. Aún así, antes de aplicar estas reglas a la SSB, ya genero una con bastante aleatoriedad con una buena trasposicion de filas, columnas, diagonales,...
6º "Por último un consejo para evaluar la calidad de un método de cifrado por bloque: cuando varíes un elemento de la entrada (byte en tu caso) debe variar un 50% de los elementos de la salida, estadísticamente, de esta forma puedes protegerte un poco más frente a un criptoanálisis diferencial." ¿1 Byte de la clave, o 1 Byte del bloque cifrado? Esto me ha dejao intrigao... xq si es de cada bloque de cifrado, tendria que usar la realimentación de clave en base al archivo a cifrar, y esto ahora mismo no se me ocurre como lograrlo...
7º Me es facil alterar ciclicamente la SSB a lo largo del proceso con un +1 mod (longitud del bloque), ya que por ejemplo tomemos: 15243 => 21354 => 32415 => 43521 => 54132 ==> 15243, conclusion, para 1000 elementos, podemos lograr una alteracion radical del orden durante 1000 ciclos... (cojan calculadoras).
8º No se como explotar mejor el sistema SSB, pero creo que lo comentado en el post de agregar dimensiones, debo dedicarle muxo tiempo:
Pues no, entre tus propuestas y mi análisis tengo una forma válida: Según mi análisis la función dada llevaba el par (x,y) a (x+P-Q, y+R-S), si quitamos Q y S ya no se producirá ninguna colisión, hemos conseguido mantener toda la información de la clave haciendo sólo dos movimientos. Sin embargo, en apariencia, esto puede dejar el sistema un poco cojo, las permutaciones no son demasiado barullantes.
Y puesto que aplicar otro movimiento más es a todas vistas desperdiciar información de la clave... no podemos tocar más las dimensiones x e y. Dimensiones, sí, si queremos hacer más movimientos podemos añadir dimensiones, y esa es la clave de la idea que te planteo ahora. Imagina un hipercubo (¿chungo eh?), un cubo de cuatro dimensiones (elijo 4 por ser potencia de 2 y porque no quiero imaginarme 8 dimensiones o más).
Imagina un hipercubo de dimensión 16, (para tu querido bloque de 65536 elementos) al que le hacemos un desplazamiento según cada una de las dimensiones. Se deduce inmediatamente que los desplazamientos afectan a todos los elementos pero que un desplazamiento no puede anular el efecto de otro... no hay colisiones. La clave a utilizar sería de 16 elementos para cada dimensión = 64 elementos (como son bits, 512 bits) que es una clave muchísimo más pequeña pero de la que aprovechamos absolutamente todo, dando 256^64 = 1,34e+154 posibilidades diferentes.
Creo yo que la fortaleza del esquema que te doy no es para nada desdeñable.
Pero ahora son las 2:30 am y me kedan 4 horas para dormir... tras un dia de trabajo... mañana lo intentaré figura!
PD: MUCHISIMAS GRACIAS POR TU TIEMPO, me alegro ver que la alegria es reciproca (yo despierto neuronas que tenias casi oxidadas segun tu otro post, y tu me motivas a seguir estrujando mis novatas neuronas para evolucionar y avanzar :D)
PPD: Espero que de este hilo saliese el proximo competidor del NIST jajajajaja, estaría bueno no?
PPPD: Saludos de un ventiañero del norte de España :)
Hola, lamento no haber podido
DamyMr3 Agosto 2005 - 11:29pm
Hola, lamento no haber podido responderte antes, no he tenido tiempo.
Te comento brevemente algunas cosillas:
En lo del entorno multidimensional, la idea que te haces es buena, no es mas que añadir más variables. Después de pensarlo un poco, obtener la clave de la permutación es muy sencillo si se usan dos dimensiones solamente, no sé que pasa si se usan mas, porque tengo cierto límite de dimensiones en mi cabeza.
El usar un alfabeto de 91 caracteres es válido para las personas, pero no olvides que trabajamos con máquinas. En una comunicacion puede utilizarse criptografía de clave pública para dar el saludo, autentificar y ponerse deacuerdo en una clave privada y aleatoria para el resto de la comunicación, que se realiza con un algoritmo simétrico dada su mayor velocidad.
Lo que dices es cierto de que aunque coincidan las SSB pueden no coincidir el cifrado polialfabético, con eso estoy de acuerdo. Pero piensa que si un atacante es capaz de romper la parte complicada del sistema, la parte sencilla no puede ser demasiado inconveniente. Mañana si puedo te explicaré detalladamente cómo se puede debilitar tu sistema con un ejemplo simplificado.
Una funcion lleva elementos de un conjunto en otro conjunto, y a un elemento del primer conjunto le corresponde un único elemento del segundo conjunto. Una función biyectiva asocia a cada elemento del primer conjunto uno y sólo uno del segundo, y este a su vez solo proviene del elemento mencionado. Además todos los elementos del conjunto origen tienen imagen en el destino, y todas los elementos del destino provienen de un origen. Como consecuencia hay tantos elementos en el origen como en el destino.
Cuando hablo de variar elementos, lo ideal es que varíen bits. Si se cumple lo mencionado, es que el sistema no se aleja mucho de producir resultados aleatorios, será más difícil encontrar una debilidad al determinar que un bit depende de otro y establecer estadísticamente relaciones entre ellos.
Para hacer una permutación de n elementos, la clave mínima a usar de forma que todas las permutaciones sean posibles en log2(n!). Si se usa una clave mayor se produciran siempre colisiones (principio del palomar). Yo creo que el hecho de que se produzcan colisiones es bueno siempre que sean pocas por caso y todas las permutaciones sean posibles. de todas formas llegar a un mecanismo que utilice claves de longitud log2(n!) (en bits) promete ser un problema difícil.
Saludos de un veintiunañero :D, que no me imagino cuantos años me has echao :P.
Ánimo y suerte con el proyecto.
PROYECTO DE CIFRADOR - LA AMPLIACION
Strapping31 Julio 2005 - 2:26am
PROYECTO DE CIFRADOR - AMPLIACION
=====================================
ANTES DE NADA, AVISO, ESTO ES LA EXPLICACION DEL ALGORITMO QUE USARA MI PROYECTO DE CIFRADOR, EL ALGORITMO ESTA DISEÑADO POR MI, Y ESTO QUE TENEIS AKI SON ESKEMITAS QUE AYUDAN A PODER ANALIZAR EL SISTEMA DE SEGURIDAD. NO ESTA COMPLETO AL DETALLE PERO SI FACIL DE ENTENDER CON ALGO DE PACIENCIA. PERDONAD LA LONGITUD,... ESPERO QUE OS GUSTE :)
======================================
Buenas DamyMr, bueno, te informo de los eskemas. Pero para dar una explicación miniaturizada, necesitaremos empekeñecer el entorno, para que sea así más facil coger el enfoke global.
Valores Posibles De Byte: 1,2,3,4,5,6,7,8,9
Secuencia ORIGINAL: 3,2,4,5,9,6,8,1,7
CLAVE: 2,6,9
Aplicando Capa Sustitución:
A) Creación de Mapa Polialfabetico:
1 2,3,4,5,6,7,8,9,1
2 6,7,8,9,1,2,3,4,5
3 9,1,2,3,4,5,6,7,8
B) Paso ORIGINAL - INTERMEDIO1:
Original: 3,2,4,5,9,6,8,1,7
Alfabeto: 1,2,3,1,2,3,1,2,3
Interm_1: 4,7,3,6,5,5,9,6,6
* Se lo que pensais, habría sido más simple, hacer la operación de ORIGINAL + CLAVE (mod ELEMENTOS) = CIFRADO. Pero pese a que para un humano es más fácil este camino, la realidad es que para una computadora, es muchisimo más rapido facilitarle un MAPABIN y usar un algoritmo ekivalente. (LO HE COMPROBAO).
C) INTERMEDIO1 - INTERMEDIO2.
Bien, este es el gran cachondeo del colega DamyMr :). Veamos, supongamos que para la transposición usasemos una matriz cuadrada en la cual entrasen TODOS los elementos. En este caso requeriríamos una 3x3, ya que hay 9 elementos:
1 2 3
4 5 6
7 8 9
Ahora trabajaremos sobre la matriz que indica las posiciones originales del bloque, y generaremos la SSB. Recordando que la clave es: 2,6,9
Explico, divido el proceso en 2 fases. 1º sacar ekivalente de la clave modulo rango de la matriz cuadrada => 2 mod 3 = 2, 6 mod 3 = 0, 9 mod 3 = 0. 2ª Aplicar un avance de X posiciones sobre los elementos de esa fila o columna.
------2 6 9
------2 0 0
9 0 - 1 2 3 - 2 2
6 0 - 4 5 6 - 0 6
2 2 - 7 8 9 - 0 9
------0 0 2
------9 6 2
Esto hare una demostracion (A) Superior, B) Derecha, C) Abajo, D) Izquda)
A) 7 2 3 B) 3 7 2 C) 3 7 9 D) 3 7 9
___4 5 6 ___ 4 5 6 ___ 4 5 2 ___ 4 5 2
___1 8 9 ___ 1 8 9 ___ 1 8 6 ___ 6 1 8
La SSB a pasado de 123456789 a 379452618 tras aplicar la clave. NOTA: Usando una SSB de rango N, siendo N la longitud del alfabeto, nos olvidamos de todo esto de tener que modular... supongamos q la matriz fuese de 256x256, tendriamos 65536 elementos, perdon, posiciones diferentes!. SSB posibles: 65536! Una animalada... yo resto un elemento a la caja, por motivos de contadores, y de economizar código :). Y aún así admitiria ficheros como clave, pudiendo usarse los 256 valores posibles de cada byte... dando una potencia de 7 KiloBits aprox, solo para cada bloque de 64 KB, ya que para el siguiente bloque se generaria una nueva SSB a partir del 2º Kilobyte del archivo clave, y así sucesivamente... QUE SALVAJADA NO? :P
Ahora simplemente cogemos la secuencia INTERMEDIA anterior, y aplicamos este reorden, dando lugar a la secuencia INTERMEDIA_2
123456789 379452618
473655966 = 396657546
Ahora el paso final, reaplicamos el primer paso, la sustitución a esta nueva secuencia de datos...
D) Paso INTERMEDIO2 - FINAL:
Interm_2: 3,9,6,6,5,7,5,4,6
Alfabeto: 1 2 3 1 2 3 1 2 3
Final...: 4 5 5 7 9 6 6 9 5
RESULTADO FINAL: "324596817" + CLAVE 269 en mi algoritmo "455796695"
=============================================
Conclusiones De Este Novato:
Creo que este sistema de cifrado, consigue una alta seguridad, pues sinceramente, dado el diseño de la SSB, no hay manera de
recuperar hayar la clave a partir de parejas de archivos... ya que aun con mi mente retorcida no se me ocurren posibilidades,
pues probando una clave, que nos diese una ekivalencia parcial con el original, sería más por pura casualidad que por
descubrir parte de la clave; ya que pese a no dar este algoritmo 1000 vueltas, con el duro diseño de la SSB, con 1 vuelta me
parece más que suficiente.
Creo que mi algoritmo, es bastante eficiente. Y logra una bestial velocidad, lo tengo ya testeadito en mi ekipo, y consigue
una velocidad de vértigo (consigo unos 36 MB/s de cifrado, contra los 7 que logro con AES...) y eso que solo está
implementado en ANSI C; si supiera ensamblador, podria aplicar todo esto a nivel de BIT, pero puesto que no se operar bits,
trabajo a nivel de BYTE, que la verdad, estando formalizado en grupos de 8 bits, toy trankilo manejando mis bytes :P
NOTAS DE LA SSB: Esta se genera dependiendo de la cantidad de elementos procesables; es decir, si el archivo mide 70 KB, pues
se genera una SSB para los primeros 64, y luego otra para los 6 restantes. Dado el diseño de la SSB, no necesito crear
relleno, pues es flexible, pudiendo adaptarse a por ejemplo, una matriz de 2 bytes. Aunque inicialmente trabaje
predeterminadamente cajas de 64 KB. (sería más apropiado una SSB de 10 KB, pero llamemos capricho a mi deseo de usar numeros
multiplos informaticos... 16,32,64,128... por amor al arte :)
===================================
Esto es una pekeña exposición pa coger una idea general de como se genera la SSB; pero tiene bastante más currillo, para
garantizar su flexibilidad y estabilidad. Hay más operaciones para definirla... pero esto era una especie de DEMO de lo que
me estoy currando.
Me gustaría recibir opiniones de todos los veteranos, aficionados y maestros de estas artes. Toy creando de enfocar mis
habilidades mentales a crear seguridad gratuita para el mundo... Otros lokillos del ordenador como yo se dedican a crear
virus, que aunque también tiene su gran curro de diseño, odio los resultados, prefiero aportar cosas positivas, y no dolores
de cabeza a la gente normal...
BUENISIMAS NOCHES! SON LAS 2:20 AM, ME KEDAN 7 HORAS DE SUEÑO!! Y MAÑANA CURRO! QUE DOLOR!!!!
PD: El proyecto de ANSI C que estoy desarrollando es 100% compatible con todos los sistemas operativos de MS, aceptando
Drag&Drop, función por linea de comando, trabajo por menu (textual), liberando carga al micro al trabajar en segundo plano
siempre (así no molesta :D).
PPD: UN FUERTE ABRAZO A TODA LA GENTE! GRACIAS ENTRE TODOS POR ANIMARME A DESARROLLAR ESTE TRABAJO!!! Gracias DamyMr, JM Lucena, Jorge Ramió Aguirre, Inmemoriam, Envite, nk2701,... y MUCHISIMAS GRACIAS a mis amiguetes de www.dtodo1poco.com que me animaron desde el principio :) (como comento DamyMr, la Fuerza de mi algoritmo reside en la SSB).
Para Comunicación Privada: Strapping @ gmail . com :P
Análisis del algoritmo
DamyMr31 Julio 2005 - 5:15pm
Genial idea!!! me recuerda un poco al cubo de rubik.
-----------------------------------------
ATENCION: El mensaje es largo y en él explico cómo analizo el sistema criptográfico nuevo propuesto por Strapping, y extraigo conclusiones interesantes acerca de su fortaleza y los problemas que presenta.
Buena lectura
-----------------------------------------
Sin embargo creo que tienes algunos errores en tu razonamiento:
El primero es el siguiente: en una función biyectiva (que es la que nos interesa) el cardinal del conjunto de partida debe ser igual al cardinal del conjunto de llegada, eso implica que si tomamos 4 subclaves de 256 bytes (1kb) por SSB, no tendremos 65535! posibles permutaciones, sino "solo" 256^1024 como máximo, que es un número muchísimo menor pero a su vez exageradamente grande.
Esto que te cuento es por que tú nunca puedes crear más información con la clave que la que te proporcione la clave misma: puesto que es una función, si tienes n elementos en el conjunto de partida, tendrás >=n posibilidades en el conjunto de llegada, el = se alcanza con la biyectividad y representa que aprovechamos la clave al máximo. Si no aprovechamos la clave al máximo, se puede conseguir un esquema que con menos bytes proporcione el mismo nivel de seguridad.
Ahora voy a probar que, por desgracia, tu función no es biyectiva. Para ello probaré que no es inyectiva con un contraejemplo muy sencillo: supongamos que los cuatro fragmentos de clave son una ristra de unos (a), y supongamos después que es una ristra de doses (b); en ambos supuestos el resultado es el mismo, queda la permutación trivial, y hemos encontrado f(a)=f(b) siendo a!=b, un contraejempo claro. De lo que se deduce que las permutaciones generadas no alcanzan 1024^256 que era el máximo teórico, no se está exprimiendo la clave al máximo.
Los cálculos para acotar las posibles permutaciones con una SSB de 256x256 elementos se me antojan complicados, lo haré en una de 4x4 para que compruebes que existen mucha menos posibilidades de las que inicialmente se pueden pensar, los elementos tendrán 2 bits de información (caso equivalente a 8 bits y caja de 256x256 que es con lo que trabajas):
Primera impresión: hay 16! = 20922789888000 posibilidades.
Segunda impresión: la clave consta de 4 fragmentos de 4 elementos, cada elemento puede tener cuatro valores (00, 01, 10, 11). Las posibilidades de claves diferentes son 16^4 (16 elementos y cuatro valores por elemento) 4^16 = 4294967296 posibilidades. Creo que la reducción de complejidad es impresionante, y eso sin contar aún con las colisiones.
Ahora analicemos las colisiones para intentar llegar un poco más allá:
tenemos un elemento A en (x,y) y un elemento A' de llegada en (x', y'); las cuatro claves S, D, A, I (Superior, Derecha, Abajo, Izquierda) tendrán elementos que denotaré con subíndices en letra minúscula (como pueda), las ecuacion del movimiento es la siguiente:
------ X
|
| COORDENADAS, COMO EN UNA IMAGEN
Y
(x',y') = (x,y) + (0, Si) + (Dj, 0) - (0, Ak) - (Il, 0)
siendo i, j, k, l los sbíndices de los elementos que correspondan en cada momento. Como sabemos que el elemento está en (x, y) y sabemos que el movimiento Arriba se efectua en una columna (coordenada x) pero afecta a la colocacion de todos los elementos respecto su fila (cordenada y) podremos calcular cuantas colisiones se producen:
Primer movimiento, la i corresponde al valor x-ésimo de la clave superior:
(x',y') = (x,y+Sx) + (Dj, 0) - (0, Ak) - (Il, 0)
Segundo movimiento, la j corresponde al valor de la segunda coordenada donde nos encontremos:
(x',y') = (x+D ,y+Sx ) - (0, Ak ) - (Il , 0)
y+Sx subindices
Tercer movimiento, como el primero (pero signo negativo):
(x',y') = (x+D ,y+Sx -A ) - (Il , 0)
y+Sx x+D
y+Sx subíndices de subíndices
Cuarto movimiento, como el segundo pero con signo negativo:
(x',y') = (x+D - I ,y+Sx -A )
y+Sx y+Sx -A x+D
x+D y+Sx
y+Sx
//La leche, cuatro niveles de subíndices.
He considerado Superior y derecha con signos positivos, y abajo e inferior con signos negativos, da igual mientras los opuestos sean opuestos. La ecuación tiene la forma (x',y') = (x+P-Q, y+R-S).
Como ves, x' = x+P-Q, es una ecuación con múltiples soluciones, P-Q=k => P=Q+k, todas las claves que cumplan esto darán lugar a una permutación igual, por ejemplo:
Ahora solo hablo de claves con todos los elementos iguales en cada fragmento.
P-Q=0, R-S=0, para todo elemento, la permutación quedará como estaba, hay 4 posibilidades para P (00, 01, 10, 11) y con eso Q queda determinado; hay cuatro posibilidades para R y S también queda determinado. En total existen 4*4=16 claves con todos los elementos iguales que dan el mismo resultado, no mueven la permutación.
Más aún: Si una clave tiene todos los elementos iguales y su opuesta también, las otras dos claves con ser iguales basta (no hace falta que tengan los elementos iguales), con lo que tenemos:
Además podemos buscar las claves que dejan la permutación como está, sólamente que desplazada, por ejemplo: (uso hexadecimal q no tengo ganas de dar formato)
fcde
4123
8567
c9ab
Que es ekivalente a hacer un movimiento hacia las X y uno hacia las Y.
Si fijamos el movimiento, por ejemplo (+1, +1), con un fragmento con los elementos iguales y el opuesto que haga correspondencia, podemos sacarlo: por ejemplo 2222 0123 1111 3012. Siguiendo un razonamiento similar al anterior tenemos 2048 claves para cada posicion de éstas que queramos conseguir. Como hay 16 posiciones posibles, incluidas las anteriores, hay 32768 combinaciones para dar lugar a 16 permutaciones.
Creo que es éste es un dato malo para tu sistema.
No sé probar cuantas colisiones se producirían en un caso general, pero sospecho que para cada posición posible habría 2048 formas de llegar a ella (no estoy seguro pero lo creo). Si esta suposición fuese cierta, habría 2097152 posibles permutaciones con la clave de 16 elementos de dos bits cada uno, muy alejado de las 20922789888000 posibilidades que creíamos al empezar. Este nivel de secreto se podría haber alcanzado con una clave de 10,5 elementos en vez de los 16 iniciales.
Extrapolando esta hipótesis a tu problema, habria 2*256*256^256 claves que den lugar a la misma permutación
1,6546307108511235737966016864599e+619 de colisiones por elemento.
Haciendo números, de las 5,1629485230975091650002279432724e+287193 posibilidades que tú creías que había, en teoría sólo puede haber 1,0907481356194159294629842447338e+2466, y teniendo en cuanta las colisiones calculadas, habría 6,5920941057497189814279637673208e+1846 posibilidades. Este nivel de secreto se podría haber alcanzado con una clave de 766,875 bytes de los 1024 iniciales.
El sistema no aprovecha óptimamente la información de la clave, apenas usa un 75% de la misma. Su fuerza debe residir necesariamente en la longitud de la misma.
Las conclusiones que saco son:
Me parece buena la idea pero hay que refinarla mucho más.
Tienes que tratar de conseguir un aprovechamiento óptimo de la clave.
El sistema aún sería fácilmente atacable, el ataque te lo describí someramente en el otro post, pero ahora veo que es mejor de lo que yo pensaba.
Una pequeña "pequeñísima" virtud es que si consiguiésemos obtener la permutación perteneciente a una clave, sería muy difícil obtener la clave porque las colisiones son muchas, ahí entraría en juego la confusión de los cifrados polialfabéticos que menciona el algoritmo, sin embargo este cifrado es tremendamente débil y su aportación es pequeña a la seguridad total. Una vez obtenida la permutación, nos enfrentariamos a un cifrado polialfabético a nivel de byte con dos fases, no es demasiado complicado conseguirlo si tenemos la suficiente cantidad de información.
Me parece un sistema bastante seguro, pero que puede dar mucho más de sí.
Gracias a todo el que haya podido leer el mensaje.
Nuevo Cifrador
Strapping11 Junio 2005 - 1:38pm
Y me pregunto yo, ¿por qué reinventar la rueda?. Después de todo el trabajo que te estás dando con el programa, no sería mejor utilizar algún módulo GPL de cifrado simétrico que te diera esa seguridad a la hora de cifrar datos. No soy ningún experto en criptología, soy administrador de sistemas, pero todo esto me ha recordado bastante a la filosofía de UNIX o GNU/Linux -> "Un programa es un conjunto de instrucciones que cumplen una función pero que la cumplen bien", frente a la filosofía de Windows -> "un programa que lo hace todo". Y en tu caso, como quieres hacerlo multiplataforma, yo apostaría por eso. :D
Un saludo, JP Molina (Granada) / ::.. Si vales, bene est, ego valeo
Holas:
Tras hablar con más expertos en el tema del cifrado, he llegao ha ciertas conclusiones, y a parte, he cubierto las necesidades.
1º -> Sabemos que hay programas que realizan hasta 32 vueltas de cifrado al mixmo documento plano. Pero me parece que esto es una técnica que simplemente come tiempo, pero que no garantiza mucho. Yo pretendo dar como muchísimo 4 vueltas, es decir, aplicar dos veces cada capa de cifrado.
2º -> Contar con una única capa de cifrado siendo esta de sustitución es insuficiente, debido a las cabeceras de los archivos, y a las secuencias de igual valor de byte. Por esto, hay que compensar este fallo de mi sistema de seguridad.
Ideas:
-> A) Comprimir el archivo original, tal y como propuso "Envite". De este modo consigo matar dos pajaros de un tiro: Consigo reducir el tamaño de las cabeceras de archivo a solo 20 bytes (tamaño de la cabecera del compresor q tengo elegido), y Consigo también, eliminar todas las secuencias de igual valor de Byte. Por contra, aunque el proceso de cifrado es más corto por ser el archivo a cifrar (el comprimido) menor que el original, se debe esperar a que se genere el comprimido (y en caso inverso la descompresión). Pero me fijado que la inmensa mayoria de cifradores utilizan una compresión de modo opcional. Así que no me preocupo.
-> B) CAPA DIFUSORA; como ya habréis leido los forofos de esta web, las tecnicas fundamentales de cifrado son Sustitución y Difusión/Transposición. Pues bien, ya he diseñado por fin un sistema de difusión, que permite perder totalmente la cabecera del archivo.
Una Vez Terminada La Creación Del Programa, Este Es El Pronóstico Para La Versión 2.0
A) Cifra hasta a 34 MBytes/s
[Trabaja En Segundo Plano, por lo que la
velocidad es variable]
B) Cifra de 6.5 BITs a 1666 BITs
C) Trabaja Con Bloques De Tamaño Variable
[de 1 a 65535 Bytes (524.280 bits)]
D) Trabaja Con Claves De Longitud Variable
[de 1 a 256 Bytes -> Alfabeto de 91 chars]
PARA LA VERSION 3:
-> Tengo pensado usar también el contenido de archivos como clave, de modo que logramos incrementar la potencia de cifrado llegando a trabajar a [ 8 x (Tamaño En Bytes De Archivo Clave) ]; Ejemplo: Usando como clave un archivo típico fondo de escritorio JPG de 1024 x 768, tamaño: 125 KB, llegamos a cifrar a 1 MegaBIT de potencia.
¿Qué Os Parece Esta Salvajada? ¿Creéis que sería comercializable?
==============================================================
Esquema del Algoritmo:
1) Peticion de datos de entrada
(clave, archivo origen, archivo destino)
Si Operación Cifrado:
2) Comprimir archivo origen
3) Capa de Sustitución al Comprimido
4) Capa de Difusión al Comprimido
5) reaplicación de pasos 3 y 4.
Si Operación Descifrado:
2) Invertir Capa de Difusión
3) Invertir Capa de Sustitución
4) Repetir pasos 2 y 3
5) Descomprimir archivo
OPINIONES? SUGERENCIAS? CONSEJOS? CORRECCIONES?
No soy más que un jodio novato, así que no creo que halla creado el futuro AES, pero si es posible jejejeje, hay q ser optimistas. Espero Vuestros Comentarios :)
PD: Gracias Por Vuestra Colaboración :-)
Como experimento está bien,
DamyMr29 Julio 2005 - 2:08am
Como experimento está bien, pero dudo mucho de que sea comercializable. En primer lugar aclararte que existen algoritmos que hacen muchas rondas, pero creo que era el IDEA en el que se ha conseguido ya criptoanalizar hasta una ronda menos. Algunos de esos algoritmos como el DES o el Blowfish utilizan redes de Feistel en las que en cada ronda sólo cifran la mitad de un bloque, un par de rondas son completamente inservibles para ellos.
El sistema que tu propones creo que no sería demasiado complicado criptoanalizar para los expertos disponiendo de parejas de mensajes en texto plano y su correspondiente cifrado, no das detalles de cómo funciona la capa de difusión pero creo que un criptoanálisis diferencial le puede dar muy duro (supongo que la capa de difusión sea una trasposición y cada letra en una posición dada irá inexorablemente a otra posición).
No pretendo desanimarte, ni mucho menos, sólo decirte que cuantas más vueltas más seguro. Si pusieras una descripción más detallada del funcionamiento quizás pudiese decirte algo más.
E un egperimento zi! :-)
Strapping29 Julio 2005 - 6:46pm
Hola maestro... es un experimentillo con el que pretendía crear algo way. No tengo ninguna intención de comercializarlo. En todo caso liberarlo bajo GNU, para que todo el mundo pueda usarlo sin tener que pagar un céntimo!.
Yo creía que el sistema que proponía, una transposición de 65.000 elementos, y una sustitución de 1666 bits, sería algo bastante resistente.
Intentaré darte una descripción más detallada del funcionamiento para que me dieses tu opinión.
El algoritmo tenia decidido hacer SUSTITUCION-TRANSPOSICION-SUSTITUCION. (3 fases...)
La sustitución, sería algo parecido al Vigenere, es decir, una sustitución polialfabética de 1.7 KBits. Y la tranposición, pues veamos, te explico.
La cantidad posibles de reordenamientos de N elementos es N!; usease factorial de N (pa los que no ten mu puestos en temas matematicos). Puesto q mi bloque maaximo (variable) es de 65535 elementos, hay 65535! transposiciones posibles. De esas 7.8 x 10^287188 reordenaciones posibles aplico 1, ¿cual? pues facil, aplico la ekivalente a la llave decidida por el usuario. Es decir, la caja de transposición se genera a partir de la clave. Y puesto que hay 3.2 x 10^501 claves posibles, pues hay bastante juego creo yo.
Recalco: NO PIENSO TRATAR DE COMERCIALIZARLO => 1º Eso exige patentes, las cuales son MUY caritas; 2º Hay miles de alternativas gratuitas; 3º Estoy en contra de las patentes en ciertos ámbitos, pues entorpecen el desarrollo/evolución; 4º La comunidad gratuita me ha aportado muxo, y quiero colaborar con mi granito de arena :-).
Me gustaría que este proyecto personal diese fruto a algo way :-) Agradecería ayuditas jejejeje...
PD: Perdon por la longitud del post, muchas gracias por vuestro tiempo :)
Me gusta la idea de que la tr
DamyMr29 Julio 2005 - 7:34pm
Me gusta la idea de que la trasposición sea dependiente de la clave pero ¿cómo narices lo consigues? estoy un poco intrigado... Para que el sistema sea resistente tienes que asegurarte que las trasposiciones obtenidas a partir de la clave sean todas diferentes, es decir, que no haya colisiones pues eso haría el sistema muchísimo mas débil. Decirte también que tengas en cuenta el hecho de que pueden atacarlo mediante parejas de texto plano y texto cifrado como te puse en el otro post, y el gran problema de esto es que se pueda obtener la clave. Un sistema un poco más seguro no permitiría obtener la clave (salvo por fuerza bruta) conociendo parejas de textos planos/cifrados. Actualmente estoy diseñando un método que pretende ser mucho más resistente a los ataques conocidos, incluso a la fuerza bruta (no sonriais, que es posible) y pretendo tenerlo terminado en un par de meses.
Acerca de la idea de que utilices un archivo como clave, me parece muy buena, sería muy dicífil poder romper un sistema no trivial como el que propones con claves de varios miles de bits, pero también tiene algunas pegas: la clave se debe transmitir (normalmente se utiliza criptografía de clave pública para ello, que es lenta), la clave se debe almacenar (en un ordenador personal no hay problemas, pero en una máquina pequeña quizás sí, además de que posiblemente no se almacene una clave sino varias, una para cada interlocutor) y la clave se debe manejar (cargarla en memoria, y 120Kb de memoria es mucha memoria para pequeños dispositivos).
La mejor de diseñar un nuevo algoritmo es aprovechar la clave al máximo: 128 bits dan para un sistema bastante seguro pero hay que estrujarse el cerebro para aprovechar al máximo la información contenida en la clave (si no usas toda la información contenida en la clave se puede diseñar un sistema equivalente con una clave menor). Por cierto, ¿usarias la cabecera del archivo como principio de la clave? Pienso que es mejor desechar esa información pues en archivos conocidos la cabecera es o suele ser casi invariable.
PD: No te tomes a mal todo esto, intento ayudarte para que no caigas en errores de bulto y consigas hacer algo mejor.
PPD: ¿Cómo consigues hacer la trasposición a partir de la clave? Mira que me tiene intrigado... (y si lo haces bien como te dije, aquí radicará la fuerza de tu sistema)
PPD: También pido perdón por la longitud del post y agradezco vuestro tiempo.
PPPD: (lo siento, última hora) Trabajas con un bloque de 64Kb pero descifras el bloque completo o lo haces por flujo (es decir empiezas a descifrar desde el principio y lo que queda ya esta descifrado)???.
Transposition powar! jeje
Strapping30 Julio 2005 - 3:35am
Gracias por valorar mi algoritmo, como para hacerle estos análisis :)
Dado que tu también estás trabajando en el desarrollo de un método wapo de cifrado, pues me gustaría realizar un intercambio simbiótico, si es posible, jeje... mi e-mail: strapping@gmail.com, mi messenger strapping_83@hotmail.com pa xateá! :D Yevo estudiando por libre criptografía desde hace bastantes meses...
Como has comentado, la gran potencia del cifrado, residirá en la sección de transposición. La verdad, esque ese atake que has mencionado, de descubrir la clave a partir de un archivo y el correspondiente cifrado... la verdad esque creo que es extraordinariamente jodido. Dados dos bloques de 64 KiloBytes, A y A' descubrir cual es la clave que se ha utilizado... me parece intratable (aunque es la opinión de sólo un aficionao), pues lo único q se me ocurre es probar clave a clave, y comparar... y aún coincidiendo los primeros bytes, no significa nada, xq es más posible que sea casualidad, a que realmente hayas descubierto la clave, xq la tecnica hace que todo sea 100% dinámico e interdependiente.
Las sustituciones, como son polialfabeticas las realizo en "flujo", pero, para la transposición genero una Super S-Box para 65535 elementos. Esta SSB se define a partir de la clave; por tanto a cada clave le corresponde una SSB. Y dada la cantidad de SSB para esa cantidad... me parece sinceramente intratable.
A parte, el exo de trabajar de esta manera, me permite agilizar el sistema de modo muy eficiente. E incluso me permite una modificación radical rapidisima de un bloque al siguiente. (sumando 1 modulo 65535). Y puesto que el programa hace una sustitución posterior a la trasposición, esto hace que sea terriblemente dificil crear una función inversa.
Creo que mi algoritmo puede ser muy bueno. Puede que con este proyecto aporte algo sustancioso a la comunidad forofa de los ordenatas y la seguridad informática como yo.
Gracias Por TU Tiempo gran DamyMr :-) Agradezco mucho que dedikes tiempo a este hilo. A ver si más gente se anima.
PD: Para la transposición mejor te lo voy preparando unos eskemas, los cuales podras ver más alante, esque aún solo están en mi cabeza :). Seguro que no te defraudarán. Y Creo que este sistema reforzaría tontamente muchos algoritmos...
PPD: Te gustaría que formasemos un ekipo en el desarrollo de un nuevo software que obviamente sería distribuido bajo licencia GNU de esa, gratuito y código abierto :-) [a ver si creamos un nuevo AES (Advanced Encription Standard) jejeje! seriamos famosetes jajaja].
PPPD: A lo de desechar secciones de cabeceras de archivo, obviamente es mejor, pero por otro lado, dado el potencial en BITs de cifrado que se logra con un archivo, me parece un trabajo innecesario (andar informando de q bytes son desechables en cada formato de archivo). Con mi algoritmo, con un archivo de 110 KB (tipico fondo de escritorio JPG), consigo un cifrado de 1 MegaBit, con bastantes garantias de seguridad ;-).
PPPPD: Mi programa en variables, se come aproximadamente unos 130 Kilobytes. Es bastante (64*2 + unos pocos bytes mas), pero a la vez, he estrujado al máximo mi mente para no rekerir más... para que sea eficiente. Está en ANSI C (portable a todas las mákinas).
GRACIAS POR VUESTRO TIEMPO!!!! ME VOY A DORMIR!!!! 3:40 AM!!!
Y no me tomo a mal nada, es más, me alegro de recibir comentarios, ideas de ayuda, y demás :)
Yo en principio tengo intenci
DamyMr30 Julio 2005 - 1:08pm
Yo en principio tengo intención de crear el prototipo en Java, más que nada porque lo controlo mejor que otros lenguajes, pero si veo que la idea marcha adelante me atrevería a hacerlo en ensamblador (aunque sea sólo la rutina de codificación) para demostrar la velocidad que se puede alcanzar.
Estoy impaciente por ver cómo construyes una SSB (me gusta el nombre, jejej) a partir de una cadena de caracteres, y que estés seguro de que ésta contiene exactamente la misma información que la clave (o sea a clave diferente SSB diferente).
Sobre la forma de atacar el sistema necesito esos esquemas, pero te pongo sobre la pista: contando con archivos en texto plano y sus correspondientes cifrados, se buscan dos bloques que sean muy parecidos, por lo menos en el principio (cabecera incluida) como puede ser una carta dirigida a varios destinatarios donde solo cambia el nombre, aunque con menos parecido también sería válido. Como los bloques han sido codificados con la misma clave, esos bits de información pasarán a ocupar exactamente el mismo lugar y la misma codificación, es decir, se podrá conocer parte de la SBB y de ahí con el la sustitución polialfabética es muy posible llegar a conocer bits de la clave. Conocer varias de las trasposiciones y de las sustituciones polialfabéticas harán que varios bits se puedan descifrar ya de entrada en cualquier mensaje. Para seguir decodificando la clave se me ocurre buscar más coincidencias (ya no importa que los primero caracteres coincidan, sino que coincidan otros caracteres no emparejados) y estadísticamente avanzar poco a poco.
Si el archivo clave mantiene su cabecera, detectando los primeros bytes se puede llegar a conocer muchos otros bytes del principio, lo cual consigue que al menos el cifrado polialfabetico de los bytes que se pretenden enmascarar desaparezca. No hace falta detectar el tipo de archivo, desechando 200 bytes no creo que quede ni rastro de la cabecera.
No tengo problemas en intercambiar ideas, es beneficioso para todos. Te lanzo una idea en un hilo diferente, porque creo que puede tener su atractivo.
Lo de hacer un programa y liberarlo aun tengo mis dudas. Hay que proporcionar a la comunidad antes toda la información y una implementación de prueba para que sea analizado y que se detecten de ese modo errores que se puedan haber pasado por alto. Conseguir que un algoritmo sea aceptado es un proceso largo y tedioso (salvo que ganes un concurso) pero no imposible. Cuenta conmigo para todo en lo que te pueda ayudar.
Vigenere
InMemoriam2 Junio 2005 - 7:17pm
En vez de utilizar la misma clave repetidamente, empieza a utilizar el texto del mensaje a continuacion de la clave como una nueva clave.
Ejemplo:
Mensaje: estoescoserycantarparaloscriptografos
clave: holaestoescoserycantarparaloscriptogr
Quizas te asocie algo si buscas "autokey vigenere" en Google...
-
Dios estaba sobrio aquella noche...
Varias opciones
Envite1 Junio 2005 - 11:32pm
a) comprime el archivo antes de cifrarlo
b) usa una clave más larga, mayor que cualquier posible ristra de ceros
c) cifra varias veces, con claves de distinta longitud
No estoy de acuerdo con lo que dices, pero defenderé con mi vida tu derecho a decirlo.
- Voltaire -
Mejoras
nk27011 Junio 2005 - 10:07pm
I si codificas dos veces el mismo texto? así cuando haya muchos ceros seguidos tampoco se notarà!
El problema es q si los *.doc empiezan todos por los mismos caracteres la cifra pierde toda la gracia, pues todos los mensajes tendran el principio del texto llano igual y deducir a partir de eso la clave dicen q es muy fácil.
Quizá la solucion seria sólo codificar las partes del documento donde haya texto y el resto no se codificara, pues será igual para todos los documentos.
No se si te he ayudado mucho, pero no se me ocurre nada más!
Suerte con tu programa!
NK