A DC-Net allows parties to communicate anonymously in a point-to-point network. Even though DC-Nets where proposed by Chaum (CACM 1985) more than thirty years ago, only lately the protocol has gained more attention because of both e ciency improvements in point to point communication, and several attacks discovered in onion routing, the most popular anonymous protocol. This work describes an implementation of a practical variant of DC-Nets (proposed by Franck, Hevia, and van Der Graaf 2016) which includes a useful API. Preliminary experiments indicate that the protocol is better suited for non-interactive applications such as an anonymous bulletin board. We indeed implement such a mobile app and discuss possible extentions.
Mantener el anonimato navegando en Internet se ha vuelto una demanda signi cativamente mas popular en los ultimo an~os. Usuarios de todas las latitudes reclaman que se respete su derecho a la privacidad1; posiblemente como consecuencia de las revelaciones realizadas tanto por el grupo Wikileaks como por el ex-empleado de la CIA Edward Snowden. Estas revelaciones ilustraron el masivo monitoreo por parte de organismos de inteligencia2 a la actividad diaria de millones de personas que hacen uso de la red. Bajo ese panorama, se ha hecho necesario contar con herramientas que aseguren el anonimato en la red. Sin embargo, garantizar anonimato ante adversarios so sticados requiere dos condiciones: (1) uso y testeo masivo por parte de un signi cativo numero de usuarios, y (2) garant as matematicas (criptogra cas) de la seguridad del protocolo que se esta utilizando.
El software mas popular y utilizado para permanecer anonimo mientras se navega en Internet es TOR \The Onion Router"3. Onion-routing [GRS96], el protocolo implementado por TOR, ha sufrido recientes cuestionamientos, tales como si es o no realista suponer que el adversario no es capaz de monitorear todos los canales de comunicacion { uno de los supuestos mas cruciales de TOR. La pregunta es sin duda razonable dada la extensa capacidad de monitoreo que poseen organismos de inteligencia para con todos los usuarios de Internet4. Aun as , en la practica TOR sigue siendo la herramienta mas popular para navegar de manera anonima en Internet, siendo incluso recomendada por el mismo Snowden5 para evitar las intromisiones de la NSA y otras organismos similares. Dado que concentrar nuestra privacidad en una sola herramienta puede ser riesgoso, se hace necesario evaluar la factibilidad de protocolos alternativos que toleran adversarios globales (capaces de monitorear todos los canales de comunicacion) tales como las DC-nets. Este trabajo busca aportar en este estudio de alternativas. 2 2.1
El problema de la Cena de Criptografos (Dining Cryptographers Problem) fue propuesto por David 3https://www.torproject.org/ 4http://apps.washingtonpost.com/g/page/world/ nsa-slideshow-on-the-tor-problem/499/
5http://www.inc.com/larry-kim/ 5-online-privacy-tips-from-edward-snowden.html Chaum en el an~o 1985 [Cha85, Cha88] para ejemplicar un protocolo de env o de mensajes de manera anonima entre un grupo de participantes.
El problema es el siguiente: tres criptografos estan cenando en su restaurante favorito. Al terminar la cena, el mesero se acerca a su mesa y les informa que el ma^tre indica que su cuenta ya esta pagada. Los criptografos, sorprendidos, quieren resolver si la cuenta fue pagada por alguno de ellos, o si simplemente fue pagada por algun agente externo (la NSA, por ejemplo). Obviamente, como buenos criptografos, desean que su protocolo no revele la identidad del criptografo pagador (si existiera) pero al mismo tiempo permita dilucidar si uno de ellos pago o fue un agente externo. Luego de pensarlo, el problema es resuelto con el siguiente protocolo:
(1) Cada uno de los criptografos lanza una moneda al aire, de forma secreta. Luego de esto, le muestra la moneda al compan~ero que esta inmediatamente a su derecha. (2) Cada criptografo informa al resto si las dos monedas que puede ver (la propia y la de su compan~ero a la izquierda) son iguales o no, pero con una condicion: si el criptografo viendo las monedas no pago la cuenta, simplemente dice la verdad. Si no, si no fue el (o ella) quien hizo el pago, el criptografo revela lo contrario a lo que ve (si eran iguales dice que eran distintas y viceversa). (3) Si un numero impar de criptografos revela que las monedas eran distintas, implica que fue uno de ellos quien pago la cuenta, de lo contrario signi ca que la NSA fue la que realizo el pago.
En el art culo original se demuestra que este protocolo (posteriormente rebautizado como DC-Net ). brinda anonimato incondicional: aun si un atacante tuviera todo el poder de computo posible, le es imposible poder identi car al emisor del mensaje. Este anonimato se mantiene tanto para todos los participantes del protocolo como para cualquier observador externo.
Con lo anterior, Chaum brinda un protocolo que hace posible transmitir mensajes publicos de manera anonima. Chaum tambien propuso algunas variaciones, tales como protocolos que permiten enviar mensajes de largo arbitrario. 2.2
Existe una generalizacion practica para utilizar el protocolo DC-Net con mensajes de largo mayor a 1 bit. En vez de manifestar un bit (pago o no la cuenta), cada participante env a un mensaje (cadena de bits) arbitrario. Ademas se reemplaza el lanzamiento de una moneda vista entre dos participantes con una llave aleatoria compartida entre ambos participantes. Por ultimo, en vez de reemplazar el mensaje enviado dependiendo de que valor tomo la moneda (el \O Exclusivo" o XOR entre el mensaje y el valor de la moneda), el mensaje a enviar y las llaves compartidas que posee el participante son sumadas modulo un valor jo su cientemente grande.
En la practica, primero es necesario establecer el anonymity-set, esto es, quienes seran los participantes del protocolo, los responsables de enviar y aportar con sus mensajes para asegurar el anonimato del potencial emisor. Luego, se utiliza una ronda de compartimiento de llaves, donde cada par de participantes comparten una llave secreta (este proceso podr a realizarse utilizando protocolo Di e-Hellman). Una vez que todos poseen llaves compartidas entre s , cada uno de los participantes enviara uno de los dos siguientes mensajes al resto: un valor K igual a la suma de las llaves que posee compartidas, o un valor K + M igual a la suma de las llaves que posee compartidas mas un mensaje M que quiere enviar de manera anonima. Con esto, cada participante env a un valor m = K si es que no quiere transmitir nada y solo quieren aportar en el anonimato del resto, o m = K + M si es que s desea enviar un mensaje M . Finalmente, cada uno de los participantes suma los valores que recibio, lo que hara que las llaves compartidas se cancelen y solo quede visible el mensaje que compartio uno de los participantes. De esta manera, el emisor se mantiene anonimo tanto para el resto de los participantes como para cualquier observador externo que monitoree todos los valores intercambiados en el protocolo. 2.2.1
Lo anterior funciona siempre y cuando a lo mas un participante env e un mensaje. A priori, no es claro que los participantes puedan ponerse de acuerdo respecto a quien de los participantes enviara el mensaje, sin violar el anonimato del protocolo. Por ello, una colision de mensajes { esto es, el env o de un mensaje por parte de dos o mas participantes { es normal en la ejecucion de una DC-Net. Cuando una colision ocurre, al realizar la suma los valores enviados por todos los participantes, las llaves se cancelan resultando la suma de los dos (o mas) mensajes enviados. Dado que este valor es t picamente un mensaje ininteligible, una colision implica un fracaso en la transmision de los mensajes involucrados. Esto es un problema conocido. Varias implementaciones y disen~os propuestos han buscado hacerse cargo y resolverlo para poder permitir el env o de varios mensajes en una misma iteracion. 2.2.2
Otro aspecto importante de la seguridad de los protocolos basados en DC-Net es su tolerancia a los participantes maliciosos. Tales participantes env an mensajes erroneos { que no se ajustan al protocolo acordado { o omiten enviarlos cuando debieran. Si es que no se evita este comportamiento, podr a resultar en un protocolo erroneo, que nunca concluya con un mensaje transmitido, o bien que entregue mensajes equivocados. Afortunadamente, la mayor parte de los protocolos resuelven este problema integrando primitivas criptogra cas al env o de los mensajes. 3
Este trabajo se basa en una variante practica del protocolo DC-Net propuesta por J. van de Graaf y Christian Franck [FvdG14], que hace uso de primitivas criptogra cas (Pedersen commitments y zeroknowledge proofs principalmente) para sortear los problemas de colision de mensajes y participantes maliciosos.
El disen~o que se explicara a continuacion es un trabajo en curso realizado en conjunto con los autores antes mencionados, y se omitiran los detalles correspondientes a demostraciones de seguridad, debido a que lo importante a destacar son los desaf os que implican realizar la implementacion del protocolo.
Sea Gq un grupo de orden q, en donde el problema del logaritmo discreto se crea dif cil de resolver. Sean g; h generadores de Gq elegidos aleatoriamente. Sea s 2 Zq un secreto que no se desea comprometer. Ademas sea r 2 Zq elegido aleatoriamente. Se le llama un Pedersen commitment sobre s al valor: s r c := g h
Los Pedersen commitments brindan dos propiedades importantes: ocultamiento perfecto (unconditionally hiding ) y vinculacion computacional (computationally binding ). Esto quiere decir que, si una persona calcula un commitment sobre un cierto valor s, (1) la persona se compromete a dicho valor (pero sin revelarlo), ya que, por un lado es imposible para un tercero conocer s a partir de c, y (2) es computacionalmente dif cil demostrar que dentro de c existe un valor distinto a s. 3.1.2
Una zero-knowledge proof permite a una persona poder demostrar el conocimiento de cierto valor que cumple una propiedad (en Ingles, statement ), sin revelar el valor de (el testigo) en esa demostracion. Se pueden construir demostraciones para diferentes tipos de propiedades (statements ), como por ejemplo: el conocimiento de un logaritmo discreto; la igualdad de diferentes logaritmos con distintas bases, ademas de combinaciones con operadores logicos, entre otros. Ademas existen maneras para poder demostrar propiedades genericas sobre logaritmos discretos [CS97]. 3.2
El protocolo comienza con cada participante Pi intercambiando dos valores kij ; rij con cada otro participante Pj dentro del anonymity-set. Ademas se establece que kij = kji y kii = 0 ( dem para r). Finalmente cada participante Pi calculara el valor Ki = Pjn=1 kij , donde n es el numero total de participantes ( dem para calcular ri). 3.3 3.3.1
Cada Pi calculara cKi = gki hrKi (commitment sobre Ki). Luego de esto debera enviar al resto de los participantes cKi junto con una PoK 6 indicando que conoce los valores (Ki; rKi ) dentro de cKi .
Al recibir los commitment y las PoK de cada participante Pi, se deben veri car cada una de las PoK, ademas debe comprobarse que Qn i=1 cKi = 1 (propiedad que se tiene debido a que las llaves deben cancelarse unas con otras). De no tenerse esta ultima propiedad (lo que signi ca que al menos un participante envio valores erroneos), existen maneras que permiten encontrar al participante malicioso en cuestion. En la actual implementacion se priorizo encontrar participantes maliciosos en etapas subsecuentes del protocolo, debido a que un participante malicioso en esta etapa no puede comprometer el anonimato que brinda el mensaje, sino simplemente retrasar el desarrollo del protocolo. 3.3.2
Cada participante Pi debe establecer tres valores distintos (dependiendo si enviara o no un mensaje): mi: mensaje plano que enviara el participante. Si no enviara ningun mensaje, mi = 0. padi: cadena aleatoria de bits que se utiliza para reducir la posibilidad de enviar dos mensajes iguales (mas adelante en el protocolo se explicara su uso). Si no enviara ningun mensaje, padi = 0. bi: bit estableciendo si se enviara o no un mensaje, bi = 1 si se enviara un mensaje, 0 si no.
6Proof of Knowledge es una Zero-Knowledge Proof donde el participando demuestra el conocimiento de un cierto valor dentro de un statement, sin revelar dicho valor.
Luego de establecer estos valores, cada Pi formara el mensaje Mi, que resulta ser una concatenacion de los 3 valores anteriores (la concatenacion de valores 0n es para prevenir que se produzcan over ow al sumarlos posteriormente):
Mi = 0n jj mi jj 0n jj padi jj 0n jj bi
Posteriormente cada Pi debera escoger 3 valores aleatorios: rmi ; rpadi y rbi , para luego calcular commitments sobre los 3 valores anteriores: cmi ; cpadi y cbi (utilizando como valores aleatorios los escogidos previamente). Con estos commitments cada Pi debera realizar una demostracion de que el mensaje Mi esta bien formateado, esto es que: \el ultimo bit es 1 o el ultimo bit es 0 al igual que todo el mensaje" (bi = 1 _ (bi = 0 ^ mi = 0)). Se env a al resto de los participantes los 3 commitments calculados junto con la demostracion anterior.
Posteriormente se veri can las demostraciones enviadas por cada uno de los participantes. 3.3.3
El proximo paso es enviar una PoK sobre el mensaje Mi. El punto importante a destacar aqu es que no se env a un commitment asociado a Mi, sino que este se calcula en base a los 3 commitments enviados anteriormente cmi ; cpadi y cbi . Por ello cada Pi env a la PoK correspondiente, y es veri cada por el resto de los participantes calculando el commitment correspondiente. 3.3.4
Finalmente cada Pi formara el mensaje de salida Oi = Mi + Ki. Al igual que antes, debe ademas crear una PoK sobre Oi en el commitment cOi (que tambien se puede calcular como funcion de los commitments anteriormente enviados). Se enviara el mensaje Oi junto con la PoK correspondiente y sera revisada por el resto de los participantes. 3.4
Todos los participantes enviaron su respectivo mensaje de salida Oi, los cuales deben ser sumados entre todos formando el valor C1 = (M ; t) = Pn i=1 Oi (M es la suma de los valores mi y padi de todos los participantes, mientras que t corresponde a la suma de cada uno de los valores bi). Teniendo estos valores, se pueden producir tres casos: 1. t = 0: Ningun participante quiso enviar un mensaje, por lo que el protocolo naliza. mensaje, el cual fue recibido por todos los participantes y se mantiene el anonimato de su emisor.
El protocolo naliza. 3. t > 1: Dos o mas participantes enviaron un mensaje, por lo que se ha producido una colision de mensajes (M consiste en la suma de varios mensajes mi). Para resolver esto se correra un protocolo de resolucion de colisiones basado en superposed-receiving [Wai89] explicado a continuacion. 3.5
Para resolver la colision, la idea principal es correr nuevamente el protocolo pero solamente un subconjunto de los participantes que tienen su mensaje involucrado en la colision enviaran mensajes. Para ello se calcula el valor M = M =t. Si el mensaje Mi < M , entonces se reenviara en la ronda 2k (donde k es el numero de la ronda donde se produce la colision). En caso contrario se reenviara en la ronda 2k + 1.
Una parte importante de superposed-receiving es que la ronda 2k + 1 puede ser calculada como funcion de los mensajes enviados en las rondas k y 2k de la siguiente manera: C2k+1 = Ck C2k. Por ello las rondas 2k + 1 se le llaman rondas virtuales, y las rondas 2k se llaman rondas reales. De esta manera se disminuye la cantidad de rondas reales a realizarse para la resolucion de las colisiones.
De esta manera, en las rondas subsecuentes la cantidad de mensajes involucrados ira disminuyendo, haciendo que posibles colisiones que se produzcan (que se resuelven recursivamente de la misma manera) sean menores, implicando que despues de t rondas reales se habran enviados los t mensajes involucrados en la primera colision. Importante a destacar es que en las rondas siguientes deben enviarse PoK indicando que el mensaje que se env a en dicha ronda es el mismo que estuvo involucrado en alguna colision anterior (o se env a un mensaje vac o).
Con esto, al enviarse los t mensajes involucrados en la primera colision, el protocolo naliza y todos los participantes pueden ver que su mensaje fue enviado y se mantiene su anonimato frente tanto a los otros participantes como a observadores externos que vean el desarrollo del protocolo de manera pasiva. Como fue dicho anteriormente, el disen~o de este protocolo es un trabajo en curso, por lo que mayores detalles de demostraciones de seguridad se estan actualmente investigando y preparando una publicacion mas espec ca. 4
2. t = 1: Solamente un participante envio un mensaje, por lo que el valor M corresponde a ese El objetivo principal de este trabajo viene siendo la implementacion del protocolo explicado anteriormente como API, de manera tal que pueda ser utilizado en variadas aplicaciones que necesiten contar con un protocolo de mensajer a anonima entre varios participantes. Algunos detalles y desaf os que implican la implementacion de un protocolo de DC-NET son explicados a continuacion. 4.1
La implementacion se esta desarrollando en Java principalmente por el hecho que una primera prueba de concepto sera utilizar la API implementada en una aplicacion movil Android (basado en Java), por lo que su integracion ser a mas simple y rapida. No existe ninguna razon de fondo (performance o alcance del lenguaje) por lo que se escogio dicho lenguaje de programacion, por lo que los mismos resultados se obtendr an si es que se implementara en otro lenguaje mas comun en otras implementaciones de DC-NET, como lo es C++.
Para la conexion entre los participantes se utiliza ZeroMQ 7, que, en palabras de sus autores, \son sockets en esteroides". Funciona para abstraer la implementacion de la capa de transporte de la aplicacion y despreocuparse de reconexiones o manejar perdidas de datos. Con ZeroMQ se simpli ca la implementacion de broadcasting o conexiones punto a punto entre los distintos participantes (ambos tipos de conexiones necesarias para el protocolo). 4.2
Un desaf o importante a considerar en la implementacion (y que el disen~o del protocolo no se preocupa) es como descubrir la locacion del resto de los participantes que formaran parte del anonymity-set. Para ello se tomo la decision de contar, ademas de los nodos participantes, con un nodo Directorio. Este nodo funcionara como punto de entrada al anonymityset y sera el responsable de informar la direccion IP de cada uno de los nodos participantes. Ademas de esto, el nodo Directorio tiene como responsabilidad establecer los parametros necesarios para correr el protocolo (numero de participantes, valores publicos para realizar los commitments, entre otros), por lo que tambien se vuelve un punto de control dentro del protocolo. Un aspecto importante es que todo lo que relaciona el protocolo con mantener anonimato (env o y veri caciones de demostraciones de seguridad) no pasa por el nodo Directorio, por lo que su incorporacion no altera en nada el requisito de seguridad buscado (emisores de mensajes anonimos).
Esta tarea tambien se puede realizar entre los propios nodos participantes, sin la necesidad de incorporar un nodo Directorio. Si bien en esta investigacion 7http://zeromq.org/ se priorizo la facilidad de implementar la variante utilizando el nodo adicional, correr alguna variante de gossip protocol para informar la identidad de participantes nuevos que vayan entrando a la sala podr a solucionar el problema. Esta segunda variante ademas tiene la ventaja de no poseer un punto vulnerable (que ser a el nodo Directorio), evitando ataques directos al nodo Directorio, retrasando (o incluso imposibilitando) la creacion del anonimity-set. Reiterar que se implemento el nodo Directorio por simplicidad, pero se tienen en cuenta los posibles ataques que puede recibir el sistema, que no tienen incidencia en romper el anonimato que brinda el protocolo.
Actualmente el nodo Directorio inicializa estableciendo los parametros publicos del protocolo y publica su direccion IP. Luego, cada nodo Participante que se quiera unir se conecta a la direccion publica del Directorio y espera que se complete la cuota de participantes establecida en un comienzo. Cuando se conectan n participantes al Directorio, este informa la direccion IP de cada uno de los participantes a todo el resto, para que posteriormente inicien el protocolo solo enviandose mensajes entre ellos, nalizando as la labor del Directorio. 4.3
En la implementacion actual, la gran mayor a de las primitivas criptogra cas han sido implementadas desde cero, valiendose principalmente de la biblioteca para manejar numeros grandes de Java, BigInteger 8. Si bien esto no es una practica recomendada (lo ideal es utilizar bibliotecas criptogra cas ya probadas por la comunidad), no se ha descubierto ninguna por parte de los autores que se adecue a las necesidades requeridas por el protocolo (Pedersen Commitments y ZKP asociadas). Este punto es algo importante a resolver ya que, como fue dicho, la implementacion de primitivas criptogra cas no es recomendado y es imperante utilizar implementaciones ya probadas y veri cadas por la comunidad, como lo podr a ser Charm-Crypto9 o Scapi10. De todas maneras, la criptograf a implementada se desarrollo utilizando interfaces, por lo que cuando se descubra una librer a que cumpla los requerimientos criptogra cos que se buscan, su implantacion sea realizada de manera facil. 4.4
La API que se tiene actualmente engloba los aspectos basicos del disen~o del protocolo explicado anteriormente. Aun faltan ciertas demostraciones a imple8https://docs.oracle.com/javase/7/docs/api/java/ math/BigInteger.html 9http://charm-crypto.com/index.html 10https://scapi.readthedocs.io/en/latest/ mentar (que aun no estan listas en el disen~o), pero la parte medular del protocolo esta implementado y funcional, dejando como unica gran labor al usuario nal de la API establecer ciertos parametros de seguridad (numero de bits de los grupos necesarios para las demostraciones, por nombrar a alguno) ademas del mensaje a enviar por cada participante. Luego de establecer esos valores, el protocolo empieza a funcionar y corre perfectamente, revelando (a medida que van saliendo) los mensajes salientes del protocolo. Como es un trabajo en curso, queda como trabajo futuro la realizacion de pruebas de seguridad (atacar el sistema) para poder detectar leaks de informacion que derivar an en la perdida de anonimato por parte de los emisores de mensajes. 4.5
Como prueba de concepto de la API implementada se creo una aplicacion Android que ofrece la funcionalidad de establecer el env o de mensajes anonimos basado en el protocolo DC-NET explicado anteriormente.
Existen dos funcionalidades de la aplicacion: ser un nodo Directorio o ser nodo Participante. Al ser Directorio, es necesario establecer parametros basicos del protocolo (numero de participantes a aceptar en el anonymity-set y largo maximo de los mensajes). Luego de esto la aplicacion queda esperando que se conecten los participantes, para posteriormente enviar la direccion IP de todos los participantes al resto de ellos. Por otro lado, al ser Participante, es necesario primero conectarse a un Directorio, y luego de que el Directorio informa la direccion de cada otro participante, se establece un mensaje y se env a. El protocolo corre y los mensajes anonimos se van mostrando en pantalla a medida que van llegando.
Con esto, podemos argumentar que la API implementada sirve para poder ser utilizar por otra aplicacion que necesite contar con mensajer a anonima entre un grupo de usuarios en particular. 5
La API se puso a prueba simulando una red local utilizando el software Common Open Research Emulator (CORE)11, que permite simular redes de manera simple y visual. La red se con guro para soportar 23 nodos participantes y 1 nodos directorio, conectados a traves de una red local (latencia y ancho de banda standard de red local).
Se realizaron 2 tipos de experimentos: 1. Taman~o del anonymity-set creciente: se fue aumentando la cantidad de nodos participantes in11http://www.nrl.navy.mil/itd/ncs/products/core volucrados, ademas de que el 100% de los nodos enviaron mensajes. 2. Taman~o del anonymity-set jo: siempre se mantuvieron 23 nodos participantes, pero se iba variando la cantidad de mensajes que se enviaban.
En cada uno de los 2 experimentos se midieron 3 variables: tiempo total de la ejecucion (hasta que se env an todos los mensajes involucrados), tiempo que demora en llegar el primer mensaje y tiempo promedio por mensaje. Los resultados se muestran y analizan en la proxima seccion. 6
En la Figura 1 vemos que a medida que el anonymity-set va creciendo (y donde todos los nodos env an un mensaje), el tiempo total va aumentando paulatinamente de manera exponencial. Esto se debe a que como existen conexiones punto a punto entre los nodos deben realizarse n2 conexiones distintas. Lo rescatable en este punto es que tanto el tiempo de llegada del primer mensaje como el tiempo promedio por mensaje no aumentan considerablemente, otorgando una cierta homogeneidad al protocolo.
Por otro lado, en la Figura 2 se ve que teniendo un taman~o jo del anonymity-set (23 en este caso), el tiempo total a medida que mas nodos van enviando mensajes va aumentando de manera lineal. Este escenario hace mas prospero el uso del protocolo, ya que ser a algo mas comun tener una cierta cantidad de participantes jos, y habran veces que algunos transmitan y otras veces no. (una vez disen~ado e implementado todo el protocolo) realizar un analisis de seguridad a la API implementada, tratar de atacarla y buscar posibles leaks de informacion que comprometan el anonimato, ya que el protocolo puede que funcione correctamente, pero la implementacion de este requiere otro tipo de ataques y pruebas para ser considerada correcta. Otro aspecto importante a realizar es poder hacer un pro ling a la implementacion, encontrar zonas de ejecucion que esten tomando mucho tiempo y realizarle mejoras para poder disminuir los tiempos. Por ultimo ser a importante realizar pruebas de la implementacion en escenarios reales (comunicacion a traves de Internet, no en una red local) y observar como se comporta en dicho escenario.
Los tiempos obtenidos en las pruebas son tiempos razonables para pensar en una aplicacion de foro anonimo (bulletin-board ), donde la inmediatez de los mensajes no es un aspecto crucial, como lo ser a un sistema de mensajer a instantanea (sala de chat). Lo importante a destacar del trabajo es que es uno de los primeros que implementa y dejar a a la comunidad un sistema basado en DC-NET, el cual si bien ya lleva bastantes an~os desde su aparicion, ha sido tomado en cuenta con mucha mas importancia ultimamente debido a los cuestionamientos y ataques descubiertos al protocolo por excelencia en anonimato, onion-routing. La necesidad por anonimato siempre estara, y es responsabilidad de la academia dotar de protocolos seguros que permitan a los usuarios ejercer su derecho a la privacidad. [Cha85] [CS97]
Jan Camenisch and Markus Stadler. Proof systems for general statements about discrete logarithms. Technical report, Citeseer, 1997. [Ped91] [Wai89]
Torben Pryds Pedersen. Non-interactive and information-theoretic secure veri able secret sharing. In Annual International Cryptology Conference, pages 129{ 140. Springer, 1991.
Michael Waidner. Unconditional sender and recipient untraceability in spite of active attacks. In Workshop on the Theory and Application of of Cryptographic Techniques, pages 302{319. Springer, 1989.