Como se ha indicado en la entrada anterior, El funcionamiento de FreeNet es muy similar al de I2P en el sentido de que permite que sus usuarios establezcan conexiones seguras al interior de una gran red de nodos que son utilizados para enrutar trafico entre cada uno de los participantes de la red, brindando un funcionamiento muy similar al de una VPN. Sin embargo existen algunas diferencias, una de las principales potencialidades que tiene FreeNet respecto a I2P, es su capacidad de crear redes privadas al interior de la gran red de routers, estas redes son comúnmente conocidas como “DarkNets internas” y le permite a un usuario definir grupos privados de “Amigos”. Este esquema es sin duda mucho más seguro que permitir que cualquier router pueda contactar con la instancia local del usuario, sin embargo es mucho más lento y el rendimiento es muy pobre, especialmente cuando se tiene pocos “Friends” adicionados en la instancia.
Antes de que un cliente pueda utilizar FreeNet de forma privada (un grupo cerrado de Friends) es necesario cumplir las siguientes premisas:
- Antes de que un usuario pueda crear una “DarkNet interna” tiene que tener por lo menos 5 Friends adicionados para que el trafico pueda ser enrutado por medio de dichos nodos.
- Los Friends son un mecanismo seguro para interactuar con la red de FreeNet por medio de nodos con un nivel de “confianza” mínimo, esto quiere decir, que todo el trafico que viaje desde la instancia local, pasará por medio de dichos Friends.
- Para que el mecanismo de “Friends” funcione, la comunicación debe ser bidireccional, es decir, no basta con que un usuario determinado adicione como “Friend” a otro nodo en la red, el nodo adicionado debe aceptar dicha solicitud de “unión” y para hacerlo debe adicionar como “Friend” al solicitante, de esta forma se garantiza la comunicación bidireccional entre ambos nodos.
- Cuando un usuario adiciona a un Friend y este responde adicionandolo también, ninguno de los dos nodos podrá interactuar y/o ver los Friends que tiene el otro, a menos que sean Friends comunes a ambos.
- Todo el trafico entre los nodos Friends es cifrado, lo que quiere decir que es difícil para alguno de los Friends que enruta el trafico conocer que tipo de información esta transportando, sin embargo no es algo imposible. Por este motivo siempre es recomendable conocer cuales son los Friends por los que viaja el trafico de la instancia o al menos haber hablado en alguna ocasión.
Ahora bien, para adicionar Friends o para conocer los detalles relacionados con la instancia local de FreeNet, es necesario dirigirse a http://127.0.0.1:8888/friends/ desde esta ruta se puede agregar un nuevo contacto, simplemente adicionando su correspondiente referencia en el campo de texto destinado para ello, por otro lado, para que otros contactos puedan adicionar a la instancia local como Friend, también es necesario que conozcan la referencia del nodo, por este motivo al final del enlace anterior se encuentra la referencia del nodo local, la cual debe ser entregada a los contactos adicionados, ya que como se ha dicho, tanto la instancia local como la instancia remota deben tenerse adicionados como Friends de forma mutua para que conexión funcione correctamente.
COMO FUNCIONA FREENET
Como se ha indicado anteriormente, cada nodo en FreeNet reserva un pequeño espacio en disco para almacenar ficheros relacionados con la red, esta zona de almacenamiento es conocida como “DataStore” cada uno de estos espacios de almacenamiento tienen asociada una clave la cual es empleada para recuperar dicho espacio para leer y/o escribir, esta zona de almacenamiento se encuentra distribuida entre sobre todos los nodos conectados en la red de Freenet, por este motivo, FreeNet puede considerarse realmente como una gran dispositivo de almacenamiento distribuido entre múltiples máquinas. Por otro lado, los ficheros almacenados en el DataStore se cifran y solamente pueden ser accedidos por medio de una clave para descifrarlos, los usuarios de cada instancia de FreeNet tienen poco control sobre lo que se almacena en el DataStore, los cuales pueden ser conservados o eliminados de forma automática en función de que tan populares son. De esta forma, para que algo sea borrado de FreeNet, es necesario no buscarlo y esperar que nadie más lo haga, lo cual desde un punto de vista practico es poco viable, es por esta razón que es “resistente a la censura”. El tamaño que ocupa el DataStore depende del tamaño que se desee destinar para ello, sin embargo existen algunas recomendaciones básicas que ofrecen un buen desempeño tanto para el ordenador local como para la red de FreeNet global, estas medidas son:
10% del disco duro si el tamaño de este es <20GB.
5% del disco duro si el tamaño de este es <10GB Y >20GB
512MB si el tamaño del disco es >10GB
256MB si el tamaño del disco es >5GB
Además de lo anterior, cuando un nodo es iniciado por primera vez, este no tiene información alguna sobre los demás nodos que se encuentran en la red, el enrutamiento de todas las peticiones se hace en función a la localización del nodo y de los «peers» que se encuentran más cercanos, tomando como base el valor de punto flotante que se encuentra reservado en el hash del nodo (valor que está entre «0» y «1»). En la medida de que cada nodo almacena y distribuye contenidos (Ficheros almacenados en el DataStore) este mismo nodo adquiere mejor ancho de banda ya que «aprende» a conocer otros nodos que se encuentran en las cercanias (en las siguientes lineas se explicará como es el tema de las claves en FreeNet) comenzarán a conformar clusters de nodos que comparten los mismos ficheros, lo más importante de todo esto, es que la red de esta forma se “auto-organiza” en una estructura de cluster distribuida, posteriormente, en la medida que estos ficheros sean más populares en la red, son replicados sobre cada uno de los nodos que los consultan.
Claves de Ficheros en FreeNet
Como se ha mencionado en lineas anteriores, cada uno de los ficheros almacenados en un nodo de freenet se encuentra replicado en otros nodos que contienen una copia de este mismo fichero (en formato comprimido y en pequeños trozos de 32KB), lo que permite que los contenidos se encuentren descentralizados y accesibles un mayor número de usuarios dependiendo de su popularidad (frecuencia de uso por parte de otros nodos). Sin embargo, para que la información que se almacena en cada nodo pueda ser fácilmente identificable por otros nodos, se utilizan claves FreeNet para los ficheros almacenados, muchas de estas claves son simplemente hashes y no tienen ningún tipo de relación con el contenido del fichero o su “semántica” lo que quiere decir que estas claves no dicen nada sobre el contenido del fichero, en FreeNet, todo se maneja con este tipo de claves, por lo tanto conviene explicar cuales son sus clasificaciones.
NOTA: Aunque a lo mejor resulta redundante para aquellos que entienden lo que es un Hash, es importante para aquellos que no tienen este concepto, saber que un hash, es un procedimiento mediante el cual se convierte una pieza de datos en un número relativamente pequeño que sirve como “fingerprint” identificativo de dicha pieza de información, de este modo, si por algún motivo el contenido del fichero cambia, aunque se trate de un cambio pequeño, el hash del fichero cambia radicalmente.
Los tipos de claves en FreeNet son: CHK (Content Hash Key), SSK (Signed Subspace Key), USK (Updatable Subspace Key), KSK (Keyword Signed Key)
Claves CHK
Se trata del tipo más fundamental (Content Hash key) son ficheros con contenido estático, tales como documentos de texto, vídeos, PDF, etc. Donde la CHK es simplemente el hash del contenido del fichero que identifica de forma única al mismo, se trata simplemente de un fingerprint. De esta forma, no es posible que dos ficheros con contenidos diferentes, tengan el mismo CHK. Este tipo de clave consiste de las siguientes partes:
Hash del fichero.
Clave de Descifrado que permite acceder al fichero en texto legible
Configuración criptográfica usada.
Normalmente las CHK son utilizadas desde FProxy (Se trata de la aplicación web que se inicia automáticamente en el puerto 8888 cuando se inicia FreeNet y suelen invocarse con el siguiente formato:
http://localhost:8888/CHK@hash,clave descifrado,config. criptografica
La clave de descifrado se encuentra almacenada en el interior del fichero, por lo tanto no es posible descifrar el fichero sin la clave CHK correspondiente
Claves SSK (Signed Subspace Keys)
Se trata de claves que se utilizan sobre contenidos que cambian frecuentemente, como por ejemplo sitios web de noticias o páginas web con publicación constante contenidos como blogs. Funcionan de tal forma que se pueden actualizar los contenidos de forma distribuida con un mecanismo de “no repudio” lo que quiere decir, que nadie puede modificar un contenido con este tipo de claves y afirmar que ha sido alguien más quien lo ha hecho. Funciona con criptografía de clave publica, de esta forma el autor de un sitio web puede firmar sus contenidos y solamente la(s) persona(s) que tienen la clave privada podrán realizar modificaciones sobre este contenido.
A diferencia de las CHK, las SSK contienen 5 partes que son:
Hash de Clave Publica: Es el fingerprint del fichero
Clave de Descifrado del Documento: Solamente conocida por los clientes y no por los nodos que almacenan datos, así que ningún nodo puede descifrar estos datos sin la dirección completa, funciona es igual que las CHK.
Configuración criptográfica usada.
Nombre seleccionado por el usuario: Nombre del sitio elegido por el autor.
Versión actual del sitio, este número se incrementa cada vez que existe una modificación en el sitio.
El formato de este tipo de direcciones utilizadas en FProxy es
http://localhost:8888/SSK@hash,clave descifrado,config. Criptografica /NOMBRE_SITIO, 55
Para que este tipo de clave funcione correctamente, se sigue el siguiente procedimiento:
- El autor crea una clave asimétrica (clave publica y privada para firmar el contenido)
- El autor crea una clave simétrica (clave para realizar el proceso de cifrado y descifrado)
- El fichero es cifrado con la clave simétrica y firmado con la clave privada y la firma se almacena en el fichero, Los nodos no almacenan la clave asimétrica, solamente la parte publica de la clave asimétrica, por lo tanto ningún nodo podrá conocer realmente el contenido que esta almacenando ya que no dispone de la clave simétrica para descifrar el contenido.
Claves USK (Updateable Subspace Keys)
Se trata de un tipo de claves que sirven de wrapper para las claves del tipo SSK, de hecho las USK son SSK, solamente que son útiles para enlazar la ultima versión de un sitio SSK, de este modo es mucho más sencillo de utilizar ya que oculta todo el proceso de búsqueda de las últimas versiones de un sitio SSK.
El formato de este tipo de claves es:
http://localhost:8888/USK@hash,clave descifrado,config. Criptografica /NOMBRE_SITIO, NÚMERO
Donde el último número representa el número de la versión. El caso de que este valor sea positivo o negativo, el comportamiento cambia un poco.
Número positivo: El nodo de FreeNet local, mantiene una lista de las versiones que conoce, solamente la versión, los datos pueden estar o no, almacenados en el datastore local, esta lista se actualiza constantemente dependiendo de las ultimas visitas realizadas al sitio. Cuando se busca un número de versión positivo, se busca en la lista local de versiones por dicha versión o superior, en el caso de que encuentre alguna, siempre retornará la superior, mientras tanto, en un proceso independiente en background busca por nuevas versiones que aun no se encuentran incluidas en el listado de versiones local para adicionar dichos números en el registro de USK local.
http://localhost:8888/USK@hash,clave descifrado,config. Criptografica /sitioweb, 10
Lo anterior buscará en el listado la versión 10 o una superior, una vez encontrada dicha versión, inicia un proceso para actualizar el listado local.
Número Negativo:
Al indicar un número negativo como parámetro, se realiza una búsqueda un poco más profunda, dado que intenta obtener las siguientes 4 versión sobre el número de versión indicado en el nodo local y en otros nodos que son conocidos para la instancia local, el proceso de búsqueda se realiza en un ciclo de cada 4 versiones hasta que no se puedan encontrar las 4 versiones siguientes ni en el nodo local ni en ningún otro, de esta forma se garantiza que siempre se va a obtener la ultima versión disponible.
Por ejemplo, suponiendo que se escriba lo siguiente:
USK@hash,clave descifrado,config. Criptografica /sitioweb, -5
El nodo de FreeNet buscará las siguientes 4 versiones (5 … 9) si se encuentra la versión “9” buscará las 4 siguientes (9 … 13). Es ciclo se repetirá de forma consecutiva hasta que alguna de las versiones no se encuentre. Recordar que esta búsqueda se realiza en el nodo local de freenet y el otros nodos conocidos, por lo tanto puede tardar más que la búsqueda anterior indicando un valor positivo.
Claves KSK (Keyword Subspace Keys)
Se trata claves en Freenet que le permiten a un usuario almacenar páginas etiquetadas directamente en la red de freenet (páginas o ficheros de texto plano) su formato es muy simple
KSK@pagina.html
Ahora que se han explicado los principales tipos de claves en Freenet, se puede proceder a explicar como utilizar estos formatos y otras herramientas incluidas en Freenet. Esto se tratará de explicar en la próxima publicación.
Correction: When connecting to freenet, even for the first time, routing is not random. Routing is always done based on node locations. The key (hash) is mapped to a 0…1 floating point number space, and the peer with the closest location to that number is chosen for routing. (the locations of their peers are also taken into account by default) This so-called ‘greedy routing’ is fundamental to the theoretical basis of how Freenet is able to find data at all in the network.
Point of detail: Files are not stored whole on nodes in the network. They are compressed, split into 32 KB chunks, run through Forward Error Correction to double the original size, encrypted, independantly hashed, and finally inserted to nodes all over the network. (using the same ‘greedy routing’ as mentioned above)
Me gustaMe gusta
your corrections are absolutely valid and correct, I have made corresponding changes to the post, as you say, the location of «peers» are made according to the «proximity» of nodes in the same way that files are not stored on freenet as a whole in each node, but are split into small chunks, processed and then inserted.
Thanks for your comment, it was obvious errors and that I had gone completely, will be more careful when posting entries.
Thank you again.
Me gustaMe gusta
Hola adastra, muchas gracias por compartir esta informacion con todos nosotros, queria saber si podria enviarte alguna inquietud acerca el tema de tor, estuve intentando enviarte un correo a la direccion que aparece en contacto pero no me dio, de ante mano muchas gracias!
Me gustaMe gusta
Si, puedes contactar conmigo en la otra dirección de correo electrónico que acabo de poner en la página de contacto, sin embargo si quieres puedes hacer tu pregunta por aquí, ya que probablemente le sea útil a otros lectores que tengan inquietudes similares, como te parezca más cómodo.
Un Saludo.
Me gustaMe gusta