Post on 14-Aug-2020
UNIVERSIDAD DE CHILE
FACULTAD DE CIENCIAS FÍSICAS Y MATEMÁTICAS
DEPARTAMENTO DE CIENCIAS DE LA COMPUTACIÓN
IMPLEMENTACIÓN DE UNA RED DE MEZCLA EFICIENTE PARA
COMUNICACIÓN ANÓNIMA
MEMORIA PARA OPTAR AL TÍTULO DE INGENIERO CIVIL EN
COMPUTACIÓN
PATRICIO BENJAMÍN SEGUEL LÓPEZ
PROFESOR GUÍA:
SR. ALEJANDRO HEVIA ANGULO
MIEMBROS DE LA COMISIÓN:
SR. CLAUDIO GUTIÉRREZ GALLARDO
SR. BENJAMÍN TOMÁS BARROS ARANCIBIA
SANTIAGO DE CHILE
AGOSTO 2009
ESTE TRABAJO HA SIDO FINANCIADO POR EL PROYECTO FONDECYT NRO. 1070332.
Resumen
En el contexto de comunicaciones en la red, los usuarios siempre han buscado la forma
de transmitir sus mensajes recibiendo ciertas garantías de seguridad; un caso particular es
asegurar el anonimato del emisor. En este trabajo de título se busca implementar una he-
rramienta que logre entregar esta garantía de seguridad en forma e�ciente y que pueda ser
utilizada en diversas aplicaciones.
El tema central de esta memoria es el estudio e implementación de protocolos cripto-
grá�cos para la comunicación anónima en la red, en particular de las redes de mezcla. Esta
técnica es utilizada como base para la implementación de la mayoría de las aplicaciones de
comunicación anónima. Aunque propuestas en los años 80, a través del tiempo las redes de
mezcla han experimentado muchas optimizaciones. En este trabajo se busca desarrollar una
nueva solución que implemente las mejoras y optimizaciones más recientes, utilizando una de
las últimas propuestas que ha demostrado ser más e�ciente que sus predecesores.
En una red de mezcla, un conjunto de servidores intermediarios se encargan de permutar
el orden de los mensajes recibidos y ocultarlos con encriptación. En una red de mezcla
veri�cable, cada servidor realiza un procedimiento de permutación y encriptación de los
mensajes, cuya integridad es comprobada por el resto de los participantes. Este procedimiento
de veri�cabilidad marca la diferencia entre distintas redes de mezcla y �nalmente determina
su e�ciencia.
Los trabajos más recientes han planteado novedosas formas de comprobar el procedimien-
to de mezcla de los servidores, obteniendo resultados diferentes en cada caso. En este trabajo
dichas propuestas fueron estudiadas y analizadas con el �n de determinar la más adecuada
para aplicaciones prácticas como la comunicación de mensajes anónimos. Posteriormente,
se implementó un sistema distribuido modular y extensible que provee una red de mezcla
e�ciente, así como un sistema de correo anónimo para ejempli�car el uso de esta red.
i
A mis padres y a Andrea por su cariño y apoyo.
Agradecimientos
Mis agradecimientos al profesor Alejandro Hevia por sus enseñanzas y sus sabios consejos.
Sin su apoyo no habría sido posible la realización de este trabajo. Agradezco también a
los profesores Tomás Barros y Claudio Gutiérrez, por sus acertadas recomendaciones para
mejorar la calidad de este trabajo.
Agradezco especialmente a mi novia Andrea, por su paciencia y apoyo incondicional. Por
acompañarme por este largo camino y estar siempre a mi lado, aun en tiempos de adversidad.
Por último, agradezco a mis padres y a mis hermanas, por su cariño, entrega y esfuerzo.
Gracias a ellos fue posible llegar al �nal de este camino.
iii
Índice General
Resumen i
Agradecimientos iii
1. Introducción 1
1.1. Reseña histórica y contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3.1. Lista de objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3.2. Plan de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conceptos básicos y herramientas criptográ�cas 5
2.1. Conceptos y notaciones matemáticas . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1. Notaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.2. Aritmética modular . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.3. Grupos, generadores y grupos cíclicos . . . . . . . . . . . . . . . . . . 6
2.1.4. Hipótesis de logaritmo discreto y DDH . . . . . . . . . . . . . . . . . 7
2.2. Re-encriptación de los mensajes . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3. Mezcla de los mensajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4. Sistemas de encriptación homomór�cos . . . . . . . . . . . . . . . . . . . . . 9
2.5. Esquemas de compromiso (Commitment scheme) . . . . . . . . . . . . . . . 10
2.5.1. Compromiso de un conjunto de valores . . . . . . . . . . . . . . . . . 12
2.5.2. Compromiso de una permutación . . . . . . . . . . . . . . . . . . . . 12
2.6. Prueba de nula divulgación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.6.1. Prueba de conocimiento . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.6.2. Pruebas de nula divulgación no interactivas . . . . . . . . . . . . . . 15
2.7. Sistemas criptográ�cos umbral . . . . . . . . . . . . . . . . . . . . . . . . . . 15
iv
2.7.1. Generación de claves distribuida . . . . . . . . . . . . . . . . . . . . . 15
2.7.2. Desencriptación distribuida . . . . . . . . . . . . . . . . . . . . . . . 18
2.8. Prueba de conocimiento del mezclador . . . . . . . . . . . . . . . . . . . . . 18
2.8.1. Pruebas de mezclas a través de esquemas de compromisos . . . . . . 19
3. Estado del arte 20
3.1. Redes de mezcla clásicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.1.1. Redes de mezcla clásicas robustas . . . . . . . . . . . . . . . . . . . . 21
3.2. Redes de mezcla re-encriptantes . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3. Redes de mezcla no robustas . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3.1. The Onion Routing (TOR) . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3.2. Crowds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4. Metodología 25
4.1. Esquema general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2. Evaluación de las propuestas . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3. Implementación de la solución . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3.1. Implementación de los mezcladores . . . . . . . . . . . . . . . . . . . 27
4.3.2. Interacción entre los mezcladores . . . . . . . . . . . . . . . . . . . . 30
4.3.3. Implementación de componentes externos . . . . . . . . . . . . . . . . 33
5. Descripción de la red de mezcla 35
5.1. Arquitectura de la solución . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.2. Descripción general del funcionamiento de la solución . . . . . . . . . . . . . 37
5.3. Protocolo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.3.1. Generación de parámetros iniciales . . . . . . . . . . . . . . . . . . . 40
5.3.2. Protocolo de generación de claves distribuida . . . . . . . . . . . . . . 41
5.3.3. Generación de parámetros para las mezclas . . . . . . . . . . . . . . . 41
5.3.4. Mezcla de los mensajes . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.3.5. Descifrado umbral . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.4. Detalle de la implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.4.1. Módulos implementados . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.5. Evaluación de rendimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
v
6. Usos de una red de mezcla y desafíos en la práctica 48
6.1. Utilización de una red de mezcla . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.2. Desafíos en la práctica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.2.1. Mejoras de rendimiento . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.2.2. Mejoras de funcionalidad . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.2.3. Ataques y conectividad . . . . . . . . . . . . . . . . . . . . . . . . . . 50
7. Conclusiones 52
Referencias 54
vi
Índice de cuadros
2.1. Prueba de conocimiento de re-encriptación de un mensaje . . . . . . . . . . . 14
4.1. Prueba de permutación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2. Prueba de conocimiento de igualdad de exponentes . . . . . . . . . . . . . . 31
4.3. Prueba de conocimiento de mezcla de mensajes . . . . . . . . . . . . . . . . 32
5.1. Comparación de mezclas de argumentos . . . . . . . . . . . . . . . . . . . . . 47
vii
Índice de �guras
2.1. Prueba de nula divulgación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1. Red de mezcla clásica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.1. Esquema de red de mezcla . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.2. Diagrama de �ujo de fase de inicialización . . . . . . . . . . . . . . . . . . . 38
5.3. Diagrama de �ujo de fase de mezcla de los mensajes . . . . . . . . . . . . . . 39
6.1. Esquema de red de mezcla con diversos Gateways . . . . . . . . . . . . . . . 51
viii
Capítulo 1
Introducción
1.1. Reseña histórica y contexto
Una red de mezcla o Mix Network es un protocolo para comunicación anónima que usa
cadenas de servidores intermediarios, también llamados mezcladores, los cuales reciben un
vector de mensajes que posteriormente permutan y re-encriptan1. El objetivo es que no se
pueda saber el orden de los mensajes de salida con respecto al orden de entrada, de esta
forma se permite ocultar quién es el remitente original de cada mensaje. Este concepto fue
introducido por Chaum [2] en el año 1981.
Hay dos tipos de redes de mezcla, las conocidas como decryption and re-encrytion mix
network, a las que llamaremos redes de mezcla clásicas y las re-encryption mix network, o
redes de mezcla re-encriptantes.
Las redes de mezcla clásicas corresponden a aquellas que siguen las ideas planteadas por
Chaum, éstas se caracterizan porque al pasar por un conjunto de mezcladores, el vector de
mensajes se encuentra bajo una serie de capas encriptadas. Estas capas las podemos com-
parar con las tradicionales muñecas rusas; las matrioskas, donde cada muñeca se encuentra
escondida dentro de otra. Por otro lado, las redes de mezcla re-encriptantes, di�eren de las
anteriores en la forma en que encriptan los datos que se reciben en cada mezclador, utilizando
esquemas de clave pública como ElGamal [3] o Pallier [10].
Al día de hoy se ha vuelto muy importante lograr desarrollar protocolos de comunicación
anónimas e�cientes, ya que estos son de gran importancia en otras áreas de la seguridad
informática, como por ejemplo cuando se desea comunicar pistas anónimas a la policía (�hot
1Se dice que un texto cifrado c es re-encriptado en un texto cifrado c′ si c 6= c′ pero la desencriptación de
ambos textos entrega el mismo texto plano
1
line�), o para consultar en forma anónima una base de datos de enfermedades con un estigma
social, como el SIDA.
En esta memoria se pretende estudiar y desarrollar una implementación e�ciente de una
red de mezcla re-encriptante, para así poder integrarla en las comunicaciones anónimas de
hoy en día a través de un sistema distribuido. Dicha integración se puede lograr utilizado
la red de mezcla en forma directa o bien como base para la implementación e�ciente de
otros protocolos orientados a mantener el anonimato. Por ejemplo los de votación electrónica
utilizan redes de mezcla planteadas por K. Sako y J. Killian [13].
1.2. Motivación
En el área de las comunicaciones en la red, siempre se ha buscado la manera de poder
transmitir mensajes con ciertas garantías de seguridad, en particular, manteniendo el anoni-
mato. Ante este escenario, las redes de mezcla aparecen como una alternativa muy atractiva,
ya que poseen características que permiten ofrecer una comunicación anónima segura entre
pares. Hoy en día existen diversos protocolos criptográ�cos para lograr anonimato en las
comunicaciones, como The Onion Routing [7] o Crowds [12], pero estos no entregan buenas
garantías matemáticas en cuanto a con�dencialidad, por esto las ideas detrás de las redes
de mezcla se han utilizado como base para la construcción de protocolos obteniendo mejores
resultados.
Para una buena implementación de una red de mezcla, se requiere un dominio de con-
ceptos y términos criptográ�cos, comprendiendo los fundamentos de esta área y al mismo
tiempo, un buen nivel técnico en el desarrollo de aplicaciones. Actualmente no existen mu-
chos profesionales que cumplan con ese per�l, o que sus estudios se encuentren orientados
a esta área especí�ca de la criptografía, por lo que en este proyecto se pretende aprovechar
las capacidades adquiridas y desarrolladas por su autor durante los años de estudio en el
Departamento de Ciencias de la Computación.
Actualmente existen diversas propuestas para desarrollar redes de mezcla, pero muy po-
cas de ellas han sido implementadas efectivamente, por lo que se utilizará como base las
propuestas realizadas por diversos autores, entre ellos J. Furukawa [4], J. Groth [8], S. Lu [9]
y D. Wikström [14]. Al ser trabajos principalmente teóricos, serán de utilidad a la hora de
realizar las evaluaciones del proyecto previas a la implementación del mismo.
2
Este trabajo es de un gran interés académico y profesional, ya que con la implementación
de una red de mezcla e�ciente, se pueden solucionar en forma directa los problemas relacio-
nados con el logro de comunicaciones anónimas seguras en la red, en particular, evitando
un impacto negativo en los tiempos de envío de mensajes para los usuarios. Adicionalmente
ofrece un avance importante de la investigación de protocolos de comunicación anónima, pro-
porcionando una herramienta de gran calidad para ser utilizada de base en otros protocolos
como la votación electrónica o sistemas de consultas privadas a bases de datos.
1.3. Objetivos
1.3.1. Lista de objetivos
Estudio de propuestas para la implementación de redes de mezcla.
Evaluar propuestas actuales y determinar cual es la más e�ciente.
Implementación de una red de mezcla utilizando las mejores alternativas estudiadas.
Desarrollo de un prototipo de aplicación de comunicación anónima que use la red de
mezcla.
1.3.2. Plan de trabajo
En este trabajo se busca comprender los fundamentos esenciales que hay detrás de una
red de mezcla, identi�cando los más importantes a la hora de realizar una implementación
de este protocolo. Para lograr esto se estudiarán y evaluarán diversas propuestas que existen
en la actualidad para determinar su e�ciencia, tanto teórica como práctica.
Para llevar a cabo esta evaluación se debe comenzar estudiando la propuesta original
de Chaum para redes de mezcla, que plantea los principios básicos de estas. Tomando esta
propuesta como base, se debe evaluar de qué manera ha ido evolucionando en el tiempo y como
diversas propuestas han ido mejorando la forma en que cada mezclador hace sus procesos y
especialmente, la forma en que realizan las pruebas de correctitud de sus procesos.
Cuando ya se ha comprendido cómo funciona una red de mezcla, se debe proceder a
evaluar una propuesta más avanzada y que ya pueda ser implementada, como lo es la idea
para votación electrónica de K. Sako y J. Killian [13].
3
Para �nalizar con la etapa de evaluación de las propuestas, es esencial revisar los trabajos
más recientes del tema. En particular J. Groth [8] y D. Wikström [14] plantean ideas muy no-
vedosas y que han comprobado ser más e�cientes que otros trabajos anteriores, especialmente
en la manera como hacen las mezclas y prueban su correctitud.
Una vez realizada la evaluación de las alternativas presentes, se pretende lograr una
implementación �nal que utilice como base la mejor alternativa estudiada, y logre entregar
una solución e�ciente en un entorno distribuido. Con estos resultados, se desarrollará una
librería que permita utilizar la red de mezcla en forma modular.
Cuando la librería se encuentre terminada, se espera poder ponerla en funcionamiento
en forma de prueba, ya sea creando un servicio que entregue anonimato a usuarios que lo
requieran, o creando un ambiente cerrado donde un grupo de usuarios conforman una red de
mezcla y la utilizan en forma interna.
Finalmente, se espera desarrollar un prototipo de aplicación de comunicación anónima,
idealmente un servicio de correo electrónico, utilizando la red de mezcla implementada.
4
Capítulo 2
Conceptos básicos y herramientascriptográ�cas
Para una mejor comprensión del informe, conviene indicar los conceptos que serán usados
frecuentemente durante el presente trabajo y que el lector debe tener presente para compren-
der la operatoria y propiedades del sistema desarrollado.
2.1. Conceptos y notaciones matemáticas
A continuación se presentan algunas notaciones y conceptos matemáticos utilizados luego
en el informe.
2.1.1. Notaciones
Para los números naturales y enteros se usarán las notaciones N y Z respectivamente.
Para un algoritmo A que recibe como parámetros un valor x y una aleatoridad r, escri-
bimos como yR←− A(x) al proceso de seleccionar una aleatoriedad r y hacer la asignación
y = A(x, r). De la misma manera, se denotará como y ∈R G a la acción de escoger un
elemento de un conjunto G en forma aleatoria (uniforme) y asignárselo a la variable y.
2.1.2. Aritmética modular
La operación de reducción modular (o módulo) es aquella que calcula el resto de la división
entre dos números y se denota como mod.
Sean a, N dos números enteros, dividendo y divisor respectivamente, dondeN > 0. Existen
enteros únicos r < N y q, tal que a = qN + r. Los valores r y q corresponden al resto y al
5
cociente de la división de a por N . Así, r es el resultado de la operación a mod N , lo que
llamamos módulo N .
Con esto, podemos asociar a cualquier entero N los siguientes conjuntos:
ZN = {0, 1, ..., N − 1}
Z∗N = {i ∈ Z : 1 ≤ i ≤ N ∧mcd(i, N) = 1}
El primero, es el llamado conjunto de enteros mod N . El segundo, es el conjunto de los
primos relativos de N , es decir, todo entero positivo i < N cuyo máximo común divisor con
N sea 1. Cabe mencionar que si N es un número primo, Z∗N = {1, ..., N − 1}
De�niremos una operación móduloN como aquella a la cual se le aplica reducción modular
al resultado de dicha operación realizada en su forma original. En ZN se de�ne la suma módulo
N :
Dados dos elementos a, b ∈ ZN , se efectúa su suma como números enteros y si esa suma
es mayor o igual que N , se divide por N , obteniendo un resto r ∈ ZN . Podemos decir
entonces que a+ b mod N = r.
Del mismo modo se de�ne el producto módulo N en ZN y Z∗N :
Dados dos elementos a, b ∈ ZN o a, b ∈ Z∗N , se efectúa en primer lugar el producto
ordinario de los enteros a y b y se divide el resultado ab por N , obteniendo un resto
s ∈ ZN o s ∈ Z∗N , según corresponda. Podemos escribir entonces ab mod N = r.
2.1.3. Grupos, generadores y grupos cíclicos
Sean G un conjunto distinto de vacío y · una operación binaria de�nida sobre los elementos
de G. Se dice que G es un grupo respecto a · si satisface las siguientes propiedades:
Clausura ∀a, b ∈ G, a · b ∈ G
Asociatividad ∀a, b, c ∈ G, (a · b) · c = a · (b · c).
Identidad ∃!e ∈ G : ∀a ∈ G, a · e = e · a, e se llama identidad.
Inverso ∀a ∈ G,∃!b ∈ G : a · b = b · a = e.
Si este grupo, es además conmutativo (∀a, b ∈ G, a · b = b · a), se le llama grupo abeliano.
6
Si consideramos un entero positivo N entonces ZN es grupo bajo la suma módulo N y
Z∗N es un grupo bajo la multiplicación módulo N . En teoría de grupos, se le llama orden al
tamaño o cantidad de elementos de un grupo.
Se conoce como conjunto generador de un grupo G, a un subconjunto S de G tal que
todo elemento de G puede ser expresado como el producto de un número �nito de elementos
de S y de sus inversos.
Para un grupo G, sea 1 su identidad y m su orden. Sea g ∈ G un elemento cualquiera
del grupo. Se le llama orden de g al primer entero n > 0 tal que gn = 1. Denotaremos al
conjunto generado por g como:
〈g〉 = {gi : i ∈ ZN} = {g0, g1, ..., gn−1}
Este grupo es, además, un subgrupo de G y su orden es igual al orden de g.
Con esto, a G se le considera un grupo cíclico si existe g ∈ G tal que 〈g〉 = G. A este
elemento g se le conoce como generador de G. Si g es generador de G entonces se cumple que
∀a ∈ G,∃! i ∈ Zm : gi = a. Al entero i se le llama el logaritmo discreto de a en base g y lo
denotamos como DlogG,g(a).
2.1.4. Hipótesis de logaritmo discreto y DDH
Para un grupo cíclico G de orden m y generador g, la hipótesis del logaritmo discreto
a�rma que si y ∈ G es escogido en forma aleatoria, es infactible calcular x tal que y = gx.
La hipótesis DDH (Decisional Di�e-Hellman), a�rma que cuando elementos x, y, z ∈ G
son elegidos en forma aleatoria, entonces no es posible distinguir en forma e�ciente entre
las dos distribuciones (gx, gy, gxy) y (gx, gy, gz), donde la multiplicación xy es mod m. Para
modelar formalmente este problema, se hace el siguiente experimento:
Sea un grupo cíclicoG, con generador g y de ordenm. Tenemos un adversario el cual recibe
entradas X, Y, Z. Consideraremos dos mundos, los que llamaremos mundo 0 y 1. En ambos
mundos, los valores X e Y son escogidos en forma aleatoria en G, pero varía la forma en que
se escoge el valor de Z. En el mundo 1, Z se calcula como Z = gxy, donde x = DlogG,g(X) e
y = DlogG,g(Y ). Por otro lado, en el mundo 0, Z es escogido de manera aleatoria en G.
Sea A el adversario y que corresponde a un algoritmo que retorna un bit b. El desa-
fío para el adversario es determinar en que mundo se encuentra. Para esto, se de�nen dos
experimentos:
7
Experimento en el mundo 1
Expddh−1G,g (A):
x ∈R G
y ∈R G
z = xy mod m
X = gx;Y = gy;Z = gz
b = A(X, Y, Z)
return b
Experimento en el mundo 0
Expddh−0G,g (A):
x ∈R G
y ∈R G
z ∈R G
X = gx;Y = gy;Z = gz
b = A(X, Y, Z)
return b
La ventaja del adversario es la función de�nida por:
AdvddhG,g = |Pr[Expddh−1G,g (A) = 1]− Pr[Expddh−0
G,g (A) = 1]|
Donde Pr[] denota una probabilidad.
Si la ventaja es baja (cercana a 0) para todo adversario con recursos razonables (tiempo
de ejecución, memoria), se dice que el problema DDH es difícil en G.
2.2. Re-encriptación de los mensajes
La re-encriptación de un mensaje consiste en transformar un texto cifrado C en otro al que
llamaremos C ′, de tal manera que ambos son distintos, pero al momento de la desencriptación
de ambos textos cifrados, se obtiene el mismo texto plano.
Sean E un algoritmo de encriptación y D su correspondiente algoritmo de desencripta-
ción. Ambos reciben como parámetros un valor o mensaje a encriptar o desencriptar y una
aleatoriedad. Sea M un texto plano, r una aleatoriedad y C = E(M, r) la encriptación del
texto plano. Decimos que C ′ es una re-encriptación de C con una aleatoriedad r′ si se cumple
8
que D(C, r) = D(C ′, r′) = M .
2.3. Mezcla de los mensajes
La mezcla de los mensajes se re�ere al procedimiento que efectúa cada mezclador al
permutar los mensajes que se reciben, con el �n de que al momento de publicarlos estos estén
en un orden diferente. De esta forma, al realizarse una re-encriptación de los mensajes junto
con la mezcla, no se puede obtener una relación entre los mensajes que entran al mezclador y
los que salen del mismo. Para realizar la mezcla, se elige una permutación a la que usualmente
se le llama π, la que se escoge de un conjunto de permutaciones sobre el conjunto {1, ..., N}
denotado SN .
Esta idea se mantiene intacta en cada una de las propuestas y aplicaciones de redes
de mezcla, por lo que en adelante se asume que cada mezclador procesa un grupo grande
de mensajes. En el caso de no recibir los mensajes como un conjunto, el mezclador los va
recibiendo en forma individual y espera a tener una cantidad de mensajes apropiada para
comenzar con el procedimiento de mezcla.
2.4. Sistemas de encriptación homomór�cos
Un sistema criptográ�co homomór�co es, en términos generales, aquel en el cual se puede
realizar alguna operación algebraica especi�ca sobre el texto plano, mediante la realización
de otra operación algebraica sobre el texto cifrado.
En términos más especí�cos y para su utilización en el documento, un sistema criptográ�co
homomór�co se de�ne como un tupla CS = (Kg,E,D), donde Kg es un generador de
claves probabilístico, E es un algoritmo de encriptación probabilista y D un algoritmo de
desencriptación determinista. Esta tupla cumple con lo siguiente:
1. Estructura de grupo. El generador de claves probabilístico Kg, recibe 1κ como pa-
rámetro de entrada y entrega un par de claves pública y privada (pk, sk) de�niendo
tres grupos abelianos Mpk, Rpk y Cpk, que corresponden al grupo de textos planos,
el de números aleatorios y el de textos cifrados respectivamente. Estos grupos tienen
operaciones en tiempo polinomial. Denotamos como PK al conjunto de posibles claves
públicas.
9
2. Correctitud. Por cada (pk, sk) ∈ Kg(1κ), m ∈ Mpk y r ∈ Rpk, los algoritmos de
cifrado y descifrado cumplen que Dsk(Epk(m, r)) = m. Es decir, un mensaje encriptado
con la clave pública, puede ser desencriptado con la clave privada.
3. Linealidad de la encriptación. Por cada (pk, sk) ∈ Kg(1k), m1,m2 ∈Mpk y r1, r2 ∈
Rpk: Epk(m1, r1)Epk(m2, r2) = Epk(m1m2, r1r2)
De aquí en adelante se asume que el orden del subgrupo más grande de Cpk y el orden de
cualquier grupo en el que nos basemos para la encriptación de mensajes, son acotados por 2κ,
donde κ es el parámetro de seguridad y debe ser lo su�cientemente grande para garantizar
la seguridad del protocolo1.
Un sistema criptográ�co que cumple con estas propiedades es el de ElGamal [3], el que
trabaja sobre un grupo Gq de orden q, tal que q divide a (p − 1) y p es primo. Gq es
generado por g. En este caso, Kg genera un par de claves pública y privada de la forma
((g, y), x) tal que y = gx mod p. Adicionalmente, el algoritmo E genera un texto cifrado de
la forma (u, v) = E(g,y)(m, r) = (gr mod p, yrm mod p). En este sistema se tiene además que
Mpk = Gp, Rpk = Zp y Cpk = Gp ×Gp.
Para la utilización de este protocolo, se suele escoger un número primo p grande (κ bits),
donde q es uno de los factores grandes de (p− 1) y el conjunto Gp es el subgrupo de orden q
de residuos cuadráticos de Zp.
En el caso de ElGamal, (u′, v′) = (gr′u, yr
′v) se considera una re-encriptación de un texto
cifrado (u, v) con una aleatoriedad r′. Esta re-encriptación la anotaremos como:
φ(g,y)((u, v), r′) = (gr′u, yr
′v) = (u′, v′)
2.5. Esquemas de compromiso (Commitment scheme)
Un esquema de compromiso es un protocolo criptográ�co mediante el cual un participante
se puede comprometer a un valor manteniéndolo oculto, pero con la capacidad de poder
revelar el valor comprometido a futuro y además, entregando la seguridad de que en él, luego
de entregado el compromiso, no podrá cambiar la elección del valor.
1Para este tipo de sistemas criptográ�cos, se suele considerar �su�cientemente grande� a un valor de κ tal
que κ ≥ 512
10
Una manera de ejempli�car esta idea es imaginar que dos participantes, Alicia y Bob,
se encuentran conversando y desean realizar una apuesta a través de un juego. Alicia debe
escoger entre dos números y luego Bob debe enviar el valor que él cree escogió Alicia y si
logra adivinar, gana la apuesta, de lo contrario, gana Alicia. Para esto, Alicia escoge uno de
los valores y envía a Bob un compromiso del valor elegido. Luego, Bob le envía el valor que
él cree que ella escogió. Finalmente, Alicia le envía la llave para abrir el compromiso y Bob
puede ver si ganó la apuesta.
Lo anterior es posible ya que un esquema de compromisos satisface dos fuertes propieda-
des:
Binding Un compromiso no puede ser abierto de dos maneras distintas, esto es, revelando
dos valores distintos.
Hiding No se puede deducir información del contenido de un compromiso c a partir del valor
de éste.
En términos generales, un esquema de compromiso (Gen,Com) consiste de un algoritmo
generador de parámetros probabilístico Gen y un algoritmo probabilístico de compromiso
Com. Ante una entrada 1k, Gen entrega como salida un parámetro ck el que de�ne un con-
junto de mensajesMck, un espacio de elementos aleatorios Rck y un espacio de compromisos
Kck. Denotaremos CK al conjunto de posibles parámetros de compromiso. Ante una entrada
ck ∈ CK,m ∈Mck y r ∈ Rck, Com entrega un valor de compromiso. Al abrir un compromiso,
el mensaje y la aleatoriedad usada son revelados.
Uno de los esquemas de compromisos más utilizados es el de Pedersen [11]. Un concepto
a tener en consideración al trabajar con este esquema, es la generación de subgrupos.
Sean primos grandes p, q tal que q divide a p − 1, lo que anotamos como q|(p − 1).
Llamaremos Gq a un subgrupo de Z∗p de orden q y g al generador de Gq. Se puede veri�car
fácilmente si un elemento a ∈ Z∗p pertenece a Gq ya que se cumple lo siguiente:
a ∈ Gq ⇔ aq mod p = 1 (2.1)
Así cualquier elemento b 6= 1 en Gq genera al grupo:
∀b 6= 1 ∈ Gq, 〈b〉 = Gq
11
El esquema de compromisos de Pedersen utiliza dos primos grandes p y q, tal que q|(p−1)
y al grupo Gq . Se escogen valores al azar g, h ∈R Gq, con lo que los valores 〈p, q, g, h〉 son
valores públicos y loggh, loghg son desconocidos por quien utilice el esquema de compromiso.
Con estos parámetros, el espacio de compromisos es Zq.
De esta forma, para comprometerse a un valor x ∈ Zq, el emisor del compromiso escoge
un valor r ∈R Zq y calcula Com(x, r) = gxhr mod p, siendo este el valor del compromiso.
Para abrir el compromiso, el emisor revela los valores x y r y el receptor veri�ca que con
estos valores se pueda reconstruir c.
Aquí al igual que en los sistemas de encriptación, se asume un parámetro de seguridad
κcom, designado por el usuario de protocolo, para asegurar la robustez del esquema. Adicio-
nalmente, se de�ne un parámetro κc que representa el limite superior en número de bits que
pueden tener los valores a ser comprometidos y además corresponde al tamaño en bits de
primo q.
2.5.1. Compromiso de un conjunto de valores
Existen variantes para el esquema de Pedersen que sirven para comprometerse a un con-
junto de valores x1, ..., xN ∈ Zq las que anotamos como (Gene, Come). En una de estas va-
riantes, se elige aleatoriamente un conjunto de parámetros (generadores) g1, ..., gN , h ∈R Gq
y el compromiso se puede calcular de una de la siguientes formas:
Escoge r ∈R Zq y calcula Come(x1, ..., xN , r) = gx11 · · · g
xNN hr mod p
Otra posibilidad es la siguiente:
Escoge r1, ..., rN ∈R Zq y calcula Come(x1, ..., xN , r1, ..., rN) = (c1, ..., cN) con ci =
gxii hri
Diremos que (Gene, Come) es un esquema de compromiso para ZNq .
2.5.2. Compromiso de una permutación
Existe una adaptación del esquema de Pedersen para comprometerse a una permutación
π ∈ SN la que anotaremos como (Genπ, Comπ). En esta adaptación, dada una permutación
π, se elige un conjunto de parámetros aleatorios g1, ..., gN , h ∈R Gq y el compromiso se calcula
como:
12
Escoge r1, ..., rN ∈R Zq y calcula Comπ = (hr1gπ−1(1), ..., hrNgπ−1(N))
Diremos que (Genπ, Comπ) es un esquema de compromiso para SN .
2.6. Prueba de nula divulgación
Una prueba de nula divulgación, la que abreviaremos como ZKP (por zero-knowledge
proof), es un método interactivo mediante el que una entidad, conocida como demostrador o
prover, quiere demostrar a otra entidad, llamado veri�cador o veri�er, que cierta a�rmación
es correcta, sin revelar nada más que la veracidad de la a�rmación. Para lograr esto, se
utilizan pruebas interactivas en las que el veri�er, mediante ciertos desafíos, se convence de
que la a�rmación del prover es correcta. Para entender de mejor manera este concepto, se
puede ver el ejemplo en la �gura 2.1.
Figura 2.1: Prueba de nula divulgación
En este ejemplo, el prover Alicia, quiere convencer al veri�er Bob, que puede abrir la
puerta dentro del laberinto. Para esto Bob pone a prueba a Alicia pidiéndole que entre
al laberinto por el lado que ella desee. Posteriormente, Bob le solicita que salga por un
lado determinado. De esta forma, si Alicia realmente puede abrir la puerta al interior del
laberinto, podrá salir por cualquiera de los dos lados, independientemente de por donde
ingresó al laberinto. Sin embargo, si Alicia no puede abrir la puerta, solo tiene un 50% de
probabilidades de engañar a Bob, ya que esto sólo sucede si es que este le pide salir por el
mismo lado que ingresó. Así, si este experimento se va repitiendo cierta cantidad de veces,
las probabilidades de que Alicia pueda engañar a Bob, son cada vez menores y este puede
concluir con una alta probabilidad, de que Alicia puede abrir la puerta.
Con este experimento, aunque Bob quede convencido de que Alicia puede abrir la puerta,
este no podrá convencer a un tercero utilizando su interacción con Alicia, ya que en esta no
13
obtuvo ninguna información adicional que le permita probar a otro individuo este hecho.
2.6.1. Prueba de conocimiento
Una prueba de conocimiento consiste en que un prover debe convencer a un veri�er de que
conoce cierto secreto. A diferencia que en una prueba de nula divulgación, se debe cumplir
que exista un algoritmo que, teniendo como como entrada solamente al prover, sea capaz de
calcular en tiempo polinomial un valor conocido como testigo o witness de este secreto, el
que es su�ciente para convencer a un veri�er de que se conoce el secreto.
Una prueba de conocimiento no tiene que ser necesariamente una prueba de nula divulga-
ción, ya que por ejemplo una prueba de conocimiento puede demostrar que sabe un secreto
revelando el valor del mismo.
Un ejemplo práctico se puede ver en el cuadro 2.1, donde se prueba conocimiento de una
re-encriptación de un mensaje para un sistema criptográ�co de ElGamal. Este protocolo es
de nula divulgación y prueba de conocimiento siempre que el veri�cador siga el protocolo.
Esta prueba basa su seguridad en el hecho de que el logaritmo discreto es difícil de calcular,
lo que necesariamente debería hacer el prover si quiere engañar al veri�er. Con esto el veri�er
se convence de que los valores dados corresponden a una re-encriptación de los mensajes.
Entrada común:Grupo Gq de orden primo q,
clave pública de ElGamal (y, g),textos cifrados (u, v) y (u′, v′)
Entrada privada:Exponente r ∈ Zq
tal que (u′, v′) = (gru, yrv)Escoge s ∈R Zq
Calcula (µ, ν) = (gs, ys) (µ, ν)−−−→c←− Escoge c ∈R Zq
Calcula d = cr + s d−→Veri�ca si se cumple(gd, yd) = ((u′/u)cµ, (v′/v)cν)
Cuadro 2.1: Prueba de conocimiento de re-encriptación de un mensaje
14
2.6.2. Pruebas de nula divulgación no interactivas
Estas pruebas de conocimientos se basan en la idea de Blum, Feldman y Micali [1] que
hacen referencia a que una cadena común aleatoria compartida entre prover y veri�er, llamada
cadena aleatoria común, es su�ciente para lograr la prueba de conocimiento sin necesidad de
interacción entre los participantes.
En general se basan en el hecho de que los datos entregados por el veri�er durante el
protocolo, se pueden simular usando la cadena aleatoria común y esta sea utilizada por el
prover para hacer su demostración.
Este tipo de pruebas se utilizan cuando se quieren realizar pruebas de conocimiento en
forma e�ciente sin la necesidad de interactuar con un veri�cador. En general, son utilizadas
al implementar algoritmos que ejecutan pruebas de conocimiento.
2.7. Sistemas criptográ�cos umbral
Un sistema criptográ�co umbral (del inglés �threshold cryptosystem�), es un protocolo en
el cual para lograr el desencriptado de un mensaje encriptado, un número de participantes
superior a un umbral determinado, deben necesariamente cooperar entre ellos en el protocolo
de desencriptado.
En el contexto de una generación de claves distribuida, los mensajes son cifrados utilizando
una clave pública y los diversos participantes del protocolo obtienen una parte de la clave
privada. De esta manera, para poder descifrar el mensaje, se necesita un subconjunto de
participantes superior al umbral determinado por el protocolo. En particular para el caso
del protocolo de generación de claves DKG y el protocolo de desencriptación distribuida, el
umbral es t, es decir, se necesita al menos t+ 1 participantes para completar el protocolo de
generación de claves y descifrado, respectivamente.
2.7.1. Generación de claves distribuida
Se habla de una generación de claves distribuida cuando un conjunto de participantes
crean una clave secreta para un sistema criptográ�co, pero ninguno de ellos tiene la clave
completa por si mismo, si no que cada uno posee una parte de la clave. De esta manera, un
subconjunto de los participantes debe cooperar con el �n de poder recuperar la clave secreta
y lograr ejecutar alguna tarea criptográ�ca, tal como desencriptar algún mensaje.
15
Una idea para la implementación de este protocolo se presenta en [6], al cual nos referi-
remos como protocolo DKG. En este protocolo se crea un par de claves privada y pública,
donde los participantes poseen una parte de la clave privada. Además, se cumple que dada
una cantidad n de participantes, en nuestro caso los mezcladores, se tolera que un número de
participantes t < n/2 actúen de manera arbitrariamente deshonesta. Ante esto, se requiere
que un subconjunto de los mezcladores de tamaño al menos t + 1 cooperen para recuperar
la clave privada. A un protocolo que cumple estas condiciones se le llama t-seguro, o bien,
seguro con umbral t.
Este protocolo requiere de la existencia de un canal de comunicación común para los n
participantes, llamado canal de broadcast. El protocolo se describe a continuación:
Valores necesarios :
Número de participantes n y el valor se seguridad t < n/2.
Primos grandes p y q tal que q|(p− 1).
Elementos g, h ∈ Gq, donde Gq es subgrupo de Z∗p de orden q.
Participantes : Mezcladores M1, ...,Mn.
Entradas públicas : n, p, q, g, h, t.
Entradas privadas : No hay.
Generación de las claves :
1. Cada mezclador Mi escoge al azar dos polinomios fi(z), f ′i(z) en Z∗q de grado
t tal que:
fi(z) = ai0 + ai1z + ...+ aitzt mod q
f ′i(z) = bi0 + bi1z + ...+ bitzt mod q
Luego difunde públicamente utilizando broadcast Cik = gaikhbik mod p, para
k = 0, ..., t. El mezclador Mi calcula los valores sij = fi(j) mod q y s′ij =
f ′i(j) mod q, para j = 1, ..., n y los envía en privado (usando encriptación) a
Mj.
16
Cada participante Mj revisa las partes sij, s′ij recibidas de los otros mezcla-
dores. Para cada i = 1, ..., n veri�ca si se cumple lo siguiente:
gsijhs′ij =
t∏k=0
(Cik)jk mod p (2.2)
Si falla para un índice i, el mezclador Mj difunde una queja contra Mi
Una vez completado el paso anterior, todo mezclador Mi que haya recibido
alguna queja de otro participanteMj, difunde públicamente los valores sij, s′ij.
Se considera deshonesto a un mezclador si es que ha recibido más de t quejas en
los pasos anteriores o si los valores publicados en el paso anterior no cumplen
con la ecuación 2.2.
2. Se de�ne QUAL como el conjunto de autoridades honestas, este cálculo se puede
realizar públicamente.
3. La clave privada es x =∑
i∈QUAL ai0 mod q, pero no se calcula directamente. Cada
mezclador Mi calcula primero su parte de la clave privada como
xi =∑
j∈QUAL
sji mod q
4. Cada mezclador Mi cali�cado como honesto en los pasos anteriores publica los
valores Aik = gaik mod p para k = 0, ..., t y también difunde públicamente yi = gxi .
5. Cada mezcladorMj veri�ca los valores enviados en el paso anterior por los distintos
mezcladores mediante la siguiente ecuación:
gsij =t∏
k=0
(Aik)jk mod p (2.3)
Si la revisión falla para algún i, el mezclador Mj se queja contra Mi y publica los
valores sij, s′ij que cumplen con la ecuación 2.2, pero no con la ecuación 2.3.
6. De�nimos como QUEJA al conjunto de todos los mezcladores que recibieron al-
guna queja válida en el paso anterior. Para los mezcladoresMi ∈ QUEJA, el resto
pertenecientes a QUAL\QUEJA recalculan xi, haciéndolo público, por medio de
la reconstrucción del polinomio fi(z) utilizando interpolación de Lagrange y los
valores fi(j) que cada mezclador j ∈ QUAL recibió de Mi. Sea QUAL(t + 1) un
17
subconjunto de t+ 1 mezcladores en QUAL, la fórmula para esto es:
fi(z) =∑
l∈QUAL(t+1)
fi(l) ∏k∈QUAL(t+1),k 6=l
z − kl − k
mod q
Con ello, sij = fi(j) mod q, xi =∑
j∈QUAL sij mod q
7. La clave pública se calcula como y =∏
i∈QUALAi0 mod p.
Salidas públicas y,QUAL, yi|i = 1, ..., n, Aij|i, j = 1, ..., n,QUEJA, xk|k ∈ QUEJA.
Salidas privadas ∀i ∈ QUAL\QUEJA Mi obtiene sij|j ∈ QUEJA, xi.
2.7.2. Desencriptación distribuida
A continuación se muestra una idea básica de un protocolo de descifrado umbral para
un sistema criptográ�co de ElGamal2, con umbral t, n participantes y un texto de entrada
(u, v) = (gr mod p, yrm mod p). En esta demostración se utiliza una prueba de conocimiento
de igualdad de exponentes la que anotaremos como EQDLog(α, β, g, h) y que muestra que
α = ga y β = ha para algún exponente a.
Participantes : Mezcladores M1, ...,Mn.
Entradas públicas : n, p, (g, y), t, QUAL, yi|i ∈ QUAL, (u, v)
Entradas privadas : Cada Mi tiene xi tal que x =∑n
i=1 xi ∧ y = gx mod p ∧ yi =
gxi mod p.
Descifrado : Cada mezclador Mi, publica βi = uxi , junto con una prueba de conocimiento.
Se recupera el mensaje como m = vQi∈QUAL u
xi= v
ux
Salidas públicas : βi, proofi = EQDLog(βi, yi, u, g),m.
2.8. Prueba de conocimiento del mezclador
Una prueba de conocimiento del mezclador es el proceso en el cual se demuestra a los
usuarios del sistema que se realizó el procedimiento de mezcla y re-encriptación en forma
correcta y por lo tanto, que se conoce una permutación y una encriptación válida, sin revelar
2El algoritmo de encriptación es el mismo que en ElGamal clásico
18
información adicional sobre la permutación utilizada sobre los mensajes, ni tampoco sobre
el cifrado de los mismos. En el contexto de este trabajo, también se referirá a estas pruebas
simplemente como pruebas de los mezcladores.
2.8.1. Pruebas de mezclas a través de esquemas de compromisos
Cada mezclador se puede comprometer a una permutación que denotaremos π utilizando
el esquema de Pedersen [11], publica este compromiso y realiza la prueba de conocimiento
sobre éste. De esta forma, demuestra a los usuarios que utiliza una permutación π, sin revelar
su valor. A estos compromisos los llamamos compromisos de permutación.
Un compromiso de permutación debe permitir al participante que se compromete poder
calcular un compromiso Comπ(π) de una permutación π. La propiedad especial que debe
tener un compromiso de permutación es que si el receptor mantiene una lista (e1, ..., eN),
puede transformar este compromiso de permutación en un compromiso de otro tipo, que
llamaremos compromiso de lista, de la forma Come(eπ(1), ..., eπ(N)) y que corresponde a la
lista de elementos que posee, pero en el orden de�nido por π. Otra forma de expresar esta
propiedad es como una transformación de un compromiso; dado un esquema de compromisos
(Genπ, Comπ) de�nido para SN y un esquema de compromisos (Gene, Come) para ZNq , deci-
mos que el primero es un compromiso de permutación válido si se cumple que Genπ = Gene
y existen algoritmos deterministas en tiempo polinomial Map y Rand tal que para cada
ck ∈ CK, rπ ∈ Rck, π ∈ SN y (e1, ..., eN) ∈ ZNq se cumple
Mapck(Comπck(π, r
π), (e1, ..., eN)) = Comeck((eπ(1), ..., eπ(N)), Rand(rπ, (e1, ..., eN)))
En el caso particular del esquema de compromisos de Pedersen, este se modi�ca de tal
forma que el algoritmo Genπ entrega generadores g1, ..., gN , h ∈R Gq. Para una entrada
π ∈ SN y r1, ..., rN ∈ Zq, el algoritmo Comπ calcula ai = hrigπ−1(i) y entrega (a1, ..., aN). El
algoritmo Gene es idéntico a Genπ y ante una entrada (e1, ..., eN) ∈ ZNq y r ∈ Zq, el algoritmo
de compromisos Come calcula a = hr∏N
i=1 geii y devuelve a. Con esto, los algoritmos Mapck
y Randck quedan de�nidos de la siguiente manera:
Rand((r1, ..., rN), (e1, ..., eN)) =N∑i=i
riei
Mapck((a1, ..., aN), (e1, ..., eN)) =N∏i=1
aeii
19
Capítulo 3
Estado del arte
Desde que se propuso la idea de las redes de mezcla por primera vez, se han realizado
diversas implementaciones que han ido adaptando esta idea a través del tiempo. Si bien
existen estas aplicaciones, muchas de ellas se han desarrollado sólo con el �n de estudiar esta
área de la criptografía.
Por otro lado, en el contexto de las comunicaciones anónimas, la idea de las redes de
mezcla ha servido de base para desarrollar diversos protocolos que han ido adaptando la
idea original de Chaum, con el �n de lograr aplicaciones más sencillas, pero que cumplan
con algunas de las características de seguridad que ofrecen las redes de mezcla. Este tipo
de aplicaciones se utilizan principalmente para navegación anónima en internet, donde no se
requiere necesariamente que las redes de mezcla sean robustas.
A continuación se describirán las propuestas teóricas y las dos aplicaciones más conocidas
del ámbito:
3.1. Redes de mezcla clásicas
Este tipo de redes de mezcla corresponden a aquellas que siguen las ideas planteadas
por Chaum. En esta idea, se utiliza el concepto de criptografía de clave pública, donde cada
mezclador tiene asociadas un par de claves, una pública y otra privada, que se utilizan para
encriptar y desencriptar los mensajes. Con esto, el remitente del mensaje original protege
este con la clave del receptor del mensaje, para garantizar que sólo éste lo pueda abrir, pero
además lo cubre con una serie de capas encriptadas utilizando las claves públicas de cada
mezclador, para que cada uno vaya sacando la capa más exterior utilizando su clave privada.
En la �gura 3.1 se puede observar esta idea, donde el mensaje se encuentra al centro y cada
20
capa exterior está asociada a un mezclador por su color y representa una encriptación con
la clave de dicho mezclador. De esta forma, cada uno de estos mezcladores elimina su capa
correspondiente antes de enviar el mensaje.
Figura 3.1: Red de mezcla clásica
Al ser el remitente el encargado de proteger con las diversas capas el mensaje original,
los mezcladores solo se encargan de desencriptar la capa más exterior, generando un nuevo
texto cifrado, que es distinto al original que recibieron, pero como contienen en el fondo al
mismo texto plano, también se trata de una re-encriptación.
3.1.1. Redes de mezcla clásicas robustas
Este tipo de redes de mezcla es utilizada en la propuesta de K. Sako y J. Killian [13], con-
siderando algunas modi�caciones en la re-encriptación de los mensajes con el �n de optimizar
el trabajo realizado en cada mezclador.
En la idea original de Chaum, para que cada mezclador pudiese demostrar la correctitud
de su trabajo, era necesario que los propios remitentes veri�caran si sus mensajes habían sido
procesados en forma correcta. Ante esto, Sako y Killian presentan una idea con la cual cada
mezclador puede probar su trabajo como un conjunto para todos los mensajes que procesa,
entregándole robustez al protocolo. Esta prueba se realiza en dos etapas:
21
Se prueba que cada mensaje ha sido re-encriptado
Se prueba que el conjunto de salida corresponde a una permutación de los textos re-
encriptados
La principal novedad en esta propuesta es la forma en que se prueba la segunda etapa.
Para esto, se genera una nueva permutación y re-encriptación de los mensajes y se comprueba
que esta mezcla se puede obtener tanto desde el conjunto original de mensajes de entrada,
como del conjunto de salida original.
El principal problema de esta propuesta, es que el proceso de generar una nueva permuta-
ción de los mensajes es muy costoso, lo que afecta de gran manera la e�ciencia del protocolo
cuando estamos ante una red de mezcla con varios mezcladores.
3.2. Redes de mezcla re-encriptantes
Estas redes de mezcla di�eren de las anteriores en la forma en que encriptan los datos que
se reciben en cada mezclador. En este caso, el remitente del mensaje no se debe preocupar de
aplicarle una capa por cada mezclador que pasará el mensaje, si no que solo lo protege con
una clave pública (cuya clave privada no es conocida por ningún mezclador). Cada mezclador
re-encripta el mensaje lo cual se puede realizar sin conocer la clave privada.
Con estas redes de mezcla el procedimiento de prueba es muy similar al de las redes
clásicas, ya que se debe comprobar tanto la correcta re-encriptación de los mensajes y la
permutación de los mismos.
La forma en que se realiza esta prueba varía de una propuesta a otra y es lo que �nalmente
determina la e�ciencia de cada una.
Por una parte, la propuesta de J. Groth [8] plantea una nueva forma de realizar estas prue-
bas, consistente en demostrar por una parte, la permutación de algún contenido ya conocido.
Luego se utiliza esta demostración en conjunto con los mensajes re-encriptados, mostrando
que algún contenido conocido, pero relacionado de alguna forma con la re-encriptación de los
mensajes, es permutado correctamente, demostrando así la correctitud del proceso.
Para realizar la prueba de la permutación de los mensajes, se plantea una idea original
basada en la igualdad de polinomios. La idea es básicamente que si tenemos un conjunto de
22
mensajes mi, podemos demostrar el conocimiento de un conjunto de elementos µi tal que se
cumple lo siguiente:
n∏i=1
(mi −X) =n∏i=1
(µi −X)
Si se logra demostrar esta igualdad, basándonos en el supuesto de que cada polinomio
tiene a lo más n raíces, podemos concluir que los elementos µi son una permutación de los
mensajes originales mi, demostrando la existencia de dicha permutación.
Esta idea ha mostrado ser muy e�ciente, ya que el generar el nuevo polinomio es mucho
más rápido que, por ejemplo, crear una nueva permutación de los mensajes.
Por otro lado, D. Wikström [14] plantea una nueva alternativa, en la que propone separar
el proceso de la prueba de la mezcla en dos etapas, una que se puede realizar en forma o�ine
y otra que se realiza online mientras se realiza la mezcla.
En la primera etapa de esta propuesta, cada mezclador se compromete a utilizar una
permutación. Para esto se utiliza algún esquema de compromiso, que permite a un usuario
comprometerse a cierto valor, manteniéndolo oculto, pero entregando la posibilidad de poder
revelar este valor posteriormente. En esta propuesta, los mezcladores si bien se comprometen
a utilizar una permutación, no la revelan en el futuro, si no que demuestran que el valor
comprometido es una permutación válida y que además poseen la capacidad de poder abrir
este compromiso. Para lograr esta demostración, se pueden utilizar diversas herramientas ya
conocidas para demostrar correctitud de una permutación, como por ejemplo, la demostración
para permutaciones de contenido conocido de J. Groth vista en el protocolo anterior.
La segunda etapa del proceso de los mezcladores es mucho más sencilla y sólo consiste en
probar que en la mezcla de los mensajes, se utilizó la permutación comprometida en la primera
etapa. Gracias al proceso realizado previo al procesamiento de los mensajes, la complejidad
de los cálculos hechos en línea es reducida considerablemente, mejorando ampliamente la
e�ciencia del proceso de mezcla.
3.3. Redes de mezcla no robustas
Existen implementaciones de redes de mezcla que no son robustas, ya que con �n de
hacerlas más e�cientes no se implementaron utilizando todos los requerimientos de seguridad
presentes en un red de mezcla, como por ejemplo, realizar las pruebas de conocimiento de las
23
mezclas. Algunas de estas implementaciones que son utilizadas en la práctica se describen a
continuación.
3.3.1. The Onion Routing (TOR)
Este protocolo utiliza la idea original de Chaum para crear una red de enrutamiento de
mensajes y así mantener el anonimato de los usuarios. En TOR [7], los mezcladores de la
red reciben el nombre de Onion Routers, nombre que nace de la similitud de la protección
por capas de los mensajes con las capas de una cebolla. Estos están conectados a través de
canales cifrados y cooperan mutuamente en el reenvío de los datos, de esta forma los datos
van pasando por diversos Onion Routers durante su trayectoria y así se mantienen protegidos
a través de canales seguros.
Uno de los principales problemas que presenta este protocolo, es que los mezcladores no
realizan una prueba de conocimiento y presenta diversas vulnerabilidades si algún mezclador
o un conjunto de estos, se encuentran comprometidos o interferidos por un participante
malicioso.
3.3.2. Crowds
Este protocolo [12] provee al usuario un mecanismo para la navegación anónima en in-
ternet y su funcionamiento es muy similar a Onion Routing. El nombre Crowds se puede
interpretar como muchedumbres o multitudes, la cual hace referencia a la cantidad de mez-
cladores que se encargan del enrutamiento de los datos. En este caso, a diferencia del protocolo
anterior, el camino entre los mezcladores es escogido al azar y los mensajes no son encriptados.
Una vez que se escoge un camino entre la multitud, este es usado para toda la comunicación
anónima entre el iniciador y cualquier destinatario en un periodo de 24 horas.
Con el encaminamiento al azar que se hace de los datos, si un intruso o un miembro
corrupto dentro del grupo de mezcladores colaboradores observa un mensaje siendo enviado
por algún usuario en particular, no puede saber si ese usuario está realmente enviando o sólo
está encaminando un mensaje ajeno.
24
Capítulo 4
Metodología
4.1. Esquema general
Para cumplir los objetivos planteados, en una primera etapa se recopiló el material nece-
sario para realizar los estudios y evaluaciones correspondientes. Posterior a esto, se realizaron
diversas evaluaciones a las propuestas encontradas, determinando cuáles de ellas ofrecen las
mejores alternativas con respecto a la e�ciencia, tanto práctica como teórica.
Una vez realizados los estudios y evaluados los resultados, se procederá a implementar
una red de mezcla dentro de un entorno distribuido. Se evaluará su desempeño y una vez
obtenidos resultados satisfactorios con respecto a las evaluaciones anteriores, se desarrollará
una librería que permita utilizar la implementación de la red de mezcla en forma modular. Es
decir, la solución se desarrollará en la forma de una librería distribuida, con el �n de permitir
poner en ejecución este recurso de diversas maneras.
La primera opción es que esta librería permita a un conjunto de usuarios crear una red
de mezcla, actuando cada uno como un mezclador, pudiendo así crear una red colaborativa
y ser usada en forma interna por el conjunto de usuarios.
Otra opción más general es permitir la oportunidad de crear un servicio donde la librería
es instalada en un conjunto de equipos que actuarán como mezcladores y se pueda acceder
a la red de mezcla que conforman de forma externa y de esta manera utilizar un servicio
de comunicación anónima. Utilizando esta última idea, se puede crear un servicio público de
correo electrónico anónimo.
Un problema a tener presente en el desarrollo de una red de mezcla, es la forma en
que cada mezclador envía sus mensajes al resto de los usuarios del sistema, ya que se debe
implementar alguna forma de difusión de los mensajes. Este problema de difusión o broadcast
25
de los mensajes, no es algo trivial, por lo que se debe tener en consideración a la hora de
implementar el sistema. Para esto, se evaluarán alternativas que ya hayan sido implementadas
y se puedan utilizar como parte de la solución �nal, ya sea directamente o modi�cándolas
para ajustarse a los requerimientos especí�cos de la red de mezcla.
Finalmente, se desarrollará una aplicación de comunicación anónima en forma de proto-
tipo, para utilizar la implementación de la red de mezcla y evaluar su e�ciencia.
4.2. Evaluación de las propuestas
La primera etapa en el desarrollo del proyecto se concentró en la evaluación de las diversas
alternativas para poner en funcionamiento una red de mezcla. Debido a que el objetivo
�nal es lograr una implementación lo más e�ciente posible, esta etapa de estudio se enfocó
principalmente en las propuestas más nuevas y que, en la teoría, han demostrado mejores
resultados en cuanto a la e�ciencia de la red de mezcla.
Ante esto, se decidió implementar las ideas propuestas por D. Wikström [14] quien propo-
ne separar el trabajo de cada mezclador en dos etapas, una que puede llevarse a cabo en forma
previa que el mezclador comience a funcionar, es decir en forma o�ine, y otra etapa online,
que se encarga del funcionamiento del mezclador mientras este se encuentra trabajando, .
Con esta separación del trabajo del mezclador, se logra una notable mejora en el rendi-
miento de cada mezclador a la hora de permutar los mensajes y hacer su prueba de conoci-
miento, ya que en la etapa previa al funcionamiento del mismo, se encarga de hacer el cálculo
de la clave distribuida de los mezcladores y realiza el trabajo correspondiente a la elección de
la permutación y la prueba de conocimiento de la misma, aligerando el trabajo del mezclador
en la fase en línea, haciendo su funcionamiento más e�ciente.
Un problema a tener en cuenta a la hora de implementar esta solución, es que la etapa
o�ine de cada mezclador, se debe hacer antes de cada mezcla de mensajes, ya que para cada
una de estas se debe escoger una permutación distinta. Una buena solución para esto, sin
sacri�car rendimiento de los mezcladores, es separar el trabajo de estos en diversos threads,
que hagan las tareas en forma paralela y así, mientras la fase en linea del mezclador se encarga
de recibir los mensajes, al mismo tiempo se están haciendo los cálculos necesarios para la
permutación de los mensajes y la prueba de conocimiento del mezclador.
26
4.3. Implementación de la solución
Para la implementación de la solución es necesario separar el trabajo en tres partes. Por
un lado, se debe evaluar la implementación de cada mezclador por sí sólo, por otro, se debe
tener en cuenta cómo interactúan los mezcladores entre sí y �nalmente, se debe considerar el
desarrollo de alguna aplicación externa a la red de mezcla y que haga uso de la misma, para
así lograr en conjunto una implementación de una red de mezcla funcional.
4.3.1. Implementación de los mezcladores
Como ya se mencionó previamente, para la implementación de cada mezclador se utilizó
como base la idea propuesta por D. Wikström [14]. Esta propuesta utiliza una red de mezcla
en base al sistema criptográ�co de ElGamal [3] sobre un grupo Gq de orden primo q. En
el desarrollo del mezclador, se divide el trabajo del mismo y las pruebas que realiza de las
permutaciones, en dos etapas, una o�ine, donde el mezclador se compromete a utilizar una
permutación y otra etapa online, en la que se demuestra que ha re-encriptado los mensajes
y los ha permutado y que además se utilizó la permutación ya comprometida.
Fase o�ine
La primera etapa se compone de los siguientes pasos.
1. El mezclador ejecuta un protocolo de generación de claves distribuida para crear una
clave pública conjunta (g, y) tal que la correspondiente clave privada x, con y = gx, es
compartida en forma secreta con los otros mezcladores.
2. El mezclador que notaremos Mj, escoge rj,i ∈ Zp aleatoriamente y calcula (grj,i , yrj,i)
para i = 1, ..., N .
3. Mj escoge una permutación π ∈ Sn en forma aleatoria, publica el compromiso de
dicha permutación el que anotamos aπj = Comπ(πj) y �nalmente hace la prueba de
conocimiento de la permutación comprometida y comprueba las pruebas de los otros
mezcladores.
Para el desarrollo de esta etapa, la primera parte, correspondiente a la generación de
claves distribuida, sólo se debe realizar una vez, por lo que este trabajo se hace al inicializar
los mezcladores.
27
El trabajo correspondiente al cálculo de la permutación y la realización de la prueba de
conocimiento de ésta se debe hacer antes de cada mezcla de los mensajes, por lo que la etapa
o�ine se debe realizar en un thread paralelo a la etapa en línea y se debe sincronizar para
que esta última etapa no haga la permutación hasta que este procedimiento esté completo.
Para realizar las pruebas de permutaciones en cada mezclador, se puede utilizar la pro-
puesta de J. Groth [8] analizada anteriormente en este documento. Para esto, necesitamos
implementar el protocolo que se muestra en el cuadro 4.1, donde se utiliza un esquema de
compromiso de Pedersen como el descrito en la sección 2.8.1 de este documento.
Fase online
La segunda etapa consiste en la realización de los siguientes pasos:
1. Cada remitente de mensaje Si, cifra su mensaje mi. Para esto escoge ri ∈ Zp aleatoria-
mente, calcula (u0,i, v0,i) = E(g,y)(mi, ri), donde mi ∈ Zp es el mensaje.
2. Sea L0 = (u0,i, v0,i)Ni=1 el conjunto de mensajes cifrados de entrada del mezclador. Para
l = 1, ..., k:
Si l = j, entonces el mezcladorMj calcula (uj,i, vj,i) = (grj,iuj−1,πj(i), yrj,ivj−1,πj(i)),
lo que corresponde a una re-encriptación de los mensajes, publica Lj = (uj,i, vj,i)Ni=1
y realiza una prueba de la mezcla a través de compromisos para mostrar que Lj−1
y Lj son consistentes con aπj , calculado en la fase o�ine.
Si l 6= j, entoncesMj revisa la prueba de mezcla a través de compromisos realizada
por Ml, es decir, revisa que Ll−1 y Ll son consistentes con aπj .
3. Los mezcladores realizan un descifrado umbral de Lk, usando sus partes de la clave x
y revelando la lista de textos planos resultantes (mπ(1), ...,mπ(N)), donde π = πk · · · π1
En esta etapa, el mezclador se encarga de permutar, re-encriptar y reenviar los men-
sajes que va recibiendo, emitiendo al mismo tiempo las pruebas de conocimiento de la re-
encriptación de los mensajes. Aquí se debe tener en consideración que para poder realizar el
procedimiento de mezcla, es necesario recibir un conjunto de mensajes relativamente grande
(en particular, mayor que un parámetro �jo µ ≥ 1) para poder garantizar que no se puedan
vincular los valores de entrada con los de salida.
28
PROVER VERIFIEREntrada común:
Parámetros ck de compromiso de permutación válido de Pederseny compromiso aπ = (a1, ..., aN)
Entrada privada:π ∈ SN y rπ ∈ Rπ
ck
tal que aπ = Comπ(π, rπ)Escoge(m1, ...,mN) ∈R [0, 2κe − 1]N y
x, (m1, ...,mN)←−−−−−−−−−−
x ∈R [0, 2κe − 1]
PROVER y VERIFIER calculan c = Map(aπ, (m1, ...,mN))Calcula r = Rand(rπ, (m1, ...,mN))Escoge d1, ..., dN , rd, r∆ ∈R Zq
∆1 = d1,∆2, ...,∆N−1 ∈R Zq,∆N = 0
ai =∏i
j=1 mπ(j) − x, ra ∈R Zq
cd = Come(d1, ..., dn; rd)c∆ = Come((−∆i−1di)i=2,...,N , r∆)ca = Come((∆i+1 − (mπ(i+1) − x)∆i
−aidi+1)i=1,...,N−1, ra) cd, c∆, ca−−−−−→e←− Escoge e ∈R [0, 2κe − 1]
De�nefi = emπ(i) + di, z = er + rdf∆i
= e(∆i+1 − (mπ(i+1) − x)∆i f1, ..., fN , z−−−−−−−→−aidi+1)−∆idi+1,
z∆ = era + r∆ f∆1 , ..., f∆N, z∆−−−−−−−−−−→
Veri�ca quecd, ca, c∆ ∈ Ceckf1, ..., fN , z ∈ Zq
f∆1 , ..., f∆N, z∆ ∈ Zq
cecd?= Come(f1, ..., fN , z)
ceac∆?= Come(f∆1 , ..., f∆N
, z∆)De�ne F1, .., FN tal queF1 = f1 − ex,eFi = Fi−1(fi − ex) + f∆N−1
para i = 2, ..., N
Veri�ca Fn?= e
∏Ni=1mi − x
Cuadro 4.1: Prueba de permutación
29
Por estos motivos, hay que tener en cuenta que los mensajes no siempre llegarán en
grandes cantidades listos para ser permutados y trabajar sobre ellos, por lo que se debe
implementar de tal manera que se esté constantemente recibiendo mensajes y solo comenzar
a realizar el trabajo correspondiente a la permutación una vez que se alcance una cantidad
de mensajes igual a µ y que sea adecuada para realizar la mezcla.
Adicionalmente, como se mencionó en la etapa anterior, se debe tener en cuenta la sin-
cronización con el trabajo que se realiza en paralelo para el cálculo de la permutación.
En el desarrollo de esta etapa, es necesario revisar cómo se realizará la prueba de mezcla
de los mensajes. Para esto, se deben implementar ciertos pasos que permiten llevar a cabo
esta tarea, en ellos, de�niremos el parámetro κr, el que de�ne qué tan bien un esquema de
compromiso esconde el valor comprometido. En primero de estos pasos, es implementar el
protocolo descrito en el cuadro 4.2.
En este protocolo se lleva a cabo una prueba de igualdad de exponentes, paso necesario
para el desarrollo del protocolo de la prueba de conocimiento de la mezcla, como se muestra
en el cuadro 4.3.
En el último paso de este protocolo, el mezclador debe probar que los valores entregados
por éste en su salida, corresponden a un re-encriptación de los datos de entrada, para lo cual
se puede utilizar el protocolo descrito previamente en el cuadro 2.1.
4.3.2. Interacción entre los mezcladores
En cada etapa los mezcladores se deben comunicar entre ellos enviándose continuamente
una gran cantidad de mensajes. Para esto es necesario utilizar alguna herramienta que permita
a cada mezclador enviar sus mensajes a través de la red de mezcla de forma transparente.
Para esto se debe implementar una solución que reciba los mensajes y los distribuya a
través toda la red y que independiente de la forma que lo haga, los mezcladores siempre
interactúan de la misma forma con esta herramienta.
Una primera solución para la interacción entre los mezcladores, es la utilización de un Bu-
lletin Board, esto es, un componente del sistema que se encarga de recibir todos los mensajes
y distribuirlos entre los diversos usuarios de la red. Para esto, es necesario que este compo-
nente tenga una lista de todos los mezcladores involucrados en el protocolo y mantener un
constante contacto con los mismos, recibiendo los mensajes de cada uno y redistribuyéndolos
30
Prueba IgualdadExpPROVER VERIFIER
Entrada común:Clave pública pk para sistema de ElGamal,
conjunto {h1, ..., hk} generador de Cpk,grupo cíclico Gq y sus generadores g, g1, ..., gN ,
compromiso de exponentes a ∈ Gq, textos cifrados (c1, ..., cN) ∈ Cpkcompromiso (b1, b2) con b1 ∈ Gq y b2 ∈ Cpk
PROVER debe mostrar que conoceexponentes s0, ..., sk, e0, ..., eN y tal que se cumple
b1 = Comeck((s1, ..., sk), t0), b2 =
∏ki=1 h
tii
∏Ni=1 (c′i)
e′i ya = Come
ck((e1, ..., ek), e0)Entrada privada:Exponentese0, ..., eN ∈ [0, 2κe − 1] ys0, ..., sk ∈ Zq tal quea = ge0
∏Ni=1 g
eii
b1 = gs0∏k
i=1 gsii
b2 =∏k
i=1 hsii
∏Ni=1 c
eii
Escoget0, ..., tN ∈R [0, 2κe+κc+κr ] yl0, ..., lN ∈R Zq
Calculaα = gt0
∏Ni=1 g
tii
β1 = gl0∏k
i=1 glii
β2 =∏k
i=1 hlii
∏Ni=1 c
tii α, β1, β2−−−−−→
c←− Escoge c ∈R [0, 2κc − 1]
Calculadi = cei + ti mod q, i = 0, ..., Nfi = csi + li mod q, i = 0, ..., k d0, ..., dN , f0, ..., fk−−−−−−−−−−−−−→
Veri�ca si
gd0∏N
i=1 gdii
?= acα
gf0∏k
i=1 gfii
?= bc1β1∏k
i=1 hfii
∏Ni=1 c
dii
?= bc2β2
Cuadro 4.2: Prueba de conocimiento de igualdad de exponentes
31
Prueba ConocimientoMezclaPROVER VERIFIER
Entrada común:Clave pública pk para sistema de ElGamal,
conjunto {h1, ..., hk} generador de Cpk,parámetro de compromiso ck,
compromiso de permutación aπ ∈ Kπck,textos cifrados (c1, ..., cN) ∈ CNpk y (c′1, ..., c
′N) ∈ CNpk
compromiso (b1, b2) con b1 ∈ Gq y b2 ∈ CpkEntrada privada:Permutación π ∈ SNsπ ∈ Rπ
ck
y r1, ..., rN ∈ Rpk
tal queaπ = Comπ
pk(π, sπ)
y c′ = φpk(cπ(i), rπ(i))Escoge
(e1, ..., eN)←−−−−−−−
(e1, ..., eN) con ei ∈R [0, 2κe − 1]
Ambos calculan a = Map(aπ, (e1, ..., eN))Escoget0 ∈R Rck,t1, ..., tk ∈R [0, 2κc+κr − 1],Calculab1 = Come
ck((t1, ..., tk), t0) yb2 =
∏k1=1 h
tii
∏Ni=1 (c′i)
eπ(i) b1, b2−−→PROVER utiliza Prueba IgualdadExp para mostrar que conoce
exponentes t0, ..., tk, (e′1, ..., e′N) = (eπ(1), ..., eπ(N)) y
e0 = Rand(sπ, (e1, ..., eN)) tal que se cumpleb1 = Come
ck((t1, ..., tk), t0), b2 =∏k
i=1 htii
∏Ni=1 (c′i)
e′i ya = Come
ck((e′1, ..., e
′k), e0)
PROVER demuestra que conoce exponentest0, ..., tk y r =
∏Ni=1 r
eii tal que
b1 = Comeck((t1, ..., tk), t0), b2 =
∏ki=1 h
tii φpk(
∏Ni=1 c
eii , r)
Es decir, muestra que la salida es una re-encriptación de los datos de entrada.
Cuadro 4.3: Prueba de conocimiento de mezcla de mensajes
32
a los demás.
Una solución más e�ciente, pero también un poco más compleja que la anterior, es hacer
un Broadcast de los mensajes en red. Para esto es necesario utilizar alguna herramienta que
permita a cada mezclador hacer un broadcast, una emisión constante de los mensajes hacia el
resto de la red. Para esto es necesario que la herramienta encargada de distribuir los mensajes,
mantenga en cada mezclador la lista de los demás usuarios de la red.
Para la implementación de la red de mezcla, en primera instancia se utilizará un Bulletin
Board, ya que es más sencillo de implementar y sirve para comenzar a hacer pruebas sobre
los otros componentes de la implementación de los mezcladores. En la etapa �nal de la
implementación, se evaluará el uso de alguna herramienta de Broadcast existente que haga
más e�ciente el funcionamiento de la red de mezcla.
Uno de los componentes que necesariamente hace uso de esta interacción entre mezcladores
y que adicionalmente presenta una complejidad por sí solo, es la generación distribuida de
las claves para la desencriptación distribuida.
Generación distribuida de claves entre los mezcladores
Para la implementación de este componente se utilizara el protocolo DKG visto con an-
terioridad. Este protocolo debe ejecutarse solo una vez al inicializar la red de mezcla y los
valores calculados aquí serán utilizados por todo el funcionamiento de la red de mezcla. Todos
los valores que son publicados durante la ejecución de este protocolo se deben difundir utili-
zando la herramienta de interacción entre mezcladores escogida, ya sea Broadcast o Bulletin
Board.
4.3.3. Implementación de componentes externos
Una vez desarrollada la red de mezcla como tal, se debe implementar alguna aplicación
que utilice la red y que sea la que interactúe con los usuarios de la misma. A esta aplicación
nos referiremos como Gateway.
La red de mezcla debe de ser implementada de tal manera que su único trabajo para
un observador exterior es la mezcla de los mensajes. De esta manera, es un Gateway el que
sirve como puente de enlace entre la red de mezcla y las aplicaciones o usuarios externos que
deseen utilizar el servicio. Así, la red de mezcla funciona como una librería que es utilizada
para la mezcla de mensajes por cualquier entidad externa.
33
Otro componente externo a tener en cuenta es uno al que llamaremos observador, el que
debe ser capaz de comprobar el correcto funcionamiento de la red de mezcla, por ejemplo,
revisando las pruebas de conocimiento de los mezcladores. Para esto, el observador puede
funcionar como un componente dentro del entorno donde funciona la red de mezcla y pro-
porcionar una interfaz donde usuarios externos puedan ver los valores publicados por los
mezcladores en el proceso o puede ser un servidor escogido por votación entre los usuarios
de la red de mezcla.
Una vez completo el desarrollo del sistema, y con el �n de poner en funcionamiento la
red de mezcla en una etapa inicial, se implementará una aplicación de correo electrónico que
utilice la red de mezcla para lograr anonimato.
34
Capítulo 5
Descripción de la red de mezcla
En esta sección se explicará la solución con más detalle, explicando sus diversos compo-
nentes, funcionalidades y como se realizó la implementación.
5.1. Arquitectura de la solución
La implementación de la solución se puede ver en la �gura 5.1, donde se pueden identi�car
cuatro componentes, los que se listan junto a un identi�cador para referencias posteriores.
Figura 5.1: Esquema de red de mezcla
35
Aplicación de mezcladores (AM): En este esquema, a modo de ejemplo, se utilizarán
tres mezcladores. La red de mezcla debe funcionar correctamente aun cuando una can-
tidad t < n/2 de mezcladores se encuentren comprometidos. Es decir, el protocolo
supone que, en esta caso, a lo más un mezclador puede encontrarse comprometido y
si este intenta alterar algún resultado en cualquier parte del proceso, esto no afectará
el funcionamiento de la red, siendo este mezclador descartado del proceso. Los mez-
cladores se encargan de generar los parámetros necesarios para el funcionamiento del
sistema. Además crean una clave pública bajo la cual los mensajes son re-encriptados (y
permutados). La clave privada correspondiente está distribuida entre los mezcladores
y se utiliza opcionalmente para desencriptar los mensajes al �nal. Durante la ejecu-
ción, cada mezclador debe emitir una prueba de mezcla, demostrando la correctitud
del proceso.
Bulletin Board/Broadcast (BB): Este componente corresponde a la herramienta encar-
gada de distribuir los mensajes de los participantes a través de la red de mezcla, es
decir, se trata de la plataforma de comunicación utilizada por los mezcladores. En el
caso de tratarse de un Bulletin Board, este mantiene la información pública del sistema,
como por ejemplo las listas de participantes corruptos y honestos, la clave pública de
la red de mezcla y los valores públicos de las pruebas de conocimiento. De esta manera,
cada vez que un mezclador desea emitir un mensaje, se lo envía al Bulletin Board y
este se encarga de difundirlo al resto de los participantes. Y en el caso de requerir algún
dato público, se lo consulta a este componente. Si en el futuro se implementara como
una herramienta de broadcast, este componente no almacenaría ninguna información y
solo se encargaría de emitir los mensajes de cada mezclador a través de la red. En este
caso, toda la información la almacenaría localmente cada participante.
Aplicación de observador (AO): Este elemento permitirá a un usuario externo compro-
bar el correcto funcionamiento de la red de mezcla, pudiendo ver y revisar las pruebas
de cada mezclador.
Aplicación de Gateway (AG): Este módulo es el encargado de conectar la red mezcla
con las personas o servicios y aplicaciones de anonimato que quieran utilizar el sistema,
como pueden ser servicios de votación electrónica, correo electrónico anónimo o con-
36
sultas privadas a bases de datos. La idea de implementar este componente es mantener
la red de mezcla funcionando en un ambiente seguro y actuar de puente con el �mundo
exterior�, interactuando con agentes foráneos. De esta manera se puede, por ejemplo,
�ltrar los mensajes que se enviarán al sistema.
5.2. Descripción general del funcionamiento de la solu-
ción
El protocolo en líneas generales se puede ver de la siguiente manera:
1. Fase de inicialización
Los mezcladores a través de AM generan los parámetros iniciales que serán utiliza-
dos en el proceso de mezcla de manera distribuida, de esta manera se requiere de
un conjunto determinado de ellos para realizar el proceso y ningún mezclador en
forma particular puede alterar los datos o resultados del proceso. En este proceso,
los datos públicos son difundidos por la herramienta BB.
Los mezcladores mediante AM generan la clave pública y privada de la red de
mezcla en conjunto de manera distribuida. En cada etapa de este proceso, los
mezcladores deben emitir pruebas de que están ejecutando el protocolo correcta-
mente. De esta forma, si un mezclador actúa en forma deshonesta, es detectado y
descartado por el resto de los mezcladores. Finalmente se emite una clave pública
conocida por todos. En este proceso se utiliza BB para difundir las pruebas y la
clave pública. Este proceso se puede ver en la �gura 5.2.
2. Fase de mezcla de los mensajes
Cada mezclador mediante AM calcula una permutación que utilizará posterior-
mente en el proceso de mezcla. Debe comprometerse públicamente a utilizar esta
permutación y emitir una prueba de conocimiento de la misma, difundida vía el
BB.
A través de AG la red de mezcla recibe un conjunto de mensajes sobre el que se
desea trabajar, encriptados con la clave pública de la red de mezcla. Los mezcla-
dores mediante AM llevan a cabo el proceso de mezcla, es decir, se preocupan de
37
Figura 5.2: Diagrama de �ujo de fase de inicialización
38
permutar y de re-encriptar los mensajes, para lo que deben generar las pruebas de
mezcla respectivas usando BB. Luego envían su conjunto para que otro mezclador
repita el proceso.
Una vez terminadas las mezcla de todos los servidores, se le envía a AG los men-
sajes ya permutados y descifrados en forma conjunta usando AM. Una vez com-
pletado este proceso, los mezcladores calculan una nueva permutación con AM,
repitiendo el proceso inicial y preocupándose de la sincronización para la recepción
de futuros mensajes. La �gura 5.3 representa una visión general de este proceso.
Figura 5.3: Diagrama de �ujo de fase de mezcla de los mensajes
Durante cada una de estas etapas los observadores mediante AO, pueden veri�car que el
procedimiento se esté llevando a cabo de forma correcta, garantizando que la mezcla de los
39
mensajes sigue el protocolo y por ende preserva las garantías de seguridad.
5.3. Protocolo
A continuación se revisará con un poco más de detalle, los procesos involucrados en el
funcionamiento de la red de mezcla:
5.3.1. Generación de parámetros iniciales
Esta es la primera etapa en la cual se generan aquellos parámetros utilizados en el resto
del proceso. Los mezcladores deben seleccionar un par de valores primos grandes p y q, que
cumplan q|(p− 1), además de seleccionar un valor g, que sea generador del grupo Z∗p. Estos
valores son generados por los mezcladores en forma distribuida, para lo cual, solo deben
generar un número aleatorio en conjunto para calcular estos valores a partir de un algoritmo
de�nido según estándares internacionales.
A partir de estos valores es posible además generar el grupo Gq mostrado en la sección
2.4, según lo de�nido en la ecuación 2.1 mostrada en la sección 2.5 de este documento.
Con estos datos ya seleccionados, se pueden de�nir tanto el sistema criptográ�co homo-
mór�co como el esquema de compromisos a utilizar, calculando un parámetro h ∈ Gp. Para
de�nir esto, se utilizarán los valores κ = 1024, κc = κe = 160 y κr = 20. Adicionalmente se
debe �jar un valor N , una constante en esta implementación, que corresponderá al número
de mensajes que procesará en cada proceso de mezcla y a partir de él, cada mezclador Mj
escoge valores rj,1, ..., rj,N ∈R Zp, que como conjunto, corresponden a su clave privada para
la posterior re-encriptación de los mensajes.
La generación de números aleatorios es un procedimiento que se debe realizar de tal mane-
ra que todos los mezcladores participen, evitando que solo un participante del sistema tenga
el control sobre los mismos. Para lograr esto se ejecuta el protocolo DKG con parámetros
p, q, g �jos para producir y′ = gx′y de esta manera, los mezcladores utilizarán el valor y′
como semilla para la generación de valores aleatorios posteriores. Una manera de lograr esto
es calcular una función de hash sobre este valor, con lo que se conseguirá una cadena de la
cual los mezcladores obtendrán un pedazo cada vez que necesiten un valor aleatorio durante
la ejecución del algoritmo de generación de parámetros.
40
5.3.2. Protocolo de generación de claves distribuida
Para esta parte, se utiliza el protocolo DKG detallado en la sección 2.7.1 de este docu-
mento. El valor de n dependerá de cuantos mezcladores se deseen conectar, por lo que no
es un número invariable, pero que a modo de ejemplo �jaremos en 3. Los demás valores pú-
blicos a utilizar serán los parámetros p, q, g, h obtenidos en el paso inicial y t de�nido como
t = n/2− 1 si n es par o t = (n− 1)/2 en caso contrario. En nuestro ejemplo, tenemos t = 1.
5.3.3. Generación de parámetros para las mezclas
Antes de realizar una mezcla de mensajes, cada mezclador debe escoger una permutación
π que utilizará solo para un conjunto de mensajes. En esta etapa los mezcladores realizan
la prueba de conocimiento de su permutación y se comprometen a utilizarla en su próxima
mezcla, ejecutando el protocolo detallado en la sección 4.3.1.
5.3.4. Mezcla de los mensajes
En esta etapa, al enviar un conjunto de mensajes a la red para iniciar el proceso de mezcla,
estos son encriptados por el remitente usando la clave pública de la red y se almacenan en un
arreglo llamado L0. Cada mezclador en secuencia, recibe el conjunto de mensajes y ejecuta
el paso 2 de la fase online del protocolo, detallado en la sección 4.3.1.
Cada mezclador recibe el vector de mensajes Li y revisa el índice del mismo para ver si
es su turno para realizar la permutación y re-encriptación de los mensajes. De ser así, realiza
el proceso de mezcla y emite las pruebas correspondientes. De no ser su turno y en caso de
no corresponder al vector inicial, quiere decir que el vector corresponde a una mezcla de otro
participante, por lo que cada mezclador debe comprobar que el valor de L sea correcto viendo
las pruebas emitidas por el participante que envío el vector de mensajes.
5.3.5. Descifrado umbral
Una vez que todos los mezcladores terminaron el proceso de permutación y re-encriptación
de los mensajes, se ejecuta sobre el ultimo vector de mensajes un descifrado umbral, obtenien-
do el conjunto de mensajes originales, pero permutados en un orden π = πn ◦ ... ◦ π1, donde
πi es la permutación realizada por el mezcladorMi. La idea básica de protocolo de descifrado
umbral se puede ver explicada en la sección 2.7. Al implementar esta idea se le deben agregar
41
pruebas de conocimiento en cada desencriptación parcial realizado por los mezcladores, para
probar que las claves parciales usadas en la desencriptación corresponden a claves parciales
distribuidas en el protocolo DKG.
5.4. Detalle de la implementación
La implementación se llevó a cabo utilizando el lenguaje de programación Java (JDK
v1.6). Se usaron las librerías criptográ�cas provistas por el kit de desarrollo java a través del
paquete java.security y el mecanismo Java RMI para invocar un método de manera remota.
Los mensajes y los datos enviados vía RMI son �serializados� a un formato XML antes de ser
enviados.
5.4.1. Módulos implementados
Para la implementación de los módulos se utiliza la clase BigInteger para representar los
parámetros y las variables en los sistemas de encriptación y compromisos. La clase llamada
DSAParams almacena los párametros p, q y g, utilizados en el protocolo. Para la generación
de números aleatorios se utiliza la clase SecureRandom y para el cálculo de funciones de hash
se utiliza la clase MessageDigest.
Adicionalmente se crearon clases propias para representar algunos de los elementos utiliza-
dos en el protocolo, como por ejemplo la clase CryptoSystem y CommitmentScheme, usados
para representar al sistema de encriptación y al esquema de compromisos respectivamente,
así como también la clase ZKP, para representar una prueba de conocimiento.
A continuación se presenta una vista general de los principales módulos implementados.
1. Generación de claves de �rma y encriptación (Mezclador.java): Cada mezclador en
forma local genera un par de claves pública y privada que utilizará en la �rma y en-
criptación de los mensajes a los otros mezcladores.
2. Generación de parámetros iniciales (Generador.java): Al comienzo de este módulo se
ejecuta una modi�cación del protocolo DKG con el �n de obtener una cadena aleatoria
que se utilizará para las futuras pruebas que necesiten valores aleatorios públicos. Este
módulo es utilizado por lo mezcladores para calcular los parámetros iniciales a utilizar
en el sistema. Sus principales funciones son:
42
public DSAParams getParams():
Esta función retorna los parámetros p, q y g, generados aleatoriamente.
public CryptoSystem getCryptoSystem():
Obtiene el sistema de encriptación homomór�co a ser utilizado.
public CommitmentScheme getCommitmentScheme():
Obtiene el esquema de compromisos a utilizar.
3. Protocolo de generación de claves distribuida (Mezclador.java): En este módulo los
mezcladores generan primero su par de claves para la encriptación y �rma de mensajes
a otros mezcladores y envían la información pública al resto de los participantes a
través de la herramienta de comunicación, ya sea Bulletin Board o Broadcast, para dar
inicio al protocolo de generación de claves distribuido, como se indica en la sección
2.7.1. Al comenzar la ejecución del protocolo DKG los mezcladores envían paso a paso
los valores generados a través de la herramienta de comunicación y van recibiendo los
valores publicados por los demás mezcladores. Los pasos a seguir son:
Se generan los polinomios descritos en este protocolo de manera aleatoria. Para
esto, se generan el par de coe�cientes aleatorios correspondientes para cada poli-
nomio.
Luego cada mezclador calcula y emite los valores Cik y sij. Estos últimos van en-
criptados para el mezclador correspondiente utilizando las claves públicas creadas
antes de comenzar este protocolo.
Cada autoridad veri�ca los datos de los otros mezcladores. Para ello, primero
revisa si los datos tienen una �rma válida y de ser así, revisa si los valores enviados
corresponden a lo indicado por el protocolo. Finalmente, cada mezclador envía un
arreglo de valores indicando si hay quejas para cada otro mezclador. Luego, recibe
los valores enviados por los otros mezcladores.
Se veri�can los valores recibidos y se forma el conjunto de mezcladores honestos
QUAL, revisando que no tengan más de una queja válida. En caso contrario, se
descarta automáticamente al mezclador.
Se generan las partes de la clave privada según lo especi�cado en el protocolo y
los valores Aij que luego son publicados vía el Bulletin Board o broadcast.
43
Los mezcladores veri�can los datos recibidos de los otros participantes y de existir
algún participante contra el que se presentan al menos t+1 quejas, este se considera
deshonesto y se procede a reconstruir su polinomio utilizando interpolación de
Lagrange y se emite este resultado, junto con el cálculo del trozo de clave del
mencionado mezclador.
Cada mezclador considerado honesto en este punto, calcula la clave pública y la
emite utilizando la herramienta de comunicación.
Las salidas privadas de cada mezclador son almacenadas por cada uno, para luego
ser utilizado en el proceso de descifrado.
4. Fase o�ine de mezcla de mensajes (Mezclador.java): En este módulo cada mezclador
implementa la fase o�ine del proceso de mezcla de mensajes explicado en la sección
4.3.1, pero sin incluir el protocolo DKG. Los pasos son los siguientes:
Cada mezclador Mj escoge N variables rji aleatoriamente y calcula (grji , yrji),
valores que serán usados para la re-encriptación de los mensajes.
Se crea una permutación π en forma aleatoria y emite un compromiso aπ a dicha
permutación.
Para realizar la prueba de conocimiento de la permutación, se escoge un frag-
mento de la cadena generada en el primer módulo y lo utiliza para generar los
valores ei para calcular c = Map(aπ, (e1, ..., eN)) y publicar este valor, junto con
la aleatoriedad usada.
Se calculan los valores necesarios para realizar la prueba y se publican.
Cada mezclador revisa los valores de las pruebas de conocimientos publicados por
los demás, de encontrarse datos erróneos, se descartan mezcladores de la misma
forma que en el protocolo DKG.
5. Fase online de mezcla de mensajes (Mezclador.java): En este módulo cada mezclador
hace una re-encriptación y permutación de los mensajes recibidos, haciendo las prue-
bas de conocimiento necesarias. Se ejecuta el protocolo detallado en la sección 4.3.1,
siguiendo la misma dinámica de los protocolos anteriores ejecutados por el mezclador.
El único cuidado adicional que se debe tener, es que al momento de comenzar a realizar
44
las mezclas, se debe tener una permutación nueva que no haya usado antes, por lo que
se ejecuta en forma paralela la fase o�ine y se espera que esta termine para seguir con
el protocolo.
6. Protocolo de descifrado umbral (Mezclador.java): En este módulo cada mezclador hace
un descifrado parcial del vector de textos encriptados y permutados siguiendo el pro-
tocolo indicado en la sección 2.7 y siguiendo la misma dinámica de pruebas que las
emitidas para mostrar la re-encriptación de los mensajes.
7. Herramienta de comunicación (Comunicacion.java): Corresponde al Bulletin Board o
a Broadcast, según como se desee implementar. En este desarrollo solo se implementó
el Bulletin Board y este se encarga de recibir valores y publicarlos para que el resto
de los participantes tenga acceso a ellos, ya que estos son de acceso público. Algunas
funcionalidades se detallan a continuación:
public Comunicacion():
Constructor, permite generar un objeto sobre el que trabajarán todos los mezcla-
dores mediante el uso de Java RMI.
public ZKP[] publicaZKP(ZKP[] zkp, String proceso):
Corresponde a la función accedida por los mezcladores para publicar los datos que
desean hacer públicos en las pruebas de conocimientos realizadas, para el proceso
identi�cado.
public ZKP[] solicitaZKP(String proceso):
Los mezcladores o un observador puede obtener las pruebas de todos los mezcla-
dores para el proceso identi�cado.
public String[] solicitaMensajes():
Obtiene los mensajes que deben ser permutados. El formato de los mensajes se
encuentra en formato XML
public String[] publicaMensajes(String[], int i):
Publica los mensajes que deben ser permutados.
public int publicaPK(PublicKey pk, int identi�cador):
Funcionalidad para que cada mezclador, singularizado por el identi�cador, publi-
45
que su clave pública individual.
PublicKey solicitaPK(int identi�cador):
Obtiene la clave pública del mezclador indicado por el identi�cador.
PublicKey solicitaMixPK():
Obtiene la clave pública de la red de mezcla.
8. Aplicación de observador (Observador.java):
Esta aplicación tiene acceso a todas las pruebas realizadas por los mezcladores, revisar
que los procesos se han realizado en forma correcta. Entre otras cosas puede revisar lo
siguiente:
Veri�cación de la generación de parámetros. Puede revisar si los parámetros ini-
ciales son válidos.
Veri�cación de las pruebas de conocimiento. Puede revisar las pruebas de conoci-
miento de los mezcladores en cada etapa para determinar y los procedimientos se
llevaron a cabo de forma correcta.
9. Gateway (Gateway.java):
Es la aplicación encargada de enlazar la red de mezcla con el mundo exterior. Se comuni-
ca con el Bulletin Board para obtener la clave pública de la red de mezcla y entregársela
a los usuarios �nales del sistema para que la utilicen al encriptar los mensajes inicial-
mente.
Recibe mensajes desde el exterior y cuando acumula un conjunto de ellos adecuado
para iniciar el proceso de mezcla, se lo envía a la herramienta de comunicación de los
mezcladores para iniciar el proceso de mezcla. Una vez terminado el proceso, recibe los
mensaje en un orden distinto para ser publicados a los usuarios externos.
Para motivos de hacer pruebas, se desarrolló un ejemplo de aplicación de correo elec-
trónico dentro del mismo Gateway, con la funcionalidad de ir almacenando localmente
los mensajes y enviarlos cuando se acumule una cantidad determinada.
46
5.5. Evaluación de rendimiento
Para evaluar el rendimiento de la red mezcla y determinar su e�ciencia, se debe compararar
con otros protocolos propuestos hasta ahora. Para esto se debe hacer una comparación del
número de exponenciaciones que realizan el prover y el veri�er en cada protocolo para N
mensajes.
Se consideran en esta evaluación algunos de los protocolos que han mostrado ser los más
e�cientes, estos son los de J. Furukawa [4], J. Groth [8], J. Furukawa y K. Sako [5], J. Groth
y S. Lu [9] y �nalmente la propuesta de D. Wikström [14] implementada en este trabajo.
En esta comparación se evaluan los protocolos utilizando el sistema criptográ�co de El-
Gamal [3] y el esquema de compromisos de Pedersen [11] con números primos p, q donde
q|(p− 1), |q| = 160 y |p| = 1024. Se tomarán como referencias los cálculos realizados por los
autores en cada una de las propuestas.
Furukawa-Sako [5] Furukawa [4] Groth-Lu [9] Groth [8] Wikström [14]Prover 8N 7N 7N 6N NVeri�er 10N 8N 8N 6N N
Cuadro 5.1: Comparación de mezclas de argumentos
Como se puede ver en la tabla 5.1, el protocolo implementado en este trabajo es conside-
rablemente más e�ciente que el resto.
47
Capítulo 6
Usos de una red de mezcla y desafíos enla práctica
6.1. Utilización de una red de mezcla
La idea original de las redes de mezcla es la base para la implementación de la mayoría de
protocolos de anonimato. Actualmente las implementaciones de redes de mezcla no son muy
e�cientes para su uso continuo, por lo que no es muy factible utilizarlas para implementar
algún otro protocolo que necesite hacer uso de la red en forma frecuente.
Es por esto que la implementación de una red de mezcla e�ciente es sumamente útil para
ser utilizada como base para la implementación de algún sistema de comunicación anónima
que sea con�able y óptimo en su tiempo de ejecución.
Algunos ejemplos de aplicaciones que podrían utilizar a una red de mezcla para lograr
anonimato:
Protocolos de votación electrónica : Es evidente que en cualquier tipo de elección es
un requisito imprescindible mantener el voto de cada persona en secreto, pero además
se debe ser capaz de poder contar todos los votos sin revelar al votante. En este caso
se puede utilizar el sistema implementado para mezclar los votos encriptados de los
electores, emitiendo dicho voto a través de alguna terminal conectada a un Gateway de
entrada. Para confeccionar este protocolo, se debe elaborar alguna forma de validación
adicional para que los electores autenti�quen y demuestren la correctitud de sus votos.
Consultas anónimas a bases de datos : Existen bases de datos con información rele-
vante sobre ciertos temas que tienen algún nivel de prejuicio a nivel social, como por
ejemplo, bases de datos con antecedentes sobre pacientes con SIDA, o de organizacio-
48
nes como alcohólicos anónimos. En esos casos, se requiere poder realizar algún tipo
de consulta sobre esta información, manteniendo en secreto a la persona que consul-
ta. Notar que una manera de consultar podría ser enviar un mensaje de la forma
m = (Consulta, pk); el servidor simplemente contesta a la consulta encriptando la
respuesta con la clave pública pk y publicándolo en un Bulletin Board.
Denuncias anónimas : Es muy común hoy en día que exista un miedo por parte de la
población para denunciar algún delito, ya que existe la posibilidad de que al conocerse
la identidad del denunciante, este corra algún tipo de peligro. Es por eso que se han im-
plementado líneas de denuncia anónimas, donde se puede entregar datos e información
relevante sobre alguna situación que se quiera denunciar, manteniendo desconocida la
identidad del delator.
Servicios de correo anónimo : En diversas ocasiones se requiere enviar algún correo elec-
trónico sin que se conozca el origen del mismo, como por ejemplo, en casos que los
correos pueden ser interceptados o monitoreados. Este caso puede ser un poco más
delicado, ya que al implementarse un sistema de correo que funcione en forma pública,
se pude prestar para malos usos, como el enviar correo basura en forma anónima. De
todas maneras, por su simplicidad un prototipo de esta aplicación fue implementado
en este trabajo.
6.2. Desafíos en la práctica
6.2.1. Mejoras de rendimiento
Si bien esta implementación es e�ciente y utiliza algunas de las herramientas mejor ca-
talogadas por los estudios realizados en la actualidad, el buen rendimiento del sistema está
dado por como realiza el proceso de mezcla de los mensajes. Aunque en un futuro podría
mejorarse este aspecto debido a nuevos estudios o el desarrollo de nuevas herramientas, es
muy probable que su rendimiento no se vea muy incrementado sin sacri�car su seguridad.
Sin embargo, al utilizar el sistema como base para otro más grande, se podrían lograr
algunas mejoras de rendimiento cambiando algunos aspectos de la implementación con res-
pecto a algún detalle especí�co del sistema �nal. Por ejemplo, se podrían hacer cambios en
el sistema de comunicaciones de la red, para enviar algún tipo de mensajes especí�co propio
49
del nuevo sistema, con lo que se podría mejorar el rendimiento en el envío de datos por la
red.
6.2.2. Mejoras de funcionalidad
Otro aspecto a tener en cuenta en la utilización de la red de mezcla con otros servicios, es
la forma en que interactúa la red con el exterior, ya que se podrían lograr mejoras sustanciales
creando un gateway especí�co para el nuevo servicio conjunto, lo que si bien mantiene intacto
el funcionamiento y rendimiento interno de la red de mezcla, podría mejorar sustancialmente
la interacción con los usuarios.
6.2.3. Ataques y conectividad
Una de las principales riesgos a los que se ve expuesto cualquier aplicación o servicio en
la red, es a los ataques de denegación de servicios o DoS. Estos tipos de ataques son los más
comunes ya que son muy fáciles de llevarse a cabo.
Una forma de ejecutar este tipo de ataques es llenar la red con datos sin sentido para evitar
que los mensajes legítimos puedan pasar a través de esta. Otro tipo de ataque es saturar un
servidor con tareas inútiles, haciendo que utilice todos sus recursos e impidiendo que este se
conecte con los usuarios que quieran hacer uso del sistema. Estos ataques pueden ser mucho
peores si son realizados por diversas máquinas cooperando entre sí, lo que se conoce como
ataque de denegación de servicios distribuido o DDoS. Estos últimos ataques es común verlos
con equipos infectados con algún tipo de virus que los convierte en esclavos del atacante real.
Actualmente existen propuestas de algoritmos de ruteo de mensajes para prevenir ciertos
ataques DoS, sin embargo es posible que no exista una solución de�nitiva durante un largo
período de tiempo. Por este motivo, se deben tener ciertos cuidados adicionales para tratar
de disminuir el impacto de estos ataques.
Una forma de tomar precauciones ante estos ataques, es implementando un conjunto
de Gateways en la red de mezcla, de manera que estos actúen en forma distribuida para
administrar los mensajes que ingresan al sistema y las conexiones de elementos externos a la
red. Además, por tratarse de varios equipos trabajando en manera cooperativa, los ataques
DoS serían más complejos ya que deberían atacar en forma conjunta a todos los Gateways
para hacer caer el servicio. La estructura de esta solución se puede ver en la �gura 6.1.
50
Figura 6.1: Esquema de red de mezcla con diversos Gateways
51
Capítulo 7
Conclusiones
En base a los objetivos planteados inicialmente se puede concluir que:
A través de la comprensión de los fundamentos en el funcionamiento de una red de
mezcla y del estudio de diversas propuestas, fue posible desarrollar una solución e�-
ciente y que permite demostrar su correcto funcionamiento a la hora de mezclar los
mensajes recibidos. Esta implementación utiliza las herramienta más actuales, las que
principalmente están enfocadas en agilizar el proceso de demostración de que el trabajo
de cada mezclador es válido y correcto, y que han demostrado ser las más e�cientes a
la hora del funcionamiento de la red de mezcla. El esquema se implementó basado en lo
propuesto por D. Wikström [14], integrando demostraciones expuestas por J. Groth [8],
las que en conjunto representan las ideas más e�cientes propuestas hasta el momento.
La solución utilizó en su implementación, diversas herramientas propuestas por exper-
tos, como por ejemplo, el protocolo DKG para la generación de claves distribuidas.
Estos módulos de la red de mezcla fueron desarrollados en forma independiente y son
interesantes de por si. Pueden cambiarse de encontrar en el futuro mejores métodos.
Los mensajes son cifrados utilizando sistemas criptográ�cos homomór�cos basados en
logaritmo discreto. En este caso se realizó una implementación utilizando ElGamal, pero
el funcionamiento de la red es independiente del sistema que se utilice, por lo que si
se desea, se puede fácilmente implementar el uso de algún otro sistema de encriptación
homomór�co como Pallier [10], por lo que ofrece �exibilidad en este aspecto.
La implementación del sistema permite cambiar el Bulletin Board usado como herra-
mienta de comunicación por un protocolo de broadcast.
52
La red de mezcla esta desarrollada de tal manera que funciona como una librería distri-
buida, por lo que puede ponerse en funcionamiento y ser utilizada por otras aplicaciones
o usuarios de la manera que estos estimen conveniente. Por ejemplo, puede implemen-
tarse como una red cerrada para el uso interno de usuarios locales, como también puede
ponerse en funcionamiento a través de diversos equipos en la red para ofrecer un servi-
cio de conexión global. En el caso particular planteado en los objetivos de este trabajo,
la red de mezcla puede ser utilizada por un servicio de correo electrónico que permita
ofrecer anonimato a sus usuarios.
Implementar una red de mezcla claramente no lo es todo, ya que esta es simplemente una
herramienta que le permite a otros servicios implementar comunicación anónima en la red, sin
embargo, esta herramienta es la columna vertebral en la gran mayoría de estos protocolos.
Al lograr el desarrollo de una base e�ciente y segura para estos otros servicios, se puede
lograr un avance en el desarrollo de soluciones que ofrezcan anonimato, siendo estas ágiles y
utilizables en el día a día por las personas.
Los protocolos de comunicación anónima son herramientas muy fuertes y útiles si se
utilizan correctamente. Lamentablemente existe una visión critica cuando se habla de ano-
nimato, ya que se suele asociar inmediatamente a la necesidad de ocultarse para hacer algo
malo. Pero al mirar estos protocolos se debe ver también sus usos prácticos y necesarios
para las personas, ya que bajo diversos contextos, proteger la identidad de las mismas es de
vital importancia. En nuestra vida diaria nos encontramos con variadas situaciones en las
que mantener el anonimato es una necesidad, o bien un derecho, como por ejemplo en los
servicios electorales, las denuncias o �tips� anónimos a las autoridades, consultas de datos
o información sensible socialmente, etc. Considerando que en el tiempo, la gran mayoría de
estas situaciones se llevan a cabo utilizando medios tecnológicos, la implementación de una
herramienta que ofrezca e�ciencia y seguridad para su realización es un gran paso adelante.
53
Referencias
[1] M. Blum, P. Feldman, and S. Micali. Non-interactive zero-knowledge and its applica-
tions. In Proceedings of the twentieth annual ACM symposium on Theory of computing,
pages 103�112, New York, NY, USA, 1988. ACM.
[2] D. L. Chaum. Untraceable electronic mail, return addresses, and digital pseudonyms.
Commun. ACM, 24(2):84�90, 1981.
[3] T. ElGamal. A public key cryptosystem and a signature scheme based on discrete
logarithms. In Proceedings of CRYPTO 84 on Advances in cryptology, pages 10�18,
New York, NY, USA, 1985. Springer-Verlag New York, Inc.
[4] J. Furukawa. E�cient and veri�able shu�ing and shu�e-decryption. IEICE Trans
Fundamentals, E88-A(1):172�188, 2005.
[5] J. Furukawa and K. Sako. An e�cient scheme for proving a shu�e. In CRYPTO
'01: Proceedings of the 21st Annual International Cryptology Conference on Advances
in Cryptology, pages 368�387, London, UK, 2001. Springer-Verlag.
[6] R. Gennaro, S. Jarecki, H. Krawczy, and T. Rabin. Secure distributed key generation
for discrete-log based cryptosystems. Journal of Cryptology, 20(1):51�83, 2007.
[7] D. M. Goldschlag, M. G. Reed, and P. F. Syverson. Hiding routing information. In
Proceedings of the First International Workshop on Information Hiding, pages 137�150,
London, UK, 1996. Springer-Verlag.
[8] J. Groth. A veri�able secret shu�e of homomorphic encryptions. In PKC '03: Procee-
dings of the 6th International Workshop on Theory and Practice in Public Key Crypto-
graphy, pages 145�160, London, UK, 2003. Springer-Verlag.
54
[9] J. Groth and S. Lu. Veri�able shu�e of large size ciphertexts. In Public Key Cryptography
� PKC 2007, volume 4450 of Lecture Notes in Computer Science, pages 377�392. Springer
Berlin, June 2007.
[10] P. Pallier. Public-key cryptosystems based on composite degree residuosity classes. In
Advances in Cryptology - EUROCRYPT '99, volume 1592 of Lecture Notes in Computer
Science, pages 223�238. Springer-Verlag, 1999.
[11] T. P. Pedersen. Non-interactive and information-theoretic secure veri�able secret sha-
ring. In CRYPTO '91: Proceedings of the 11th Annual International Cryptology Confe-
rence on Advances in Cryptology, pages 129�140, London, UK, 1992. Springer-Verlag.
[12] M. K. Reiter and A. D. Rubin. Crowds: Anonymity for web transactions. ACM Tran-
sactions on Information and System Security, 1(1):66�92, 1998.
[13] K. Sako and J. Kilian. Receipt-free mix-type voting scheme: A practical solution to
the implementation of a voting booth. In Proceedings of Advances in Cryptology -
EUROCRYPT '95, volume 921 of Lecture Notes in Computer Science, pages 393�403.
Springer Berlin, 1995.
[14] D. Wikström. A commitment-consistent proof of a shu�e. versión preliminar en Works-
hop on Trustworthy Elections WOTE'08, Leuven, Belgica, 2008.
55