Hola a todos,
Haciendo una referencia al primer post que puse, me indicaron que el cifrado AES tenía un alfabeto muchísimo más extenso que codificar un sistema de cifrado sobre los 256 bytes de la tabla ASCII.
Mi pregunta es la siguiente:
Dado que el almacenamiento físico de los caracteres cifrados depende del soporte del sistema operativo (los 256 bytes) o combinaciones de bytes si se usa Windows por la compatibilidad de las tablas de caracteres de cada idioma o el sistema unicode (que desconozco), un sistema de cifrado con un alfabeto tan extenso tiene que ajustarse a los caracteres físicos existentes y cada uno de los elementos de su alfabeto no puede ser diferente, sino que consistiría en repeticiones de los caracteres a emplear, generados por un algoritmo y con la clave introducida seleccionar el caracter repetido que corresponda al cifrado/descifrado hasta finalizar con todos los caracteres con los que se desee operar. No conozco mucho los distintos sistemas criptográficos, pero me parece deducir que AES puede estar basado en el Sistema de cifrado de Hill, el mismo en que basé yo el algoritmo que desarrollé (Cifrado PSA).
Por poner un ejemplo más sencillo, por si no he sabido explicarlo con la suficiente claridad, sería lo siguiente:
Los caracteres básicos para escribir son 26 letras (27 con la ñ) y 10 dígitos (0-9). Eso hace un total de 36-37 elementos. Supongamos que la tabla ASCII de nuestro PC sólamente dispone de esos 37 elementos para almacenar archivos en el disco duro. Si queremos cifrar un texto, podremos complicar todo lo que queramos el método de cifrado, pero siempre tendremos que utilizar esos 37 elementos para codificarlo y almacenarlo. Si "inventamos" elementos nuevos en el sistema de cifrado, empleando 1 o más bytes, serán elementos generados que representen una serie de repeticiones de esos 37 elementos, lo que nos lleva igualmente al Sistema de Hill. ¿No es cierto?
Agradecería vuestros comentarios sobre este asunto.
Me gustaría saber si hay alguna persona o entidad que pueda probar la seguridad del algoritmo que registré, me parece que es muy bueno y quisiera testarlo. También podría proponer un "ejercicio" y publicarlo en otro post, si os parece bien.
Gracias a todos.
Archivos Binarios :)
Xero Cool8 Abril 2005 - 12:01am
Con archivos binarios y programación assembler se puede jugar con los registros e intercambiar los bits unos con otros, ademas se pueden utilizar punteros e índices para agregarle ese bit extra que quieres, pero antes se tienen que convertir el archivo a binario, C++ puede hacerlo muy facilmente incorporando código assembler a su definición de registros y asi trabajarlos como números binarios.
Esto ya esta probado, pero solo con archivos de texto.
Además puedes encriptar tu código utilizando funciones matemáticas reversibles (o sea que se tienen que utilizar funciones biyectivas). Ej: xor, add, neg, etc.
Redundancia
Shevek4 Abril 2005 - 4:20pm
Lo que quieres decir es que cifrar texto plano (alfabeto de 37 elementos o hasta 64, si contamos signos de puntuación y mayúsculas) con un alfabeto de 2^128 elementos es una pasada.
Bueno, realmente NO se cifra letra a letra, sino que se cogen bloques de 16 letras y se cifra cada bloque.
Lo que sí se supone, es que cada letra se codifica con 8 bits (256 valores); puesto que cada letra de texto plano usa aprox. unos 6 bits de información (64 valores), hay dos bits de redundancia por cada letra.
Si tu sistema de cifrado está bien construido -y AES lo está- esta redundancia supone una debilidad muy relativa.
Por si acaso, la mayoría de las implementaciones lo que hacen es comprimir previamente el texto plano; esta compresión transforma grosso modo n símbolos de 6 bits en 3n/4 símbolos de 8 bits, con lo que la redundancia desaparece.
SKS, criptografia de curva elíptica de bolsillo
http://pagina.de/sks