Hay conceptos con los que nos topamos en multitud de ocasiones y que en realidad no entendemos plenamente cuál es su razón de ser. A veces incluso podemos encontrarnos ante un caso en el cual utilizamos un método (como puede ser el hash objeto de este post) sin darnos cuenta dada su transparencia respecto a sus usuarios.
En un mundo en el cual la transmisión de archivos (con sistemas tan utilizados como puede ser los basados en tecnología P2P), la firma de contratos electrónicos (de los que nos interesa estar seguros de la integridad y no modificación de los mismos después de haber sido suscritos por usuarios) y la transmisión de datos de los cuales queremos estar seguros de su no modificación (por aplicación de tecnologías de criptografía por ejemplo) las tecnologías hash resultan importantes.
Muchas empresas están comenzado a incluir funciones de hash a la hora de almacenar los contratos que ha realizado por vía electrónica, con tal de garantizar la no modificación de forma similar a lo que sucedía con los contratos en papel (pensemos que un archivo electrónico sobre el cual no realizamos ninguna actuación puede ser modificado de tal forma que no sea visible de forma más sencilla a lo que sucede con sus homónimos en papel).
Por estas razones puede ser buena idea comenzar por comentar, desde un punto de vista básico, a qué nos referimos cuando hablamos de hash.
El hash es una palabra que aparece mencionada en ámbitos tan importantes como puede ser la criptografía o la firma digital, pero afirmar esto no nos aclara nada sobre su verdadera función. Ello resultará mucho más sencillo si realizamos un acercamiento no técnico inicial, sobre el cual podemos realizar un juego. Para empezar, debemos tener en cuenta que el hash tiene una longitud constante, que en nustro ejemplo será de una palabra. Así, con qué palabra indicaríais a una tercera persona qué foto viene a continuación?
Si téneis únicamente una palabra, supongo que escogeréis elefantes (que es la más evidente). Si se os permitiese una palabra más, a lo mejor diríais «dos elefantes». Cuando a la otra persona le llegasen dos fotos, y en una de ellas no apareciesen dos elefantes, sabría perfectamente que no nos referíamos a ella. Para ser más efectivos podríamos utilizar un algoritmo (al que denominaremos función hash) más trabajado (aunque aún no entrando en cálculos matemáticos propiamente dichos), creando un número de 3 dígitos de acuerdo con las siguientes reglas:
-
El primer dígito será el tipo de animal (los elefantes son el 2)
-
El segundo dígito será el número de animales presente en la foto
-
El tercer dígito sería el color que predomina en el fondo de la foto (el verde sería el 1 p.ej.)
Ahora podemos dar la misma información que daríamos con «dos elefantes con un fondo verde» dando sencillamente el valor 221 fruto de nuestra función hash. Este cálculo se realiza de forma rápida y sencilla. Ahora bien, qué sucedería si la foto que él ve es la siguiente:
Si aplicamos la función hash que habíamos aplicado a la foto anterior obtendríamos también 221. Podríamos ampliar el número de dígitos con nuevos datos que nos facilitase su identificación inequívoca, pero seguiremos llegando a fotos muy similares que contarán con el mismo hash. Este hecho recibe el nombre de colisión, que implica que dos archivos de origen producen el mismo hash de resultado (y del cual podemos leer más en el siguiente enlace, o en este otro al respecto específico de la generación de dos documentos con el mismo hash). Gracias a estos ejemplos podemos observar uno de los usos que una eventual función hash puede tener: el localizar elementos similares (como pueden ser fotos parecidas dentro de una Base de Datos de imágenes).
En casos sencillos podemos utilizar páginas web como ésta para obtener el resultado inverso (es decir, a partir del hash de una palabra, obtener de qué palabra estamos hablando). Podemos poner como ejemplo el hash md5 de mi nombre, Sergio, que tiene el siguiente formato:
3bffa4ebdf4874e506c2b12405796aa5
Si ponemos este hash en la página web, obtenemos que la palabra original era Sergio. Esta longitud (podemos observar como resulta más largo que la palabra original) responde a la búsqueda de eviar duplicidades indebidas. Si hablamos de principios puramente teóricos, el deseo sería poder encontrar una función totalmente inyectiva (es decir, a diferentes entradas, diferentes salidas). No obstante, esto resulta bastante complicado de obtener, pudiendo encontrar en algunos casos como la aplicación de una función hash es capaz de producer un número infinito de colisiones (basta con que reduzcamos un único bit el archivo de origen para producir el hash para ver que se pueden producir colisiones). Ahora bien, la realización práctica de estas colisiones (siendo además necesario realizar esta duplicidad antes del período de expiración, en caso de tenerlo) resulta más complicado.
Ahora bien, la existencia de estas colisiones (tal y como viene relatado en el ejemplo de uno de los anteriores enlaces) puede crear situaciones bastante peculiares. Podemos empezar con el almacenamiento de los contratos electrónicos que realizan algunas empresas. Pensemos en lo que sucede en el caso de que en una Base de Datos se almacene únicamente el hash del contrato y los datos de la persona que lo ha suscrito. A primera vista podría parecer suficiente, pero si añadimos la vulnerabilidad conocida de estos algoritmos (y más en origen a la hora de generar por ejemplo dos contratos con el mismo hash) podemos comenzar a tener nuestras dudas. Cómo estar seguro de que consta que hemos suscrito un contrato en particular y que la otra parte no afirmará que el contrato que hemos suscrito es muy diferente (aportando el hash como prue
ba)? Más preocupante es aún el caso en que se almacenan estas dos variables (los datos correspondientes al contrato y los datos correspondientes al usuario) por separado, sin crear un hash del contrato con los datos del usuario y la fecha incorporados (con tal de garantizar un poco más la seguridad del eventual usuario). Pensemos en lo sencillo que resultaría variar en este caso un simple campo de la BBDD, sin necesidad de tan siquiera molestarnos en crear dos documentos con el mismo hash (variamos el valor del «contrato suscrito» y dado que no hay ningún campo que dependiese del correo electrónico, nombre, DNI u otro dato del usuario, tendríamos un grave problema de seguridad desde el punto de vista legal). A quién daría la razón el Juez?
Por supuesto, hay mecanismos para solventar estos problemas, y no todas las implementaciones han sido tan ruinosas como el peor de los escenarios que yo he planteado. Ahora bien, hay que tener en cuenta que el utilizar un mecanismo como éste (o el candadito de los navegadores) no implica que nos encontremos directamente en una situación plenamente segura jurídicamente hablando.
