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