=Paper=
{{Paper
|id=Vol-1727/ssn16-final1
|storemode=property
|title=Implementation and Analysis of a DC-Net Based Anonymous Messaging System
|pdfUrl=https://ceur-ws.org/Vol-1727/ssn16-final1.pdf
|volume=Vol-1727
|authors=Camilo Gómez
|dblpUrl=https://dblp.org/rec/conf/ssn/Gomez16
}}
==Implementation and Analysis of a DC-Net Based Anonymous Messaging System==
https://ceur-ws.org/Vol-1727/ssn16-final1.pdf
Implementation of a DC-Net Based Anonymous
Messaging System
Camilo Gómez N.
NIC Chile Research Labs
University of Chile
camilo@niclabs.cl
Bajo ese panorama, se ha hecho necesario contar
con herramientas que aseguren el anonimato en la red.
Abstract Sin embargo, garantizar anonimato ante adversarios
sofisticados requiere dos condiciones: (1) uso y testeo
A DC-Net allows parties to communicate masivo por parte de un significativo número de usuar-
anonymously in a point-to-point network. ios, y (2) garantı́as matemáticas (criptográficas) de la
Even though DC-Nets where proposed by seguridad del protocolo que se está utilizando.
Chaum (CACM 1985) more than thirty years El software más popular y utilizado para per-
ago, only lately the protocol has gained more manecer anónimo mientras se navega en Internet es
attention because of both efficiency improve- TOR “The Onion Router”3 . Onion-routing [GRS96],
ments in point to point communication, and el protocolo implementado por TOR, ha sufrido re-
several attacks discovered in onion routing, cientes cuestionamientos, tales como si es o no realista
the most popular anonymous protocol. This suponer que el adversario no es capaz de monitorear to-
work describes an implementation of a practi- dos los canales de comunicación – uno de los supuestos
cal variant of DC-Nets (proposed by Franck, más cruciales de TOR. La pregunta es sin duda ra-
Hevia, and van Der Graaf 2016) which in- zonable dada la extensa capacidad de monitoreo que
cludes a useful API. Preliminary experiments poseen organismos de inteligencia para con todos los
indicate that the protocol is better suited for usuarios de Internet4 . Aun ası́, en la práctica TOR
non-interactive applications such as an anony- sigue siendo la herramienta más popular para nave-
mous bulletin board. We indeed implement gar de manera anónima en Internet, siendo incluso re-
such a mobile app and discuss possible exten- comendada por el mismo Snowden5 para evitar las in-
tions. tromisiones de la NSA y otras organismos similares.
Dado que concentrar nuestra privacidad en una sola
1 Introducción herramienta puede ser riesgoso, se hace necesario eval-
uar la factibilidad de protocolos alternativos que tol-
Mantener el anonimato navegando en Internet se ha
eran adversarios globales (capaces de monitorear todos
vuelto una demanda significativamente más popular
los canales de comunicación) tales como las DC-nets.
en los último años. Usuarios de todas las latitudes
Este trabajo busca aportar en este estudio de alterna-
reclaman que se respete su derecho a la privacidad1 ;
tivas.
posiblemente como consecuencia de las revelaciones
realizadas tanto por el grupo Wikileaks como por el
ex-empleado de la CIA Edward Snowden. Estas rev-
2 Anonimato via DC-Nets
elaciones ilustraron el masivo monitoreo por parte de 2.1 Dining Cryptographers Problem
organismos de inteligencia2 a la actividad diaria de
El problema de la Cena de Criptógrafos (Dining
millones de personas que hacen uso de la red.
Cryptographers Problem) fue propuesto por David
Copyright c by the paper’s authors. Copying permitted for 3 https://www.torproject.org/
private and academic purposes. 4 http://apps.washingtonpost.com/g/page/world/
1 http://www.livescience.com/37398-right-to-privacy. nsa-slideshow-on-the-tor-problem/499/
html 5 http://www.inc.com/larry-kim/
2 http://www.huffingtonpost.com/news/nsa-spying/ 5-online-privacy-tips-from-edward-snowden.html
Chaum en el año 1985 [Cha85, Cha88] para ejempli- pendiendo de que valor tomó la moneda (el “O Exclu-
ficar un protocolo de envı́o de mensajes de manera sivo” o XOR entre el mensaje y el valor de la moneda),
anónima entre un grupo de participantes. el mensaje a enviar y las llaves compartidas que posee
El problema es el siguiente: tres criptógrafos están el participante son sumadas módulo un valor fijo sufi-
cenando en su restaurante favorito. Al terminar la cientemente grande.
cena, el mesero se acerca a su mesa y les informa que En la práctica, primero es necesario establecer el
el maı̂tre indica que su cuenta ya está pagada. Los anonymity-set, esto es, quiénes serán los participantes
criptógrafos, sorprendidos, quieren resolver si la cuenta del protocolo, los responsables de enviar y aportar con
fue pagada por alguno de ellos, o si simplemente fue sus mensajes para asegurar el anonimato del potencial
pagada por algún agente externo (la NSA, por ejem- emisor. Luego, se utiliza una ronda de compartimiento
plo). Obviamente, como buenos criptógrafos, desean de llaves, donde cada par de participantes comparten
que su protocolo no revele la identidad del criptógrafo una llave secreta (este proceso podrı́a realizarse uti-
pagador (si existiera) pero al mismo tiempo permita lizando protocolo Diffie-Hellman). Una vez que todos
dilucidar si uno de ellos pagó o fue un agente externo. poseen llaves compartidas entre sı́, cada uno de los par-
Luego de pensarlo, el problema es resuelto con el sigu- ticipantes enviará uno de los dos siguientes mensajes
iente protocolo: al resto: un valor K igual a la suma de las llaves que
(1) Cada uno de los criptógrafos lanza una moneda posee compartidas, ó un valor K + M igual a la suma
al aire, de forma secreta. Luego de esto, le muestra de las llaves que posee compartidas más un mensaje M
la moneda al compañero que está inmediatamente a que quiere enviar de manera anónima. Con esto, cada
su derecha. (2) Cada criptógrafo informa al resto si participante envı́a un valor m = K si es que no quiere
las dos monedas que puede ver (la propia y la de su transmitir nada y solo quieren aportar en el anonimato
compañero a la izquierda) son iguales o no, pero con del resto, ó m = K + M si es que sı́ desea enviar un
una condición: si el criptógrafo viendo las monedas mensaje M . Finalmente, cada uno de los participantes
no pagó la cuenta, simplemente dice la verdad. Si no, suma los valores que recibió, lo que hará que las llaves
si no fue el (o ella) quien hizo el pago, el criptógrafo compartidas se cancelen y sólo quede visible el mensaje
revela lo contrario a lo que ve (si eran iguales dice que que compartió uno de los participantes. De esta man-
eran distintas y viceversa). (3) Si un número impar era, el emisor se mantiene anónimo tanto para el resto
de criptógrafos revela que las monedas eran distintas, de los participantes como para cualquier observador
implica que fue uno de ellos quien pagó la cuenta, de externo que monitoree todos los valores intercambia-
lo contrario significa que la NSA fue la que realizó el dos en el protocolo.
pago.
En el artı́culo original se demuestra que este pro- 2.2.1 Colisión de Mensajes
tocolo (posteriormente rebautizado como DC-Net). Lo anterior funciona siempre y cuando a lo más un
brinda anonimato incondicional: aún si un atacante participante envı́e un mensaje. A priori, no es claro
tuviera todo el poder de cómputo posible, le es im- que los participantes puedan ponerse de acuerdo re-
posible poder identificar al emisor del mensaje. Este specto a quién de los participantes enviará el mensaje,
anonimato se mantiene tanto para todos los partici- sin violar el anonimato del protocolo. Por ello, una col-
pantes del protocolo como para cualquier observador isión de mensajes – esto es, el envı́o de un mensaje por
externo. parte de dos o más participantes – es normal en la eje-
Con lo anterior, Chaum brinda un protocolo que cución de una DC-Net. Cuando una colisión ocurre, al
hace posible transmitir mensajes públicos de man- realizar la suma los valores enviados por todos los par-
era anónima. Chaum también propuso algunas varia- ticipantes, las llaves se cancelan resultando la suma de
ciones, tales como protocolos que permiten enviar los dos (o más) mensajes enviados. Dado que este valor
mensajes de largo arbitrario. es tı́picamente un mensaje ininteligible, una colisión
implica un fracaso en la transmisión de los mensajes
2.2 DC-Net Generalizada involucrados. Esto es un problema conocido. Varias
implementaciones y diseños propuestos han buscado
Existe una generalización práctica para utilizar el
hacerse cargo y resolverlo para poder permitir el envı́o
protocolo DC-Net con mensajes de largo mayor a 1
de varios mensajes en una misma iteración.
bit. En vez de manifestar un bit (pagó o no la cuenta),
cada participante envı́a un mensaje (cadena de bits)
2.2.2 Participantes Maliciosos
arbitrario. Además se reemplaza el lanzamiento de
una moneda vista entre dos participantes con una llave Otro aspecto importante de la seguridad de los pro-
aleatoria compartida entre ambos participantes. Por tocolos basados en DC-Net es su tolerancia a los par-
último, en vez de reemplazar el mensaje enviado de- ticipantes maliciosos. Tales participantes envı́an men-
sajes erróneos – que no se ajustan al protocolo acor- igualdad de diferentes logaritmos con distintas bases,
dado – o omiten enviarlos cuando debieran. Si es que además de combinaciones con operadores lógicos, en-
no se evita este comportamiento, podrı́a resultar en tre otros. Además existen maneras para poder de-
un protocolo erróneo, que nunca concluya con un men- mostrar propiedades genéricas sobre logaritmos discre-
saje transmitido, o bien que entregue mensajes equiv- tos [CS97].
ocados. Afortunadamente, la mayor parte de los pro-
tocolos resuelven este problema integrando primitivas 3.2 Compartición de Llaves
criptográficas al envı́o de los mensajes.
El protocolo comienza con cada participante Pi in-
tercambiando dos valores kij , rij con cada otro par-
3 Variante Práctica de DC-Net
ticipante Pj dentro del anonymity-set. Además se
Este trabajo se basa en una variante práctica del establece que kij = −kji y kii = 0 (ı́dem para r).
protocolo DC-Net propuesta por J. van de Graaf y Finalmente
Pn cada participante Pi calculará el valor
Christian Franck [FvdG14], que hace uso de prim- Ki = j=1 kij , donde n es el número total de par-
itivas criptográficas (Pedersen commitments y zero- ticipantes (ı́dem para calcular ri ).
knowledge proofs principalmente) para sortear los
problemas de colisión de mensajes y participantes ma- 3.3 Envı́o de Commitments y ZKP
liciosos.
El diseño que se explicará a continuación es un tra- 3.3.1 Llaves Compartidas
bajo en curso realizado en conjunto con los autores Cada Pi calculará cKi = g ki hrKi (commitment so-
antes mencionados, y se omitirán los detalles corre- bre Ki ). Luego de esto deberá enviar al resto de los
spondientes a demostraciones de seguridad, debido a participantes cKi junto con una PoK 6 indicando que
que lo importante a destacar son los desafı́os que im- conoce los valores (Ki , rKi ) dentro de cKi .
plican realizar la implementación del protocolo. Al recibir los commitment y las PoK de cada
participante Pi , se deben verificar cada Qn una de las
3.1 Primitivas Criptográficas
PoK, además debe comprobarse que i=1 cKi = 1
3.1.1 Pedersen Commitments [Ped91] (propiedad que se tiene debido a que las llaves deben
cancelarse unas con otras). De no tenerse esta última
Sea Gq un grupo de orden q, en donde el prob-
propiedad (lo que significa que al menos un partici-
lema del logaritmo discreto se crea difı́cil de resolver.
pante envió valores erróneos), existen maneras que per-
Sean g, h generadores de Gq elegidos aleatoriamente.
miten encontrar al participante malicioso en cuestión.
Sea s ∈ Zq un secreto que no se desea comprometer.
En la actual implementación se priorizó encontrar par-
Además sea r ∈ Zq elegido aleatoriamente. Se le llama
ticipantes maliciosos en etapas subsecuentes del pro-
un Pedersen commitment sobre s al valor:
tocolo, debido a que un participante malicioso en esta
c := g s hr etapa no puede comprometer el anonimato que brinda
el mensaje, sino simplemente retrasar el desarrollo del
Los Pedersen commitments brindan dos protocolo.
propiedades importantes: ocultamiento perfecto
(unconditionally hiding) y vinculación computacional 3.3.2 Valores Individuales
(computationally binding). Esto quiere decir que, si
una persona calcula un commitment sobre un cierto Cada participante Pi debe establecer tres valores
valor s, (1) la persona se compromete a dicho valor distintos (dependiendo si enviará o no un mensaje):
(pero sin revelarlo), ya que, por un lado es imposible
• mi : mensaje plano que enviará el participante. Si
para un tercero conocer s a partir de c, y (2) es
no enviará ningún mensaje, mi = 0.
computacionalmente difı́cil demostrar que dentro de c
existe un valor distinto a s. • padi : cadena aleatoria de bits que se utiliza
para reducir la posibilidad de enviar dos mensajes
3.1.2 Zero-Knowledge Proofs
iguales (más adelante en el protocolo se explicará
Una zero-knowledge proof permite a una persona su uso). Si no enviará ningún mensaje, padi = 0.
poder demostrar el conocimiento de cierto valor α que
cumple una propiedad (en Inglés, statement), sin rev- • bi : bit estableciendo si se enviará o no un mensaje,
elar el valor de α (el testigo) en esa demostración. bi = 1 si se enviará un mensaje, 0 si no.
Se pueden construir demostraciones para diferentes 6 Proof of Knowledge es una Zero-Knowledge Proof donde
tipos de propiedades (statements), como por ejem- el participando demuestra el conocimiento de un cierto valor
plo: el conocimiento de un logaritmo discreto; la dentro de un statement, sin revelar dicho valor.
Luego de establecer estos valores, cada Pi formará mensaje, el cual fue recibido por todos los partic-
el mensaje Mi , que resulta ser una concatenación de ipantes y se mantiene el anonimato de su emisor.
los 3 valores anteriores (la concatenación de valores 0n El protocolo finaliza.
es para prevenir que se produzcan overflow al sumarlos
posteriormente): 3. t > 1: Dos o más participantes enviaron un men-
saje, por lo que se ha producido una colisión
Mi = 0n || mi || 0n || padi || 0n || bi de mensajes (M ∗ consiste en la suma de varios
mensajes mi ). Para resolver esto se correrá un
Posteriormente cada Pi deberá escoger 3 valores protocolo de resolución de colisiones basado en
aleatorios: rmi , rpadi y rbi , para luego calcular com- superposed-receiving [Wai89] explicado a contin-
mitments sobre los 3 valores anteriores: cmi , cpadi y uación.
cbi (utilizando como valores aleatorios los escogidos
previamente). Con estos commitments cada Pi de- 3.5 Resolución de Colisiones
berá realizar una demostración de que el mensaje Mi
está bien formateado, esto es que: “el último bit es Para resolver la colisión, la idea principal es correr
1 o el último bit es 0 al igual que todo el mensaje” nuevamente el protocolo pero solamente un subcon-
(bi = 1 ∨ (bi = 0 ∧ mi = 0)). Se envı́a al resto de los junto de los participantes que tienen su mensaje in-
participantes los 3 commitments calculados junto con volucrado en la colisión enviarán mensajes. Para ello
la demostración anterior. se calcula el valor M̄ = M ∗ /t. Si el mensaje Mi < M̄ ,
Posteriormente se verifican las demostraciones en- entonces se reenviará en la ronda 2k (donde k es el
viadas por cada uno de los participantes. número de la ronda donde se produce la colisión). En
caso contrario se reenviará en la ronda 2k + 1.
3.3.3 Mensaje formateado Una parte importante de superposed-receiving es
que la ronda 2k + 1 puede ser calculada como función
El próximo paso es enviar una PoK sobre el men- de los mensajes enviados en las rondas k y 2k de la
saje Mi . El punto importante a destacar aquı́ es que siguiente manera: C 2k+1 = C k − C 2k . Por ello las ron-
no se envı́a un commitment asociado a Mi , sino que das 2k + 1 se le llaman rondas virtuales, y las rondas
éste se calcula en base a los 3 commitments enviados 2k se llaman rondas reales. De esta manera se dismin-
anteriormente cmi , cpadi y cbi . Por ello cada Pi envı́a uye la cantidad de rondas reales a realizarse para la
la PoK correspondiente, y es verificada por el resto de resolución de las colisiones.
los participantes calculando el commitment correspon- De esta manera, en las rondas subsecuentes la can-
diente. tidad de mensajes involucrados irá disminuyendo, ha-
ciendo que posibles colisiones que se produzcan (que
3.3.4 Mensaje de Salida
se resuelven recursivamente de la misma manera) sean
Finalmente cada Pi formará el mensaje de salida menores, implicando que después de t rondas reales
Oi = Mi + Ki . Al igual que antes, debe además crear se habrán enviados los t mensajes involucrados en la
una PoK sobre Oi en el commitment cOi (que también primera colisión. Importante a destacar es que en las
se puede calcular como función de los commitments an- rondas siguientes deben enviarse PoK indicando que
teriormente enviados). Se enviará el mensaje Oi junto el mensaje que se envı́a en dicha ronda es el mismo
con la PoK correspondiente y será revisada por el resto que estuvo involucrado en alguna colisión anterior (o
de los participantes. se envı́a un mensaje vacı́o).
Con esto, al enviarse los t mensajes involucrados
3.4 Envı́o de Mensaje de Salida en la primera colisión, el protocolo finaliza y todos los
Todos los participantes enviaron su respectivo men- participantes pueden ver que su mensaje fue enviado
saje de salida Oi , los cuáles deben ser sumados entre y se mantiene su anonimato frente tanto a los otros
Pn
todos formando el valor C 1 = (M ∗ , t) = i=1 Oi (M ∗ participantes como a observadores externos que vean
es la suma de los valores mi y padi de todos los par- el desarrollo del protocolo de manera pasiva. Como
ticipantes, mientras que t corresponde a la suma de fue dicho anteriormente, el diseño de este protocolo es
cada uno de los valores bi ). Teniendo estos valores, se un trabajo en curso, por lo que mayores detalles de de-
pueden producir tres casos: mostraciones de seguridad se están actualmente inves-
tigando y preparando una publicación más especı́fica.
1. t = 0: Ningún participante quiso enviar un men-
saje, por lo que el protocolo finaliza. 4 Detalles de Implementación
2. t = 1: Solamente un participante envió un men- El objetivo principal de este trabajo viene siendo
saje, por lo que el valor M ∗ corresponde a ese la implementación del protocolo explicado anterior-
mente como API, de manera tal que pueda ser uti- se priorizó la facilidad de implementar la variante uti-
lizado en variadas aplicaciones que necesiten contar lizando el nodo adicional, correr alguna variante de
con un protocolo de mensajerı́a anónima entre varios gossip protocol para informar la identidad de partic-
participantes. Algunos detalles y desafı́os que impli- ipantes nuevos que vayan entrando a la sala podrı́a
can la implementación de un protocolo de DC-NET solucionar el problema. Esta segunda variante además
son explicados a continuación. tiene la ventaja de no poseer un punto vulnerable (que
serı́a el nodo Directorio), evitando ataques directos
4.1 Tecnologı́as Involucradas al nodo Directorio, retrasando (o incluso imposibili-
La implementación se está desarrollando en Java tando) la creación del anonimity-set. Reiterar que se
principalmente por el hecho que una primera prueba implementó el nodo Directorio por simplicidad, pero se
de concepto será utilizar la API implementada en una tienen en cuenta los posibles ataques que puede recibir
aplicación móvil Android (basado en Java), por lo que el sistema, que no tienen incidencia en romper el anon-
su integración serı́a más simple y rápida. No existe imato que brinda el protocolo.
ninguna razón de fondo (performance o alcance del Actualmente el nodo Directorio inicializa estable-
lenguaje) por lo que se escogió dicho lenguaje de pro- ciendo los parámetros públicos del protocolo y pub-
gramación, por lo que los mismos resultados se ob- lica su dirección IP. Luego, cada nodo Participante
tendrı́an si es que se implementara en otro lenguaje que se quiera unir se conecta a la dirección pública
más común en otras implementaciones de DC-NET, del Directorio y espera que se complete la cuota de
como lo es C++. participantes establecida en un comienzo. Cuando se
Para la conexión entre los participantes se utiliza conectan n participantes al Directorio, éste informa la
ZeroMQ 7 , que, en palabras de sus autores, “son sock- dirección IP de cada uno de los participantes a todo
ets en esteroides”. Funciona para abstraer la imple- el resto, para que posteriormente inicien el protocolo
mentación de la capa de transporte de la aplicación y solo enviándose mensajes entre ellos, finalizando ası́ la
despreocuparse de reconexiones o manejar pérdidas de labor del Directorio.
datos. Con ZeroMQ se simplifica la implementación de
broadcasting o conexiones punto a punto entre los dis- 4.3 Primitivas Criptográficas
tintos participantes (ambos tipos de conexiones nece- En la implementación actual, la gran mayorı́a de
sarias para el protocolo). las primitivas criptográficas han sido implementadas
desde cero, valiéndose principalmente de la biblioteca
4.2 Nodo Directorio y Nodos Participantes para manejar números grandes de Java, BigInteger 8 .
Un desafı́o importante a considerar en la imple- Si bien esto no es una práctica recomendada (lo ideal
mentación (y que el diseño del protocolo no se pre- es utilizar bibliotecas criptográficas ya probadas por la
ocupa) es como descubrir la locación del resto de los comunidad), no se ha descubierto ninguna por parte
participantes que formarán parte del anonymity-set. de los autores que se adecúe a las necesidades requeri-
Para ello se tomó la decisión de contar, además de das por el protocolo (Pedersen Commitments y ZKP
los nodos participantes, con un nodo Directorio. Este asociadas). Este punto es algo importante a resolver
nodo funcionará como punto de entrada al anonymity- ya que, como fue dicho, la implementación de primi-
set y será el responsable de informar la dirección IP tivas criptográficas no es recomendado y es imperante
de cada uno de los nodos participantes. Además de utilizar implementaciones ya probadas y verificadas
esto, el nodo Directorio tiene como responsabilidad por la comunidad, como lo podrı́a ser Charm-Crypto9
establecer los parámetros necesarios para correr el o Scapi10 . De todas maneras, la criptografı́a imple-
protocolo (número de participantes, valores públicos mentada se desarrolló utilizando interfaces, por lo que
para realizar los commitments, entre otros), por lo que cuando se descubra una librerı́a que cumpla los requer-
también se vuelve un punto de control dentro del pro- imientos criptográficos que se buscan, su implantación
tocolo. Un aspecto importante es que todo lo que rela- sea realizada de manera fácil.
ciona el protocolo con mantener anonimato (envı́o y
verificaciones de demostraciones de seguridad) no pasa 4.4 API Resultante
por el nodo Directorio, por lo que su incorporación
La API que se tiene actualmente engloba los aspec-
no altera en nada el requisito de seguridad buscado
tos básicos del diseño del protocolo explicado anteri-
(emisores de mensajes anónimos).
ormente. Aun faltan ciertas demostraciones a imple-
Esta tarea también se puede realizar entre los pro-
pios nodos participantes, sin la necesidad de incorpo- 8 https://docs.oracle.com/javase/7/docs/api/java/
rar un nodo Directorio. Si bien en esta investigación math/BigInteger.html
9 http://charm-crypto.com/index.html
7 http://zeromq.org/ 10 https://scapi.readthedocs.io/en/latest/
mentar (que aun no están listas en el diseño), pero volucrados, además de que el 100% de los nodos
la parte medular del protocolo está implementado y enviaron mensajes.
funcional, dejando como única gran labor al usuario
final de la API establecer ciertos parámetros de se- 2. Tamaño del anonymity-set fijo: siempre se man-
guridad (número de bits de los grupos necesarios para tuvieron 23 nodos participantes, pero se iba var-
las demostraciones, por nombrar a alguno) además del iando la cantidad de mensajes que se enviaban.
mensaje a enviar por cada participante. Luego de es- En cada uno de los 2 experimentos se midieron 3
tablecer esos valores, el protocolo empieza a funcionar variables: tiempo total de la ejecución (hasta que se
y corre perfectamente, revelando (a medida que van envı́an todos los mensajes involucrados), tiempo que
saliendo) los mensajes salientes del protocolo. Como demora en llegar el primer mensaje y tiempo promedio
es un trabajo en curso, queda como trabajo futuro por mensaje. Los resultados se muestran y analizan en
la realización de pruebas de seguridad (atacar el sis- la próxima sección.
tema) para poder detectar leaks de información que
derivarı́an en la pérdida de anonimato por parte de los
6 Análisis de los Resultados
emisores de mensajes.
En la Figura 1 vemos que a medida que el
4.5 Aplicación Móvil anonymity-set va creciendo (y donde todos los nodos
envı́an un mensaje), el tiempo total va aumentando
Como prueba de concepto de la API implemen-
paulatinamente de manera exponencial. Esto se debe
tada se creó una aplicación Android que ofrece la fun-
a que como existen conexiones punto a punto entre
cionalidad de establecer el envı́o de mensajes anónimos
los nodos deben realizarse n2 conexiones distintas. Lo
basado en el protocolo DC-NET explicado anterior-
rescatable en este punto es que tanto el tiempo de lle-
mente.
gada del primer mensaje como el tiempo promedio por
Existen dos funcionalidades de la aplicación: ser
mensaje no aumentan considerablemente, otorgando
un nodo Directorio o ser nodo Participante. Al ser
una cierta homogeneidad al protocolo.
Directorio, es necesario establecer parámetros básicos
Por otro lado, en la Figura 2 se ve que teniendo
del protocolo (número de participantes a aceptar en
un tamaño fijo del anonymity-set (23 en este caso), el
el anonymity-set y largo máximo de los mensajes).
tiempo total a medida que más nodos van enviando
Luego de esto la aplicación queda esperando que se
mensajes va aumentando de manera lineal. Este esce-
conecten los participantes, para posteriormente enviar
nario hace más próspero el uso del protocolo, ya que
la dirección IP de todos los participantes al resto de
serı́a algo más común tener una cierta cantidad de par-
ellos. Por otro lado, al ser Participante, es necesario
ticipantes fijos, y habrán veces que algunos transmitan
primero conectarse a un Directorio, y luego de que el
y otras veces no.
Directorio informa la dirección de cada otro partici-
pante, se establece un mensaje y se envı́a. El proto-
colo corre y los mensajes anónimos se van mostrando
en pantalla a medida que van llegando.
Con esto, podemos argumentar que la API imple-
mentada sirve para poder ser utilizar por otra apli-
cación que necesite contar con mensajerı́a anónima en-
tre un grupo de usuarios en particular.
5 Experimentos
La API se puso a prueba simulando una red local
utilizando el software Common Open Research Emu-
lator (CORE) 11 , que permite simular redes de manera
simple y visual. La red se configuró para soportar 23
nodos participantes y 1 nodos directorio, conectados Figure 1: Tamaño de Anonymity-Set Variable
a través de una red local (latencia y ancho de banda
standard de red local).
Se realizaron 2 tipos de experimentos:
7 Conclusiones y Trabajo Futuro
1. Tamaño del anonymity-set creciente: se fue au-
El trabajo detallado hay que entenderlo como un
mentando la cantidad de nodos participantes in-
trabajo en curso, por lo que aun queda mucho tramo
11 http://www.nrl.navy.mil/itd/ncs/products/core por recorrer. Claramente queda como trabajo futuro
ient untraceability. Journal of cryptology,
1(1):65–75, 1988.
[CS97] Jan Camenisch and Markus Stadler. Proof
systems for general statements about dis-
crete logarithms. Technical report, Citeseer,
1997.
[FvdG14] Christian Franck and Jeroen van de Graaf.
Dining cryptographers are practical. arXiv
preprint arXiv:1402.2269, 2014.
[GRS96] David M Goldschlag, Michael G Reed, and
Figure 2: Tamaño de Anonymity-Set Fijo Paul F Syverson. Hiding routing informa-
tion. In International Workshop on In-
(una vez diseñado e implementado todo el protocolo) formation Hiding, pages 137–150. Springer,
realizar un análisis de seguridad a la API implemen- 1996.
tada, tratar de atacarla y buscar posibles leaks de in-
formación que comprometan el anonimato, ya que el [Ped91] Torben Pryds Pedersen. Non-interactive
protocolo puede que funcione correctamente, pero la and information-theoretic secure verifi-
implementación de éste requiere otro tipo de ataques able secret sharing. In Annual Interna-
y pruebas para ser considerada correcta. Otro aspecto tional Cryptology Conference, pages 129–
importante a realizar es poder hacer un profiling a 140. Springer, 1991.
la implementación, encontrar zonas de ejecución que [Wai89] Michael Waidner. Unconditional sender and
estén tomando mucho tiempo y realizarle mejoras para recipient untraceability in spite of active
poder disminuir los tiempos. Por último serı́a impor- attacks. In Workshop on the Theory and
tante realizar pruebas de la implementación en esce- Application of of Cryptographic Techniques,
narios reales (comunicación a través de Internet, no en pages 302–319. Springer, 1989.
una red local) y observar como se comporta en dicho
escenario.
Los tiempos obtenidos en las pruebas son tiem-
pos razonables para pensar en una aplicación de foro
anónimo (bulletin-board ), donde la inmediatez de los
mensajes no es un aspecto crucial, como lo serı́a un
sistema de mensajerı́a instantánea (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 años desde su aparición, ha sido tomado en
cuenta con mucha más importancia últimamente de-
bido a los cuestionamientos y ataques descubiertos al
protocolo por excelencia en anonimato, onion-routing.
La necesidad por anonimato siempre estará, y es re-
sponsabilidad de la academia dotar de protocolos se-
guros que permitan a los usuarios ejercer su derecho a
la privacidad.
Referencias
[Cha85] David Chaum. Security without iden-
tification: Transaction systems to make
big brother obsolete. Commun. ACM,
28(10):1030–1044, 1985.
[Cha88] David Chaum. The dining cryptographers
problem: Unconditional sender and recip-