el código indescifrable II

Hace tiempo rumiaba que la única forma totalmente segura de cifrar un archivo de 8 "letras" era con una clave de 8 "letras". Es decir, la clave tiene que ser tan larga como los datos, ya que es la única forma de que las posibilidades de descifrado sean infinitas, infinitos mensajes descifrados correctamente con parte de las infinitas claves, obteniendo textos o datos legibles entre los cuales será imposible determinar cuál es el bueno.

Algunos programas de ordenador comerciales utilizan códigos para evitar la piratería o para que el cliente pueda actualizar su producto. Estos códigos a veces se introducen a mano, y otras veces vienen proporcionados en un archivo, para mayor comodidad evitando tener que teclearlo, pues suelen ser muy largos.

Ahí está la solución: no podemos memorizar una clave de -pongamos- un millón de caracteres, ni nos cundiría en tiempo introducirla, pero podemos utilizar cualquier fichero del ordenador que sepamos que no va a alterarse como clave: un documento de texto, un ejecutable EXE, una DLL...
De este modo podemos tener claves tan enormes como el tamaño en Kb del fichero, sin necesidad de memorizar nada más que la situación y nombre de ese fichero en el disco duro.

Por supuesto esto no sustituye al password tecluscrito, sino que lo complementa. Si el intruso se hace con el algoritmo de encriptación (damos por hecho que es un crack de la informática y tiene medios y conocimientos para sacar todas las entrañas del ejecutable de nuestro programa encriptador) y sabe o sospecha que la clave está en algún fichero dentro del mismo ordenador, se lo dejamos tiradísmo: el descrifrado por fuerza bruta será mucho más sencillo que si el código fuera una clave normal y corriente, ya que el número de ficheros en un disco duro es muy limitado en comparación con las combinaciones de una clave decente: sólo tendría que atacar probando con todos los ficheros del ordenador hasta que salga el correcto. Cuando tenga el fichero, tendrá a la vez los 8 millones de bits de la clave.

Por tanto, nuestra clave se introduciría de esta manera:

PASSWORD:> C:\windows\bin\CLULSE.DLL 1a2b3c4d5e

Como vemos la clave consta de dos partes: un fichero de claves dentro del ordenador y una clave manual alfanumérica que únicamente está guardada en nuestra memoria sesuda.

Suponemos que el archivo CLULSE.DLL ocupa 2 Megas. Es un archivo que no nos sirve para nada, pero es real, quizá de un programa que no utilizamos o hemos borrado, o ese intruso al que no se le escapa ni una podría sospechar de un fichero .DLL que no tiene el encabezado de un DLL auténtico. Porque no, no vamos a esconder la llave debajo del felpudo, ni en la caja fuerte, ni al final de un pasillo repleto de robots asesinos... todo eso es ayudar al intruso a saber dónde buscar: la llave tiene que estar visible, pero sin forma de llave, y debe de estar mezclada con otros miles de objetos variopintos.
Podremos encriptar con este DLL en concreto archivos de hasta 2 megas interaccionando cada bit del archivo con cada bit del DLL sin que en ningún momento haya que reciclar datos.

El algoritmo sería muy sencillo, teniendo una clave tan larga, y además... BINARIA lo que aumenta la complejidad al no restringirla a los caracteres manejados por los humanos, que se reducen a los introducibles cómodamente desde un teclado... bastaría con simples operaciones booleanas de bit de forma secuencial, ganando en velocidad de encriptado y desencriptado.

Por ejemplo:
Tomamos en primer bit del fichero de clave y hacemos una operación de conjunción (AND), disyunción (OR) o exclusión (XOR) con el primero de la clave manual complementaria; el bit obtenido lo llamaremos X. Con X volvemos a hacer otra operación lógica con el primer bit del fichero a encriptar o desencriptar... y vamos grabando.
Ahora volvemos a aplicar lo mismo pero partiendo ésta vez de el anterior valor de X: operación con el siguiente bit del fichero de clave, su resultado lo operamos con el siguiente bit de la clave manual, y obtenemos un nuevo X para operar con el bit que venga del fichero a encriptar.

Los bits de la clave manual se terminarán rápido, porque será una palabra corta asequible para nuestra memoria y el tiempo que requiere teclearla, y tendremos que volver a recliclarla desde el principio; pero ahí seguirá de fondo el fichero de clave con sus millones de bits para evitar que se repitan patrones.

Pegas:
1. Como siempre la máxima debilidad es que en un momento dado el documento sin desencriptar residirá en el disco duro y, aunque se borre, existen programas para recuperar datos borrados del disco duro.

• Solución 1: También existen programas para borrar lo que ya está borrado, definitivamente.
• Solución 2: Complementaria a la anterior: el propio programa de encriptado-desencriptado permitirá visualizar -e incluso redactar- el documento guardándolo en la RAM (memoria que se desvanece al apagar el ordenador), no usando jamás el disco duro para soportar ninguno de los datos delicados. Podría ser un procesador de texto -para el caso de encriptaciónd e textos- con el codificador integrado. Esto es lo que tengo hecho desde hace años: aprovechando las fuentes libres de un procesador de textos en C, añadí el encriptador y los menús pertinentes. De este modo escribo en el editor y guardo el archivo ya encriptado en el disco duro, el texto desencriptado nunca pasa por el disco duro... en teoría... porque tampoco tengo la certeza de que el programa no se valga del disco duro en algún momento para ficheros temporales. En la medida de que el procesador se basa en windows... esas cosas las controlará el propio sistema operativo más allá del código en C del programa. Mis conocimientos no llegan hasta tanto, de hecho yo no sería capaz de programar el propio procesador de textos por mí mismo si no es copiando y pegando código.
  

2. La posibilidad de que el sistema operativo marque la fecha de última utilización en el archivo del fichero de claves, dando al intruso pistas sobre qué ficheros del disco duro tienen más probabilidad de ser los que busca.