N. del Ed.: Modesto nuestro amigo Asusn61j... Supongo que habrá que agradecerle que piense que aquí están "las mejores mentes del mundo" ;)
Hola. He creado mi propio sistema de encriptación de datos. Aún se encuentra en la fase beta, pero ya he podido crear una aplicación en Java que se encarga de encriptar textos. Estoy trabajando en la aplicación que desencriptará los mensajes.
En fin, me gustaría probar que tan bueno o que tan malo es mi sistema. A continuación presentaré 5 códigos en los cuales está encriptada el año de nacimiento de mi madre. Los 5 códigos tienen el mismo valor pero con caracteres diferentes...
Los 5 códigos representan exactamente el mismo valor. Es probable que alguien logre descifrarlo. De ser así creo que no tendría caso continuar con este proyecto.
Veamos quién lo resuelve...
Recomendaciones
Asusn61j27 Diciembre 2011 - 2:35pm
Muchas gracias por la recomendaciones.
Las tomaré en cuenta para modificaciones futuras. Lo hice en java ya que así aprovecho para desarrollar mis habilidades en el uso del mismo.
De igual forma lo considero el mejor lenguaje de todo el mundo.
Podrías descifrar los últimos 2 dígitos?
Vamos a probar.12d42 en
squirrel27 Diciembre 2011 - 6:56pm
Vamos a probar.
12d42 en hexadecimal es 77122 en decimal. Último dígito es 2. Valor en el dígito 2 es 1. Exponente de un dígito: 2. Resto 77. 77 en binario (conversión par/impar) es 11. Cada bit 1 elevado al exponente 2 da 0, por lo que queda 00.
Aquí surge la primera duda: Si como dices debería dar un 6 (110 en binario) o faltan dígitos o una parte del algoritmo no está clara. Suponiendo que lo que haces es un producto de todos los bits juntos, entonces 11x11=110, pero no está claro que sea lo que pretendías. Aún así, probemos con el último dígito:
EDICIÓN: Tengo el producto en binario muy oxidado. 1x1=1 (resultado por separado 11 = 3 en base 10) y 11x11=1001 (9 en base 10).
deccf en hexadecimal es 912591 en decimal. Último dígito es 1. Valor en el dígito 1 es 1. Exponente de un dígito es 2. Resto es 959. 959 en binario (conversión par/impar) es 111. Cada bit 1 elevado al exponente 2 da 0, por lo que queda 000. Si la variación del dígito anterior que supuse es correcta entonces 111x111 da 1110, o 14 en decimal. Como debería ser un dígito entre 0 y 9, no parece que la suposición sea correcta, con lo cual volvemos al problema de que el algoritmo no está claro.
EDICIÓN: 1x1=1 (resultado por separado 111 = 7 en base 10) y 111x111=110001 (49 en base 10).
Ahora, y dejando de lado el intento de aplicar tu algoritmo, vamos con las consecuencias técnicas:
- Tu algoritmo carece de clave. Sabiendo completamente cómo funciona se puede descifrar cualquier mensaje cifrado, no se necesita nada más.
- Dices que guardar el exponente te permite compactar los números. Sin embargo, eso te limita a números con un único factor (es decir N=a^b) mientras que la mayor parte de los números o bien son primos o no tienen un único factor (es decir N=a^b+c^d+...y^z). También te obliga a trabajar con números realmente grandes (no, 1024 no es un número enorme) si no quieres facilitar el encontrar patrones en tus números.
- Indicas que la aleatoriedad la introduces mediante los exponentes y la cantidad de dígitos. Sin embargo, de momento tu sistema está limitado a que el indicador del exponente debe estar obligatoriamente entre los primeros 10 dígitos de tu número decimal, dado que sólo utilizas un dígito para indicar su posición. Ésto hace que sea impracticable el trabajar con números muy grandes, lo cual nos lleva al último punto.
- Incluso aunque hagas conversiones de formato, al final tu codificación hexadecimal ocupa mucho más que los datos que pretendes cifrar. Si te fijas en otros sistemas, como por ejemplo Blowfish, se procura que el número de bits necesarios para la versión cifrada no sea mucho mayor que la versión en claro. El motivo es simple: Imagina que usaras tu sistema de codificación para cifrar un disco. Si tu disco tiene 100GB, usando tu sistema la capacidad utilizable del disco se quedaría en torno a los 18GB (22/4). Incluso aunque utilices un sistema de empaquetado en binario, sigues necesitando un separador para los diferentes grupos, que también necesita almacenarse.
Un último consejo: Está bien que te guste la herramienta que utilizas para tu trabajo y que la valores, pero no te enamores de ella. Si te gusta Java, estupendo. Aún así, procura aprender algún otro lenguaje e incluso algún otro paradigma de programación. Te hará ser mejor programador y saber ver también las partes menos brillantes de cada herramienta (todas las tienen).
Posibles fallos de tu algoritmo
ray_bradbury27 Diciembre 2011 - 1:22pm
Antes que nada avisar que no tengo un conocimiento de criptografia profundo ni mucho menos. Se me ocurre varios posibles fallos (los cuales creo ya te habran dicho anteriormente, y probablemente mejor, otros usuarios).
1 - Relativo al secreto: Lo unico necesario para descifrarlo reside en el algoritmo. Si se obtiene el algoritmo mediante ingenieria inversa estas vendido, todos los textos cifrados ya no servirian de nada. El analisis del algoritmo, por el hecho de implementarlo en Java, es bastante sencillo. Java al ser precompilado, al igual que todos los leguajes precompilados, facilita mucho el analisis de código.
2 - Relativo a la fortaleza: Igual me equivoco, pero con un texto minimamente extenso un analisis de frecuencia te reventaria el algortimo.
3 - Relativo a la eficiencia: 19 caracteres para cifrar 4 me parecen mucho espacio, no es nada eficiente respecto al volumen de datos cifrado.
4 - Respecto a la velocidad de ejecucion: Al programar en Java se pierde e rendimiento. Es un problema inherente a todos los lenguajes precompilados, que se tienen que interpretar/compilar antes de ejecutarse, y el ordenador 'pierde tiempo' realizando operaciones innecesarias. Es por ello que en caso de buscar velocidad deberias recurrir a lenguajes que NO sean precompilados (c/c++ por ejemplo)
Conclusion:
- El analisis de algoritmos por parte de la comunidad no parte del secretismo, sino de la fortaleza del algoritmo. Los algoritmos mas potentes son publicos y pese a ello (o quizas debido a ello) se consideran seguros.
- No parece demasiado practico. Si fueses a cifrar un CD de datos necesitarias un DVD para almacenar el contenido cifrado.
Como se resuelve...
Asusn61j27 Diciembre 2011 - 7:11am
El numero 406... en hexadecimal, transformado a decimal equivale a 1030.
El ultimo dígito del 1030 es 0. El 0 me indica que en la posición 0 hay algo importante. En la posición 0 esta el número 1. El número 1 me indica la cantidad de dígitos que tiene el exponente máximo que se encendió en la serie binaria. Resulta que el exponente tiene 1 digito, el cual está a la derecha. Ese dígito es 0.
Que me queda? El 3... El 3 es un número impar, por lo tanto un 1. (Si fuese un número par sería un 0).
Ese 1 se eleva al exponente encontrado. El resultado es 1. Cuanto representa 1 en binario? 1...
El primer 1 de 1... que fue el año en que nació mi madre.
936b81
Este numero debería ser un 9. Veamos:
En decimal:
9661313
Ultimo numero: 3.
Numero en la tercera posición: 1.
Maximo exponente encendido: 3
Sobrante: 9661
De pares/impares a 1/0: 1001
De binario a decimal: 9.
Ya tenemos 19....
A ver si alguien descubre lo demás..... Es sencillo.
Lo que sigue es la década de los 60. Solo tengo 19 años y soy aficionado a la programación. Inicié este asunto solo para hacer el algoritmo que haga todo este proceso automáticamente. Saben por qué lo publiqué? Por que he cambiado totalmente el sistema para hacerlo más compacto, seguro y tratar de que se torne un poco más difícil de descifrar.
Por qué guardo el exponente? Se imaginan un número enorme como 1024, sería 10000000000 en binario.
Yo podría compactarlo a: 21030
El mismo valor, 1024, podría ser 12101... Así mismo, el número 2048 sería 21130 o 12111.
Guardo el exponente ya que es fácil reducir un 10000000000 a 10^10, o 2^10 en decimal.
Guardar el exponente en el código es primordial. Guardar la posición del exponente y la cantidad de dígitos me permite manejar la aleatoreidad. Y con las serias modificaciones que hice al formato, se torna más difícil predecir un mensaje codificado en este sistema ya que los valores de cada caracter serán aleatorios para cada codificación.
Ahora señores... necesito opiniones.
Muchas gracias.
Inflación
Agustín26 Diciembre 2011 - 5:29pm
Aparte de la más que probable debilidad del sistema, una inflación de 20:1 = 2000% no parece una característica envidiable, sobre todo si uno tuviera necesidad de cifrar ficheros grandes.
Algoritmo
Asusn61j26 Diciembre 2011 - 5:11pm
La solución no es 1954.
Si muestro el algoritmo pues estaría entregando el secreto. Lo que puedo hacer es terminar la aplicación java que encripta y desencripta y publicarla para que se le hagan las pruebas.
Aclaro que uso hexadecimal y binario, pero no uso ASCII. Estoy trabajando en el la aplicación final que publicaré muy pronto a través de este medio para que sea testeada.
Saludos.
Un buen sistema de cifrado es
squirrel26 Diciembre 2011 - 6:49pm
Un buen sistema de cifrado es aquel que hace casi imposible el descifrado cuando se desconoce la clave, incluso aunque se conozca el algoritmo. Si no es simplemente seguridad por oscuridad: Si descubren cómo funciona (y si lo haces en Java es incluso más fácil "desensamblar" el ejecutable y verle las tripas) toda tu seguridad desaparece.
Vamos, que si, por poner un ejemplo, tu algoritmo fuera algo en plan "cojo un número aleatorio de 32 bits, lo convierto a hexadecimal, lo incorporo a la salida y como quinto byte hago el XOR del byte menos significativo del número aleatorio con el byte del mensaje a cifrar" entonces tendrías una seguridad nula, por mucho que enrevesaras/ofuscaras el código de tu programa.
Como dice Bruce Schneier, cualquiera puede hacer un sistema de cifrado que él mismo no pueda romper. Lo difícil está en hacer un sistema de cifrado que los demás tampoco puedan romper.
Sobre sistemas seguros...
JRBAMASTER28 Diciembre 2011 - 12:42am
...podrían escribirse varios libros.
Estos principios fueron enunciados en 1883. Nótese que según esto, no debe ocultarse el sistema. El segundo principio, que al parecer es lo que se discute aquí, lo reescribió Claude Shannon sesenta años después:
Saludos desde Chile.
JRBA
Y hay algo aún más difícil
admin26 Diciembre 2011 - 6:58pm
Que los demás se interesen por romperlo.
Si el creador demuestra desde el principio que no sabe de lo que habla... si utiliza frases grandilocuentes y promesas que no se sostienen... si basa su eficacia en el secreto del algoritmo y no de la clave... las posibilidades de que alguien se moleste en romperlo son nulas.
De donde nace un peligro mucho más grande: que el pardillo se piense que ha creado algo indestructible.
Amigo
admin26 Diciembre 2011 - 5:18pm
Con respuestas como ésta lo menos que puedo decirte es que te caes de portada.
solu
DrDoom25 Diciembre 2011 - 1:34pm
La solución es: 1954
algoritmo
anv25 Diciembre 2011 - 11:24am
Si quieres saber si tu sistema de encriptado es bueno, tienes que mostrar cómo funciona el algoritmo.
Si no publicas eso estarás basandote en el desconocimiento como método para ocultar tus datos y es bien sabido que no es buena política. A la larga siempre sale mal.
Si conociendo el algoritmo nadie consigue descifrar tus mensajes entonces sabrás que el sistema es bueno.
Además, para un buen ataque hacen falta muchos mensajes encriptados o un mensaje muy largo. Cosa que en la vida real, si usasa tu sistema, el atcante terminrá consiguiendo.