Você está na página 1de 132

PROTOCOLOS SEGUROS PARA JOGOS EM REDES PEER-TO-PEER

Bernardo de Melo Pacheco

Disserta ca o de Mestrado apresentada ao Programa de P os-gradua ca o em Engenharia de Sistemas e Computa ca o, COPPE, da Universidade Federal do Rio de Janeiro, como parte dos requisitos necess arios ` a obten ca o do t tulo de Mestre em Engenharia de Sistemas e Computa ca o. Orientador: Geraldo Bonorino Xex eo

Rio de Janeiro Setembro de 2013

PROTOCOLOS SEGUROS PARA JOGOS EM REDES PEER-TO-PEER Bernardo de Melo Pacheco DISSERTAC AO SUBMETIDA AO CORPO DOCENTE DO INSTITUTO ALBERTO LUIZ COIMBRA DE POS-GRADUAC AO E PESQUISA DE ENGENHARIA (COPPE) DA UNIVERSIDADE FEDERAL DO RIO DE JANEIRO COMO PARTE DOS REQUISITOS NECESSARIOS PARA A OBTENC AO DO GRAU DE MESTRE EM CIENCIAS EM ENGENHARIA DE SISTEMAS E COMPUTAC AO.

Examinada por:

Prof. Geraldo Bonorino Xex eo, D.Sc.

Prof. Jano Moreira de Souza, Ph.D.

Prof. Jos e Ant onio Moreira Xex eo, D.Sc.

RIO DE JANEIRO, RJ BRASIL SETEMBRO DE 2013

Pacheco, Bernardo de Melo Protocolos Seguros para Jogos em Redes Peer-toPeer/Bernardo de Melo Pacheco. Rio de Janeiro: UFRJ/COPPE, 2013. XIII, 119 p.: il.; 29, 7cm. Orientador: Geraldo Bonorino Xex eo Disserta ca o (mestrado) UFRJ/COPPE/Programa de Engenharia de Sistemas e Computa ca o, 2013. Refer encias Bibliogr acas: p. 106 111. 1. Rede peer-to-peer. 2. Protocolo criptogr aco. 3. Jogo distribu do. I. Xex eo, Geraldo Bonorino. II. Universidade Federal do Rio de Janeiro, COPPE, Programa de Engenharia de Sistemas e Computa ca o. III. T tulo.

iii

` minha fam A lia, pelo eterno incentivo.

iv

Agradecimentos
Agrade co a Deus, por me fortalecer nos meus desaos e por me ajudar em todos os momentos, principalmente nos mais dif ceis. Ao meu pai, Jos e Fel cio Pacheco, pois sem voc e eu jamais estaria aqui. Sinto muito a sua falta e lamento por voc e ter me deixado durante o mestrado. Voc e, meu pai, trabalhou desde muito pequeno para sustentar a sua fam lia, e abriu m ao dos seus estudos. Por em, nunca conheci pessoa t ao s abia. Se h a um mestre aqui, este mestre e voc e. ` minha m A ae, Ver onica de Melo Pacheco, pelo seu amor materno. Seu apoio foi e ainda e fundamental para a minha cria ca o e forma c ao. Voc e e o meu porto seguro. Aos meus irm aos, Humberto de Melo Pacheco, Eduardo de Melo Pacheco e Fernanda de Melo Pacheco, pela compreens ao da minha aus encia nos almo cos e nais de semana. ` minha namorada e futura esposa Caroline Kurtemback. Sem voc A e eu n ao teria conseguido. Voc e esteve sempre comigo, me apoiando, confortando e incentivando. Voc e deixou muitas coisas suas de lado pensando em mim. Muito obrigado. ` minha av A o Rita de Mattos e amiga Cristina Mello pelo suporte familiar e tamb em pelo delicioso feij ao que me sustentou nos meus estudos. Ao meu amigo e irm ao Fenando Neves pelo apoio durante o mestrado e pela compreens ao da minha aus encia no u ltimo ano. Ao meu orientador e professor Geraldo Bonorino Xex eo pela aten ca o, tempo, conan ca e conhecimento gastos neste trabalho. Muito do que aprendi neste trabalho foi voc e que me mostrou o caminho. Saiba que aprendi muito, e sou muito grato. Aos meus amigos da empresa DotLegend pela conan ca e paci encia: Bruno Goyanna, Carlos Eug enio, Daniel Gouvea, F abio Freitas, F abio Souza, Fl avio Faria, Hor acio Fran ca, Jo ao Pap, J ulio Brafman e Roberto Ferreira. Em especial, agrade co aos meus amigos L ucio Paiva e Bruno Fran ca pela paci encia que tiveram comigo durante este trabalho. Voc es me ensinaram muito, sempre com conselhos valiosos. Tenho certeza de que este trabalho enriqueceu por causa de voc es. Aos meus amigos de gradua c ao e mestrado Allan Gir ao, Andr e Bakker, Arthur Siqueira, Diego Marins, Filipe Braida, Marcelo Justo, Pedro Ivo e Roque Pinel. Conquistamos muitas coisas juntos. v

Ao professor Jano Moreira de Souza, pela oportunidade concedida para a realiza ca o do mestrado na linha de Banco de Dados e por aceitar participar da minha banca de defesa de mestrado. Ao professor Jos e Ant onio Moreira Xex eo por participar da minha banca de defesa de mestrado e por contribuir com o seu conhecimento. ` CAPES, pelo apoio nanceiro durante o mestrado. A

vi

Resumo da Disserta c ao apresentada a ` COPPE/UFRJ como parte dos requisitos necess arios para a obten ca o do grau de Mestre em Ci encias (M.Sc.)

PROTOCOLOS SEGUROS PARA JOGOS EM REDES PEER-TO-PEER

Bernardo de Melo Pacheco Setembro/2013

Orientador: Geraldo Bonorino Xex eo Programa: Engenharia de Sistemas e Computa ca o Em um ambiente ponto-a-ponto, a seguran ca de uma aplica ca o est a distribu da entre todos os participantes, ou seja, n ao h a um servidor com o papel de parte con avel no sistema. Protocolos criptogr acos s ao formas que determinam as regras de como cada participante se comunica, e que t em por objetivo garantir a justi ca no sistema. Mental Poker e Fair Coin Flipping s ao problemas comuns tratados na literatura de criptograa com aplica co es dentro e fora da a rea de jogos. Mental Poker trata dos problemas de gerenciar um baralho, garantindo, por exemplo, que as cartas s ao distribu das com a mesma probabilidade entre os jogadores e que nenhum jogador consiga ver as cartas do outro. Fair Coin Flipping trata dos problemas de gerar um n umero aleat orio, seja uma moeda ou um dado, garantindo que nenhum jogador consiga desbalancear o n umero gerado a seu favor. No entanto, h a uma car encia de implementa co es pr aticas e de uso desses protocolos aplicados a jogos em um ambiente ponto-a-ponto. De fato existem estudos sendo realizados com protocolos criptogr acos em conjunto com jogos, por em formalizados em um n vel abstrato. Nesse contexto, este trabalho tem como objetivo estudar e propor uma biblioteca documentada que implementa um conjunto de protocolos criptogr acos que suportam determinadas a c oes em jogos em um ambiente ponto-a-ponto, especicamente a co es em jogos que utilizam a sorte por meio do jogo de dados ou cartas.

vii

Abstract of Dissertation presented to COPPE/UFRJ as a partial fulllment of the requirements for the degree of Master of Science (M.Sc.)

SECURE PROTOCOLS TO GAMES IN PEER-TO-PEER NETWORK

Bernardo de Melo Pacheco September/2013

Advisor: Geraldo Bonorino Xex eo Department: Systems Engineering and Computer Science In an peer-to-peer networking, the security of an application is distributed between all participants, i.e., there is no server as a trusted third party in the system. Cryptographic protocols are forms that determine the rules for how each participant communicates, and aim to ensure fairness in the system. Mental Poker and Fair Coin Flipping are common problems treated in the cryptographic literature with applications inside and outside the game area. Mental Poker deals with the problems of managing a deck, ensuring, for example, that the cards are distributed with equal probability among players and no player can see the cards of the other. The Fair Coin Flipping deals with the problems of generating a random number, a coin or a die, ensuring that no player can unbalance the number generated in your favor. However, there is a lack of practical implementations and use of these protocols applied to games in an peer-to-peer networking. In fact there are studies being conducted with cryptographic protocols in conjunction with games, but formalized in an abstract level. In this context, this work aims to study and propose a library that implements a documented set of cryptographic protocols that support certain actions in games in an peer-to-peer networking, specic actions in games used by the luck of the dice or cards.

viii

Sum ario
Lista de Figuras Lista de Tabelas 1 Introdu c ao 1.1 Contexto e Motiva ca o . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Organiza c ao do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . 2 Rede Ponto-a-Ponto e Protocolos Criptogr acos 2.1 Arquitetura ponto-a-ponto . . . . . . . . . . . . . 2.1.1 Rede sobreposta . . . . . . . . . . . . . . . 2.1.2 Camada de rede . . . . . . . . . . . . . . . 2.1.3 Camada de aplica ca o . . . . . . . . . . . . 2.2 Teoria dos n umeros . . . . . . . . . . . . . . . . . 2.3 Criptograa e protocolos . . . . . . . . . . . . . . 2.3.1 Terminologia . . . . . . . . . . . . . . . . 2.3.2 Algoritmo sim etrico . . . . . . . . . . . . . 2.3.3 Algoritmo de chave p ublica . . . . . . . . 2.3.4 RSA . . . . . . . . . . . . . . . . . . . . . 2.3.5 ElGamal . . . . . . . . . . . . . . . . . . . 2.3.6 O que e um protocolo criptogr aco? . . . . 2.3.7 Bit Commitment . . . . . . . . . . . . . . 2.3.8 Secret Sharing . . . . . . . . . . . . . . . . 2.3.9 Fair Coin Flipping . . . . . . . . . . . . . 2.3.10 Mental Poker . . . . . . . . . . . . . . . . xi xiii 1 1 3 3 5 5 6 7 9 11 14 14 17 17 19 19 21 22 25 26 30

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

3 Proposta de Biblioteca de Suporte a A c oes em Ponto 3.1 Base de comunica ca o dos protocolos . . . . . . . . . 3.2 M odulo Dice Rolling . . . . . . . . . . . . . . . . . 3.2.1 Proposta de protocolo para n jogadores . . . ix

Jogos Ponto-a42 . . . . . . . . . . 42 . . . . . . . . . . 44 . . . . . . . . . . 44

3.3

3.4

3.2.2 Nota c ao padr ao de dados . . . . 3.2.3 Modelagem . . . . . . . . . . . 3.2.4 Funcionamento interno . . . . . 3.2.5 Como usar o m odulo . . . . . . M odulo Mental Poker . . . . . . . . . 3.3.1 Proposta de extens ao . . . . . . 3.3.2 Modelagem . . . . . . . . . . . 3.3.3 Funcionamento interno . . . . . 3.3.4 Como usar o m odulo . . . . . . Decis oes de desing e padr oes adotados

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

47 48 51 52 55 56 61 65 70 74 77 77 79 82 85 85 85 86 87 92 92 94

4 Implementa c ao 4.1 Estrutura do peer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 M odulo Dice Rolling . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 M odulo Mental Poker . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Experimento 5.1 Congura c ao do ambiente . . . . . . . 5.2 Experimento no m odulo Dice Rolling . 5.2.1 Cen ario do experimento . . . . 5.2.2 Resultados . . . . . . . . . . . . 5.3 Experimento no m odulo Mental Poker 5.3.1 Cen ario do experimento . . . . 5.3.2 Resultados . . . . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

6 Conclus ao 102 6.1 Considera co es acerca do trabalho . . . . . . . . . . . . . . . . . . . . 102 6.2 Contribui c oes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 6.3 Limita co es e trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . 105 Refer encias Bibliogr acas 106

A Resultados do experimento 112 A.1 Dice Rolling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 A.2 Mental Poker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Lista de Figuras
2.1 2.2 2.3 2.4 2.5 Compara c ao entre os tipos de arquitetura . . . . . . . . . . . . . Arquitetura de rede sobreposta ponto-a-ponto . . . . . . . . . . Processo de criptografar e descriptografar . . . . . . . . . . . . . Processo de criptografar e descriptografar utilizando chave . . . Processo de criptografar e descriptografar utilizando duas chaves ferentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . di. . . 6 . 7 . 15 . 16 . 17 43 46 49 52 55 61 66 68 74

3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 4.1 4.2

Diagrama de classes que comp oem a base da comunica c ao dos protocolos N umero de mensagens por n umero de jogadores . . . . . . . . . . . . Diagrama de classes de projeto do m odulo Dice Rolling . . . . . . . . Diagrama de sequ encia das mensagens internas do m odulo Dice Rolling na gera ca o de dados . . . . . . . . . . . . . . . . . . . . . . . . . Diagrama de sequ encia de exemplo de uso do m odulo Dice Rolling . . Diagrama de classes de projeto do m odulo Mental Poker . . . . . . . Diagrama de sequ encia de inicializa ca o do m odulo Mental Poker . . . Diagrama de sequ encia de mensagens internas do m odulo Mental Poker na gera ca o de uma carta aberta . . . . . . . . . . . . . . . . . . . Diagrama de sequ encia de exemplo de uso do m odulo Mental Poker .

Diagrama de classes do peer . . . . . . . . . . . . . . . . . . . . . . . 78 Diagrama de sequ encia de conex ao e recebimento de mensagem de um peer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Tempo m edio de jogada no jogo Dungeons & Dragons . . . . . . . . . Tempo m edio de jogada no jogo Pathnder . . . . . . . . . . . . . . . Tempo m edio de jogada no jogo Vampire The Masquerade . . . . . . Tempo m edio de criptograa por jogada no jogo Dungeons & Dragons Tempo m edio de criptograa por jogada no jogo Pathnder . . . . . . Tempo m edio de criptograa por jogada no jogo Vampire The Masquerade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tr afego m edio por jogada no jogo Dungeons & Dragons . . . . . . . . Tr afego m edio por jogada no jogo Pathnder . . . . . . . . . . . . . . xi 89 89 89 90 90 90 91 91

5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8

5.9 5.10 5.11 5.12 5.13 5.14 5.15 5.16 5.17 5.18 5.19 5.20 5.21 5.22 5.23 5.24 5.25 5.26

Tr afego m edio por jogada no jogo Vampire The Masquerade . . . . . 91 Tr afego m edio por jogada no jogo de Maior Carta . . . . . . . . . . . 95 Tr afego m edio por jogada no jogo de Poker . . . . . . . . . . . . . . . 95 Tr afego m edio por jogada no jogo de Sete e Meio . . . . . . . . . . . 96 Tr afego m edio por jogada no jogo Escopa . . . . . . . . . . . . . . . . 96 M edia de colis ao por jogada no jogo de Maior Carta . . . . . . . . . . 96 M edia de colis ao por jogada no jogo de Poker . . . . . . . . . . . . . 97 M edia de colis ao por jogada no jogo de Sete e Meio . . . . . . . . . . 97 M edia de colis ao por jogada no jogo Escopa . . . . . . . . . . . . . . 97 Tempo m edio de criptograa por jogada no jogo de Maior Carta . . . 98 Tempo m edio de criptograa por jogada no jogo de Poker . . . . . . . 98 Tempo m edio de criptograa por jogada no jogo de Sete e Meio . . . 98 Tempo m edio de criptograa por jogada no jogo Escopa . . . . . . . . 99 Tempo m edio para gerar uma carta aberta por jogada no jogo de Maior Carta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Tempo m edio para gerar uma carta aberta na mesa por jogada no jogo de Poker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Tempo m edio para gerar uma carta fechada por jogada no jogo de Poker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Tempo m edio para gerar uma carta fechada por jogada no jogo de Sete e Meio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Tempo m edio para gerar uma carta fechada por jogada no jogo Escopa101

xii

Lista de Tabelas
3.1 3.2 Compara c ao entre os tipos de nota c ao de dados . . . . . . . . . . . . 48 Exemplo de mapeamento entre o n umero gerado pelo protocolo e as cartas do baralho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Nota co es de dado comuns . . . . . . . . . . . . . . . . . . . . . . . Jogos reais utilizados no experimento . . . . . . . . . . . . . . . . . Resultados das jogadas comuns . . . . . . . . . . . . . . . . . . . . Aumento de performance no jogo de Maior Carta sem colis ao . . . . Aumento de performance no jogo Escopa no modo sem colis ao com as rodadas anteriores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 87 88 95

5.1 5.2 5.3 5.4 5.5

. 95

Resultados das m etricas no jogo Dungeons & Dragons no modo normal112 Resultados das m etricas no jogo Dungeons & Dragons no modo em lote113 Resultados das m etricas no jogo Pathnder no modo normal . . . . . 113 Resultados das m etricas no jogo Pathnder no modo em lote . . . . . 114 Resultados das m etricas no jogo Vampire The Masquerade no modo normal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 A.6 Resultados das m etricas no jogo Vampire The Masquerade no modo em lote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 A.7 Resultados das m etricas no jogo Maior Carta . . . . . . . . . . . . . . 116 A.8 Resultados das m etricas no jogo P oquer . . . . . . . . . . . . . . . . 117 A.9 Resultados das m etricas no jogo Sete e Meio . . . . . . . . . . . . . . 118 A.10 Resultados das m etricas no jogo Escopa . . . . . . . . . . . . . . . . . 119

A.1 A.2 A.3 A.4 A.5

xiii

Cap tulo 1 Introdu c ao


Este cap tulo apresenta o contexto do trabalho e o que motivou esta pesquisa. S ao tamb em apresentados os objetivos e a organiza ca o deste trabalho.

1.1

Contexto e Motiva c ao

A seguran ca da informa ca o nunca foi t ao amplamente endere cada, utilizada, difundida e debatida entre os cidad aos comuns como nos dias de hoje. Por muito tempo, tudo relacionado ` a criptograa era exclusivamente de dom nio militar. O paradigma mudou, e em vez de codicar e decodicar informa c oes com os aliados e tentar decifrar as mensagens do inimigo, a criptograa atual vai al em disso. Seja em uma troca de e-mails, em um acesso a uma p agina na internet ou em uma transa c ao nanceira, a criptograa est a presente para garantir a seguran ca. De fato a criptograa e uma parte essencial dos sistemas de informa c ao atuais. A criptograa evita fraudes no com ercio eletr onico, impede que uma mensagem seja lida por pessoas n ao autorizadas, garante o anonimato e tamb em permite provar sua identidade. Para a grande maioria, a seguran ca da informa c ao pode signicar a seguran ca do projeto de um novo produto, uma nova estrat egia de marketing da empresa, o plano para uma campanha pol tica, os dados banc arios, o extrato de compras do cart ao de cr edito daquele m es e at e fotos pessoais da fam lia. Manter uma carta em segredo, tranc a-la em um cofre e esconder o cofre em alguma casa de qualquer cidade do mundo, n ao e seguran ca, e sim obscuridade. No entanto, se os detalhes do fucionamento interno do cofre s ao conhecidos, se outras cartas tamb em s ao trancadas em outros cofres, e se qualquer pessoa do mundo estudar como o cofre pode ser aberto, e mesmo assim ningu em conseguir ler a carta, isso e seguran ca (SCHNEIER, 1996). A seguran ca e um requisito ainda mais evidente e necess ario em um ambiente

ponto-a-ponto1 com a participa ca o de dois ou mais participantes. Ao contr ario da arquitetura cliente-servidor2 onde uma terceira parte con avel3 gerencia e garante a conabilidade do sistema, em um sistema ponto-a-ponto geralmente n ao existe essa ancora que atua como entidade con avel. Dessa forma, em um sistema pontoa-ponto, a conabilidade do sistema e distribu da entre todos os participantes que seguem as regras de um protocolo criptogr aco. Por exemplo, a tarefa de dividir um peda co de bolo ao meio entre duas pessoas caracteriza bem a ess encia de um protocolo criptogr aco. Existem v arias formas de partir um bolo ao meio. A primeira solu ca o e encontrar uma outra pessoa para partir o bolo. O problema e que e necess ario a participa c ao de outra pessoa. Na segunda solu c ao uma das duas pessoas parte o bolo e a outra pode queixar-se com a autoridade caso os peda cos sejam diferentes. Ainda assim outra pessoa deve participar. Por m, como solu c ao do problema, uma pessoa parte o bolo e a outra escolhe o peda co que desejar. Essa solu ca o n ao requer a participa ca o de nenhuma outra pessoa e ainda garante que o bolo ser a repartido igualmente. Portanto, o objetivo de um protocolo criptogr aco e resolver um problema entre dois ou mais participantes, sejam eles amigos, inimigos, desconhecidos, honestos ou desonestos, de forma que quem trapaceia e detectado e punido. Al em disso, ningu em aprende mais do que o outro participante ou do que o protocolo permite. Um protocolo criptogr aco pode ser constitu do por outros protocolos criptogr acos que realizam uma tarefa espec ca. As aplica co es de um protocolo criptogr aco s ao diversas, incluindo o processo de troca e deni c ao da chave criptogr aca utilizada em uma sess ao de comunica c ao; o processo de autentica c ao que garante que ningu em assuma a identidade alheia; o particionamento de um segredo entre n indiv duos sendo necess ario um n umero m nimo de indiv duos para reconstruir o segredo; o comprometimento de um indiv duo com uma informa ca o que n ao pode ser alterada e que ser a revelada somente no futuro; o processo de provar que algu em conhece um segredo sem revelar este segredo; a assinatura de um documento sem revelar o conte udo do mesmo; a condu ca o de uma elei ca o onde e poss vel obter o resultado nal sem que haja trapa cas e que mant em a identidade dos indiv duos; a opera ca o de jogar par ou mpar, moeda ou dados via telefone, e-mail ou por qualquer outro meio de mensagens e a opera ca o de jogar cartas sem um baralho f sico. Em um ambiente cliente-servidor, um jogo que tem elementos de sorte e que usa dados e cartas mant em toda a seguran ca e justi ca no servidor. O servidor atua como um juiz em que todos os jogadores conam, o juiz que gera, aleatoriamente, o n umero do dado e a carta do baralho. No entanto, em um ambiente ponto-aTradu c ao do termo em ingl es peer-to-peer Tradu c ao do termo em ingl es client-server 3 Tradu c ao do termo em ingl es trusted third party
2 1

ponto, tal juiz n ao existe. Para gerar um dado ou uma carta do baralho, deve-se garantir que nenhum jogador possa levar o resultado a ser desbalanceado a seu favor. Mental Poker e Fair Coin Flipping s ao problemas comuns tratados na literatura de criptograa com aplica co es dentro e fora da a rea de jogos. O Mental Poker trata dos problemas de gerenciar um baralho, garantindo, por exemplo, que as cartas s ao distribu das com a mesma probabilidade entre os jogadores e que nenhum jogador consiga ver as cartas de outro jogador. O Fair Coin Flipping trata dos problemas de gerar um n umero aleat orio, seja uma moeda ou um dado, garantindo que nenhum jogador consiga desbalancear o n umero gerado a seu favor. Apesar das v arias aplica co es em que um protocolo criptogr aco pode ser utilizado, h a uma car encia de implementa co es pr aticas e de uso desses protocolos aplicados a jogos em um ambiente ponto-a-ponto. De fato existem estudos sendo realizados com protocolos criptogr acos em conjunto com jogos, por em formalizados em um n vel abstrato. Portanto, este trabalho tem como objetivo estudar e propor uma biblioteca documentada que implementa um conjunto de protocolos criptogr acos que suportam determinadas a co es em jogos em um ambiente ponto-a-ponto, especicamente a co es em jogos que utilizam a sorte por meio de dados ou cartas. Este trabalho n ao e uma implementa ca o de um jogo, mas sim um estudo aplicado de criptograa por meio de protocolos criptogr acos em jogos.

1.2

Objetivos

Os objetivos deste trabalho s ao: Realizar um levantamento do referencial te orico relacionado a protocolos criptogr acos aplicados a jogos com o objetivo de encontrar oportunidades de implementa c ao; Propor, modelar e implementar uma biblioteca de suporte a a co es espec cas em jogos em um ambiente ponto-a-ponto, sendo estas a c oes relacionadas ` a sorte por meio de dados e cartas. Al em disso, propor e implementar extens oes de protocolos criptogr acos existentes; Analisar a complexidade e o desempenho das opera c oes da biblioteca proposta, al em de evidenciar os resultados obtidos por meio da condu ca o de experimentos variando o n umero de jogadores participantes.

1.3

Organiza c ao do Trabalho

Esta disserta ca o est a organizada da seguinte maneira: 3

O cap tulo 2 discute os conceitos referentes a ` fundamenta ca o te orica do trabalho. S ao abordados os conceitos de rede ponto-a-ponto, teoria dos n umeros, criptograa e protocolos criptogr acos. No cap tulo 3 ser a apresentada a proposta de biblioteca de suporte a a c oes em jogos num ambiente ponto-a-ponto. No cap tulo 4 ser a descrita a implementa c ao da biblioteca proposta. No cap tulo 5 ser a apresentado o experimento e os resultados que avaliam as opera co es da biblioteca. Por m, s ao apresentadas a conclus ao e as refer encias bibliogr acas deste trabalho.

Cap tulo 2 Rede Ponto-a-Ponto e Protocolos Criptogr acos


Para que seja poss vel o entendimento das t ecnicas e tecnologias utilizadas, este cap tulo apresenta os conceitos te oricos de maior relev ancia. As se co es tratam os seguintes assuntos: arquitetura ponto-a-ponto, onde ser a descrita essa arquitetura e tamb em o contexto onde este trabalho se encaixa; se ca o de teoria dos n umeros que apresenta a base matem atica deste trabalho; se ca o de criptograa que descreve os conceitos, t ecnicas e os protocolos criptogr acos que s ao a base da biblioteca que ser a proposta neste trabalho.

2.1

Arquitetura ponto-a-ponto

A arquitetura ponto-a-ponto ganhou notoriedade no nal da d ecada de 90 principalmente pelo servi co de compartilhamento de arquivos NAPSTER (2012), j a que o servi co permitia a `s pessoas compartilhar qualquer m usica sem a necessidade de pagar por elas. Mais ainda, esse tipo de arquitetura ganhou popularidade por ser um mecanismo onde os usu arios compartilhavam arquivos sem a necessidade de servidores centralizados. Trata-se, em outras palavras, de uma mudan ca de paradigma a ` usual arquitetura cliente-servidor. Esse novo paradigma prov e uma poderosa plataforma para a constru c ao de servi cos descentralizados, como armazenamento na rede, distribui ca o de conte udo, cache para a web, busca e indexa ca o mais ricas no n vel da aplica ca o. Para ORAM (2001) a arquitetura ponto-a-ponto e uma classe de aplica c oes que tira proveito dos recursos armazenamento, ciclos, conte udo, presen ca humana dispon veis nas extremidades da internet. Porque acessando estes recursos descentralizados signica operar em um ambiente de conectividade inst avel e de endere co IP imprevis vel; os n os da rede devem operar fora do DNS e ter uma autonomia

Figura 2.1: Compara c ao entre os tipos de arquitetura (adaptado de SCHOLLMEIER (2001); STEINMETZ e WEHRLE (2005)) signicativa a partir dos servidores centrais. Em outras palavras, a arquitetura ponto-a-ponto e um sistema distribu do na camada da aplica ca o, onde os n os podem se comunicar entre si por meio de um protocolo de roteamento na camada de rede. Para diferenciar de fato uma arquitetura ponto-a-ponto da cl assica arquitetura cliente-servidor, a arquitetura ponto-a-ponto pode ser descrita como puramente ponto-a-ponto1 ou ponto-a-ponto h brida2 (SCHOLLMEIER, 2001; STEINMETZ e WEHRLE, 2005). A primeira assume que os servi cos providos pela rede pontoa-ponto n ao ser ao impactados com a sa da de um n o participante. J a a segunda assume a participa c ao de um n o centralizador como parte necess aria para prover os servi cos da rede. Dessa forma, caso esse n o saia da rede, os servi cos podem ser parcialmente prejudicados. Contudo, a intera c ao entre os outros n os ainda permite que o sistema continue ativo. Na arquitetura cliente-servidor, somente o servidor fornece conte udo e prov e servi cos para os demais clientes da rede. Caso o servidor falhe, todo o sistema falha.

2.1.1

Rede sobreposta

Uma rede sobreposta3 e um conjunto de n os e liga co es l ogicas constru das em cima de uma rede existente com a nalidade de implementar servi cos que n ao est ao dispon veis (AL-OQILY e KARMOUCH, 2007). Uma rede sobreposta ponto-a-ponto procura fornecer uma s erie de caracter sticas, tais como sele c ao de n os que est ao pr oximos, armazenamento redundante, busca e localiza ca o eciente de dados, garantia de persist encia de dados, autentica ca o e anonimato (LUA et al., 2005). Segundo LUA et al. (2005), a arquitetura de rede sobreposta ponto-a-ponto pode ser segmentada em 5 camadas:
1

Tradu c ao do termo ingl es pure P2P Tradu c ao do termo ingl es hybrid P2P 3 Tradu c ao do termo ingl es overlay network
2

Camada de rede de comunica ca o: descreve as caracter sticas de comunica ca o entre dispositivos ligados de uma forma ad-hoc ; Camada de gest ao de sobreposi ca o de n os: abrange o gerenciamento dos n os, como descoberta de n os e algoritmos de roteamento; Camada de gerenciamento de recursos: abrange seguran ca, conabilidade e toler ancia a falhas a m de manter a solidez do sistema; Camada de servi cos: servi cos que suportam a camada de aplica ca o, como escalonamento de tarefas e gerenciamento de arquivos; Camada de aplica c ao: aplica co es e ferramentas que s ao implementadas com funcionalidades espec cas.

Figura 2.2: Arquitetura de rede sobreposta ponto-a-ponto (adaptado de LUA et al. (2005)) De fato o trabalho desenvolvido nesta disserta ca o faz parte da camada de aplica ca o, pois prop oe e desenvolve uma biblioteca que serve como ferramenta para a constru ca o de jogos em um ambiente ponto-a-ponto.

2.1.2

Camada de rede

A partir da perspectiva da camada de rede, ROUSSOPOULOS et al. (2003) acredita que um sistema ponto-a-ponto deve satisfazer os seguintes requisitos: Auto-organiza ca o4 : Por meio de um processo de descoberta, os n os se organizam e se comunicam. N ao h a diret orio global de n os ou recursos;
4

Tradu c ao do termo em ingl es self-organization

Comunica c ao sim etrica5 : Os n os s ao considerados iguais. Um n o pode tanto requisitar ou fornecer servi cos; Controle distribu do6 : O n o determina o seu n vel de participa ca o. N ao h a um controlador central que diz qual e o comportamento de um n o individual. WANG e LI (2003) argumentam que h a tr es importantes componentes em uma rede ponto-a-ponto: descoberta de vizinho7 , protocolo de localiza ca o8 e protocolo de roteamento9 . Um n o que acabou de entrar no sistema deve obter algumas informa co es b asicas, tais como os n os vizinhos. Al em disso, o novo n o tamb em deve publicar as informa co es de quais objetos ele possui. O n o pode consultar por objetos que ele deseja. Neste momento, o protocolo de localiza ca o descobrir a qual o n o que cont em o objeto requisitado, enquanto o protocolo de roteamento encaminha a mensagem de consulta para o n o que cont em o objeto. A partir do IP do n o que cont em o objeto consultado, o n o pode pegar o objeto desejado. Por m o n o anuncia a sua sa da da rede. Protocolos de localiza ca o e roteamento como CAN (RATNASAMY et al., 2001), Chord (STOICA et al., 2001), Pastry (ROWSTRON e DRUSCHEL, 2001) e Tapestry (ZHAO et al., 2001) s ao uma camada de rede estruturada e auto-organiz avel que t em como principais objetivos garantir requisitos como escalabilidade, eci encia, toler ancia a falhas e balanceamento de carga efetivo. Esses protocolos permitem a ` aplica ca o localizar qualquer objeto em uma probabilidade delimitada, com um pequeno n umero de roteamento na rede, enquanto que cada n o armazena uma pequena tabela de roteamento com poucas entradas (WALLACH, 2002). WALLACH (2002) discute quest oes de seguran ca que ocorrem no escopo dos protocolos de localiza c ao e roteamento. Segundo ele, a arquitetura deve ser robusta o suciente para evitar que alguns n os agindo em conjunto ataquem outros n os. N os maliciosos podem responder a uma requisi ca o com dados falsos, retornando rotas falsas a m de particionar a rede. Esse n os podem ter outros objetivos como a coleta e an alise de informa co es num sistema que tenta prover comunica ca o an onima, al em da censura a sistemas que tentam prover alta disponibilidade de informa c ao. CASTRO et al. (2002) reete que uma rede ponto-a-ponto deve ser capaz de suportar um ambiente aberto onde os participantes t em interesses conitantes entre si. Portanto, em uma rede de larga escala, e fact vel assumir a presen ca de n os maliciosos que podem corromper mensagens ou informar rotas erradas. Tais n os ainda podem assumir a identidade de outros n os para corromper ou deletar objetos
Tradu c ao Tradu c ao 7 Tradu c ao 8 Tradu c ao 9 Tradu c ao
6 5

do do do do do

termo termo termo termo termo

em em em em em

ingl es ingl es ingl es ingl es ingl es

symmetric communication distributed control neighbor nding location protocol routing protocol

em nome do n o verdadeiro. Portanto, e not avel que a seguran ca e um requisito importante tanto na camada mais baixa, ou seja, na camada de rede quanto na camada de aplica c ao descrita a seguir.

2.1.3

Camada de aplica c ao

STEINMETZ e WEHRLE (2005) argumentam que a tradicional arquitetura clienteservidor requer um esfor co muito maior para acompanhar a crescente expans ao da internet, assim como atender requisitos de novas aplica co es e servi cos que surgem com essa expans ao. Segundo eles, esses requisitos s ao: Escalabilidade10 : pode ser entendida como a capacidade de crescimento da aplica ca o ou do servi co em termos computacionais ` a medida que o n umero de usu arios cresce. Seguran ca11 : Servi cos devem sempre estar dispon veis mesmo com ataques maliciosos. Al em disso, o anonimato deve ser preservado quando requerido e a censura deve ser repudiada. Flexibilidade e qualidade de servi co12 : Servi cos devem ser ex veis o suciente para integrar novas tecnologias a m de prover servi cos de mais qualidade. A arquitetura cliente-servidor, por sua natureza centralizadora, apresenta gargalos na disposi ca o de recursos computacionais, al em de apresentar um ponto u nico de falha. STEINMETZ e WEHRLE (2005) acreditam que a arquitetura ponto-a-ponto apresenta uma mudan ca de paradigma suciente para endere car esses requisitos. Para KUBIATOWICZ (2003) uma aplica ca o ponto-a-ponto deve apresentar os seguintes requisitos: Disponibilidade13 : Informa ca o deve estar dispon vel 24 horas ao dia, sete dias da semana; Durabilidade14 : Informa c ao que entra no sistema deve permanecer no sistema; Controle de acesso15 : A informa c ao e protegida. Quem n ao e autorizado n ao pode ler nem alterar a informa ca o;
Tradu c ao Tradu c ao 12 Tradu c ao 13 Tradu c ao 14 Tradu c ao 15 Tradu c ao
11 10

do termo em ingl es scalability dos termos em ingl es security, reliability dos termos em ingl es exibility, quality of service do termo em ingl es availability do termo em ingl es durability do termo em ingl es access control

Autenticidade16 : Um documento requisitado n ao pode ser substitu do por outro documento forjado; Recupera ca o de falha de servi co17 : Deve ser dif cil comprometer a disponibilidade do sistema. Al em desses requisitos, KUBIATOWICZ (2003) lista outros objetivos que podem ser endere cados de forma n ao obrigat oria: Escalabilidade18 : O sistema deve funcionar com milhares, milh oes ou at e bilh oes de usu arios; Anonimato19 : Deve ser imposs vel ou muito dif cil para um observador saber quem produziu um documento; Nega ca o20 : Usu arios podem negar o conhecimento dos dados armazenados em sua m aquina; Resist encia a ` censura21 : Ningu em pode censurar qualquer tipo de informa ca o uma vez que esta seja inserida no sistema. Os requisitos apresentados acima s ao de fato requisitos relacionados a ` seguran ca da aplica ca o. Como ser a descrito neste trabalho, essa seguran ca e o foco dos protocolos criptogr acos. Para RISSON e MOORS (2007) a pesquisa na area de arquitetura ponto-a-ponto pode ser dividida em quatro linhas de pesquisa: busca, seguran ca, armazenamento e aplica co es. A linha de busca trata da indexa ca o da informa ca o, bem como as consultas para recuperar essa informa ca o. A linha de armazenamento est a relacionada com a troca, consist encia e replica c ao da informa c ao entre os n os. A linha de pesquisa que trata da seguran ca procura dispor essa informa ca o baseada na reputa ca o dos n os, assim como garantir que a troca de informa co es entre os n os seja justa, ou seja, que n ao tenha qualquer tipo de fraude. J a a linha de aplica c ao procura juntar o conhecimento das outras tr es linhas de pesquisa a m de criar aplica c oes e servi cos sobre essa rede, como sistema de arquivos distribu dos e servi cos de streaming por exemplo. Este trabalho est a inserido nas linhas de pesquisa de seguran ca e aplica ca o. Ser ao vistas no decorrer deste trabalho as particularidades do projeto de jogos (aplica ca o) de natureza distribu da onde e poss vel a troca de informa co es entre os jogadores
Tradu c ao Tradu c ao 18 Tradu c ao 19 Tradu c ao 20 Tradu c ao 21 Tradu c ao
17 16

do do do do do do

termo termo termo termo termo termo

em em em em em em

ingl es ingl es ingl es ingl es ingl es ingl es

authenticity denial-of-Service - DoS - resilience scalability anonymity deniability resistance to censorship

10

de uma forma justa e segura (seguran ca) a m de evitar qualquer tipo de trapa ca e vantagem de um dos jogadores.

2.2

Teoria dos n umeros

Este trabalho descreve e implementa protocolos criptogr acos. Para compreend e-los e necess ario entendimento em conceitos da a rea de teoria dos n umeros. A teoria dos n umeros e a parte da matem atica que estuda as propriedades dos n umeros inteiros, e de fato e uma das areas mais antigas da matem atica. O objetivo nessa se ca o e citar alguns desses conceitos. Para uma abordagem mais aprofundada do assunto, pode-se consultar IRELAND e ROSEN (1990), NIVEN et al. (2008) e HARDY e WRIGHT (1979). Outro excelente material e o livro N umeros Inteiros e Criptograa RSA(COUTINHO, 2003) utilizado no curso de gradua c ao de Ci encia da Computa ca o na UFRJ. N umeros inteiros Os n umeros ..., -3, -2, -1, 0, 1, 2,... s ao chamados de n umeros inteiros e pertencem ao conjunto dos inteiros Z. As letras a, b,..., n, p,..., x, y,... geralmente representam um n umero inteiro que pode estar com uma restri ca o do tipo n umero positivo ou n umero negativo. Um inteiro a e divis vel por outro inteiro b, sem ser o zero, caso exista um inteiro c onde a = bc. O fato de a ser divis vel por b e representado como b | a. N umeros primos No conjunto de n umeros inteiros, h a um subgrupo que desempenha um papel fundamental em criptograa, o grupo dos n umeros primos. Um n umero p e primo se (i) p > 1 e (ii) p n ao tem divisor exceto 1 e o pr oprio p. Caso constr ario, o n umero e chamado composto. O n umero inteiro 1 n ao e primo nem composto. A lista inicial de n umero primos e 2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 41, 43, 47, 53, 59, 61... e de fato existem innitos n umeros primos. O Teorema Fundamental da Aritm etica sustenta que cada inteiro positivo, exceto 1, pode ser escrito como um produto de primos. Um n umero n composto pode ser escrito como n = p1 p2 ...pk . Vale destacar que decompor um n umero inteiro em primos pode ser um processo muito lento. M aximo divisor comum Entre dois inteiros a e b, o m aximo divisor comum e o maior inteiro positivo d que e divisor de a e tamb em e divisor de b. Se mdc e o m aximo divisor comum entre a e b, escreve-se mdc(a, b). Se mdc(a, b) = 1, a e b s ao primos entre si ou co-primos. 11

Aritm etica modular Na aritm etica modular, um conjunto de inteiros est ao contidos em um valor limite chamado m odulo. Dois inteiros a e b s ao congruentes m odulo n se a - b e um m ultiplo de n. Basicamente, a b (mod n ) se a = b + kn para algum inteiro k. O sinal signica congru encia. O n umero inteiro b e o resto da divis ao de a por n. O n umero inteiro b tamb em e chamado de res duo de a m odulo n. O conjunto de inteiros de 0 at e n - 1 forma o conjunto completo de res duos m odulo n, o que signica que para cada inteiro a, seu res duo m odulo n e um n umero entre 0 e n - 1. A rela ca o do conjunto Z com a congru encia m odulo n forma um conjunto que e muito utilizado em criptograa. Este conjunto tem a nota c ao Zn , e um nome de conjunto dos inteiros m odulo n. Nesse conjunto, pode-se realizar opera c oes aritm eticas como soma, subtra c ao e multiplica ca o. Por exemplo, 6 + 2 em Z5 e igual a 3, j a que 6 + 2 = 8 3 (mod 5). Elemento inverso O elemento inverso, ou a invers ao de um n umero inteiro a m odulo n em Zn e um n umero inteiro x que multiplicado por a tem congru encia 1 com n. Por exemplo, o inverso de 4 m odulo 7 pode ser escrito como 4 * x 1 (mod 7), com x = 2. O problema em geral e achar um x tal que 1 = (a * x ) mod n. A mesma senten ca tamb em e escrita como a1 x (mod n ). Achar o inverso de um n umero pode ser uma tarefa muito dif cil de resolver, podendo ter uma solu c ao ou n ao. Em geral, a1 x (mod n ) tem uma solu ca o em Zn se a e n s ao co-primos. Caso contr ario, 1 a x (mod n ) n ao tem solu ca o. Se n e um n umero primo, ent ao cada n umero de 1 at e n -1 e co-primo com n e tem um n umero inverso m odulo n nesse intervalo. A fun ca o de Euler ou fun c ao totiente de um n umero n, escrita como (n), e o n umero de inteiros positivos menores que n que s ao co-primos de n. Se n e primo, ent ao (n) = n - 1. Se n = pq, onde p e q s ao primos, ent ao (n) = (p - 1)(q - 1). Essa senten ca e importante para a criptograa de chave p ublica RSA, j a que a seguran ca do m etodo est a na diculdade de fatorar um n umero inteiro n nos n umeros inteiros primos p e q, onde n = pq. Usando a mesma fun ca o totiente, e poss vel calcular o (n)1 elemento inverso x de um n umero inteiro a, onde x = a mod n. Por exemplo, para determinar o inverso do n umero 5 m odulo 7, calcula-se (7) = 7 - 1 = 6, ent ao 61 5 o inverso e5 mod 7 = 5 mod 7 = 3. Res duo quadr atico Sendo p um n umero primo, e a um n umero inteiro maior que 0 e menor que p, a e um res duo quadr atico m odulo p se x2 a (mod p ) para algum x. Por exemplo, 12 1 (mod 7 ), 22 4 (mod 7 ), 32 2 (mod 7 ). Os n umeros 1, 2 e 4 formam o 12

conjunto de res duos quadr aticos em Z7 . Os outros elementos 3, 5 e 6 s ao res duos n ao quadr aticos de Z7 . De fato achar um n umero a elevado ao quadrado que e congruente a x m odulo p pode ser t ao dif cil quanto achar os fatores primos p e q no algoritmo RSA. Grupos Um grupo e uma estrutura constitu da de um conjunto G e uma opera c ao * denida neste conjunto. A opera c ao e uma regra que a cada dois elementos a, b G associa um terceiro elemento a * b que tamb em est a em G. Como exemplo de conjunto e opera ca o, h a o conjunto dos inteiros e a soma, os inteiros e o produto, os racionais e o produto, entre outros. Nem todo conjunto e opera ca o formam um grupo. Deve-se satisfazer as seguintes leis de forma c ao para ser considerado um grupo: 1. Associatividade: dados a, b, c G temos que a * (b * c ) = (a * b ) * c ; 2. Elemento neutro: existe um elemento e G tal que para todo a G temos a * e = e * a = a; 3. Elemento inverso: dado um elemento a G, existe um elemento a G que e o inverso de a tal que a * a = a * a = e. Um grupo G n ao necessariamente precisa ter uma opera ca o comutativa, ou seja, a * b = b * a para quaisquer elementos a, b G. Um grupo cuja opera c ao e comutativa e chamado de abeliano. Como exemplo, o conjunto dos inteiros Z com a opera ca o de adi c ao forma um grupo abeliano. O n umero de elementos de um grupo e a sua ordem. De fato a ordem do grupo dos inteiros Z tem ordem innita. No entanto, para o grupo Zn dos inteiros m odulo n com a opera ca o de soma, a ordem do grupo e nita e igual a n. Supondo que G e um grupo nito com uma opera c ao *, e a e um elemento de G. Pode-se dizer que ak = a * a * a * ... * a (k vezes). Dessa forma, G = {e, a, a2 , a3 , ...}, e existe um elemento qualquer a G com um inteiro positivo k tal que ak = e. Pode-se dizer que se um grupo G e igual ao conjunto de pot encias de um elemento a, o elemento a e denominado um gerador do grupo G. O menor inteiro positivo k tal que ak = e e a ordem de a. Dessa forma, se G tem como gerador o elemento a, ent ao a ordem de G e igual a ordem de a. Um grupo que admite um elemento gerador e chamado de c clico. Por exemplo, o grupo Zn e um importante grupo que e abeliano e c clico.

13

Logaritmo discreto Exponencia ca o modular e uma express ao do tipo ax mod n e pode ser facilmente calculada. No entanto, o problema inverso da exponencia c ao modular e um problema dif cil de calcular, e e chamado de logaritmo discreto. Achar o logaritmo discreto e encontrar um n umero inteiro x onde ax b (mod n ). Por exemplo, se 3x 15 (mod 17), ent ao x = 6. Nem todo logaritmo discreto tem solu ca o. A seguran ca de muitos algoritmos de chave p ublica e baseada no problema de encontrar o logaritmo discreto, com a complexidade de achar a solu ca o semelhante ao problema de fatorar um n umero inteiro grande. O problema torna-se ainda mais dif cil de resolver com n umeros de 1024 bits.

2.3

Criptograa e protocolos

Nesta subse ca o ser ao apresentados os fundamentos da criptograa utilizada nesse trabalho, abordando a terminologia, a ideia principal de criptografar e descriptografar uma informa ca o e os tipos de algoritmos criptogr acos. Tamb em ser a descrito o que e um protocolo criptogr aco, al em de descrever passo a passo os protocolos criptogr acos de interesse neste trabalho.

2.3.1

Terminologia

Segundo MENEZES et al. (1996), Criptograa e o estudo de t ecnicas matem aticas relativas aos aspectos de seguran ca da informa ca o, tais como: Condencialidade22 : e um servi co que tem por objetivo manter o acesso a uma informa ca o somente a quem tem autoriza ca o de acesso; Integridade de dados23 : e um servi co que endere ca a altera c ao de dados por um intruso, ou seja, por algu em n ao autorizado. Para garantir a integridade dos dados, a parte receptora da mensagem deve ser capaz de detectar que a mensagem original foi alterada durante o envio; Autentica c ao24 : e um servi co relacionado ` a identica c ao. Dois participantes em uma comunica ca o devem se identicar. Deve ser poss vel que receptor da mensagem se assegure de que n ao est a recebendo uma mensagem de um intruso;
Tradu c ao do termo em ingl es condentiality Tradu c ao do termo em ingl es data integrity 24 Tradu c ao do termo em ingl es authentication
23 22

14

N ao Rep udio25 : um remente n ao deve ser capaz de negar mais tarde que enviou uma determinada mensagem. De modo geral, em criptograa temos um participante que deseja enviar uma mensagem para outro participante. O participante que envia a mensagem deseja que a mesma seja transmitida de forma segura de forma que nenhum outro observador possa ler essa mensagem. Essa mensagem26 pode ser denotada por M, e pode representar um conjunto de bits, um arquivo texto, uma imagem ou at e mesmo um v deo. Criptografar27 uma mensagem signica transformar a informa ca o contida nessa mensagem a m de impossibilitar a leitura de todos exceto o destinat ario da men28 sagem. Por outro lado, descriptografar uma mensagem signica transformar uma mensagem criptografada29 a m de obter a mensagem original. Uma mensagem criptografada e denotada por C. O processo de criptografar uma mensagem pode ser descrito matematicamente como: E(M) = C, onde E e uma fun ca o que criptografa a mensagem M. O processo de descriptografar pode ser descrito matematicamente como: D(C) = M, onde D e uma fun ca o que descriptografa a mensagem M. Descriptografar uma mensagem criptografada resulta na pr opria mensagem original. Dessa forma, chegamos a seguinte igualdade: D(E(M)) = M

Figura 2.3: Processo de criptografar e descriptografar (adaptado de SCHNEIER (1996, p 1)) Um algoritmo criptogr aco30 , e uma fun ca o matem atica usada para criptografar e descriptografar uma mensagem. Comumente existe uma fun ca o para criptografar e outra fun ca o para descriptografar. Ao contr ario dos antigos algoritmos que eram
Tradu c ao Tradu c ao 27 Tradu c ao 28 Tradu c ao 29 Tradu c ao 30 Tradu c ao
26 25

do termo em ingl es non-repudiation dos termos em ingl es message, plaintext do termo em ingl es encryption do termo em ingl es decryption do termo em ingl es ciphertext do termo em ingl es cipher

15

seguros por manter os detalhes do algoritmo em segredo, os modernos algoritmos exp oem os seus detalhes de implementa ca o, por em usam uma chave secreta para criptografar e descriptografar uma mensagem. Essa chave31 e denotada por K. Toda seguran ca desse algoritmo reside na chave, e n ao de como o algoritmo funciona. Se um observador conhecer os detalhes do algoritmo, mas n ao conhecer a chave usada na criptograa da mensagem, a mensagem n ao poder a ser lida. Temos, ent ao, a seguinte nota ca o usando uma chave para criptografar e descriptografar uma mensagem: Ek (M ) = C Dk (C ) = M Dk (Ek (M )) = M

Figura 2.4: Processo de criptografar e descriptografar utilizando chave (adaptado de SCHNEIER (1996, p 3)) A chave usada para criptografar uma mensagem n ao necessariamente deve ser a mesma chave para descriptografar. O algoritmo de criptografar pode usar uma chave K1 , enquanto o algoritmo de descriptografar pode usar outra chave K2 . Portanto, temos: Ek1 (M ) = C Dk2 (C ) = M Dk2 (Ek1 (M )) = M Os dois tipos de algoritmos mais comuns s ao (SCHNEIER, 1996): DES32 : e o algoritmo sim etrico mais popular para computadores; RSA33 : e o algoritmo de chave p ublica mais popular. A seguir s ao descritos o algoritmo sim etrico e o algoritmo de chave p ublica utilizados para criptografar e descriptografar uma mensagem.
Tradu c ao do termo em ingl es key Iniciais de Data Encryption Standard 33 Iniciais do nome dos criadores Rivest, Shamir e Adleman
32 31

16

Figura 2.5: Processo de criptografar e descriptografar utilizando duas chaves diferentes (adaptado de SCHNEIER (1996, p 4))

2.3.2

Algoritmo sim etrico

Algoritmo sim etrico34 e o algoritmo que usa uma mesma chave K para criptografar e descriptografar uma mensagem M. A seguran ca de um algoritmo sim etrico est a na chave utilizada para criptografar a mensagem. Divulgar a chave signica que qualquer pessoa pode descriptografar a mensagem. Para a comunica ca o permanecer em segredo, a chave deve permanecer secreta (SCHNEIER, 1996, p 17) (DELFS e KNEBL, 2002, p 11). O termo criptograa sim etrica35 signica que um algoritmo sim etrico e usado para criptografar e descriptografar uma mensagem. Criptografar e descriptografar uma mensagem via algoritmo sim etrico e um processo que pode ser denido como: Ek (M ) = C Dk (C ) = M Um problema desse tipo de algoritmo e como os participantes que se comunicam podem acordar sobre a chave K que ser a usada para criptografar e descriptografar a mensagem M. Tal problema estava sem solu ca o at e a descoberta do algoritmo de chave p ublica.

2.3.3

Algoritmo de chave p ublica

Um dos maiores marcos na criptograa moderna aconteceu quando Die e Helmann publicaram o trabalho New Directions in Cryptography (DIFFIE e HELLMAN, 1976). Este trabalho introduziu o conceito de algoritmo de chave p ublica. 36 Algoritmo de chave p ublica, tamb em chamado de algoritmo assim etrico e o algoritmo que usa uma chave para criptografar e outra chave diferente para descriptografar uma mensagem. Qualquer pessoa pode usar uma chave para criptografar uma mensagem, mas s o uma determinada pessoa pode descriptografar essa mensagem.
Tradu c ao do termo em ingl es symmetric algorithm Tradu c ao do termo em ingl es symmetric cryptography 36 Tradu c ao do termo em ingl es public-key algorithm ou asymmetric algorithm
35 34

17

A chave utilizada para criptografar a mensagem e chamada de chave p ublica37 , e a chave utilizada para descriptografar a mensagem e chamada de chave privada38 . Deduzir a chave privada a partir da chave p ublica e matematicamente dif cil (DIFFIE e HELLMAN, 1976). O termo criptograa de chave p ublica39 signica que um algoritmo de chave p ublica e usado para criptografar e descriptografar uma mensagem. De todos os algoritmos de chave p ublica propostos, o algoritmo RSA (RIVEST et al., 1978b) e o mais popular, f acil de entender e tamb em de implementar. O Algoritmo de chave p ublica n ao substitui o algoritmo sim etrico, pelo contr ario, ambos s ao complementares na congura ca o de uma comunica c ao segura. Algoritmos de chave p ublica s ao geralmente utilizados para denir as chaves que ser ao usadas num algoritmo sim etrico. Para SCHNEIER (1996, p 38), h a dois motivos para isso: Algoritmos de chave p ublica s ao lentos. Algoritmos sim etricos s ao geralmente 1000 vezes mais r apidos; Algoritmos de chave p ublica s ao mais vulner aveis a ataques. Supondo que uma mensagem M perten ca a um conjunto de n possibilidades, basta criptografar essas n possibilidades com a chave p ublica e comparar com a mensagem original criptografada. Esse ataque n ao determina a chave privada, mas descobre a mensagem M original. Em conjunto, o algoritmo sim etrico e o algoritmo de chave p ublica podem ser usados da seguinte maneira (SCHNEIER, 1996, p 38): Bob envia para Alice sua chave p ublica; Alice gera uma chave aleat oria K e usa a chave p ublica de Bob para cifr a-la e envi a-la para Bob; Com sua chave privada, Bob descriptografa a mensagem enviada por Alice para recuperar a chave K ; Ambos criptografam suas mensagens usando a mesma chave K. Uma caracter stica importante desse sistema e o fato de que a chave K e criada sob demanda, ou seja, uma nova chave e criada sempre que for necess ario uma comunica c ao segura, e destru da quando a comunica c ao termina. Como a chave K n ao e guardada para uma comunica ca o futura, as chances de roubo dessa chave diminuem, j a que a mesma permanece v alida somente durante o per odo em que a comunica c ao est a sendo praticada. Interessante observar que os passos realizados
Tradu c ao do termo em ingl es public key Tradu c ao do termo em ingl es private key 39 Tradu c ao do termo em ingl es public-key cryptography
38 37

18

por Alice e Bob constituem o que e chamado de protocolo criptogr aco. Protocolo criptogr aco ser a abordado em instantes. Antes, os algoritmos criptogr acos de chave p ublica RSA e ElGamal ser ao descritos.

2.3.4

RSA

O algoritmo de chave p ublica RSA(RIVEST et al., 1978b) e de fato o mais popular e tamb em o mais f acil de entender e implementar. A seguran ca do RSA est a na diculdade de fatorar um n umero grande primo. Recuperar a mensagem original a partir da chave p ublica e equivalente a fatorar o produto de dois n umeros primos, o que e um problema muito dif cil, j a que n ao s ao conhecidos algoritmos r apidos de fatora ca o. Para gerar a chave p ublica, primeiro escolhe-se dois n umeros primos p e q e calcula-se n = pq. Em seguida, calcula-se um inteiro positivo e que seja invers vel m odulo (n), ou seja, e e (n) s ao co-primos com mdc(e, (n)) = 1. A chave p ublica e composta pelo par (n, e). Para criptografar a mensagem m, deve-se quebrar a mensagem m em blocos b que s ao menores que o valor num erico n. Para criptogragar o bloco b, calcula-se c = e b modn. A mensagem m criptografada ser a o conjunto de blocos b criptografados. Para descriptografar, calcula-se o n umero d que e o inverso de e em (n). Em 1 1 outras palavras, d = e mod(n) ou d = e mod((p 1)(q 1)) A chave privada e composta pelo par (n, d). Para descriptografar c e recuperar o bloco b original, calcula-se b = cd modn. Recuperando cada bloco b recupera-se a mensagem m original.

2.3.5

ElGamal

ElGamal e um algoritmo assim etrico descrito por ELGAMAL (1985) cuja seguran ca est a baseada na diculdade de resolver um logaritmo discreto. Lembrando que resolver um logaritmo discreto pode ser t ao dif cil quanto fatorar um n umero primo grande p como no algoritmo assim etrico RSA. Para gerar as chaves do algoritmo criptogr aco, primeiro dene-se que G e um grupo c clico de ordem q com elemento gerador g. Escolhe-se um n umero inteiro x aleat orio x que est a entre {1, ..., q 1}. Calcula-se h = g . Al em de tornar p ublica a estrutura do grupo G, a chave p ublica e composta por h, q, g, e a chave privada e o elemento x. Para criptografar uma mensagem m, utiliza-se a chave p ublica (G,q,g,h ). Escolhe-se um n umero inteiro aleat orio r que est a entre {1, ..., q 1} e que seja coprimo com o n umero primo p, ent ao calcula-se a = g r e b = mhr . A nota ca o para r r o texto criptografado e (a, b) = (g , mh ). 19

Para descriptografar (a, b), calcula-se abx = m, ou b (a1 )x = m. O fator a1 e o elemento inverso de a no grupo G. Devido ao fator r aleat orio no processo de criptografar, o texto criptografado para uma mensagem m n ao se repete, ou seja, se a mesma mensagem e criptografada mais de uma vez, n ao ser a obtido o mesmo bloco criptografado (a, b ). O algoritmo ElGamal possui a propriedade de ser homom orco multiplicativo e homom orco aditivo. Criptograa homom orca signica que e poss vel criptografar duas mensagens separadas, realizar uma opera ca o com as duas mensagens criptografadas, descriptografar o resultado dessa opera ca o e obter o mesmo resultado caso as duas mensagens originais fossem utilizadas. Por exemplo, ao criptografar o n umero 4, criptografar o n umero 7, realizar a opera c ao de multiplica ca o nas duas mensagens criptografadas, descriptografar o resultado da multiplica ca o, o resultado obtido eo n umero 28, j a que 4 * 7 = 28. O interessante e o fato de que quem descriptografa a mensagem obt em o resultado da opera ca o, mas n ao tem conhecimento dos n umeros originais que foram utilizados para gerar o resultado. A ideia de homomorsmo aplicado em criptograa foi primeiramente introduzida em (RIVEST et al., 1978a) com o chamado homomorsmo privado, onde o autor argumenta que parece que existe alguma fun ca o criptogr aca que permite que o dado criptografado seja manipulado sem a necessidade de descriptografar o mesmo. O homomorsmo multiplicativo do ElGamal pode ser vericado da seguinte forma: E (m1 ) E (m2 ) = (g r1 , m1 hr1 )(g r2 , m2 hr2 ) = (g r1+r2 , (m1 m2 )hr1+r2 ) = E (m1 m2 ) Como resultado, as mensagens m1 e m2 s ao multiplicadas, pois as mensagens criptografadas foram multiplicadas. O homomorsmo aditivo pode ser obtido elevando o elemento gerador g pela mensagem m, resultando em g m : E (g m1 ) E (g m2 ) = (g r1 , g m1 hr1 )(g r2 , g m2 hr2 ) = (g r1+r2 , (g m1 +m2 )hr1+r2 ) = E (m1 + m2 ) No homomorsmo aditivo do ElGamal, a mensagem descriptografada estar a na m1 +m2 forma g . No entanto, isso signica que para achar m1 + m2 e necess ario resolver o logaritmo discreto resultante de g m1 +m2 , o que geralmente e uma tarefa dif cil ou impratic avel dependendo do tamanho em bits dos n umeros do grupo G. Al em do algoritmo criptogr aco ElGamal, outros algoritmos apresentam algum tipo de homomorsmo, com destaque para o RSA(RIVEST et al., 1978b) que apresenta homomorsmo multiplicativo, Paillier (PAILLIER, 1999) com homomorsmo aditivo e multiplicativo, Goldwasser-Micali (GOLDWASSER e MICALI, 1982) com homomorsmo ou exclusivo (XOR ) e Naccache-Stern (NACCACHE e STERN, 1997) com homomorsmo aditivo e multiplicativo. Como exemplo de aplica co es do homomorsmo em criptograa, pode-se destacar o uso na computa ca o em nuvem. Como 20

descrito em (TEBAA et al., 2012), os dados s ao mantidos criptografados na nuvem garantindo a seguran ca da informa c ao, sendo poss vel por meio da criptograa homom orca executar opera co es com os dados criptografados. Como descrito no trabalho de CRAMER et al. (1997), o homomorsmo tamb em tem aplica c ao em sistemas de vota ca o eletr onica segura. Por exemplo, considerando uma vota ca o onde a op c ao 1 (um) e a favor e a op ca o 0 (zero) e contra ao que est a em pauta sendo votado, cada participante pode criptografar seu voto, de forma que por meio do homomorsmo aditivo seja poss vel somar os votos e obter o resultado nal sem compromoter a seguran ca e a privacidade de quem votou.

2.3.6

O que e um protocolo criptogr aco?

Protocolo e uma s erie de passos envolvendo dois ou mais participantes que tem por objetivo realizar uma tarefa. Uma s erie de passos signica que o protocolo tem in cio e m. Envolvendo dois ou mais participantes signica que n ao existe protocolo com apenas um participante. E tem por objetivo realizar uma tarefa signica que o protocolo deve resolver algum problema (SCHNEIER, 1996) (MENEZES et al., 1996). Segundo SCHNEIER (1996), protocolos ainda apresentam outras caracter sticas: Cada participante do protocolo deve conhecer o protocolo e todos os seus passos previamente; Cada participante deve concordar com o protocolo; O protocolo n ao deve ser amb guo, ou seja, cada passo deve ser bem denido a m de evitar interpreta co es erradas; O protocolo deve ser completo, ou seja, deve haver uma a ca o espec ca para cada situa ca o poss vel. Um protocolo criptogr aco e um protocolo que usa criptograa, precisamente algum algoritmo criptogr aco. Os participantes podem ser amigos que conam um nos outros ou podem ser advers arios. O objetivo de um protocolo criptogr aco n ao e somente manter uma informa ca o em segredo, mas sim evitar e detectar que algu em fora do protocolo escute o protocolo e ganhe informa ca o ou que um dos participantes trapaceie. De outra forma, n ao deve ser poss vel fazer ou aprender mais do que especicado pelo protocolo (SCHNEIER, 1996). Na descri ca o de um protocolo, e comum usar nomes reservados para os participantes do protocolo. Alice e Bob s ao os dois nomes mais comuns. Os nomes s ao usados por conveni encia e tamb em para personalizar a discuss ao, j a que e mais f acil dizer que Alice envia uma mensagem para Bob do que Participante A envia um 21

mensagem para o Participante B. Originalmente os nomes Alice e Bob apareceram no trabalho que descreve o algoritmo assim etrico RSA (RIVEST et al., 1978b). Al em desses principais nomes, h a uma lista mais extensa que dene outros nomes, onde cada nome desempenha um determinado papel no protocolo (SCHNEIER, 1996, p 23). Os passos a seguir constituem um protocolo, onde Alice deseja enviar uma mensagem para Bob de forma segura. Nesse caso, o protocolo utiliza o algoritmo sim etrico na comunica ca o (SCHNEIER, 1996, p 30): 1. Alice e Bob combinam sobre qual algoritmo sim etrico ser a usado; 2. Alice e Bob combinam uma chave; 3. Alice criptografa sua mensagem utilizando o algoritmo e a chave que foram escolhidos; 4. Alice envia para Bob sua mensagem criptografada; 5. Bob descriptografa a mensagem utilizando o mesmo algoritmo e chave para recuperar a mensagem original. O mesmo protocolo poderia ser feito utilizando o algoritmo de chave p ublica (SCHNEIER, 1996, p 32): 1. Alice e Bob denem as chaves p ublicas e privadas que ser ao utilizadas no protocolo; 2. Bob envia para Alice a sua chave p ublica; 3. Alice criptografa a mensagem utilizando a chave p ublica de Bob e envia a mensagem para Bob; 4. Bob descriptografa a mensagem usando sua chave privada. Como descrito anteriormente, o algoritmo de chave p ublica n ao substitui o algoritmo de chave sim etrica, mas e utilizado para gerar a chave que ser a utilizada no algoritmo sim etrico.

2.3.7

Bit Commitment

Nessa subse ca o ser a descrito o protocolo bit commitment que e a base dos protocolos utilizados nessa disserta ca o. Bit commitment e um tipo de protocolo que permite a um participante se comprometer com uma mensagem (um ou mais bits ) sem que a mesma seja revelada para os outros participantes. Al em disso, a m de evitar a manipula ca o ou altera ca o da mensagem original, o protocolo garante que 22

o participante que se comprometeu n ao consegue mudar sua mensagem antes que a mesma seja revelada (SCHNEIER, 1996, p 86). O protocolo bit commitment e um protocolo de duas fases entre o emissor e o receptor. Na fase de comprometimento o emissor est a comprometido com um valor espec co que n ao poder a ser alterado. Al em disso, o receptor n ao tem qualquer conhecimento sobre esse valor. Na fase de revela c ao, o emissor envia alguma informa ca o extra para o receptor a m de que o mesmo possa determinar o valor previamente comprometido (NAOR, 1991) (CREPEAU, 2012). O conceito de comprometimento com uma informa ca o que estabelece uma comunica ca o justa e segura foi primeiramente formalizado por BRASSARD et al. (1988). Como exemplo, considere que Alice e Bob est ao jogando par ou mpar, sendo que Alice escolheu par e Bob escolheu mpar. Mentalmente, Alice escolhe um n umero. Da mesma forma, Bob tamb em o faz. Como Bob cona em Alice, Bob fala primeiro o seu n umero e pergunta a Alice qual n umero ela pensou. Se Alice for justa, ela diz o seu verdadeiro n umero e ambos conseguem saber se a soma dos dois n umeros e par ou mpar. No entanto, caso Alice seja uma trapaceira, ela pode mudar o n umero que ela pensou originalmente para um n umero que, somado com o n umero de Bob, seja par. Nesse caso, Bob n ao saberia que foi trapaceado. Como forma de contornar esse problema, o protocolo bit commitment permite que Bob se comprometa com um n umero sem que esse n umero seja revelado para Alice. Por exemplo, Bob escreve o seu n umero em um peda co de papel e o sela dentro de um envelope. Bob envia o envelope para Alice, sendo que Alice n ao consegue ver o que est a dentro do envelope. Em seguida, Alice revela o seu n umero para Bob. Agora, ambos podem abrir o envelope selado e vericar se a soma dos dois n umeros e par ou mpar. Formas de garantir o Bit Commitment A m de garantir que um participante se comprometa com uma informa ca o e que a mesma n ao possa ser alterada posteriormente, o uso da criptograa sim etrica ou de fun c ao de m ao u nica geralmente s ao usadas para implementar o protocolo de bit commitment. A seguir ser ao descritos os protocolos usando ambas abordagens. Usando a criptograa sim etrica, o protocolo bit commitment pode ser constru do da seguinte forma (SCHNEIER, 1996): 1. Bob gera um ou mais bits aleat orios R e envia para Alice; R 2. Alice cria uma mensagem composta por seus bits de interesse mais a mensagem R enviada por Bob. Ela criptografa a mensagem com alguma chave aleat oria K e envia a mensagem criptografada para Bob; 23

EK (R, b) 3. Alice envia para Bob a chave K ; 4. Bob descriptografa a mensagem para revelar a mensagem. Para validar a mensagem que Alice enviou, Bob verica se sua mensagem R est a presente na mensagem descriptografada. Se o protocolo n ao usar a mensagem R de Bob, Alice poderia, depois do passo 2, testar mais de uma chave para descriptografar a sua mensagem. Cada chave resultaria em uma mensagem diferente. Portanto, Alice poderia trapacear Bob enviando-o uma chave que resultaria em uma mensagem diferente da que ela escolheu originalmente. Acrescentando a mensagem R, Alice teria que encontrar uma chave que, al em de trocar a sua mensagem original para outra mensagem de seu interesse, tamb em resultasse na mensagem R que Bob escolheu. Antes de descrever o protocolo bit commitment via fun ca o de m ao u nica, e necess ario saber o que e uma fun ca o de m ao u nica. Fun ca o de m ao u nica40 e uma fun ca o f acil de ser calculada mas extremamente dif cil de ser revertida. Dado um valor qualquer x, e f acil calcular f (x), mas dado f (x) e dif cil calcular x (GOLDREICH e LEVIN, 1989). Dif cil de ser revertida signica que milh oes de anos seriam necess arios para reverter f (x) mesmo se todos os computadores do mundo fossem utilizados. Matematicamente ainda n ao foi provado a exist encia de uma fun ca o de m ao u nica, mas existem fun co es que s ao usadas como uma (SCHNEIER, 1996). Idealmente, em fun c oes de m ao u nica, f (x) != f (x ) se x != x . Usando uma fun ca o de m ao u nica H, o protocolo bit commitment pode ser constru do da seguinte forma: 1. Alice gera duas strings aleat orias, R1 e R2 ; R1 , R2 2. Alice cria uma mensagem composta por R1 e R2 mais o bit b que ela deseja se comprometer; (R1 , R2 , b) 3. Alice computa o valor da fun c ao de m ao u nica para a mensagem e a envia juntamente com uma das mensagens aleat orias para Bob; H (R1 , R2 , b), R1 4. Alice envia para Bob a mensagem original; (R1 , R2 , b)
40

Tradu c ao do termo em ingl es one-way function

24

5. Bob calcula o valor da fun ca o u nica da mensagem e compara com a mensagem original enviada por Alice. Bob valida essa mensagem comparando o valor de R1 com o valor de R1 recebido no passo 3. Nesse protocolo Bob n ao precisa enviar nenhuma mensagem para Alice. Alice se compromete com seu bit b quando envia o resultado da fun ca o u nica juntamente com a mensagem R1 no passo 3. Para Alice trapacear alterando o bit b para b, ela teria que achar outra mensagem R2 onde H (R1 , R2 , b ) = H (R1 , R2 , b), o que praticamente impede que Alice mude a sua mensagem depois de envi a-la para Bob.

2.3.8

Secret Sharing

Secret sharing, ou compartilhamento de segredo e um protocolo que tem o prop osito de manter uma mensagem em segredo entre um grupo de participantes. Esse protocolo, inventado independentemente por SHAMIR (1979) e BLAKLEY (1979), quebra a mensagem em peda cos, onde cada peda co sozinho n ao signica nada, mas quando os peda cos s ao reunidos a mensagem e reconstru da. Em geral um participante con avel gera um segredo x e distribui uma parte desse segredo para os n participantes. Se o segredo puder ser reconstru do a partir de k participantes, esse sistema e chamado de (k,n )-threshold. Por exemplo, se 10 participantes compartilham um segredo, e caso seja necess ario apenas 4 participantes para revelar o segredo, esse sistema e chamado de (4,10)-threshold. No entanto, k - 1 participantes n ao podem reconstruir o segredo, ou seja, 3 ou menos participantes n ao s ao sucientes para reconstruir o segredo. Para descrever o protocolo proposto por SHAMIR (1979), seja o segredo D = D1 , ..., Dn , onde n e o n umero de participantes. Seja tamb em um n umero primo p maior que D e n. O protocolo (k,n )-threshold e um protocolo baseado em interpola ca o polinomial: dado k coordenadas (xi , yi ),...,(xk , yk ) com diferentes valores para cada xi , h a um polin omio f (x ) de grau k - 1 tal que f (xi ) = yi para todo i. Para dividir o segredo D em Di partes, escolhe-se um polin omio aleat orio k1 f (x) = a0 + a1 x + ... + ak1 x de grau k - 1, onde a0 = D e calcula-se D1 = f (1), ... , Di = f (i),..., Dn = f (n). Os coecientes a1 , ..., ak1 s ao inteiros escolhidos tal que 0 a < p e os valores Di , ..., Dn s ao calculados m odulo p. Dessa forma, dado um subconjunto de k do conjunto de valores Di e poss vel achar os coecientes de f(x) por interpola c ao polinomial e ent ao calcular D = f (0). Seguindo conceitualmente o protocolo acima, PEDERSEN (1991) prop oe um protocolo distribu do para compartilhar um segredo. Pode-se destacar as seguintes caracter sticas do protocolo: N ao depende de uma parte con avel como no protocolo descrito acima, ou seja, a fun ca o polinomial f (x ) n ao e escolhida por um u nico participante de 25

conan ca dos outros participantes, mas sim gerada a partir da colabora ca o de todos os participantes; O peda co do segredo que um participante recebe pode ser validado, ou seja, pode-se garantir que o segredo recebido est a correto. Essa propriedade e importante porque o segredo n ao e mais calculado por uma parte con avel; A seguran ca est a baseada na diculdade de calcular um logaritmo discreto. Assumindo que p e q s ao n umero primos e que q | p - 1, Gq e um grupo de ordem q e g um gerador de Gq , o protocolo pode ser descrito da seguinte forma: 1. Cada participante Pi escolhe um polin omio aleat orio fi (z ) em Gq de grau t : fi (z ) = ai0 + ai1 z + ... + ait z t Pi envia para cada participante Xik = g aik mod p para k = 0,...,t. Seja o valor ai0 representado por xi e Xi0 por hi . Cada Pi calcula o segredo parcial xij = fi (j ) mod q para j = 1,...,n e envia xij de forma segura para o jogador Pj . 2. Cada jogador Pj verica os segredos parciais que recebeu dos outros jogadores ao checar, para i = 1,...,n : g xij =
t jk k=0 (Xik )

mod p

Se algum teste falhar para um ndice i, o jogador Pj envia para todos os outros jogadores uma den uncia contra o jogador Pi . 3. Se mais do que t jogadores denunciarem o jogador Pi , ent ao o jogador Pi e banido. 4. O valor p ublico h e calculado como h = hi mod p. O valor secreto compartilhado x n ao e calculado por nenhum jogador, sendo x = xi mod q. Esse protocolo tem um papel fundamental na gera c ao e distribui ca o das chaves (GDC) do algoritmo ElGamal utilizado no protocolo Mental Poker descrito na Se ca o 2.3.10.

2.3.9

Fair Coin Flipping

Alice e Bob querem jogar cara ou coroa sem uma moeda f sica. Alice prop oe a Bob que os dois pensem em um bit aleat orio. O resultado ser a o ou exclusivo (XOR exclusive-or ) entre esses dois bits. Alice e Bob podem determinar que o bit 0 e cara e que o bit 1 e coroa. O protocolo que descreve esse cen ario pode ser dessa forma: 1. Alice pergunta a Bob qual o bit que ele pensou; 26

2. Bob fala para Alice o bit que ele pensou; 3. Alice pega a resposta de Bob e calcula o XOR de seu bit com o bit enviado por Bob; 4. Alice revela o resultado para Bob. Pode-se perceber que esse cen ario descrito por esse protocolo permite que Alice trapaceie. Caso Alice e Bob sejam justos e verdadeiros, o protocolo funciona. Caso Alice e Bob n ao se conhe cam ou sejam advers arios, Alice pode trapacear dizendo um bit cujo resultado nal seja a seu favor. Endere cando o problema acima, BLUM (1982) introduziu o problema onde duas pessoas querem jogar moeda por telefone, al em de propor uma solu ca o usando um protocolo de bit commitment. O protocolo segue a seguinte estrutura: 1. Alice compromete seu bit aleat orio com Bob utilizando um protocolo de bit commitment ; 2. Bob revela seu bit para Alice; 3. Alice revela o bit de resultado para Bob. Bob vence caso tenha acertado o bit de resultado. No passo 2, Alice j a conhece o resultado nal, por em n ao pode mud a-lo, pois no passo 1 comprometeu-se com Bob enviando seu bit aleat orio. No passo 3, Bob verica se o valor comprometido por Alice no passo 1 e igual ao valor gerado por um protocolo de bit commitment sobre o valor revelado por Alice no passo 3. Um protocolo que se prop oe a resolver o problema de jogar moeda sem uma moeda f sica deve apresentar as seguinte propriedades (BLUM, 1982): 1. Se qualquer um dos participantes do protocolo n ao pegar o outro trapaceando, ent ao ele tem certeza de que a probabilidade de sair cara ou coroa e de 50%; 2. Se qualquer um dos participantes do protocolo pegar o outro trapaceando, ent ao deve ser poss vel provar que o outro trapaceou; 3. Depois que Bob jogou sua moeda, Alice sabe o resultado, mas Bob ainda n ao tem ideia do resultado; 4. Depois que ambos jogaram a moeda, Alice deve ser capaz de provar para Bob qual o resultado da moeda. Uma forma de implementar um protocolo que possua as propriedades descritas anteriormente e usar uma fun ca o de m ao u nica (SCHNEIER, 1996, p 83): 27

1. Alice escolhe um n umero aleat orio x. Assumindo que f (x) e uma fun ca o de uma m ao u nica, Alice calcula y = f (x); 2. Alice envia y para Bob; 3. Bob adivinha se x e par ou mpar e envia sua escolha para Alice; 4. Se Bob acertar na sua escolha, o resultado da moeda ser a cara. Se a escolha for incorreta, o resultado da moeda ser a coroa. Alice anuncia o resultado e envia o n umero x para Bob; 5. Bob conrma que y = f (x). A primeira fase do comprometimento acontece no passo 2, quando Alice envia o resultado da fun c ao de m ao u nica para Bob. Nesse ponto, Alice n ao pode mais mudar de ideia sobre o valor original de x, pois Bob ir a conferir no passo 5, por meio da aplica c ao da fun ca o de m ao u nica com o valor x enviado por Alice, se o resultado e igual ao valor de y enviado por Alice no passo 2. O mesmo protocolo pode ser constru do usando a criptograa de chave p ublica (SCHNEIER, 1996, p 84): 1. Alice e Bob geram suas chaves p ublica e privada; 2. Alice gera duas mensagens, uma indicando cara e outra indicando coroa. Essas mensagens devem conter alguma sequ encia aleat oria de bits que ser a usada para vericar a autenticidade do protocolo. Alice criptografa ambas as mensagens com sua chave p ublica e as envia para Bob; EA (M1 ), EA (M2 ) 3. Como Bob n ao pode ler o conte udo da mensagem, ele escolhe uma aleatoriamente. Ele criptografa a mensagem escolhida com sua chave p ublica e envia o resultado para Alice; EB (EA (M )), onde M e M1 ou M2 4. Alice, que n ao pode ler a mensagem recebida, descriptografa a mensagem com sua chave privada e envia o resultado para Bob; DA (EB (EA (M ))) = EB (M1 ) se M = M1 ou EB (M2 ) se M = M2 5. Bob descriptografa a mensagem com sua chave privada para revelar o resultado nal. Bob envia a mensagem descriptografada para Alice. DB (EB (M1 )) = M1 ou DB (EB (M2 )) = M2

28

6. Alice recebe o resultado e verica se a mensagem aleat oria criada no passo 2 est a correta; 7. Alice e Bob revelam as suas chaves para ambos vericarem se ningu em trapaceou. Alice poderia gerar duas mensagens iguais (que poderiam ser duas caras ou duas coroas), mas no passo 7 Bob descobriria essa trapa ca. Alice poderia usar outra chave para descriptografar a mensagem no passo 4, mas Bob iria perceber que a mensagem gerada no passo 5 est a sem sentido. Por outro lado, Bob poderia for car coroa criptografando incorretamente no passo 3, mas Alice iria perceber vericando a mensagem aleat oria no passo 6. Bob poderia alegar que n ao consegue descriptografar a mensagem no passo 5 por causa de uma eventual trapa ca de Alice, mas essa tentativa de fraude seria descoberta no passo 7. Dessa forma, o protocolo mostra-se seguro contra trapa cas que podem acontecer de ambas as partes. Pode-se imaginar que uma moeda e um dado com duas faces. Seguindo os mesmos princ pios do protocolo fair coin ipping, pode-se estender esse protocolo para criar um protocolo de jogar dado de uma forma segura entre dois participantes que n ao conam um no outro. Se n ao houver um protocolo, um jogador pode alegar que tirou 6 e 6, e o outro jogador n ao ir a acreditar ou n ao ter a como provar a trapa ca. O protocolo descrito a seguir integra a biblioteca JGAMMON (2012), biblioteca que implementa o jogo gam ao e que est a escrita na linguagem Java41 : 1. Cada participante gera um n umero aleat orio de 64 bits : R1 e R2 ; 2. Cada um calcula uma fun c ao de m ao u nica para o n umero aleat orio. Cada um envia o resultado da fun c ao de m ao u nica para o outro. Nesse passo, utiliza-se 42 a fun ca o SHA como fun ca o de m ao u nica. SHA(R1 ) e SHA(R2 ); 3. Cada participante envia o n umero aleat orio gerado no passo 1; 4. Cada participante verica se o c alculo da fun ca o de m ao u nica de Ri enviado no passo anterior e igual ao resultado da fun ca o de m ao u nica enviada no passo 2; 5. Ambos os participantes podem gerar o resultado do dado da seguinte forma: (primeiro byte(R1 ) + primeiro byte(R2 )) mod 36.
http://java.com/en/download/index.jsp Iniciais de Secure Hash Algorithm, SHA foi projetado pelo NIST - National Institute of Standards and Technology - em parceria com a NSA - National Security Agency - como padr ao no uso de assinatura digital.
42 41

29

Esse protocolo tem as mesmas propriedades do protocolo fair coin ipping que utiliza a fun c ao de m ao u nica. Ambos os participantes n ao podem trapacear, pois o n umero que cada um escolheu para gerar o resultado nal foi comprometido no passo 2. Outro protocolo semelhante utilizando a linguagem de programa ca o E43 tamb em segue o mesmo princ pio do protocolo descrito anteriormente (COMMUNITIES, 2012).

2.3.10

Mental Poker

Num jogo de cartas, jogadores est ao sentados ao redor de uma mesa jogando p oquer. Nesse cen ario e relativamente fact vel ver se algu em est a trapaceando. No entanto, se os jogadores n ao est ao sicamente presentes e resolvem jogar p oquer via e-mail ou via telefone, ou seja, trocando mensagens em vez de cartas, como garantir que essas mensagens que representam as cartas do baralho s ao distribu das da mesma forma para todos os jogadores? Como garantir que nenhum jogador trapaceie observando as cartas do outro jogador? O termo Mental Poker signica jogar cartas sem um baralho via um canal de comunica c ao, como por exemplo a internet, sem a interven ca o de uma terceira parte em que todos conam e que tem a fun c ao de facilitar a intera ca o entre os jogadores. Segundo FORTUNE e MERRITT (1984) a primeira discuss ao sobre Mental Poker foi em 1933 quando Niels Bohr tentou jogar com seus amigos, por em sem sucesso. A primeira tentativa mais s eria e fundamentada ocorreu em 1979, quando SHAMIR et al. (1979) chegaram a um resultado paradoxal. Segundo os autores, o jogo e justo se estiver de acordo com as seguintes restri co es: 1. Cada jogador deve conhecer as cartas em sua m ao, mas n ao deve ter informa co es das cartas dos outros jogadores; 2. O m etodo de distribuir as cartas deve assegurar que as m aos s ao disjuntas, ou seja, uma mesma carta n ao pode estar em mais de uma m ao; 3. A m ao de cada jogador e formada com a mesma probabilidade; 4. Durante o jogo, os jogadores podem pegar as cartas restantes do baralho, ou revelar alguma carta sem comprometer a seguran ca das cartas da sua m ao. De fato SHAMIR et al. (1979) provaram matematicamente que e imposs vel conceber um Mental Poker com os requisitos acima, mas forneceram uma solu c ao pr atica para o problema com um protocolo criptogr aco. A seguir o protocolo para dois jogadores e descrito (SCHNEIER, 1996, p 92):
43

http://erights.org/

30

1. Alice e Bob, cada um gera o seu par de chaves p ublica e privada; 2. Alice gera 52 mensagens, uma para cada carta do baralho. Cada mensagem deve conter uma string aleat oria que servir a para vericar a autenticidade das mensagens. Alice criptografa todas as mensagens com sua chave p ublica e as envia para Bob; EA (Mn ) 3. Bob, que n ao pode ler as mensagens, escolhe cinco mensagens ao acaso. Ele criptografa essas cinco mensagens com sua chave p ublica e as envia de volta para Alice; EB (EA (Mn )) 4. Alice, que n ao pode ler as mensagens, descriptografa com sua chave privada e as envia de volta para Bob; DA (EB (EA (Mn ))) = EB (Mn ) 5. Bob descriptografa suas mensagens com sua chave privada para revelar suas cartas; DB (EB (Mn )) = Mn 6. Bob escolhe mais cinco cartas ao acaso das 47 cartas restantes e as envia para Alice; EA (Mn ) 7. Alice descriptografa as mensagens com sua chave privada para revelar suas cartas; DA (EA (Mn )) = Mn 8. No nal, Alice e Bob revelam suas cartas e suas chaves para que todos tenham certeza de que ningu em trapaceou. Esse protocolo pode ser estendido para tr es ou mais jogadores. Tanto esse protocolo como o descrito a seguir usam criptograa comutativa44 , isto e, se alguma mensagem e criptografada mais de uma vez, a ordem em que essa mensagem e descriptografada n ao importa. A seguir e descrito o protocolo estendido para tr es jogadores (SCHNEIER, 1996, p 93): 1. Alice, Bob e Carol, cada um gera seu par de chaves p ublica e privada;
44

Tradu c ao do termo em ingl es cryptographic commutative

31

2. Alice gera 52 mensagens, uma para cada carta do baralho. Cada mensagem deve conter uma string aleat oria que servir a para vericar a autenticidade das mensagens. Alice criptografa todas as mensagens com sua chave p ublica e as envia para Bob; EA (Mn ) 3. Bob, que n ao pode ler as mensagens, escolhe cinco mensagens ao acaso. Ele criptografa essas cinco mensagens com sua chave p ublica e as envia de volta para Alice; EB (EA (Mn )) 4. Bob envias as outras 47 mensagens para Carol; EA (Mn ) 5. Carol, que n ao pode ler as mensagens, escolhe cinco mensagens ao acaso. Ela criptografa essas cinco mensagens com sua chave p ublica e as envia para Alice; EC (EA (Mn )) 6. Alice, que n ao pode ler as mensagens, descriptografa com sua chave privada e as envia de volta para Bob e Carol; DA (EB (EA (Mn ))) = EB (Mn ) DA (EC (EA (Mn ))) = EC (Mn ) 7. Bob e Carol descriptografam suas mensagens com sua respectiva chave privada para revelar suas cartas; DB (EB (Mn )) = Mn DC (EC (Mn )) = Mn 8. Carol escolhe mais cinco cartas ao acaso das 42 cartas restantes e as envia para Alice; EA (Mn ) 9. Alice descriptografa as mensagens com sua chave privada para revelar suas cartas; DA (EA (Mn )) = Mn 10. No nal, Alice, Bob e Carol revelam suas cartas e suas chaves para que todos tenham certeza de que ningu em trapaceou.

32

O protocolo proposto acima, no entanto, n ao oferece condencialidade, requerendo que cada jogador revele a sua m ao ao m do jogo (passo 10) para assegurar que ningu em trapaceou. Isso signica que a estrat egia do jogador passa a ser conhecida pelos seus oponentes, o que geralmente n ao e desej avel acontecer na maioria de jogos de cartas que envolvem dinheiro. Por exemplo, um jogador que blefou deve mostrar suas cartas e revelar sua estrat egia para os outros jogadores da mesa. Idealmente, o passo 10 n ao seria necess ario. Como colocado por SCHNEIER (1996, p 93), somente e interessante saber se o ganhador trapaceou. Todos os outros jogadores podem trapacear desde que percam o jogo. Al em disso, LIPTON (1981) provou que uma pequena quantidade de informa c ao e vazada nesse algoritmo que utiliza a criptograa RSA. Se a representa ca o bin aria da carta e um res duo quadr atico, ent ao a carta criptografada tamb em ser a um res duo quadr atico. Essa propriedade pode ser usada, por exemplo, para marcar todas as cartas de um determinado naipe. O estudo de protocolos que endere cam o problema do Mental Poker evoluiu com os trabalhos apresentados por Claude Cr epeau. Para CREPEAU (1985), um jogo de p oquer deve alcan car as seguintes condi c oes: 1. Unicidade das cartas; 2. Distribui c ao uniforme e aleat oria das cartas; 3. Aus encia de uma terceira parte con avel; 4. Detectar com alta probabilidade qualquer trapa ca; 5. Condencialidade completa das cartas; 6. Minimizar os efeitos de alian ca entre jogadores fora do protocolo; 7. Condencialidade completa da estrat egia. Em seu trabalho, CREPEAU (1985) prop oe um protocolo que satisfaz os seis primeiros requisitos, mas n ao alcan ca o s etimo requisito - condencialidade completa da estrat egia. Para iniciar o protocolo, suponha que P1 , P2 , ..., PN desejam jogar p oquer e que DECK = {1, 2,..., 52}. Assuma tamb em a correspond encia entre o baralho padr ao e o conjunto {1, 2,..., 52}. Cada Pi escolhe uma permuta ca o i de {1, 2,..., 52} e mant em em segredo. O baralho embaralhado ser a a composi ca o de fun co es das permuta c oes, ou seja, N ...2 1 . Para um jogador Pi escolher uma carta, o mesmo escolhe um valor k em DECK que ningu em tenha escolhido, e gera a sua carta calculando N ...2 1 (k ). Como as permuta co es s ao mantidas em segredo, o valor de uma permuta ca o e obtido usando 45 o protocolo Escondendo-Revelando proposto no mesmo trabalho. Esse protocolo
45

Tradu c ao para o termo em ingl es Hiding-Revealing protocol

33

permite que uma parte A escolha um valor de um conjunto conhecido pela parte B sem que a parte B saiba qual valor a parte A escolheu. Isso permite Pi obter os valores 1 (k ), 2 1 (k ) at e N ...2 1 (k ) dos outros jogadores. O jogo prossegue com os jogadores obtendo cartas dessa forma. Contudo, algum jogador pode trapacear ao computar N ...2 1 (k ) para algum k DECK que n ao o pertence. Com isso esse jogador pode ver cartas que est ao na m ao de outro jogador ou que est ao no baralho. Para vericar esse tipo de trapa ca, o protocolo exige que cada jogador revele sua permuta ca o i no nal do jogo, o que revela a m ao de cada jogador. Em outro trabalho que tem por base o protocolo apresentado, CREPEAU (1986) consegue satisfazer o s etimo requisito, tornando-se a primeira solu ca o completa para o problema do Mental Poker. Nesse novo protocolo, a ideia e adicionar informa co es distintas e aleat orias para cada valor secreto em 1 , 2 , ..., N , onde a informa ca o adicionada e grande o suciente para n ao ser adivinhada. Quando um jogador ler o valor da permuta c ao do outro jogador, tamb em ser a lida essa informa c ao. Essas informa co es ser ao posteriormente reveladas pelos jogadores, e se todas forem diferentes, ningu em trapaceou. Sendo s um par ametro seguro escolhido pelos jogadores, Pi escolhe i,j com 1 j i - 1, e alguns arrays de tamanho 52 com strings aleat orias de tamanho s. Para k DECK , i,j (k ) e chamado de registro de i (k ) para Pj . Sempre que Pj ler i (k ), ele receber a o valor i,j (k ) correspondente e n ao um outro valor i,j (k ). Se Pj tentar trapacear lendo algum i (k ) em vez do valor correto i (k ), ele tamb em receber a o valor i,j (k ) em vez de i,j (k ). Dessa forma, se um jogador desonesto ler uma carta que pertence a outro jogador Pi , ele receber ao mesmo registro, o que acusa a trapa ca ao m do jogo. Embora o protocolo funcione em teoria, EDWARDS (1994) provou n ao funcionar na pr atica. Tr es computadores com arquitetura SPARC demoraram oito horas para embaralhar um baralho. CREPEAU (1986) dene protocolos para preparar o jogo, pegar uma carta, detectar eventuais trapa cas, restaurar o registro das jogadas, descartar e revelar uma carta. SCHINDELHAUER (1998) argumenta que esses protocolos apresentam a limita c ao de que devem seguir uma determinada sequ encia. Por exemplo, o baralho deve ser embaralhado somente no in cio do jogo. Al em disso, SCHINDELHAUER (1998) aponta outras limita c oes: as cartas devem ser u nicas no baralho, n ao pode reutilizar cartas que foram descartadas e n ao pode inserir uma nova carta no baralho. Em suma, os protocolos denidos por CREPEAU (1986) s ao sucientes para jogos de p oquer, mas n ao satisfazem opera c oes mais gen ericas em outros tipos de jogos. Dessa forma, SCHINDELHAUER (1998) modica e estende muitas ideias e t ecnicas de CREPEAU (1986) e prop oe um conjunto de opera co es gen ericas que fazem sentido na maioria dos jogos. As opera c oes s ao aplicadas em uma u nica carta, no baralho ou num conjunto de cartas. As opera co es aplicadas nas cartas s ao escolher uma carta do baralho mostrando ou n ao a carta para os outros jogadores e 34

tamb em revelar uma carta da m ao do jogador para os outros jogadores. As opera co es aplicadas no baralho compreendem a cria c ao do baralho, embaralhar, inserir carta no baralho e particionar o baralho, ou seja, escolher k cartas do topo e colocar no m do baralho. A ideia e compartilhar a carta entre todos os jogadores, ou seja, cada carta e criptografada com a chave p ublica de cada jogador, sendo necess ario a participa ca o de todos os jogadores para gerar ou revelar uma carta. O tamanho de uma carta cresce linearmente com o n umero de jogadores. A cada opera ca o e realizada uma verica c ao de corre ca o, garantindo que ningu em trapaceou. Em vez de vericar a corre ca o das opera c oes ao nal do jogo, a verica c ao ocorre a cada opera ca o. BARNETT e SMART (2003), baseado no trabalho e nas opera co es de cartas descritas por SCHINDELHAUER (1998), prop oe um framework abstrato composto por quatro protocolos, com um protocolo de gera ca o de chaves, protocolo de codica ca o, protocolo de codica ca o de uma carta que j a est a codicada e protocolo de decodica ca o. O framework proposto est a baseado no logaritmo discreto e foi implementado com o ElGamal(ELGAMAL, 1985). A principal vantagem apresentada por BARNETT e SMART (2003) e a redu ca o do tamanho da carta codicada que, ao contr ario da proposta de SCHINDELHAUER (1998), o tamanho da carta em bits e independente do n umero de jogadores. Entre as opera c oes poss veis da abordagem de BARNETT e SMART (2003) est a a cria ca o de uma carta aberta, cria ca o de uma carta fechada, cria c ao de uma carta aleat oria a partir do baralho, publica ca o de uma carta fechada para os outros jogadores, cria c ao de um baralho, embaralhar um baralho e partir o baralho ao meio, ou seja, colocar x cartas da base no topo do baralho. Os trabalhos apresentados at e agora sobre Mental Poker de fato s ao modelos abstratos e n ao foram implementados na pr atica, ou quando foram implementados n ao foram pr aticos como mostrou o trabalho de EDWARDS (1994) que demorou oito horas para embaralhar um baralho. No entanto, o trabalho apresentado por STAMER (2005) parece ser de fato a primeira implementa ca o pr atica que n ao requer uma terceira parte con avel e que mant em a condencialidade da estrat egia dos jogadores. Nesse trabalho o autor incorporou o sistema de criptograa proposto por BARNETT e SMART (2003), permitindo que o tamanho em bits da carta n ao dependa do n umero de jogadores. Com isso, o autor criou uma implementa c ao eciente do framework proposto por SCHINDELHAUER (1998). STAMER (2005) desenvolveu uma biblioteca chamada LibTMCG46 em C++ que tem como objetivo a cria ca o de jogos de cartas peer-to-peer de uma forma segura. A biblioteca tem aproximadamente 7300 linhas de c odigo e est a sob a licen ca GPL47 .
O endere co que cont em o projeto LibTMCG e http://www.nongnu.org/libtmcg/. A Licen ca P ublica Geral, do ingl es GPL General Public License e uma licen ca de software livre que permite ao usu ario executar, copiar, distribuir, estudar e alterar o software. Detalhes da licen ca GNU pode ser encontrado em http://www.gnu.org/licenses/gpl.html.
47 46

35

Como exemplo de uso da biblioteca, o autor cita o desenvolvimento de uma rede peer-to-peer chamada SecureSkat (STAMER, 2013) que implementa o jogo de cartas Skat48 . Apesar de realizar uma implementa ca o pr atica dos protocolos criptogr acos abstratos de Mental Poker, STAMER (2005) ressalta que em jogos com muitos jogadores ou com um baralho grande, por exemplo um baralho de p oquer com 52 cartas, as t ecnicas e opera c oes utilizadas na biblioteca LibTMCG ainda s ao muito custosas. A seguir e descrito um protocolo mais novo e com uma abordagem diferenciada em rela ca o aos protocolos descritos nessa se ca o. De fato o protocolo descrito a seguir ser a o protocolo implementado e estendido no m odulo que gerencia cartas da API proposta nesse trabalho. Abordagem orientada ao p oquer Com base nos protocolos descritos anteriormente, GOLLE (2005) prop oe um novo protocolo para embaralhar e distribuir cartas. O protocolo proposto utiliza duas caracter sticas de jogos de cartas, em especial jogos de p oquer, que s ao negligenciadas por protocolos gen ericos de cartas: 1. cartas em jogos de p oquer s ao distribu das em rodadas, com apostas entre as rodadas em vez de serem distribu das de uma s o vez; 2. o n umero total de cartas utilizadas num jogo de p oquer e pequeno e depende do n umero de jogadores. O n umero total de cartas utilizadas num jogo geralmente n ao e maior que a metade do baralho. A ideia do protocolo e distribuir o custo de embaralhar e distribuir as cartas ao longo das rodadas em vez de realizar essa tarefa num u nico momento com tempo e custo de processamento elevado. Comparado com outros protocolos que embaralham todo o baralho de uma s o vez, GOLLE (2005) argumenta que seu protocolo 49 diminui a lat encia e o custo computacional por realizar essa tarefas de forma fragmentada ao longo do jogo. Segundo o autor, a partir de uma estimativa calculada analiticamente por meio do n umero de modula ca o exponencial, o custo computacional para embaralhar e distribuir as cartas num jogo de Texas Holdem50 entre 5 jogadores foi 66% menor comparado com outros protocolos mais gen ericos. Tamb em foi levantado que a lat encia para a congura ca o inicial do jogo - etapa que distribui as cartas para compor a m ao inicial de cada jogador - foi 85% menor.
Skat e um jogo de cartas popular da Alemanha jogado com 3 jogadores e um baralho com 32 cartas. 49 O termo lat encia no contexto do protocolo e entendido como o tempo de comunica c ao entre os jogadores. 50 Texas Holdem e estilo mais popular de jogo de p oquer geralmente jogado com dois a cinco jogadores.
48

36

Conceitualmente, as cartas no protocolo s ao representadas pelo intervalo [1,...,52]. Uma carta c aleat oria e gerada juntamente pelos jogadores ao calcular a criptograa E(c) de c a [1,...,52]. Os jogadores comparam E(c) com cada carta criptografada E(c1),...,E(ct) que foi distribu da durante o jogo. Se E(c) for igual a uma carta criptografada, E(c) e descartada e uma nova carta e gerada. Caso a carta ainda n ao tenha sa do no jogo e essa carta e para o jogador P, os outros jogadores ajudam o jogador P a descriptografar E(c) de forma que a carta c seja conhecida apenas por P. Percebe-se que a a ca o de embaralhar e distribuir as cartas ocorrem em paralelo a cada carta que e gerada. Em contrapartida, o protocolo proposto n ao e adequado para distribuir todas as cartas do baralho, pois a medida que aumenta o n umero de cartas que s ao geradas, o n umero de colis oes tamb em aumenta. O n umero de colis oes esperado para distribuir 1 a(a1) oes para a 52. a cartas e de aproximadamente 52 ( 2 ) colis Assumindo que k seja o n umero de jogadores e que num cen ario estressante k 1 jogadores est ao trapaceando, o protocolo proposto assegura as seguintes propriedades: Corre ca o51 : A cada carta distribu da, seja para quem est a trapaceando ou n ao, a carta e gerada de forma aleat oria a partir do conjunto de cartas; Privacidade52 : O jogador(es) que est a( ao) trapaceando n ao obt em( em) nenhuma informa c ao adicional sobre as cartas dos outros jogadores que n ao est ao trapaceando; Robustez53 : O protocolo permite que um jogador desista do jogo, mas previne que um jogador impe ca outro jogador de continuar jogando. Com um baralho de 52 cartas como exemplo, a seguir ser a descrito o protocolo proposto por GOLLE (2005) que utiliza o sistema de criptograa ElGamal(ELGAMAL, 1985): 1. Deni c ao dos par ametros do ElGamal: assuma que p seja um n umero primo grande e q um n umero primo menor que p tal que q |(p - 1). Seja g Z p um elemento de ordem q e G o grupo multiplicativo de Z gerado por g . Seja p x x um n umero aleat orio Zp e y = g . Os par ametros p, g e y s ao a chave p ublica. O n umero x e a chave privada que ser a gerada no pr oximo passo; 2. Gera c ao distribu da de chaves: a gera ca o distribu da de chaves (GDC) proposta por PEDERSEN (1991), tamb em chamada de (k, n )-threshold ou (k,
51 52

Tradu c ao do termo em ingl es correctness. Tradu c ao do termo em ingl es privacy. 53 Tradu c ao do termo em ingl es robustness.

37

n )-GDC, permite que um conjunto de n jogadores gere juntamente um segredo de forma que o mesmo que distribu do entre os jogadores sendo necess ario um subgrupo de tamanho maior ou igual a k para revelar, enquanto um subgrupo menor que k n ao consegue obter qualquer informa ca o. Os jogadores geram o par de chave p ublica e privada do ElGamal, onde ao nal todos os jogadores conhecem a chave p ublica e compartilham um segredo xi da chave privada x k sendo i=1 xi = x mod q. O protocolo de PEDERSEN (1991) e descrito na Se ca o 2.3.8; 3. Gera c ao da chave sim etrica: cada par de jogadores (Pi , Pj ) acorda uma chave secreta ki,j para ser usada em uma criptograa sim etrica, o que torna poss vel uma comunica ca o segura entre os jogadores; 4. Representa ca o das cartas em mem oria: cada jogador calcula antecipadamente os valores das 52 cartas como g 0 , g 1 , ..., g 51 G; 5. C alculo do grupo de combina ca o de cartas: assumindo que k e o n umero de jogadores e que o baralho cont em 52 cartas, cada jogador calcula e armazena as seguintes mensagens criptografadas: Di = E (g 52i ) para i = 0,..., k - 1, onde S = {D0 , ..., Dk1 }. Como ser a visto a seguir, o grupo S e utilizado para vericar se uma carta j a foi gerada anteriormente; 6. Comprometimento com a carta: cada jogador Pi escolhe ri {0, ..., 51}, calcula Ci = E (g ri ) e anuncia um comprometimento de Ci por meio de uma fun ca o hash. Se um jogador tentar trapacear ao escolher ri / {0, ..., 51}, nenhum problema ocorre no protocolo; 7. Provando o comprometimento: cada jogador Pi revela Ci e todos os jogadores vericam se todos os valores comprometidos no passo anterior est ao corretos. Se um ou mais valores comprometidos est ao errados, o jogador que trapaceou e banido e um novo grupo e formado com os outros jogadores; 8. Gerando carta criptografada: usando a propriedade de criptograa homom orca aditiva do ElGamal, os jogadores calculam E ( i g ri ) = E (g c ), onde c = i ri mod q. Se todos os jogadores escolherem honestamente os valores de r, c {1, ..., 51k }; 9. Testando colis ao: sendo E (m1 ) e E (m2 ) duas mensagens criptografadas com ElGamal, JAKOBSSON e SCHNORR (1999) prop oem um teste de igualdade 54 de texto que a partir de E (m1 ) e E (m2 ) e poss vel vericar se m1 = m2 sem revelar m1 ou m2 ou qualquer outra informa c ao. Em seu protocolo, dado o
54

Tradu c ao da express ao em ingl es oblivious test of plaintext equality.

38

conjunto (g, y, m, s ) e x como chave privada, e necess ario determinar e provar se logg (y) = logm (s). O protocolo tem a seguinte forma: (a) Congura ca o: seleciona-se um n umero aleat orio a Z p; (b) Prova de primeira ordem: seja o conjunto ( s, , m) = (sa , max , ma ). Verica-se se s= ; (c) Prova de segunda ordem: Verica-se se logm (m ) = logs ( s) e tamb em se logg (y) = logm ). ( Como forma de vericar e exemplicar o uso do protocolo acima para determinar se duas cartas s ao iguais, assuma duas cartas: c1 e c2 . As duas cartas criptografadas possuem a seguinte forma: E(c1 ) = E(g c1 ) = (g r1 , g c1 y r1 ) = (a1 , b1 ) e E(g c2 ) = (g r2 , g c2 y r2 ) = (a2 , b2 ), sendo r1 e r2 n umeros aleat orios e y = x g . Utilizando o homomorsmo multiplicativo do ElGamal, calcula-se E (c1 )/E (c2 ) = (g r1 r2 , g c1 c2 y r1 r2 ). Para testar se duas cartas s ao iguais, o problema e equivalente a testar se uma mensagem criptografada e o n umero 1 criptografado. Portanto, se c1 = c2 , ent ao E (c1 )/E (c2 ) = (g r1 r2 , g 0 y r1 r2 ) = (g r , 1 y r ) = (g r , y r ) = (a, b ). Utilizando o protocolo de JAKOBSSON e SCHNORR (1999), o conjunto (g, y, m, s ) e substitu do por (g, y, a, b ) para provar se logg (y) = loga (b). Para testar a prova de primeira ordem, o conjunto ( b, , a ) = (br , ar x , ar ) e r e um n umero aleat orio. Como o protocolo de PEDERSEN (1991) distribui x a chave privada entre os jogadores, ou seja, k i=1 xi = x, o fator a pode ser xi calculado por todos os jogadores de forma que ax = k e i=1 a . Portanto, necess aria a participa ca o de todos os jogadores para executar o protocolo de igualdade de cartas. A prova de primeira ordem pode ser vericada da seguinte forma: b= b r = ar x y rr = g rr x g rr x = g rr x A primeira parte da prova de segunda ordem pode ser vericada da seguinte forma: loga ( a) = logb ( b) 39

loggr (g rr ) = logyr (y rr ) r =r Por m, a segunda parte da prova de segunda ordem pode ser vericada da seguinte forma:

logg (y ) = loga ) ( logg (y ) = loggrr (g rr x ) logg (y ) = x y = gx Como parte do processo de verica ca o de igualdade de cartas, os jogadores mant em uma lista L = {E (c1 , ..., E (ct ))} contendo todas as cartas criptografadas que j a foram distribu das durante o jogo. Essa lista mant em cartas que foram geradas de forma aberta e tamb em cartas que foram geradas de forma fechada. Se L = 0, os jogadores devem testar se uma nova carta gerada E (g c ) L. Para cada carta criptografada E (g c ) L, os jogadores devem determinar se c = c mod 52 da seguinte forma: (a) Usando o homomorsmo do ElGamal, os jogadores calculam E (g c /g c ) = E (g cc ); (b) Utilizando o teste de igualdade de texto proposto por JAKOBSSON e SCHNORR (1999), os jogadores comparam E (g cc ) com cada valor criptografado do conjunto S. Se alguma igualdade e encontrada, a carta c j a saiu anteriormente. O protocolo aborta e os jogadores iniciam novamente o protocolo de gera ca o de carta. Se n ao foi encontrada nenhuma igualdade, ou seja, se para cada E (g c ) L, E (g cc ) / S , a carta c ainda n ao foi distribu da no jogo; 10. Gerando uma carta aberta: Cada jogador revela ri e o n umero aleat orio usado para gerar E (g ri ). Os jogadores vericam se todos ri {0, ..., 51} e se os valores criptografados est ao corretos. Se um ou mais jogadores trapacearam, o protocolo aborta e um novo grupo e formado pelos outros jogadores. Se todos os jogadores foram honestos, a carta gerada e i ri mod 52; 11. Gerando uma carta fechada: Cada jogador revela somente para Pj o valor de ri e o n umero aleat orio usado para gerar E (g ri ). Nesse momento utiliza-se a chave secreta acordada entre o par Pi , Pj no passo 3 para estabelecer uma 40

comunica c ao segura com criptograa sim etrica. O jogador Pj verica se todos ri {0, ..., 51} e se os valores foram criptografados corretamente. Se um ou mais jogadores trapacearam, o protocolo aborta e um novo grupo e formado pelos outros jogadores. Se todos os jogadores foram honestos, a carta gerada e i ri mod 52. O passo 2 garante que nenhum jogador consiga descriptografar a carta criptografada, pois somente com a colabora ca o de todos os jogadores e poss vel reconstruir a chave privada. De fato o protocolo n ao precisa em nenhum momento reconstruir a chave privada. No passo 9 os jogadores tem o objetivo de vericar se uma carta E (g c ) j a foi gerada anteriormente. Essa verica c ao e feita com a carta criptografada e sem revelar o valor da carta por meio do teste de igualdade de texto. Para cada carta criptografada E (g c ) L, os jogadores computam E (g cc ). No entanto, como chegar matematicamente na express ao E (g cc )? Para isso, lembrando que na criptograa ElGamal a mensagem m criptografada e composta por duas partes (a, b ), e seja E (g c ) = (a1 , b1 ) e E (g c ) = (a2 , b2 ), a express ao E (g cc ) e equivalente a E (g c )/E (g c ) 1 1 = (a1 a 2 , b1 b2 ). Para um melhor entendimento da motiva c ao do uso da propriedade homom orca multiplicativa para vericar se uma carta j a foi gerada e tamb em do uso do conjunto S denido no passo 5, a seguir encontra-se uma breve argumenta ca o. Considere um exemplo composto por 2 jogadores, P1 e P2 , e um baralho de 4 cartas apenas. As cartas s ao identicadas pelos n umeros 0, 1, 2 e 3. Na primeira rodada a carta 2 foi gerada. Na segunda rodada, o jogador P1 escolhe o n umero 3 e o jogador P2 tamb em escolhe o n umero 3. O valor da carta gerada e 3 + 3 = 6. Aparentemente c = c, pois 2 = 6. No entanto, as cartas 2 e 6 s ao a mesma carta, pois a carta 6 deve ser reduzida pelo m odulo do n umero total de cartas, ou seja, 6 2 mod 4. Como solu c ao desse problema, o conjunto S e gerado no passo 5. Nesse exemplo, S = {E (g 40 ), E (g 41 )} ou S = {E (g 0 ), E (g 4 )}. Dessa forma, utilizando o homomorsmo multiplicativo, calcula-se E (g 62 ) = E (g 4 ). Utilizando o teste da igualdade de texto descrito no passo 9, o valor E (g 4 ) e comparado com cada elemento de S. Portanto, nesse exemplo verica-se que E (g 4 ) S, ou seja, a carta j a foi gerada em uma rodada anterior.

41

Cap tulo 3 Proposta de Biblioteca de Suporte a A c oes em Jogos Ponto-a-Ponto


Este cap tulo apresenta a proposta conceitual da biblioteca de suporte a determinadas a c oes em jogos ponto-a-ponto, como a c oes relacionadas a ` sorte com dados e cartas. Para tanto, e apresentado a estrutura b asica que comp oe o protocolo de comunica c ao da biblioteca. Tamb em s ao apresentados os dois m odulos que comp oem a biblioteca chamados de Dice Rolling e Mental Poker, sendo o primeiro para jogar dados e o segundo para jogar cartas. Para cada m odulo e realizada uma proposta de protocolo criptogr aco ou opera co es, a modelagem conceitual, como cada m odulo funciona internamente e tamb em como us a-lo. Por m s ao descritas as decis oes arquiteturais adotadas na modelagem da biblioteca.

3.1

Base de comunica c ao dos protocolos

Um protocolo criptogr aco envolve a troca de mensagens entre os participantes a m de realizar uma tarefa. Em termos de processo de comunica c ao, deve existir alguma estrutura que represente e permita essa troca de mensagens. Com esse objetivo, a Figura 3.1 apresenta o diagrama de classes que tem por responsabilidade permitir a comunica c ao entre os jogadores participantes do protocolo. Os m odulos que comp oem a biblioteca e que s ao descritos neste cap tulo utilizam essa estrutura b asica como forma de comunica c ao entre os jogadores do protocolo. Uma mensagem trocada entre os jogadores no protocolo e representada pela classe Message. A classe Message, como o o pr oprio nome indica, tem a responsabilidade de carregar informa co es - mensagem - entre os jogadores. Sua estrutura e composta pelos campos Method, Headers e Data. O campo Method e um enumerator 1 do tipo MessageMethod que indica qual a c ao, ou passo, o protocolo est a executando.
Enumerator, tamb em chamado de enum, e um tipo de dado composto por um conjunto de elementos nomeados que atuam como identicadores e constantes.
1

42

Figura 3.1: Diagrama de classes que comp oem a base da comunica ca o dos protocolos Esse campo e obrigat orio, pois n ao existe mensagem sem uma a ca o. Nesse caso, seria uma mensagem vazia. Os tipos de m etodos de MessageMethod ser ao descritos ainda nesse cap tulo ` a medida que a arquitetura de cada m odulo for descrita. Como um exemplo, o m etodo do tipo FirstDiceHashCommitment utilizado no m odulo Dice Rolling indica que um jogador est a enviando o seu valor comprometido de um dado. O campo Headers e um enumerator do tipo MessageHeader que tem a responsabilidade de carregar informa co es extras que podem fazer sentido num determinado momento. Esse campo e opcional. Como exemplo, o header do tipo Step indica a rodada em que um jogo se encontra, e o campo Comment pode informar um coment ario feito por algum jogador naquela jogada. A classe Message pode carregar zero ou mais MessageHeader. Por m, o campo Data carrega a mensagem composta por um array de bytes. De fato, o campo Data armazena os valores num ericos e criptografados em bytes que s ao trocados e utilizados no protocolo criptogr aco. A interface IProtocolCommitted e obrigat oria para qualquer classe que utilize os protocolos ciptogr acos da biblioteca. A implementa ca o dessa interface signica que uma classe e capaz de enviar uma mensagem para um determinado jogador ou peer via chamada do m etodo SendMessage(message:Message, peerID:int):void. Al em disso e poss vel obter uma lista com o identicador de cada peer participante do protocolo via chamada do m etodo GetPeersID():List<int>. Portanto, a classe que estiver utilizando algum m odulo da biblioteca ser a capaz de enviar uma mensagem do tipo Message para qualquer peer, pois o pr oprio m odulo da biblioteca que estiver sendo utilizado chamar a internamente esse m etodo para enviar uma

43

mensagem do protocolo.

3.2

M odulo Dice Rolling

Esta subse c ao apresenta o primeiro m odulo da biblioteca chamado de Dice Rolling que prov e a capacidade de jogar dados em uma forma distribu da entre um conjunto de jogadores.

3.2.1

Proposta de protocolo para n jogadores

O protocolo de jogar moeda, que tamb em pode ser utilizado para jogar dado, descrito na se ca o 2.3.9 descreve a intera ca o de apenas dois jogadores. A seguir e proposto uma extens ao desse protocolo com a participan ca o de n jogadores: 1. O jogador P1 gera um n umero aleat orio R1 de 64 bits. Por meio de uma fun ca o hash SHA, P1 calcula o valor hash de R1 e envia para P2 , ..., Pn ; SHA(R1 ) 2. Como o jogador P1 , os jogadores P2 , ..., Pn tamb em executam o passo anterior, onde cada jogador se compromete com o seu n umero aleat orio; SHA(R2 ), ..., SHA(Rn ) 3. P1 envia para P2 , ..., Pn o seu n umero aleat orio R1 ; R1 4. Como o jogador P1 , os jogadores P2 , ..., Pn tamb em executam o passo anterior, onde cada jogador envia seu n umero aleat orio para os outros jogadores; R2 , ..., Rn 5. Nesse momento, cada jogador compara o n umero hash e o n umero aleat orio que recebeu de cada jogador; e o n umero comSHA(R1 ) = SHA(R1 ), ..., SHA(Rn ) = SHA(Rn ), onde Rn prometido ao nal do passo 2 e Rn e o n umero aleat orio enviado ao nal do passo 4; 6. Cada jogador calcula o resultado da seguinte forma: (R1 + ... + Rn ) mod 6. Como inst ancia do protocolo acima, a seguir e descrito o protocolo com tr es jogadores:

44

1. Alice gera um n umero aleat orio RA de 64 bits. Por meio de uma fun ca o hash SHA, Alice calcula o valor hash de RA e envia para Bob e Carol; SHA(RA ) 2. Bob gera um n umero aleat orio RB de 64 bits . Por meio de uma fun ca o hash SHA, Bob calcula o valor hash de RB e envia para Alice e Carol; SHA(RB ) 3. Carol gera um n umero aleat orio RC de 64 bits . Por meio de uma fun c ao hash SHA, Carol calcula o valor hash de RC e envia para Alice e Bob; SHA(RC ) 4. Alice envia para Bob e Carol o seu n umero aleat orio RA ; RA 5. Bob e Carol conrmam se o n umero que Alice se comprometeu no passo 1 e igual ao valor hash do n umero enviado no passo 4. SHA(RA ) = SHA(RA ), onde SHA(RA ) e o comprometimento enviado no passo 1 e RA e o n umero de 64 bits enviado no passo 4 6. Bob envia para Alice e Carol o seu n umero aleat orio RB ; RB 7. Alice e Carol conrmam se o n umero que Bob se comprometeu no passo 2 e igual ao valor hash do n umero enviado no passo 6. SHA(RB ) = SHA(RB ), onde SHA(RB ) e o comprometimento enviado no passo 2 e RB e o n umero de 64 bits enviado no passo 6 8. Carol envia para Alice e Bob o seu n umero aleat orio RC ; RC 9. Alice e Bob conrmam se o n umero que Carol se comprometeu no passo 3 e igual ao valor hash do n umero enviado no passo 8. SHA(RC ) = SHA(RC ), onde SHA(RC ) e o comprometimento enviado no passo 3 e RC e o n umero de 64 bits enviado no passo 8 10. Alice, Bob e Carol conrmam entre eles se o resultado e v alido; 11. Alice, Bob e Carol calculam o resultado da seguinte forma: (RA + RB + RC ) mod 6.

45

Ao nal do passo 3, todos os jogadores est ao comprometidos com os seus n umeros, pois cada um enviou o seu n umero hash e tamb em recebeu o n umero hash dos outros jogadores. Dessa forma, qualquer tipo de trapa ca e descoberta, pois cada participante verica se o n umero hash comprometido pelo outro jogador e igual ao n umero hash gerado a partir do n umero original enviado pelo outro jogador. O protocolo proposto tamb em evita qualquer tipo de trapa ca caso dois jogadores se juntem para jogar contra o jogador restante. Supondo que Alice e Bob trapaceiem escolhendo os n umeros entre eles no passo 1 e 2, o n umero resultante ainda seria aleat orio, pois o n umero gerado por Carol no passo 3 ainda seria aleat orio. Mais ainda, caso Alice e Bob alterem os seus n umeros originais, Carol descobriria a trapa ca conferindo o n umero hash comprometido por Alice e Bob nos passos 1 e 2. O protocolo proposto gera 12 trocas de mensagens entre os tr es jogadores. A medida que o n umero de jogadores aumenta, o n umero de mensagens aumenta. Como mostra a Figura 3.2, temos 24 trocas de mensagens com 4 jogadores, 40 trocas de mensagens com 5 jogadores e 60 trocas de mensagens com 6 jogadores.

Figura 3.2: N umero de mensagens por n umero de jogadores Seja a vari avel n o n umero de jogadores participantes do protocolo, cada jogador deve enviar para os outros (n - 1) jogadores 2 mensagens, uma contendo o valor hash de comprometimento e outra contendo o valor aleat orio. Logo, o n umero total de mensagens e 2 * n * (n - 1) = 2n2 - 2n. Portanto, a complexidade e O (n2 )2 para a opera ca o de jogar dados. Caso o n umero de jogadores aumente consideravelmente, o sistema composto por esses peers pode car comprometido devido a grande quantidade de troca de mensagens, podendo, de fato, aumentar o tempo para gerar o n umero do dado. Al em disso, caso seja necess ario jogar, por exemplo, tr es dados, o n umero de mensagens triplica. Por exemplo, supondo um sistema com 5 jogadores, onde um jogador tenha
A nota c ao Big O e uma nota c ao matem atica aplicada para analisar o desempenho e comportamento de um algoritmo quando os dados de entrada crescem para valores muito grandes que seguem para o innito.
2

46

que jogar tr es dados, o n umero de mensagens trocadas entre esses jogadores e tr es vezes 40 mensagens, ou 120 mensagens. Fica claro que um sistema composto por um n umero grande de jogadores poder a car comprometido, pois o tempo para gerar um n umero de dado pode ser muito grande. O m odulo Dice Rolling proposto a seguir implementa o protocolo para n jogadores descrito acima. Esse m odulo tamb em implementa a estrat egia de executar o protocolo n vezes para jogar n dados. Al em do mais, como alternativa, o m odulo implementa um outro modo de jogar os dados, o chamado modo em lote. Por exemplo, para jogar 4 dados, em vez de executar o protocolo quatro vezes, uma vez para cada dado, o protocolo e executado apenas uma vez, gerando os quatro n umeros em apenas uma rodada.

3.2.2

Nota c ao padr ao de dados

No m odulo Dice Rolling, o jogador expressa a sua jogada por meio de uma nota c ao de dado. A nota ca o de dado e um sistema que serve para representar diferentes combina co es de dados, geralmente em jogos de role-playing game, usando uma nota ca o como 3d10 + 4, que representa o jogar de tr es dados de dez faces, com o resultado sendo a soma dos valores desses tr es dados mais o n umero quatro. Na nota ca o padr ao, o caractere d representa o dado. O n umero que precede a letra d indica o n umero de dados. O n umero que aparece depois da letra d indica o n umero de faces do dado. A nota ca o pode ser modicada com uma opera c ao matem atica e um n umero (KIPM, 2013): XdY [-][+][x][/] N X dados com Y faces modicados por meio de uma opera c ao matem atica com o n umero N. Um segundo dado tamb em pode ser usado em vez de um n umero (KIPM, 2013): XdY [-][+][x][/] AdB X dados com Y faces modicados por meio de uma opera c ao matem atica com A dados de B faces. Ainda como uma outra varia c ao comum, e poss vel escrever a nota ca o na forma XdY - [L][H], onde o caractere L signica o dado com o menor valor e o caractere H o dado com o maior valor. Por exemplo, 3d6 - L signica jogar tr es dados de seis faces e eliminar o dado de menor valor. Em 4d6 - H, quatro dados de seis faces s ao jogados e o maior dado e eliminado.

47

A nota ca o padr ao e uma evolu c ao de outra nota ca o introduzida em 1974, com a edi ca o Blue Box do jogo Dungeons & Dragons 3 (WINTER, 2007). Na nota ca o original de Dungeons & Dragons, os dados eram indicados pela amplitude de resultados. Por exemplo, 2d6 era expressado como 2-12, 3d10 era 3-30 (WINTER, 2007). A nota c ao que indica a amplitude de resultados tem uma vantagem por tornar imediato a identica c ao dos poss veis valores. A Tabela 3.1 apresenta alguns valores representados na nota ca o de amplitude de resultados e tamb em na nota c ao padr ao. Com a nota ca o de amplitude de resultados e imediato identicar qual e a melhor op ca o para um ataque ao inimigo. Nesse exemplo, e f acil identicar que a op c ao 2-16 oferece um valor maior de dano ao inimigo. Tabela 3.1: Compara c ao entre os tipos de nota ca o de dados (adaptado de WINTER (2007)) Nota ca o padr ao 1d8 2d6 2d4 + 1 2d8 1d10 Nota ca o de amplitude 1-8 2-12 3-9 2-16 1-10

No entanto, a nota ca o de amplitude de resultados tem algumas desvantagens. Identicar a combina ca o de dados que deve ser usada para gerar uma determinada amplitude de resultados pode ser uma tarefa desaadora. Por exemplo, para gerar 3-12, deve-se usar 3d4 ou 1d10 + 2? Para gerar 30-300, deve-se usar 30d10, 1d10 x 30, 5d10 x 6? A probabilidade de resultados muda signicativamente dependendo de qual estrat egia usar. Com a nota ca o padr ao, esses problemas s ao evitados. Como ser a discutido ainda nesse cap tulo, o m odulo Dice Rolling implementa uma vers ao da nota c ao padr ao, e tamb em oferece a possibilidade para o usu ario da biblioteca implementar a sua pr opria vers ao da nota ca o padr ao.

3.2.3

Modelagem

Para modelar o m odulo Dice Rolling foram necess arios alguns ciclos de concep c ao, implementa c ao, teste, valida c ao e aperfei coamento para que o m odulo pudesse car simples de usar, que atendesse a um objetivo claro, o de jogar dado de forma segura entre dois ou mais jogadores, e que tamb em oferecesse a possibilidade do usu ario estender determinados comportamentos. A Figura 3.3 representa o diagrama de classes a n vel de projeto do m odulo Dice Rolling.
Dungeons & Dragons e um role-playing game, ou RPG, de fantasia medieval, publicado pela considerado como a origem dos RPG modernos. primeira vez em 1974. E
3

48

Figura 3.3: Diagrama de classes de projeto do m odulo Dice Rolling

49

A classe central do m odulo e a classe abstrata DiceRolling, que prov e a orquestra ca o de todas as outras classes, al em de servir como o ponto de acesso ao m odulo. A classe DiceRolling tem a responsabilidade de receber uma nota ca o de dado e retornar um resultado, al em de oferecer um hist orico de todas as jogadas anteriores. Por ser uma classe abstrata, ela n ao pode ser instanciada, mas sim implementada por meio de dois m etodos abstratos: CalculateSecureNumbers(numberOfDices int): void e ReceiveMessage(message: DRMessage, peerID: int): void. O primeiro m etodo tem a fun c ao de calcular, por meio da implementa c ao do protocolo criptogr aco Dice Rolling descrito anteriormente, numberOfDices n umeros que ser ao utilizados na avalia ca o da nota c ao de dado. O segundo m etodo tem a responsabilidade de receber cada mensagem enviada por outro peer a m de permitir a troca de mensagens necess arias para a implementa c ao do procolo. Como descrito na Se c ao 3.1 a classe Message e a unidade de mensagem que e trocada entre os peers a cada passo do protocolo. Essa classe cont em a mensagem enviada de um peer para o outro, o passo corrente em que o protocolo se encontra, a nota ca o de dado da jogada e tamb em um coment ario que indica o contexto da jogada, como matando um monstro. Como descrito na Se c ao 3.1 a interface IProtocolCommitted permite que o usu ario use esse m odulo por exigir a implementa ca o de dois m etodos abstratos: SendMessage(message: Message, peerID: int): void e GetPeersID(): List<int>. O m odulo Dice Rolling n ao sabe enviar uma mensagem, pois depende de qual arquitetura ou tecnologia est a sendo usada. Portanto, quem sabe enviar uma mensagem e o pr oprio usu ario do m odulo. Dessa forma, o primeiro m etodo abstrato exige que o usu ario tenha a responsabilidade de enviar uma mensagem para outro peer. O segundo m etodo retorna um identicador de cada peer que est a participando do protocolo. A interface IDiceRolling prov e para a classe usu aria do m odulo Dice Rolling um ponto de acesso aos resultados das jogadas. O m etodo Roll(peerID: int, result: DRResult): void e chamado internamente pelo m odulo Dice Rolling passando o resultado da jogada via objeto DRResult e tamb em o identicador do peer que jogou os dados. Portanto, sempre que um jogador iniciar uma jogada, todos os jogadores, inclusive o jogador que iniciou a jogada, receber ao os resultados por meio desse m etodo. A interface IDiceNotationParser tem a responsabilidade de calcular o resultado do protocolo a partir de uma nota c ao de dado. O m etodo abstrato Result(DiceNotation: String, SecureNumbers: List<long>): Dictionary<String, String> recebe uma nota ca o de dado e uma lista de n umeros que foram gerados por meio do protocolo criptogr aco, e retorna um dicion ario com o resultado em forma de resultado aberto e resultado nal. Por 50

exemplo, supondo uma nota ca o de dado 1d6 + 2d4, e uma lista de n umeros seguros 245, 25, 385 gerados pelo protocolo, o resultado nal ser a 5 + 1 + 1 que e igual a 7, e o resultado aberto ser a a lista com os valores dos dados na forma (5, 1, 1). Dessa forma, e obtido o resultado nal, assim como os valores individuais dos dados que determinaram o resultado nal. Por m, essa interface ainda exige que o usu ario implemente mais dois m etodos: IsDiceNotationValid(DiceNotation> String) e NumberOfDicesNeeded(DiceNotation: String). O primeiro indica se uma nota ca o de dado e v alida, ou seja, se todos os operadores s ao v alidos, se a ordem em que os termos aparecem est ao corretos, etc. O segundo m etodo analisa uma nota ca o de dado e retorna a quantidade de dados necess arios para calcular essa nota ca o de dado. Por exemplo, com a nota c ao 2d12 + 3d4 s ao necess arios 5 dados. Depois de gerar o resultado, a classe DiceRolling guarda um hist orico das jogadas por meio de objetos DRResult. Pode-se recuperar, para uma determinada rodada, o nome do jogador que iniciou a jogada por meio de um n umero que identica o peer, a nota ca o de dado, o coment ario da jogada, assim como o resultado nal e o resultado aberto. O m etodo GetHistory(): List<DRResult> retorna uma lista de objetos DRResult permitindo ao usu ario manipular o hist orico de jogadas por meio de opera co es em uma lista. O m etodo ClearHistory(): void permite ao usu ario apagar o hist orico das jogadas caso necess ario. A adi c ao de um novo objeto DRResult, ou seja, o registro de uma nova jogada e feita somente pelo m odulo Dice Rolling, e n ao pelo usu ario do m odulo.

3.2.4

Funcionamento interno

O m odulo Dice Rolling e composto por um conjunto de classes, cada uma com responsabilidade bem denida. No diagrama de sequ encia da Figura 3.4, a enfase est a na ordem temporal das mensagens trocadas entre os objetos dessas classes a m de executar as tarefas do m odulo Dice Rolling. A opera ca o de jogar um dado e iniciada a partir do recebimento da mensagem ass ncrona Roll, que envia uma nota ca o de dado para ser calculada pelo m odulo. Antes que o protocolo criptogr aco seja iniciado, uma mensagem s ncrona e enviada ao objeto ClassicDiceNotationParser para vericar se essa nota ca o de dado e v alida. Em caso positivo, outra mensagem s ncrona e enviada para determinar a quantidade de dados que essa nota ca o de dado exige. Em seguida, inicia-se a execu ca o do protocolo criptogr aco a partir da mensagem ass ncrona CalculateSecureNumbers. Nesse momento os peers participantes trocam uma s erie de mensagens que tem por objetivo executar o protocolo criptogr aco descrito na se ca o 3.2.1. O resultado do protocolo criptogr aco e um conjunto de n umeros de 64 bits utilizados para o c alculo dos valores dos dados. Dessa forma,

51

Figura 3.4: Diagrama de sequ encia das mensagens internas do m odulo Dice Rolling na gera ca o de dados quando o protocolo criptogr aco termina de executar, uma mensagem ass ncrona e enviada via CalculateResults para a classe principal DiceRolling para c alculo da nota ca o de dados. A partir disso, por meio da mensagem Result, a classe ClassicDiceNotationParser tem a fun c ao de calcular o resultado fechado e o resultado aberto da nota c ao de dado com os n umeros seguros gerados pelo protocolo criptogr aco. Em seguida um novo registro e adicionado ao hist orico de jogadas por meio da chamada AddHistory que adiciona o identicador do peer, o n umero da rodada, o resultado fechado, o resultado aberto e o coment ario feito pelo jogador naquela rodada. Por m, a execu ca o termina quando o m odulo Dice Rolling chama o m etodo de callback Roll(peerID:int, result:DRResult):void da interface IDiceRolling passando o resultado daquela jogada e o identicador do peer que jogou.

3.2.5

Como usar o m odulo

A seguir e apresentado um c odigo fonte de exemplo do uso do m odulo Dice Rolling. O c odigo est a escrito na linguagem de programa ca o C#:
1 2 3 4 5 6

public class Player : IDiceRolling { private DiceRolling _diceRolling; public Player (DiceRolling dr) { _diceRolling = dr; _diceRolling.SetDelegate(this); 52

7 8 9 10 11 12 13 19 20 21 22 23 24 25 26 27 28 29 30 31 32

} public void SendMessage(Message message, int peerID) { /* implementa ca ~o */ } public List<int> GetPeersID() { /* implementa ca ~o */ } public void SetDiceNotationParser (IDiceNotationParser diceNotationParser) { _diceRolling.SetDiceNotationParser(diceNotationParser); } public void Roll(int peerID, DRResult result) { /* implementa ca ~o */ } public void RollDice(string diceNotation, string comment){ _diceRolling.Roll(diceNotation, comment); } }

Para a classe Player usar o m odulo Dice Rolling e necess ario implementar a interface IDiceRolling e fazer agrega ca o com uma subclasse de DiceRolling. A interface IProtocolCommitted e implementada nas linhas 9 e 12, enviando mensagens para outros peers e informando o identicador de cada peer participante do protocolo. A interface IDiceRolling e implementada na linha 29, m etodo onde o resultado de uma jogada ser a recebido. O construtor, na linha 4, recebe como par ametro um tipo DiceRolling, o que permite um desacoplamento de depend encia4 , permitindo o uso de diferentes implementa c oes de protocolos criptogr acos desde que sejam subclasses de DiceRolling. Na linha 6 e declarado a delega c ao, onde a classe do tipo DiceRolling ir a delegar o envio de mensagens pela classe Player. Na linha 30 e realizado de fato a chamada do m etodo Roll, passando a nota ca o de dado e um coment ario da jogada. A linha 23 mostra a possibilidade do usu ario substituir o componente padr ao que valida e calcula uma nota ca o de dado. Abaixo est a um exemplo de execu ca o do m odulo Dice Rolling :
1
4

Player player = new Player(new DROneWayFunction(true));

Esse padr ao e conhecido como inje c ao de depend encia, em ingl es dependency injection, onde a depend encia entre m odulos n ao e denida programaticamente, mas sim pela inje c ao dessa depend encia via polimorsmo.

53

player.RollDice("1d6 + 2d12 - 3", "Matando o monstro.");

Na linha 1 e feito a inje c ao de depend encia com a classe concreta DROneWayFunction. O par ametro true indica que o protocolo criptogr aco ser a executado em lote, ou seja, o protocolo ser a executado apenas uma vez independente do n umero de dados (ver mais detalhes no nal da se ca o 3.2.1). Na linha 2 o dado e jogado de fato, passando como argumentos a nota ca o de dado e o coment ario da jogada. O resultado dessa jogada ser a recebido na linha 26 na implementa ca o da classe Player. A seguir temos as formas de estender o m odulo Dice Rolling. A primeira forma e denir outro protocolo criptogr aco para jogar os dados.
1 2 3 4 5 6 7 8 9 10

public class MyOwnProtocol : DiceRolling { public override void CalculateSecureNumbers (int numberOfDices) { /* implementa ca ~o */ } public override void ReceiveMessage(Message message, int peerID) { /* implementa ca ~o */ } } Player player = new Player(new MyOwnProtocol(false));

Depois de herdar da classe DiceRolling, a classe MyOwnProtocol poder a ser usada como implementa ca o do protocolo criptogr aco como mostrado na linha 10 acima. Nesse exemplo o protocolo n ao ser a executado em lote, ou seja, caso a nota ca o tenha 5 dados, o protocolo ser a executado 5 vezes, uma para cada dado. A outra forma de estender o m odulo e denir a pr opria nota ca o de dado que ser a utilizada para jogar os dados entre os peers :
1 2 3 4 5 6 7 8 9 10 11

public class MyOwnDiceNotationParser : IDiceNotationParser { bool IsDiceNotationValid(string diceNotation) { /* implementa ca ~o */ } int NumberOfDicesNeeded(string diceNotation) { /* implementa ca ~o */ } Dictionary<string, string> Result (string diceNotation, IList<long> secureNumbers) { /* implementa ca ~o */ } } 54

12 13

player.SetDiceNotationParser(MyOwnDiceNotationParser);

A linha 13 do c odigo acima mostra que a nota c ao de dado padr ao e substitu da pela nota c ao implementada por MyOwnDiceNotationParser. Por m, a Figura 3.5 exibe um diagrama de sequ encia como exemplo das poss veis intera c oes de uma classe usu aria do m odulo Dice Rolling :

Figura 3.5: Diagrama de sequ encia de exemplo de uso do m odulo Dice Rolling A classe Player inicia com uma mensagem ass ncrona Roll para jogar os dados passando como argumentos a nota c ao de dado 2d6e o coment ario Matando o monstro. Por sua vez, a classe DROneWayFunction executa o c alculo dos dados via protocolo criptogr aco e retorna o resultado passando o identicador do jogador que iniciou a jogada e o resultado num objeto do tipo DRResult. Para o jogador que iniciou a jogada, o valor retornado para o identicador e -1, pois foi ele mesmo que jogou. Para o outro jogador, o identicador retornado tem valor 2345. Em seguida, o jogador realiza mais algumas opera co es como recuperar o resultado fechado da jogada por um m etodo que ele implementou chamado GetClosedResult, retornando a propriedade FinalResult da classe DRResult. Por m, o jogador decide apagar todo o hist orico do jogo chamando o m etodo ClearHistory.

3.3

M odulo Mental Poker

Esta subse c ao apresenta o segundo m odulo da biblioteca chamado de Mental Poker que prov e a capacidade de jogar cartas em uma forma distribu da entre um conjunto de jogadores. 55

3.3.1

Proposta de extens ao

Como descrito na subse c ao Uma abordagem orientada ao p oquer da se c ao 2.3.10, GOLLE (2005) prop oe um protocolo de Mental Poker que permite a distribui c ao de cartas entre os jogadores de forma segura. A carta gerada e distribu da pelo protocolo pode ser aberta, ou seja, vis vel entre todos os jogadores ou ser uma carta fechada, sendo vis vel apenas por um u nico jogador. A grande diferen ca do protocolo est a no fato de que n ao e preciso embaralhar todo o baralho antes da primeira rodada, diminuindo o custo computacional e a lat encia de comunica c ao entre os jogadores. As cartas s ao geradas ` a medida que uma nova carta precisa ser distribu da. Esse protocolo e ideal para jogos que usam apenas uma parte do baralho e que n ao distribuem todas as cartas entre os jogadores de uma s o vez, caracter sticas de um jogo de p oquer. Todavia, o protocolo proposto por GOLLE (2005) descreve como distribuir cartas entre jogadores, mas n ao descreve nenhum tipo de opera ca o com cartas, como por exemplo jogar uma carta aberta na mesa ou descartar uma carta. Por isso, com o objetivo de estender o protocolo, o m odulo Mental Poker proposto neste trabalho implementa e estende o protocolo de GOLLE (2005) com as seguintes opera co es: Jogadores geram uma carta para a mesa de forma aberta; Jogador joga carta de sua m ao na mesa de forma aberta; Jogador coloca uma carta de sua m ao novamente no baralho; Jogador Pi escolhe e pega carta da m ao do jogador Pj ; Jogador Pi recebe carta da m ao do jogador Pj que foi escolhida pelo pr oprio jogador Pj ; Jogador descarta carta de sua m ao no monte de descarte de forma aberta; Jogador descarta carta de sua m ao no monte de descarte de forma fechada; Jogadores incluem cartas do monte de descarte de novo no baralho. Supondo que k seja o n umero de jogadores, para que seja poss vel implementar essas opera co es, cada jogador Pi mant em um dicion ario que guarda todas as cartas criptografadas que cada jogador Pj para j = 1,...,k - 1 possui. Por exemplo, num jogo composto pelos jogadores Alice e Bob, Alice mant em um dicion ario onde a chave e um identicador para o jogador Bob, e o valor e o conjunto das cartas criptografadas que Bob possui. Assuma que a m ao (conjunto de cartas criptografadas) do jogador Pi seja o conjunto Hi = {E (c1 ), ..., E (ct )}. De maneira geral e estendendo o protocolo proposto por GOLLE (2005), a cada carta gerada para o jogador Pi , cada jogador Pj 56

para j = 1,...,k - 1 armazena que o jogador Pi agora possui essa carta ao adicionar a carta gerada ao conjunto Hi . Assuma que cada jogador mant em um conjunto S, 52i sendo Di = E (g ) para i = 0,..., k - 1, onde S = {D0 , ..., Dk1 }. Assuma tamb em que T seja o conjunto que armazena todas as cartas que est ao na mesa e que F seja o conjunto que armazena as cartas que est ao no monte de cartas descartadas durante o jogo, tamb em chamado de monte de descarte. Cada jogador mant em o estado dos conjuntos T e F durante a partida. Para vericar se uma carta c pertence realmente ao jogador Pi , ou seja, se c Hi , deve-se seguir o algoritmo descrito a seguir. Para cada carta criptografada E (g c ) Hi , os jogadores devem determinar se c = c mod 52 da seguinte forma: 1. Usando o homomorsmo do ElGamal, os jogadores calculam E (g c /g c ) = E (g cc ); 2. Utilizando o teste de igualdade de texto proposto por JAKOBSSON e SCHNORR (1999), os jogadores comparam E (g cc ) com cada valor criptografado do conjunto S. Se alguma igualdade for encontrada, a carta c de fato pertence ao jogador Pi . Lembrando que o protocolo de teste de igualdade de texto s o pode ser realizado com a participa ca o de todos os jogadores, pois a chave privada est a distribu da entre eles. Importante ressaltar que as opera co es propostas tamb em mant em as propriedades de corre ca o, privacidade e robustez denidas no protocolo GOLLE (2005). A partir disso, as opera co es propostas s ao denidas abaixo: Jogadores geram uma carta para a mesa de forma aberta: por existir o conjunto T descrito acima que tem a fun c ao de armazenar todas as cartas que est ao na mesa, os jogadores podem executar o mesmo protocolo de gera c ao de uma carta aberta. No entanto, em vez de adicionar essa carta gerada em algum conjunto Hi que representa a m ao de um jogador, os jogadores adicionam essa carta ao conjunto T. Jogador joga carta de sua m ao na mesa de forma aberta: para implementar essa opera ca o, deve ser poss vel garantir que a carta que o jogador Pi jogou de fato pertence a ele. Por exemplo, caso o jogador Pi possua em sua m ao as cartas 3 e 5, e caso esse jogador jogue a carta de n umero 6 na mesa, como garantir que a carta 6 est a criptografada em sua m ao e que Pi n ao est a trapaceando? Se o jogador Pi jogou na mesa a carta c, os demais jogadores devem vericar se essa carta E (g c ) Hi . Se n ao for encontrada nenhuma igualdade, ou seja, se para cada E (g c ) Hi , E (g cc ) / S , a carta c n ao pertence ao jogador Pi . Os outros jogadores devem excluir o jogador Pi e fechar um novo grupo. 57

Se a carta c pertencer de fato ao jogador Pi , ent ao a carta c e jogada na mesa e n ao pertence mais ao jogador Pi . Cada jogador tamb em deve excluir E (g c ) de Hi ; Jogador coloca uma carta de sua m ao novamente no baralho: no protocolo proposto por GOLLE (2005) o conjunto L armazena as cartas que j a foram distribu das durante o jogo. A carta c e armazenada criptografada no conjunto L, ou seja, na forma E (g c ). A opera ca o de um jogador Pi colocar uma carta c de sua m ao novamente no baralho corresponde a remover E (g c ) do conjunto L e cada jogador remover E (g c ) de Hi . Portanto, a carta c poder a ser distribu da em outra rodada para qualquer outro jogador, inclusive para o jogador que inseriu novamente a carta no baralho. De fato quando a mesma carta for gerada posteriormente, n ao ser a exposta nenhuma informa ca o de que e a mesma carta, pois a criptograa ElGamal e aleat oria, ou seja, a mesma carta c pode ser representada por diferentes valores criptografados; Jogador Pi escolhe e pega carta da m ao do jogador Pj : como o jogador Pi armazena o conjunto Hj , ou seja, as cartas que o jogador Pj possui em sua m ao, Pi escolhe qualquer carta criptografada E (g c ) Hj e anuncia para todos os outros jogadores que ele deseja pegar essa carta. No protocolo proposto por GOLLE (2005), cada par Pi,j estabelece uma chave sim etrica entre eles. O jogador Pj criptografa a carta c para formar E (g c ) e envia para todos os outros jogadores. Por meio de um algoritmo de criptograa sim etrica que utiliza uma chave secreta estabelecida entre os jogadores, o jogador Pj envia o valor da carta c e o fator aleat orio r para Pi , sendo a carta c a carta c criptografada em E (g ) escolhida por Pi e r e o n umero aleat orio utilizado na c gera ca o de E (g ). Nesse momento o jogador Pi verica, por meio de c e r, se o valor E (g c ) gerado por Pj est a correto. Para vericar se de fato a carta c enviada pelo jogador Pj para o jogador Pi corresponde a E (g c ) escolhida por Pi , os jogadores calculam E (g c /g c ) = E (g cc ) e vericam por meio do teste de igualdade de texto se de fato E (g c ) = E (g c ). Se o jogador Pj n ao trapaceou, todos os jogadores atualizam as cartas que os jogadores Pi e Pj possuem, sendo que agora a carta E (g c ) foi removida de Hj e inserida em Hi . A carta c era conhecida apenas pelo jogador Pj . Agora a carta c e conhecida entre os jogadores Pi e Pj durante todo o jogo; Jogador Pi recebe carta da m ao do jogador Pj que foi escolhida pelo pr oprio jogador Pj : opera c ao semelhante a ` opera ca o descrita acima. No entanto, agora c e o jogador Pj quem escolhe E (g ) Hj e envia para o jogador Pi ;

58

Jogador descarta carta de sua m ao no monte de descarte de forma aberta: jogador Pi escolhe uma carta E (g c ) de sua m ao Hi para jogar no conjunto de cartas descartadas F. O jogador Pi anuncia para todos os outros jogadores a carta c que E (g c ) representa. Para garantir que a carta c corresponde a E (g c ) anunciada pelo jogador Pi , todos os jogadores calculam E (g c ) a partir da carta c anunciada por Pi . Calculando E (g c /g c ) = E (g cc ), os jogadores vericam por meio do teste de igualdade de texto se de fato E (g c ) = E (g c ). Se c = c, cada jogador atualiza o conjunto Hi retirando E (g c ). Por m, E (g c ) e inserida no conjunto F. Jogador descarta carta de sua m ao no monte de descarte de forma fechada: jogador Pi escolhe uma carta E (g c ) de sua m ao Hi para jogar no conjunto F. c O jogador Pi remove E (g ) de sua m ao. Cada jogador tamb em remove E (g c ) de Hi . Por m, E (g c ) e inserida no conjunto F. Jogadores incluem cartas do monte de descarte de novo no baralho: para que seja poss vel gerar as cartas que outrora foram descartadas no monte de descarte, os jogadores devem remover os elementos do conjunto L para cada elemento presente no conjunto F. Al em disso, todos os elementos do conjunto F tamb em devem ser removidos, pois essas cartas passaram do monte de descarte para o baralho onde os jogadores pegam as cartas. Em suma, a interse c ao dos conjuntos L e F deve ser removida. Al em das opera co es propostas acima que estendem o protocolo de GOLLE (2005), este trabalho tamb em prop oe mais duas modica co es no protocolo. A primeira modica ca o somente se aplica em jogos que utilizam cartas abertas. O objetivo desta modica ca o e eliminar a colis ao no processo de gera c ao de uma carta. Assumindo um baralho com 52 cartas, o protocolo de cartas gera um n umero entre 0 e 51. O usu ario do protocolo deve manter uma tabela que mapeia esse n umero gerado pelo protocolo com o valor da carta do baralho que est a sendo utilizado no jogo. Por exemplo, assumindo um baralho com 5 cartas, o usu ario pode usar a Tabela 3.2 para o seu jogo. Caso o n umero 1 seja gerado pelo protocolo na primeira rodada, ent ao todos os jogadores sabem que a carta Dama de paus saiu, pois o jogo utiliza somente cartas abertas. Dessa forma, na segunda rodada, a carta Dama de paus n ao precisa mais ser gerada, pois caso seja gerada, acontecer a uma colis ao e o protocolo dever a ser executado novamente. Portanto, para resolver este problema, em vez de gerar um n umero entre 0 e 4, o protocolo gera um n umero entre 0 e 3 na segunda rodada e a tabela de mapeamento deve ser atualizada, pois o intervalo de cartas mudou e

59

Tabela 3.2: Exemplo de mapeamento entre o n umero gerado pelo protocolo e as cartas do baralho N umero 0 1 2 3 4 Carta Rei de ouros Dama de paus Vale de espadas de copas As Coringa

tamb em o mapeamento entre o n umero e o valor da carta. Com esta proposta o conjunto L e S n ao s ao utilizados, pois n ao h a colis ao. Esta primeira modica c ao tem a limita c ao de funcionar somente em jogos com todas as cartas abertas. Se existir uma carta fechada, a modica ca o n ao funciona. No entanto, a segunda proposta aproveita a seguinte caracter stica comum em deter5 minados jogos, como o jogo Escopa : mesmo que o jogo contenha cartas fechadas, o jogo e desenvolvido em rodadas, sendo que ao m de cada rodada todos os jogadores mostram todas as suas cartas jogando-as na mesa. Logo, a ideia e alterar o protocolo de gera ca o de cartas para n ao gerar na rodada posterior as cartas que foram abertas na rodada anterior. Por exemplo, assuma novamente a Tabela 3.2 e um jogo com dois jogadores. Na primeira rodada, cada jogador recebe uma carta fechada. Como as cartas s ao fechadas, pode haver colis ao no momento de gerar a segunda carta. Em seguida, a primeira rodada e nalizada quando cada jogador joga a sua carta na mesa, por exemplo, as cartas Rei de ouros e Dama de paus. Como essas duas cartas j a sa ram, a segunda rodada n ao precisa mais gerar essas cartas. Logo, no in cio da segunda rodada e antes de gerar qualquer carta, o mapeamento das cartas deve ser atualizado. Em seguida, o protocolo e alterado para gerar um n umero entre 0 e 2. Mais duas cartas fechadas s ao geradas, sendo que colis oes podem ocorrer. O jogo continua nas rodadas seguintes com esta mesma ideia. Para por em pr atica esta modica ca o, al em de atualizar o mapeamento durante as rodadas e atualizar o intervalo de n umero que o protocolo de cartas deve gerar, ao m de cada rodada o conjunto L deve ser apagado para comportar as cartas que ser ao geradas (abertas ou fechadas) na rodada seguinte. O conjunto T que guarda as cartas que est ao na mesa tamb em deve ser apagado. Como ser a visto no cap tulo 5 que apresenta o experimento, essas modica c oes de fato reduzem a quantidade de bytes trafegados no protocolo, o tempo gasto em opera co es de criptograa e o tempo para gerar uma carta.
Escopa e um jogo de cartas onde o objetivo e fazer o maior n umero de escopas que e a soma de 15 pontos com as cartas da m ao do jogador e as cartas da mesa. O jogo Escopa utiliza um baralho de 40 cartas com no m aximo 3 jogadores. Ao m de cada rodada, todas as cartas s ao reveladas.
5

60

3.3.2

Modelagem

Muitos dos conceitos utilizados na modelagem do m odulo Dice Rolling foram aproveitados para modelar o m odulo Mental Poker. A Figura 3.6 representa o diagrama de classes a n vel de projeto do m odulo Mental Poker.

Figura 3.6: Diagrama de classes de projeto do m odulo Mental Poker

61

A principal classe do m odulo e a classe MentalPoker, pois e a partir dela que o usu ario pode utilizar as opera co es do m odulo de jogar cartas. O m odulo e inicializado por meio do m etodo Initialize(deckSize:int, withoutCollision:bool):void que recebe a quantidade de cartas do baralho e se o jogo utilizar a somente cartas abertas. Por padr ao, o valor do par ametro withoutCollision e falso. Caso seja verdadeiro, o protocolo executar a como na proposta de extens ao descrita na se c ao anterior, ou seja, n ao haver a colis ao entre as cartas sendo necess ario que o usu ario do m odulo altere o mapeamento entre os n umeros gerados pelo protocolo e a carta do jogo. Al em de determinar o tamanho do baralho que ser a utilizado durante o jogo e o modo de execu c ao, este m etodo tamb em estabelece a chave p ublica e a chave privada distribu da aplicando o protocolo de PEDERSEN (1991) descrito na se ca o 2.3.8 e requerido no passo 2 do protocolo de GOLLE (2005). Por m, uma chave sim etrica, requerida no passo 3 do protocolo de GOLLE (2005), tamb em e estabelecida para cada par de jogadores para o envio de informa co es seguras. Essas chaves s ao armazenadas na propriedade SymmetricKeys:Dictionary<int,BigInteger>, onde a chave e o identicador do peer e o valor e a chave acordada entre os peers. Em seguida, todas as opera co es do m odulo Mental Poker podem ser utilizadas. Para isso, a interface IMentalPoker fornece uma forma de receber os resultados dessas opera c oes ass ncronas. Por exemplo, ao chamar o m etodo GetOpenCardFromDeck():void da classe MentalPoker, o m etodo GetOpenCardFromDeck(peerID:int, card:int):void da interface IMentalPoker ser a chamado passando o valor da carta que foi retirada do baralho e o identicador do peer que jogou. A lista a seguir descreve as principais opera co es que s ao fornecidas pelo m odulo: Ler as cartas que o jogador possui na m ao: m etodo GetMyHand():Hand da classe MentalPoker. A classe Hand fornece as cartas que um peer tem em sua m ao. As cartas s ao representadas por um dicion ario, onde a chave e um n umero que representa a carta criptografada, e o valor e a pr opria carta; Visualizar as cartas criptografadas que os outros jogadores possuem na m ao: m etodo GetPeerHand(peerID:int):Hand da classe MentalPoker que recebe como argumento o identicador do outro peer. O jogador somente tem acesso ao valor criptografado da carta, e n ao ao valor da carta. Isso representa o jogador segurando as cartas de forma que os outros jogadores n ao conseguem enxergar o valor da carta; Visualizar as cartas que est ao na mesa: m etodo GetTableCards():List<int> da classe MentalPoker retorna o valor de cada carta que est a na mesa; Pegar uma carta aberta do baralho: m etodo GetOpenCardFromDeck():void 62

da classe MentalPoker. O m etodo GetOpenCardFromDeck(peerID:int, card:int):void da interface IMentalPoker recebe o resultado. Para o jogador que executou essa a ca o, o resultado ser a composto pelo valor da carta e por um identicador vazio, ou seja, e o pr oprio peer que retirou a carta. Para os outros jogadores o resultado ser a composto pelo identicador do peer que retirou a carta e tamb em o valor da carta; Pegar uma carta fechada do baralho: m etodo GetClosedCardFromDeck():void da classe MentalPoker. O m etodo GetClosedCardFromDeck(peerID:int, card:int):void da interface IMentalPoker recebe o resultado. Para o jogador que executou essa a c ao, o resultado ser a composto por um identicador vazio e o valor da carta. Para os outros jogadores o resultado ser a composto pelo identicador do peer que retirou a carta com o valor da carta vazio; Pegar uma carta aberta do baralho para a mesa: m etodo GetOpenCardToTable():void da classe MentalPoker. O m etodo GetOpenCardToTable(peerID:int, card:int):void da interface IMentalPoker recebe o resultado. Para o jogador que executou essa a ca o, o resultado ser a composto pelo valor da carta e por um identicador vazio, ou seja, e o pr oprio peer que gerou a carta para a mesa. Para os outros jogadores o resultado ser a composto pelo identicador do peer que iniciou a jogada e tamb em o valor da carta; Jogar uma carta aberta na mesa: m etodo PlayOpenCard(card:int):void da classe MentalPoker que recebe como argumento o valor da carta que ser a jogada na mesa. O m etodo PlayOpenCard(peerID:int, card:int):void da interface IMentalPoker recebe o resultado. O resultado e composto pelo identicador do peer que jogou a carta na mesa e tamb em pelo valor da carta. O jogador que realizou a jogada receber a o identicador do peer vazio; Inserir uma carta fechada da m ao no baralho: m etodo InsertClosedCardInDeck(card:int):void da classe MentalPoker que recebe como argumento o valor da carta que ser a inserida no baralho. O m etodo InsertClosedCardInDeck(peerID:int):void da interface IMentalPoker recebe o resultado. O resultado e o identicador do peer que inseriu a carta no baralho; Pegar uma carta da m ao do outro jogador: m etodo GetClosedCardFromHand(encryptedCard:byte[], peerID:int):void da classe MentalPoker que recebe como argumento o valor da carta 63

criptografada e o identicador do peer que possui essa carta. O m etodo GetClosedCardFromHand(fromPeerID:int, toPeerID:int, card:int):void da interface IMentalPoker recebe o resultado. Para o jogador que recebe a carta, o resultado e composto pelo identicador do peer que recebe a carta, nesse caso vazio, o identicador do peer que passa a carta e tamb em o valor da carta. Para o jogador que passou a carta, o resultado e composto pelo identicador que recebe a carta, o identicador que passa a carta e vazio, e o valor da carta. Para os outros jogadores que n ao participam da opera ca o, o resultado e composto pelos identicadores dos peers, mas a carta e vazia; Receber uma carta da m ao do outro jogador: m etodo ReceiveClosedCardFromHand(peerID:int):void da classe MentalPoker que recebe como argumento o identicador do peer que ir a passar uma carta. O m etodo ReceiveClosedCardFromHand(fromPeerID:int, toPeerID:int, card:int):void da interface IMentalPoker recebe o resultado. O resultado e semelhante ao descrito na opera ca o anterior; Descartar uma carta aberta no monte de descarte: m etodo DiscardOpenCard(card:int):void da classe MentalPoker que recebe como argumento a carta para descarte. O m etodo DiscardOpenCard(peerID:int, card:int):void da interface IMentalPoker recebe o resultado. Para o jogador que descartou a carta, o resultado e composto por um identicador vazio e o valor da carta. Para os outros jogadores o resultado e composto pelo identicador do peer que descartou a carta e tamb em pelo valor da carta descartada; Descartar uma carta fechada no monte de descarte: m etodo DiscardClosedCard(card:int):void da classe MentalPoker que recebe como argumento a carta para descarte. O m etodo DiscardClosedCard(peerID:int):void da interface IMentalPoker recebe como resultado o identicador do peer que descartou a carta. Para o jogador que realizou essa opera ca o o valor do identicador do peer ser a vazio. Inserir as cartas do monte de descarte de novo no baralho: m etodo MoveDiscardedCardsToDeck():void da classe MentalPoker. O m etodo MoveDiscardedCardsToDeck(peerID:int):void da interface IMentalPoker recebe como resultado o identicador do peer que iniciou a opera c ao. Para o jogador que realizou essa opera ca o o valor do identicador do peer ser a vazio. Remapear o protocolo para a rodada seguinte: m etodo ResetToAnotherRound():void da classe MentalPoker. Este m etodo 64

implementa a segunda proposta de altera ca o do protocolo de cartas, ou seja, as cartas que foram jogadas abertas na mesa ao m da rodada anterior n ao precisam ser geradas novamente na rodada seguinte. Este m etodo deve ser usado em jogos onde as cartas dos jogadores s ao jogadas na mesa ao m de cada rodada. Ao m de cada rodada, ao chamar este m etodo, o intervalo de n umeros que o protocolo de cartas pode gerar e alterado, sendo o intervalo entre 0 e (intervalo nal atual - n umero de cartas na mesa). Os elementos dos conjuntos L e T tamb em s ao removidos. A responsabilidade e do usu ario em executar a tarefa de atualizar o mapeamento da tabela de n umeros e cartas do jogo. A classe ElGamal, como o nome sugere, tem a responsabilidade de criptografar e descriptografar uma mensagem utilizando a criptograa assim etrica ElGamal. Por meio dos m etodos Encrypt(data:byte[]):byte[] e Decrypt(data:byte[]):byte[] uma mensagem pode ser criptografada e descriptografada. O m etodo SetKeys(keys:Dictionary<string,BigInteger>):void recebe as chaves p ublicas p, g e y e a chave privada xi daquele jogador. O m etodo GenerateLargePrime(length:int):BigInteger cria um n umero primo de tamanho length bits. A classe MPHistory armazena as jogadas que ocorreram durante o jogo. O campo Operation descreve uma string que identica o nome do m etodo que correspondente a uma a ca o, como por exemplo PlayOpenCard, e os campos FromPeerID e ToPeerID identicam os peers que participaram daquela opera ca o. Por m, a classe Message representa a mensagem trocada entre os peers durante o protocolo e a interface IProtocolCommitted permite a troca dessas mensagens entre os peers assim como identica cada peer participante do protocolo.

3.3.3

Funcionamento interno

O m odulo Mental Poker inicia seu funcionamento pela chamada do m etodo Initialize(deckSize:int, withoutCollision:bool):void, recebendo como par ametros o n umero de cartas do baralho e se o protocolo executar a somente com cartas abertas evitando colis ao entre as cartas. Juntamente com essas duas congura co es, este m etodo inicia internamente mais duas opera c oes: deni ca o da chave p ublica e da chave privada distribu da utilizada no algoritmo ElGamal por meio do protocolo de PEDERSEN (1991) descrito na se c ao 2.3.8 e tamb em deni c ao de uma chave sim etrica entre cada par de jogador. Estas opera co es s ao requeridas nos passos 2 e 3 do protocolo de GOLLE (2005), respectivamente. Para ilustrar estas opera co es, a Figura 3.7 mostra as mensagens trocadas entre dois jogadores, onde cada um utiliza o m odulo via classe MentalPoker. A partir 65

Figura 3.7: Diagrama de sequ encia de inicializa ca o do m odulo Mental Poker do m etodo Initialize, uma mensagem InitializeParameters e enviada para os outros jogadores informando o n umero de cartas do baralho, indica c ao se o protocolo utilizar a somente cartas abertas (o que evita colis oes) e o n umero primo que ser a utilizado na criptograa ElGamal. Em seguida, inicia-se a fase de deni ca o da chave p ublica e da chave privada distribu da entre os jogadores. As mensagens PeddersenCoefficient e PeddersenFunction correspondem ao coecientes do polin omio escolhido pelo jogador e o valor da fun ca o, respectivamente. Em seguida, para a deni ca o da chave sim etrica utilizada na comunica c ao entre os dois jogadores no protocolo de cartas, utiliza-se a estrat egia de criptograa h brida (SCHNEIER, 1996, p 86). Em outras palavras, um algoritmo de chave p ublica e usado como forma de determinar uma chave sim etrica entre os participantes. A mensagem SymmetricPublic envia a chave p ublica para o outro jogador, que por sua vez criptografa uma chave sim etrica com a chave p ublica que recebeu. A mensagem SymmetricKey envia a chave sim etrica criptografada de volta para o outro jogador, que descriptografa por meio da sua chave privada, nalizando o processo de deni ca o da chave sim etrica entre eles e tamb em de inicializa ca o do m odulo Mental Poker. Depois que o m odulo foi inicializado, qualquer opera ca o dispon vel na classe MentalPoker pode ser executada. Por exemplo, a Figura 3.8 apresenta as mensagens que s ao trocadas internamente no m odulo Mental Poker entre os jogadores na gera ca o de uma carta aberta. O protocolo e iniciado quando a classe MentalPoker recebe uma mensagem GetOpenCardFromDeck da classe Player. Uma mensagem de notica c ao chamada OpenCardSignal e enviada para o outro jogador indicando que a opera c ao de gerar uma carta aberta deve ser executada. Dessa forma, ambos os jogadores escolhem um n umero aleat orio e o criptografam na classe ElGamal com

66

a mensagem Encrypt. Depois disso, ambos os jogadores se comprometem com esse n umero criptografado aplicando uma fun ca o hash via mensagem SHA256 e enviando a mensagem Commitment. Em seguida, os jogadores enviam a carta criptografada via mensagem EncryptedCard e aplicam o homomorsmo multiplicativo do ElGamal, gerando uma carta que e a soma dos n umeros aleat orios e est a na forma de uma tupla ElGamal (a, b ). Para determinar se essa carta j a saiu, deve-se aplicar o algoritmo de teste de igualdade de texto proposto por JAKOBSSON e SCHNORR (1999). Portanto, quando ambos os jogadores trocam o fator a elevado pela chave privada, ou seja, achaveprivada , e poss vel vericar se a carta j a foi gerada. Em caso positivo, o processo retorna do in cio. Caso contr ario, os jogadores revelam o n umero escolhido originalmente e tamb em o fator aleat orio utilizado na criptograa do ElGamal via mensagem OriginalCard. Por m, a classe MentalPoker envia a mensagem GetOpenCardFromDeck para a classe Player passando o identicador do jogador e tamb em o valor da carta gerada. An alise de complexidade Como forma de entender como cada opera ca o escala, a seguir e realizada a an alise de complexidade de cada opera c ao do m odulo Mental Poker com o objetivo de descrever o comportamento dessas opera c oes para um volume grande de jogadores. Assumindo que a vari avel n denota o n umero de jogadores do protocolo, as opera c oes podem ser avaliadas da seguinte forma: 1. Gera c ao distribu da de chaves: Seguindo o protocolo de PEDERSEN (1991) descrito na se c ao 2.3.8, cada jogador deve enviar para os outros jogadores 2 mensagens, uma contendo os coecientes do polin omio e outra contendo o resultado desse polin omio para um n umero qualquer. Logo, o n umero total de mensagens e 2 * n * (n - 1), ou seja, n jogadores enviam 2 mensagens para os (n - 1) jogadores restantes. De outra forma, 2n2 - 2n. A complexidade e 2 O(n ); 2. Teste de igualdade de texto: Seguindo o protocolo de JAKOBSSON e SCHNORR (1999), cada jogador envia uma mensagem para os outros jogadores contendo o fator a elevado pela sua chave privada. O fator a pertence a ` tupla ElGamal (a,b ) correspondente a ` carta criptografada. Logo, o n umero total de mensagens e n * (n - 1), ou seja, n jogadores enviando uma mensagem para os outros (n - 1) jogadores. Com isso, o n umero de mensagens e n2 - n. No protocolo de cartas proposto por GOLLE (2005), o conjunto S mant em n mensagens criptografadas. Para vericar se uma carta j a foi gerada no jogo, o teste de igualdade de texto deve ser realizado para cada elemento do con-

67

Figura 3.8: Diagrama de sequ encia de mensagens internas do m odulo Mental Poker na gera ca o de uma carta aberta

68

junto S. Portanto, o n umero total de mensagens e n * (n2 - n ) = n3 n2 . A complexidade e O(n3 ); 3. Gerar carta fechada: Para um jogador enviar uma mensagem para todos os outros jogadores, o n umero de mensagens e (n - 1). Como cada jogador deve enviar duas mensagens que correspondem ao hash de comprometimento da carta criptografada e o valor da carta criptografada, o n umero de mensagens e 2 * n para cada jogador. Portanto, o n umero total de mensagens e 2 * n * (n 1), ou seja, cada jogador envia duas mensagens para os outros jogadores. Para essa nova carta criptografada, deve-se vericar por meio do teste de igualdade de texto se a mesma j a foi gerada. Logo, deve-se acrescentar n3 n2 mensagens de teste de igualdade de texto. Por m, depois que foi garantido que a carta ainda n ao foi gerada, cada jogador envia o n umero aleat orio de carta escolhido em segredo para o jogador que est a gerando a carta fechada resultando em (n 1) * 1 mensagens, ou seja, uma mensagem enviada pelo restante dos jogadores ao jogador que est a gerando a carta fechada. Portanto, o n umero total de mensagens e: 2 * n * (n - 1) + n3 n2 + (n - 1) * 1 = n3 + n2 n 1. A complexidade e O(n3 ); 4. Gerar carta aberta: Mesma an alise de complexidade realizada acima para gerar uma carta aberta. No entanto, em vez de cada jogador enviar o n umero aleat orio de carta escolhido em segredo para o jogador que est a gerando a carta fechada, todos os jogadores trocam entre si esse n umero aleat orio para gerar a carta aberta. Em vez de ser (n - 1) * 1 mensagens, s ao (n - 1) * n mensagens. Portanto, o n umero total de mensagens e: 2 * n * (n - 1) + n3 n2 + (n - 1) * n = n3 + 2n2 3n. A complexidade e O(n3 ); 5. Jogar carta aberta na mesa: O jogador que joga uma carta aberta na mesa deve anunciar essa carta para os outros jogadores, ou seja, uma mensagem para (n - 1) jogadores. Em seguida, soma-se o n umero de mensagens trocadas no teste de igualdade de texto, ou seja, n3 n2 . Portanto, o n umero total para 3 2 3 2 jogar uma carta na mesa e (n - 1) + (n n ) = n n + n - 1. A complexidade e O(n3 ); 6. Inserir carta no baralho: Para inserir uma carta no baralho, o jogador envia para os outros (n - 1) jogadores a carta que deve ser inserida de volta ao baralho. Portanto, o n umero total de mensagens e n - 1. A complexidade e O (n ); 7. Pegar ou receber carta da m ao do outro jogador: O jogador que deseja pegar uma carta da m ao de outro jogador, deve avisar a todos os jogadores

69

qual e essa carta, ou seja, deve enviar uma mensagem para (n - 1) jogadores. O jogador que ir a retirar uma carta de sua m ao, envia uma mensagem com essa carta criptografada para todos os outros jogadores, ou seja, deve enviar uma mensagem para (n - 1) jogadores. Este mesmo jogador agora envia uma mensagem para o jogador que est a pegando a carta com o valor da carta e o fator aleat orio utilizado para criptografar a carta, ou seja, envia apenas uma mensagem. Para garantir que esta carta de fato pertence a `quele jogador, todos os jogadores executam o teste de igualdade de texto, acrescentando n3 n2 mensagens. Portanto, o n umero total de mensagens e (n - 1) + (n - 1) + 1 + 3 2 3 2 (n n ) = n n + 2n - 1. Este resultado tamb em e v alido para a opera ca o onde o jogador recebe a carta da m ao do outro jogador. A complexidade e 3 O(n ); 8. Descartar carta fechada: Para inserir descartar uma carta, o jogador envia para os outros (n - 1) jogadores a carta que deve ser descartada. Portanto, o n umero total de mensagens e n - 1. A complexidade e O (n ); 9. Descartar carta aberta: O jogador que deseja descartar uma carta aberta deve enviar uma mensagem com a carta criptografada para os outros (n - 1) jogadores. Al em disso, tamb em deve enviar uma mensagem para os mesmos (n - 1) jogadores com o valor da carta aberta. Para garantir que de fato esta carta pertence a `quele jogador, o teste de igualdade de texto deve ser realizado, acrescentando n3 n2 mensagens. Portanto, o n umero total de mensagens e 3 2 3 2 3 (n - 1) + (n - 1) + (n n ) = n n + 2n - 2. A complexidade e O(n ). 10. Inserir cartas do monte de descarte no baralho: O jogador que deseja inserir as cartas do monte de descarte de novo no baralho deve enviar uma mensagem os outros (n - 1) jogadores. Portanto, o n umero total de mensagens e n - 1. A complexidade e O(n).

3.3.4

Como usar o m odulo

A seguir e apresentado um c odigo fonte de exemplo do uso do m odulo Mental Poker. O c odigo est a escrito na linguagem de programa ca o C#:
1 2 3 4 5 5

public class Player : IMentalPoker { private MentalPoker _mentalPoker; public Player (MentalPoker mp, int deckSize) { _mentalPoker = mp; _mentalPoker.Initialize(deckSize); 70

6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44

_mentalPoker.SetDelegate(this); } public void SendMessage(Message message, int peerID) { /* implementa ca ~o */ } public List<int> GetPeersID() { /* implementa ca ~o */ } public List<MPHistory> GetHistory() { return _mentalpoker.GetHistory(); } public List<int> GetTableCards() { return _mentalpoker.GetTableCards(); } public Hand GetMyHand() { return _mentalpoker.GetMyHand(); } public Hand GetPeerHand(int peerID) { return _mentalpoker.GetPeerHand(peerID); } public void GetOpenCardFromDeck() { _mentalpoker.GetOpenCardFromDeck(); } public void GetOpenCardFromDeck(int peerID, int card) { /* implementa ca ~o */ } public void GetClosedCardFromDeck() { _mentalpoker.GetClosedCardFromDeck(); } public void GetClosedCardFromDeck(int peerID, int card) { /* implementa ca ~o */ }

71

45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83

public void PlayOpenCard(int card) { _mentalpoker.PlayOpenCard(card); } public void PlayOpenCard(int peerID, int card) { /* implementa ca ~o */ } public void InsertClosedCardInDeck(int card) { _mentalpoker.InsertClosedCardInDeck(card); } public void InsertClosedCardInDeck(int peerID) { /* implementa ca ~o */ } public void DiscardOpenCard(int card) { _mentalpoker.DiscardOpenCard(card); } public void DiscardOpenCard(int peerID, int card) { /* implementa ca ~o */ } public void DiscardClosedCard(int card) { _mentalpoker.DiscardClosedCard(card); } public void DiscardClosedCard(int peerID) { /* implementa ca ~o */ } public void GetClosedCardFromHand (int peerID, byte[] encrytedCard) { _mentalpoker. GetClosedCardFromHand(peerID, encryptedCard); } public void GetClosedCardFromHand (int fromPeerID, int toPeerID, int card) { /* implementa ca ~o */ } public void ReceiveClosedCardFromHand(int peerID) { 72

84 85 86 87 88 89 90 91

_mentalpoker. ReceiveClosedCardFromHand(peerID); } public void ReceiveClosedCardFromHand (int fromPeerID, int toPeerID, int card) { /* implementa ca ~o */ } }

Para a classe Player usar o m odulo Mental Poker e necess ario implementar a interface IMentalPoker e fazer agrega ca o com a classe MentalPoker. A interface IProtocolCommitted e implementada nas linhas 9 e 12, enviando mensagens para outros peers e informando o identicador de cada peer participante do protocolo. O construtor, na linha 4, recebe como par ametros um tipo MentalPoker e a quantidade de cartas utilizadas no baralho. Na linha 5 a classe MentalPoker e inicializada com o n umero de cartas do baralho. Como n ao foi passado o valor do par ametro withoutCollision, o valor padr ao e falso, ou seja, o protocolo pode utilizar cartas fechadas e com colis ao. Na linha 6 e declarado a delega ca o, onde a classe do tipo MentalPoker ir a delegar o envio de mensagens pela classe Player. Todos os outros m etodos representam alguma opera c ao do m odulo denida na pr opria classe MentalPoker. Como exemplo, na linha 32 o m etodo GetOpenCardFromDeck e invocado e, por se tratar de uma opera ca o ass ncrona como a maioria das opera c oes do m odulo, o resultado e obtido na linha 35 com a chamada do m etodo GetOpenCardFromDeck(int peerID, int card):void da interface IMentalPoker, recebendo como argumentos o identicador do peer que realizou a jogada e tamb em a carta retirada. As outras opera co es seguem o mesmo padr ao e s ao descritas em detalhes na se c ao 3.3.2 que apresenta a modelagem do m odulo. Para ilustrar algumas intera c oes, a Figura 3.9 apresenta algumas opera c oes com o m odulo Mental Poker entre dois jogadores. Primeiro um dos jogadores pede uma carta aberta do baralho via chamada GetOpenCardFromDeck. A classe MentalPoker envia para os dois jogadores o resultado dessa opera ca o, passando o identicador do jogador que pediu a carta, nesse caso identicador de n umero 2345, e o valor da carta, 23. O pr oprio jogador que iniciou a jogada recebe -1 como identicador do jogador, pois foi ele mesmo que jogou. O jogador continua pedindo uma carta fechada do baralho via chamada GetClosedCardFromDeck. A classe MentalPoker envia para os dois jogadores o resultado dessa opera ca o, por em omite o valor da carta para o outro jogador, pois a carta retirada do baralho estava fechada. Dessa forma, o jogador que retirou a carta recebe o valor 14 e o outro jogador recebe o

73

valor -1. Por u ltimo, o jogador joga uma carta na mesa via chamada PlayOpenCard, e ambos os jogadores s ao noticados dessa opera ca o pela classe MentalPoker.

Figura 3.9: Diagrama de sequ encia de exemplo de uso do m odulo Mental Poker

3.4

Decis oes de desing e padr oes adotados

A modelagem dos m odulos exigiu que algumas decis oes arquiteturais fossem tomadas a m de deixar o m odulo simples de usar, f acil de entender e manter do c odigo. O requisito fundamental foi deixar simples o uso dos m odulos da biblioteca. Para usar qualquer m odulo, basta apenas implementar uma interface, IDiceRolling para o m odulo Dice Rolling ou IMentalPoker para o m odulo Mental Poker. Todas essas interfaces herdam da interface base IProtocolCommitted que tem dois m etodos abstratos, um respons avel por enviar uma mensagem para outro peer e o outro que retorna o identicador de cada peer participante do protocolo. Portanto, a estrutura de heran ca entre as interfaces deixa claro que as funcionalidades de cada m odulo foram constru das a partir de uma interface base que suporta a comunica c ao entre os jogadores. Para o uso da biblioteca, preferiu-se a implementa ca o de uma interface em vez de herdar de uma outra classe. Supondo que para usar um m odulo o usu ario tivesse que herdar de uma superclasse desse m odulo, provavelmente a subclasse estaria impedida de assumir outros comportamentos via heran ca, j a que e muito prov avel 6 que a linguagem orientada a objetos usada n ao suportaria heran ca m ultipla . A
Heran ca m ultipla e uma propriedade das linguagens orientadas a objeto que permitem que uma subclasse herde caracter sticas e atributos de mais de uma superclasse. Linguagens populares que possuem heran ca m ultipla s ao C++, Perl e Python. Muitos questionam as desvantagens da heran ca m ultipla, como aumento da complexidade e ambiguidade caso um mesmo m etodo seja
6

74

vantagem de usar uma interface e permitir que a classe usu aria que livre para implementar outras interfaces e tamb em herdar de outra superclasse. Al em de evitar a heran ca m ultipla, a modelagem seguiu em particular o segundo princ pio de design orientado a objetos proposto por GAMMA et al. (1995) como t ecnica para reutiliza ca o de funcionalidades e comportamentos: prera composi ca o em vez de heran ca (GAMMA et al., 1995, p 32). A heran ca apresenta desvantagens como n ao poder mudar, em tempo de execu ca o, a implementa ca o da superclasse. A subclasse ca dependente da implementa ca o da superclasse que, ao mudar sua implementa c ao, ir a for car que a subclasse mude tamb em. Por outro lado, a composi ca o permite a mudan ca de implementa ca o em tempo de execu ca o por meio da refer encia a outro objeto que implementa uma determinada interface de contrato. A partir disso, outra t ecnica de implementa ca o foi utilizada em conjunto com a implementa c ao das interfaces IDiceRolling ou IMentalPoker: delega c ao 7 . Delega ca o e uma composi ca o de objetos que funciona como um mecanismo de reutiliza c ao de c odigo, onde um objeto delega uma determinada tarefa para outro objeto (GAMMA et al., 1995, p 32). Por exemplo, em vez de uma classe Window herdar de uma classe Rectangle, a classe Window pode reutilizar o comportamento da classe Rectangle mantendo uma refer encia para essa classe e delegando tarefas espec cas dessa classe (GAMMA et al., 1995, p 33). Por exemplo, no contexto do m odulo Dice Rolling, a classe DiceRolling delega para a classe usu aria o envio de uma mensagem para outro peer via m etodo SendMessage(message: Message, peerID: int): void da interface IProtocolCommitted, pois n ao cabe a classe DiceRolling saber enviar mensagem, mas sim implementar o protocolo criptogr aco. A classe usu aria e que tem a responsabilidade de saber enviar uma mensagem para outro peer, independente do meio de comunica c ao utilizado. No momento em que o usu ario envia uma nota ca o de dado para o m odulo Dice Rolling a m de obter o resultado dos dados, a classe DiceRolling recebe essa nota ca o de dados, executa e delega determinadas tarefas. Essa sequ encia de tarefas e descrita pela aplica ca o do padr ao de projeto Template Method. O padr ao de projeto Template Method dene o esqueleto de um algoritmo, delegando alguns passos desse algoritmo para subclasses ou componentes agregados que denem certos passos desse algoritmo sem alterar a estrutura desse algoritmo (GAMMA et al., 1995, p 360). Nesse contexto, a classe DiceRolling recebe uma nota c ao de dado, delega para outro componente a valida c ao dessa nota ca o e delega o c alculo do n umero de dados que essa nota ca o exige. A partir dessa quantidade de dados, delega para a subclasse o c alculo dos n umeros seguros via protocolo criptogr aco. Em seguida, delega o c alculo do resultado com base na nota ca o de dado e nos n umeros seguros. Podeimplementado por mais de uma superclasse. 7 Tradu c ao para o termo em ingl es delegation

75

se perceber que o padr ao de projeto Template Method estabelece uma estrutura de controle invertido que e referenciada como Princ pio Hollywood8 , que signica que a superclasse invoca opera c oes nas subclasses ou em outros componentes agregados, nunca ao contr ario (GAMMA et al., 1995, 362) Por m, o usu ario tem a possibilidade de estender certas funcionalidades do m odulo Dice Rolling por meio da implementa ca o da sua pr opria l ogica, substi9 tuindo a funcionalidade original do m odulo . O protocolo criptogr aco que gera os dados pode ser estendido. Por padr ao, o m odulo Dice Rolling implementa uma vers ao do protocolo criptogr aco utilizando fun ca o de m ao u nica. No entanto, o usu ario desse m odulo pode implementar sua pr opria vers ao do protocolo criptogr aco, por exemplo implementando uma vers ao que utilize criptograa sim etrica como forma de garantir o bit commitment. Para isso, a classe que implementa esse novo protocolo deve herdar da classe DiceRolling e implementar os seus m etodos abstratos CalculateSecureNumbers(numberOfDices: int): void e ReceiveMessage(message: Message, peerID: int): void. O primeiro m etodo tem a responsabilidade de gerar, por meio do protocolo criptogr aco, numberOfDices n umeros que ser ao usados para o calculo da nota ca o de dado. O segundo m etodo tem a responsabilidade de capturar uma mensagem enviada por outro peer a m de tratar essa mensagem a partir do passo atual do protocolo. Outra forma de estender o m odulo Dice Rolling e denir a sua pr opria nota c ao de dado. Por padr ao, o m odulo implementa uma vers ao da nota ca o padr ao de dados descrita na se c ao 3.2.2. Para o usu ario denir sua pr opria nota c ao de dado, deve-se implementar a interface IDiceNotationParser juntamente com seus m etodos abstratos. A responsabilidade dessa interface e denir um contrato onde seja poss vel identicar se a nota ca o de dado e v alida ou n ao, determinar quantos dados aquela nota c ao de dado requer, e a partir da nota ca o de dado e um conjunto de n umeros gerados via protocolo criptogr aco, calcular os resultados dessa jogada. Depois de criada uma classe que implemente esse contrato, basta congurar essa nota ca o como a nota c ao padr ao do m odulo Dice Rolling chamando o m etodo SetDiceNotationParser(DiceNotationParser: IDiceNotationParser): void, passando como argumento a nova classe criada para sobrescrever a nota c ao de dado original.

Tradu c ao para o termo em ingl es The Hollywood Principle Seguindo o princ pio Aberto/Fechado, traduzido do termo em ingl es Open/Closed principle, as classes est ao abertas para extens ao, mas fechadas para modica c ao (MEYER, 1988). Ou seja, em vez de alterar diretamente o c odigo fonte, a funcionalidade deve ser adicionada pela implementa c ao de uma nova classe que e adicionada por meio do polimorsmo criado via interface ou heran ca.
9

76

Cap tulo 4 Implementa c ao


Este cap tulo descreve como foi implementada a biblioteca proposta no cap tulo anterior. Para tal, foi utilizado como Ambiente de Desenvolvimento Integrado a ferramenta Microsoft Visual Studio Ultimate 20121 , utilizando C# 5.02 como linguagem de program ca o em conjunto com a plataforma de desenvolvimento e execu ca o de 3 aplica co es Microsoft .NET Framework , vers ao 4.5. A biblioteca implementada e composta por 15 classes, 4 interfaces, 2 enumerators e com aproximadamente 3.100 linhas.

4.1

Estrutura do peer

Com o prop osito de usar a biblioteca proposta no cap tulo anterior, foi necess ario a implementa c ao de um peer que pudesse se comunicar com outro peer. Em cima dessa arquitetura de envio e recebimento de mensagens na forma de array de bytes, foi poss vel implementar os m odulos da biblioteca e tamb em os protocolos criptogr acos. A Figura 4.1 apresenta o diagrama de classes que comp oem da estrutura de um peer : A classe Peer e composta por duas agrega c oes, uma com a classe Client e uma com a classe Server. A classe Peer cont em uma lista de objetos do tipo Client, onde cada inst ancia representa um canal de comunica c ao com um determinado peer. A classe Server e designada a receber e a tratar conex oes de novos peers. Assim que a classe Peer e instanciada, uma outra thread e criada para executar uma inst ancia da classe Server, que ca em loop innito esperando um novo peer conectar. Dessa forma, a classe Peer pode tratar de outros eventos, como click de mouse, entrada de texto, tratamento de eventos, etc, sem que a classe Server bloqueie a execu ca o da thread principal. Assim que um novo peer se conecta, a classe Server cria uma nova thread que trata exclusivamente do recebimento de
1 2

http://www.microsoft.com/visualstudio/eng/products/visual-studio-ultimate-2012 http://msdn.microsoft.com/en-us/library/67ef8sbd.aspx 3 http://www.microsoft.com/net

77

Figura 4.1: Diagrama de classes do peer mensagens desse novo peer. Portanto, a classe Peer executa na thread principal, a classe Server executa em uma outra thread em loop innito esperando por conex oes de novos peers, e cada conex ao de um novo peer executa em uma outra thread. Por exemplo, caso um peer esteja conectado a tr es outros peers, h a uma thread principal executando a inst ancia de peer, uma outra thread executando a inst ancia de server e outras tr es threads que tem a responsabilidade de receber as mensagens de cada peer conectado. A Figura 4.2 mostra a ordem temporal das mensagens no processo de cria c ao e troca de mensagens de um peer :

Figura 4.2: Diagrama de sequ encia de conex ao e recebimento de mensagem de um peer 78

Ao instanciar a classe Peer, por meio da mensagem Listen, uma nova inst ancia da classe Server e instanciada para escutar, em uma determinada porta, por novos peers que desejam se conectar. Quando um novo peer se conecta por meio da mensagem Connect, a inst ancia da classe Server cria uma nova thread por meio da mensagem HandleClient para escutar pelas mensagens desse novo peer. Esse processo se repete para cada novo peer que deseja se conectar. Quando uma mensagem e recebida, a thread secund aria envia essa mensagem para a thread principal via mensagem Callback. Dessa forma, a thread principal pode tratar a mensagem recebida do outro peer de acordo com o contexto da aplica c ao. Para implementar a estrutura de um peer, a linguagem de programa c ao C# prov e 4 5 os namespaces System.Net e System.Net.Sockets que s ao ideais para programa ca o 6 em rede, encapsulando e gerenciando a programa ca o via socket , al em de encapsular 7 os detalhes de conex ao TCP na internet. A classe Client utiliza como base a classe TcpClient8 que prov e m etodos para conectar, enviar e receber um uxo de dados pela rede. A classe TcpClient e 9 utilizada em conjunto com a classe IPEndPoint para estabelecer um ponto-nal na rede por meio do endere co IP e um n umero de porta. Dessa forma, a classe Client tem a capacidade de se conectar e enviar mensagens na rede. A classe Server utiliza como base a classe TcpListener10 que prov e m etodos para escutar e aceitar requisi co es de conex ao na rede. A classe IPEndpoint tamb em e utilizada em conjunto com a classe TcpListener para estabelecer um ponto-nal na rede. Com isso, a classe Server tem a capacidade de receber mensagens enviadas pela rede.

4.2

M odulo Dice Rolling

No m odulo Dice Rolling, a classe DROneWayFunction e que de fato implementa o protocolo criptogr aco utilizando fun ca o de m ao u nica como estrat egia de bit commitment. Essa classe n ao guarda em que passo a execu ca o do protocolo se encontra, pois essa informa c ao e enviada junto com cada mensagem do tipo Message que o peer recebe. Portanto, a classe DROneWayFunction tem a seguinte estrutura:
http://msdn.microsoft.com/en-us/library/system.net.aspx http://msdn.microsoft.com/en-us/library/system.net.sockets.aspx 6 Soquete de rede, tradu c ao do termo em ingl es socket, e um ponto-nal do uxo de comunica c ao entre processos atrav es de uma rede de computadores. 7 O Protocolo de Controle de Transmiss ao, tradu c ao do termo em ingl es Transmission Control Protocol - TCP, e um protocolo de rede que verica se os dados em uma comunica c ao s ao enviados de uma forma correta, na mesma sequ encia e sem erros. 8 http://msdn.microsoft.com/en-us/library/1612451t.aspx 9 http://msdn.microsoft.com/en-us/library/fzszfbba.aspx 10 http://msdn.microsoft.com/en-us/library/zsyxy9k2.aspx
5 4

79

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39

public class DROneWayFunction : DiceRolling { public override void CalculateSecureNumbers (int NumberOfDice) { /* gera n umeros aleat orios */ /* gera os n umeros hash de comprometimento */ var message = new Message(MessageMethod.FirstDiceHashCommitment, hash); Delegate.SendMessage(message); } public override void ReceiveMessage (Message message, int peerID){ switch (message.Method) { case MessageMethod.FirstDiceHashCommitment: { /* guarda os numeros hash de comprometimento do peer que iniciou a jogada */ /* gera numeros aleatorios e a partir desses gera os n umeros hash de comprometimento */ var message = new DRMessage(MessageMethod.LastDiceHashCommitment, hash); Delegate.SendMessage(message); } case MessageMethod.LastDiceHashCommitment: { /* guarda os n umeros hash de comprometimento dos outros peers */ var message = new DRMessage(MessageMethod.FirstDiceHashReveal, originalValues); } case MessageMethod.FirstDiceHashReveal: { /* recebe os valores aleatorios originais do peer que iniciou a jogada e verifica se os n umeros hash comprometidos s~ ao iguais aos valores hash dos n umeros originais */ /* envia os n umeros gerados para 80

40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59

a super classe DiceRolling calcular os resultados */ var message = new DRMessage(MessageMethod.LastDiceHashReveal, originalValues); } case MessageMethod.LastDiceHashReveal: { /* recebe os valores originais dos outros peers e verifica se os n umeros hash comprometidos s~ ao iguais aos valores hash dos n umeros originais */ /* envia os n umeros gerados para a super classe DiceRolling calcular os resultados */ } } } }

Suponha a participa ca o de dois jogadores no protocolo, Alice e Bob. Supondo que Alice seja o jogador que inicia a jogada, Alice gera os n umeros aleat orios e em seguida se compromete com esses n umeros por meio de uma fun c ao de m ao u nica, gerando os valores hash que s ao enviados para o jogador Bob na linha 8. Quando Bob recebe a mensagem, verica que o m etodo da mensagem indica que Alice est a iniciando uma jogada, o que indica que Bob deve guardar os valores enviados por Alice, gerar seus n umeros aleat orios e tamb em seus respectivos valores hash. Bob se compromete com seus valores hash enviando uma mensagem para Alice na linha 23. Alice recebe a mensagem, guarda os valores hash enviados por Bob e envia uma outra mensagem para Bob na linha 30. Essa mensagem cont em os n umeros aleat orios gerados no primeiro passo. Bob recebe a mensagem que indica e verica se o valores hash dos n umeros aleat orios enviados por Alice s ao iguais aos valores hash enviados quando Alice iniciou a jogada. Em seguida, Bob envia uma mensagem para Alice enviando os n umeros aleat orios gerados por Bob. Alice recebe essa mensagem e verica se os valores hash dos n umeros aleat orios enviados por Bob s ao iguais aos valores hash enviados por Bob. Tanto Alice quanto Bob enviam os n umeros aleat orios gerados pelo protocolo para a super classe DiceRolling que, a partir desses n umeros e da nota c ao de dados, calcula o resultado da jogada.

81

Para implementar o protocolo foram utilizadas algumas classes da plataforma .Net. A classe SHA25611 e utilizada como fun c ao de m ao u nica. O valor hash e um valor u nico de tamanho xo representando um n umero aleat orio, onde dois hashes s ao iguais somente se os n umeros aleat orios forem iguais. O valor hash gerado pelo algoritmo e representado por 256 bits. Para gerar os n umeros aleat orios foi utilizada a classe Random12 . Essa classe gera n umeros pseudo aleat orios, ou seja, gera uma sequ encia de n umeros que atende a certos requisitos estat sticos de aleatoriedade. Por m, para que uma mensagem seja enviada, e necess ario converter os n umeros aleat orios e seus respectivos valores hash para um array de bytes. Com esse objetivo foi utilizada a classe BitConverter13 que converte tipos primitivos da linguagem C# num array de bytes e vice versa.

4.3

M odulo Mental Poker

De fato a implementa ca o deste m odulo e a primeira implementa ca o conhecida do protocolo proposto por GOLLE (2005)14 . No m odulo Mental Poker, toda implementa c ao est a baseada na criptograa assim etrica ElGamal que utiliza um n umero primo p. Portanto, o primeiro requisito a ser satisfeito e a cria ca o de um n umero primo p de forma que seja poss vel utilizar o protocolo de cartas. Ao inicializar o m odulo, um n umero primo p deve ser gerado. A ideia e escolher aleatoriamente um n umero grande n e testar se este n umero e primo. Para realizar este teste, este trabalho utiliza o teste de primalidade Miller-Rabin RABIN (1980), cujo algoritmo produz um teste probabil stico. O algoritmo proposto por RABIN (1980) e uma modica ca o do algoritmo de MILLER (1976). O teste de primalidade de um n umero n e realizado da seguinte forma: 1. Sendo n - 1 um n umero par, o mesmo pode ser escrito como 2s d, onde s e d s ao n umero inteiros positivos e d e um n umero mpar. Seja tamb em um n umero aleat orio a < n; 2. Testar se ad 1(mod n ) e; 3. Testar se a2 1(mod n ) para 0 r s - 1. Se os dois testes falharem, est ao o n umero n e composto. Se os resultados dos testes forem positivos, ent ao h a uma grande probabilidade de o n umero n ser
http://msdn.microsoft.com/en-us/library/9x979460.aspx http://msdn.microsoft.com/en-us/library/ts6se2ek(v=vs.102).aspx 13 http://msdn.microsoft.com/en-us/library/3kftcaf9.aspx 14 Comunica c ao pessoal, via correio eletr onico no dia 20 de Agosto de 2013, com o pesquisador e autor do protocolo de cartas Philippe Golle
12 11
rd

82

primo. Para aumentar esta probabilidade, o teste deve ser realizado diversas vezes para diferentes valores de a. Como apresentado na se c ao 3.3.2 de Modelagem, a classe ElGamal possui o m etodo GenerateLargePrime(length:int):BigInteger que gera um n umero primo de tamanho length bits por meio do algoritmo acima. Como ideia do tamanho necess ario para o n umero primo p utilizado no protocolo de cartas via criptograa ElGamal, assuma 5 jogadores e um baralho de 52 cartas. Assuma que o elemento gerador g seja 2. Dessa forma, em uma rodada onde uma carta e gerada, se cada jogador escolher o maior n umero, 51, o homomorsmo mul51 51 51 51 51 tiplicativo resultar a em 2 2 2 2 2 = 2255 . Portanto, o n umero primo deve ser um n umero com o tamanho de 255 bits. O n umero abaixo e um exemplo de um n umero primo com 255 bits de tamanho: 92633671389852956338856788006950326282615987732512451231566 0672063305037119923 A plataforma .Net n ao tem nenhuma implementa ca o do algoritmo assim etrico ElGamal, portanto foi necess ario implementar esse algoritmo. De fato, a classe BigInteger15 foi fundamental para a implementa c ao do algoritmo. Com esta classe foi poss vel criar e manipular grandes n umeros via m etodos da pr opria classe, com destaque para o m etodo ModPow(value:BigInteger,exponent:BigInteger,modulus:BigInteger) que executa a express ao valueexponent mod modulus. A u nica implementa ca o encontrada do algoritmo ElGamal estava no livro Programming .Net Security do conhecido autor Adam Freeman (FREEMAN e JONES, 2003). A implementa ca o da classe ElGamal se inspirou naquela implementa c ao, com o foco em deixar o c odigo mais enxuto e tamb em substituir uma antiga classe BigInteger16 escrita por Chew Keong TAN pela classe BigInteger implementada anos depois na plataforma .Net. No protocolo de cartas proposto por GOLLE (2005) descrito na se ca o 2.3.10, o passo 2 dene que cada par de jogadores (Pi , Pj ) deve acordar uma chave secreta ki,j para ser usada em uma criptograa sim etrica, o que torna poss vel uma comunica c ao segura entre os jogadores. Para implementar este passo, foi utilizado a estrat egia de criptograa sim etrica, ou seja, utiliza-se um algoritmo assim etrico para trafegar a chave de um algoritmo sim etrico (SCHNEIER, 1996, p 86). O algoritmo ElGamal implementado na classe ElGamal serviu como o algoritmo assim etrico. A classe 17 DESCryptoServiceProvider da plataforma .Net foi utilizada como o algoritmo sim etrico, especicamente o algoritmo DES.
http://msdn.microsoft.com/en-us/library/system.numerics.biginteger.aspx http://www.codeproject.com/Articles/2728/C-BigInteger-Class 17 http://msdn.microsoft.com/en-us/library/system.security.cryptography .descryptoserviceprovider.aspx
16 15

83

Colocar em pr atica a teoria geralmente exp oe detalhes que n ao s ao conhecidos ou percebidos de in cio. No passo 9 do protocolo de cartas proposto por GOLLE (2005) descrito na se ca o 2.3.10, verica-se se duas cartas s ao iguais por meio do protocolo de teste de igualdade de texto proposto por JAKOBSSON e SCHNORR (1999). Assumindo que o conjunto L contenha a carta E (c1 ) = (g r1 , g c1 y r1 ) = (a1 , b1 ) e que a carta E (c2 ) = (g r2 , g c2 y r2 ) = (a2 , b2 ) foi gerada e deve ser testada, aplica-se (c1 ) o homomorsmo multiplicativo do ElGamal E = (g r1 r2 , g c1 c2 y r1 r2 ) = (a,b ). E (c2 ) O primeiro cuidado deve ser garantir que r1 seja maior que r2 , caso contr ario o 1 r r1 r2 = g = gr , sendo r = r1 r2 . resultado ser a um n umero n ao inteiro, pois g Como forma de garantir este requisito, a ideia foi comparar os fatores a das duas cartas criptografadas, ou seja, se a2 > a1 . Como o n umero gerador g e igual, e poss vel vericar qual fator aleat orio ri e maior sem conhecer o seu valor. Se r2 for maior que r1 , a solu c ao e incrementar o valor de r1 com algum fator conhecido de forma que n ao modique a mensagem original criptografada. Para isso, o n umero 1 e criptografado com um fator aleat orio r conhecido, como por exemplo, o valor 5. Criptografar a mensagem 1 com o fator aleat orio 5 resulta em (g 5 , 1 y 5 ) = (g 5 , y 5 ). Utilizando o homomorsmo multiplicativo, altera-se a mensagem E (c1 ) como E (c1 )*E (1) = (g r1 , g c1 y r1 )*(g 5 , y 5 ) = (g r1 +5 , g c1 y r1 +5 ). Novamente os fatores ai s ao comparados, e este procedimento repete-se enquanto a2 > a1 . Al em de garantir que a2 < a1 , outra situa ca o deve ser considerada. Se a carta c2 > c1 , novamente o resultado ser a um n umero n ao inteiro, pois g c1 c2 = g c = g1c . Portanto, e necess ario testar o homomorsmo multiplicativo nas duas combina co es, E (c2 ) E (c1 ) em E (c1 ) , sempre garantindo que a subtra c ao dos n umeros ou seja, testar E (c2 ) e tamb aleat orios resultem num n umero positivo como descrito acima. Assim como apresentado na implementa ca o do m odulo Dice Rolling, a classe 18 SHA256 e utilizada como fun c ao de m ao u nica na fase de comprometimento com a carta criptografada no passo 6 do protocolo de GOLLE (2005). O valor hash gerado pelo algoritmo e representado por 256 bits. Na gera ca o de n umeros aleat orios tamb em e utilizada a classe Random19 . No envio de mensagens, a classe BitConverter20 e utilizada para converter tipos primitivos da linguagem C# num array de bytes e vice versa.

18 19

http://msdn.microsoft.com/en-us/library/9x979460.aspx http://msdn.microsoft.com/en-us/library/ts6se2ek(v=vs.102).aspx 20 http://msdn.microsoft.com/en-us/library/3kftcaf9.aspx

84

Cap tulo 5 Experimento


Neste cap tulo e apresentado um estudo experimental conduzido para avaliar o comportamento e a eci encia da biblioteca desenvolvida neste trabalho, assim como avaliar os protocolos criptogr acos propostos. Dessa forma, tanto para o m odulo Dice Rolling quanto para o m odulo Mental Poker, ser ao descritos os objetivos do experimento, o cen ario em que este experimento foi desenvolvido e, por m, a apresenta ca o dos resultados obtidos e uma an alise geral sobre os mesmos.

5.1

Congura c ao do ambiente

Para executar, testar e avaliar os resultados sobre o uso da biblioteca proposta nesse trabalho, o experimento descrito a seguir foi realizado num PC com sistema operacional Windows 7, com processador Intel Core i5 2.6GHz e mem oria RAM de 4 GB.

5.2

Experimento no m odulo Dice Rolling

O objetivo e testar a implementa ca o do m odulo Dice Rolling, executar determinados cen arios de uso por meio de jogadas com varia c ao na nota ca o de dados e tamb em com varia ca o na quantidade de jogadores. Ser ao realizadas consultas no hist orico de jogadas para saber, por exemplo, qual jogador jogou os dados na terceira jogada, qual foi o resultado fechado da segunda jogada, qual o coment ario e o resultado aberto da u ltima jogada, etc. Al em disso, a partir de jogadas retiradas de jogos reais, o experimento tem o objetivo de avaliar certas m etricas, como o tempo m edio de execu ca o de uma jogada no protocolo, o tr afego m edio em bytes para executar uma jogada, o tempo m edio necess ario para realizar as opera co es de criptograa e tamb em a quantidade de mensagens trocadas entre os jogadores. A seguir e apresentado o cen ario do experimento e os resultados obtidos.

85

5.2.1

Cen ario do experimento

O experimento foi composto por peers, onde cada peer corresponde a uma aplica ca o console que est a executando localmente e escutando em uma determinada porta. Por exemplo, tr es peers, Alice, Bob e Carol escutam em localhost:8080, localhost:8081, localhost:8082 respectivamente. O relacionamento entre os peers e um grafo completo, ou seja, cada peer est a conectado com todos os outros peers do sistema. Ao executar a aplica c ao console que corresponde a um peer, foi feita a conex ao entre os peers. Depois que todos os peers se conectaram uns com os outros, foi poss vel a entrada de comandos na aplica ca o console. O comando de jogar os dados tem a forma <nota ca o de dado, coment ario>, onde o campo coment ario era opcional. Outra op c ao era executar comandos de consulta ao hist orico das jogadas que foram executadas nas rodadas passadas da seguinte forma: list: retorna a lista de todas as rodadas do hist orico. Cada rodada e composta pelo nome do jogador que iniciou a jogada, a nota ca o de dado, o resultado fechado, o resultado aberto e o coment ario da jogada; list/rodada: retorna o hist orico completo de uma determinada rodada. Por exemplo, o comando list/3 retorna o hist orico da terceira rodada; list/rodada/atributo: retorna um valor espec co de uma determinada rodada. Por exemplo, o comando list/3/resultadoAberto retorna o resultado aberto da terceira rodada. O primeiro passo foi executar cada nota c ao de dado da Tabela 5.1, tanto no modo normal quanto no modo em lote. Essas nota co es de dados foram escolhidas pois s ao muito comuns nos mais diversos jogos. O objetivo e averiguar os resultados gerados por cada jogada, como o resultado aberto, o resultado fechado, o coment ario e o jogador que realizou a jogada. Tabela 5.1: Nota co es de dado comuns Identicador ND1 ND2 ND3 ND4 ND5 ND6 ND7 ND8 Nota ca o de dado 1d6 2d6 3d6 4d6 - L 1d10 2d10 1d100 1d20 No de dados 1 2 3 4 1 2 1 1 Coment ario Tirando a sorte Matando o monstro Atirando no inimigo Maior que 10 saio da pris ao! Jogada b onus! For ca de defesa Causando dano no inimigo Se for par saio do jogo

86

O segundo passo foi executar uma massa maior de jogadas. As jogadas foram retiradas de jogos reais do site Roleplay online 1 que atua como uma comunidade de jogos RPG que s ao jogados por meio de posts ou mensagens enviadas pelos jogadores. A comunidade j a registrou 6.155 jogos e 7.204.159 mensagens. Foram escolhidos tr es jogos: Dungeons & Dragons 2 , Vampire The Masquerade 3 e Pathnder 4 . Cada jogada foi executada no modo normal e em lote com a participa ca o de 2, 3, 4 e 5 peers. A Tabela 5.2 mostra, para cada jogo, o total de jogadas e tamb em o total de dados jogados. O sistema de dados predominante para os jogos Dungeons & Dragons e Pathnder e d20, e para o jogo Vampire The Masquarade e d10. Tabela 5.2: Jogos reais utilizados no experimento Jogo Dungeons & Dragons Pathnder Vampire The Masquerade Total de jogadas 651 688 278 Total de dados 1284 930 1345

5.2.2

Resultados

A Tabela 5.3 apresenta os resultados das jogadas para o modo normal e para o modo em lote, exibindo o resultado aberto, ou seja, o valor individual de cada dado, e tamb em o resultado nal que e a avalia c ao da nota c ao de dado com o valor de cada dado: A partir disso foi poss vel exercitar a capacidade do m odulo Dice Rolling de armazenar o hist orico das jogadas. Por exemplo, para saber o coment ario feito na quarta jogada, a consulta list/4/comentario retorna o valor Maior que 10 saio da pris ao!, e o resultado aberto da segunda rodada no modo em lote tem o valor (3 6) para a consulta list/2/resultadoAberto. Os gr acos abaixo mostram os resultados da execu c ao dos jogos da Tabela 5.2, exibindo certas m etricas, como o tempo m edio e o desvio padr ao em segundos para a execu c ao de uma jogada, o tempo m edio em segundos e o desvio padr ao necess ario para realizar as opera co es de criptograa em uma jogada, e tamb em o tr afego m edio e o desvio padr ao em bytes das mensagens trafegadas para executar uma jogada5 . Num cen ario com 2, 3, 4 e 5 peers no modo normal e em lote, as Figuras 5.1, 5.2 e 5.3 mostram o tempo m edio de execu c ao de uma jogada, e as Figuras 5.4, 5.5 e
1 2

http://rpol.net http://www.wizards.com/dnd/ 3 http://web.archive.org/web/20040803073535/www.white-wolf.com/vampire 4 http://paizo.com/pathnderRPG 5 Os resultados s ao apresentados em detalhes no Ap endice A.1.

87

Tabela 5.3: Resultados das jogadas comuns Jogada ND1 ND1 ND2 ND2 ND3 ND3 ND4 ND4 ND5 ND5 ND6 ND6 ND7 ND7 ND8 ND8 Modo Normal Lote Normal Lote Normal Lote Normal Lote Normal Lote Normal Lote Normal Lote Normal Lote Jogador Alice Bob Alice Carol Alice Carol Alice Alice Carol Alice Alice Bob Alice Alice Bob Alice Resultado fechado 2 3 3 9 7 11 12 15 4 7 12 17 80 28 12 9 Resultado Aberto (2) (3) (2 1) (3 6) (2 1 4) (5 5 1) (2 5 5 1) (3 8 4 3) (4) (7) (8 4) (9 8) (80) (28) (12) (9)

5.6 mostram o tempo m edio das opera co es de criptograa, e as Figuras 5.7, 5.8 e 5.9 mostram a quantidade m edia de bytes trafegados entre os peers na execu ca o de uma jogada. Nota-se que para os gr acos dos jogos Dungeons & Dragons e Pathnder, os resultados para o modo normal e para o modo em lote apresentam uma pequena diferen ca. No entanto, para os resultados no modo normal e no modo em lote para o jogo Vampire The Masquerade, a diferen ca e bem relevante. Isso decorre da quantidade de dados presentes em uma u nica jogada. Por exemplo, as nota co es predominantes no jogo Vampire The Masquerade s ao 8d10, 9d10, 6d10, enquanto nos outros jogos as nota co es mais comuns apresentam um baixo n umero de dados por jogada, como 1d20 + 13, 2d4, 2d10. Dessa forma, o modo normal apresenta um resultado bastante inferior quando o n umero de dados presentes na mesma jogada e elevado.

88

Figura 5.1: Tempo m edio de jogada no jogo Dungeons & Dragons

Figura 5.2: Tempo m edio de jogada no jogo Pathnder

Figura 5.3: Tempo m edio de jogada no jogo Vampire The Masquerade

89

Figura 5.4: Tempo m edio de criptograa por jogada no jogo Dungeons & Dragons

Figura 5.5: Tempo m edio de criptograa por jogada no jogo Pathnder

Figura 5.6: Tempo m edio de criptograa por jogada no jogo Vampire The Masquerade

90

Figura 5.7: Tr afego m edio por jogada no jogo Dungeons & Dragons

Figura 5.8: Tr afego m edio por jogada no jogo Pathnder

Figura 5.9: Tr afego m edio por jogada no jogo Vampire The Masquerade

91

5.3

Experimento no m odulo Mental Poker

O objetivo e testar a implementa c ao do m odulo Mental Poker variando o tipo de jogo e a quantidade de jogadores participantes. De fato, por se tratar da primeira implementa c ao do protocolo proposto por GOLLE (2005), e de interesse avaliar algumas m etricas do protocolo, como o tr afego m edio em bytes por jogada, o n umero m edio de colis oes por jogada, o tempo m edio necess ario para executar as opera co es de criptograa em uma jogada e o tempo m edio para completar uma jogada. A seguir e apresentado o cen ario do experimento e os resultados obtidos.

5.3.1

Cen ario do experimento

Assim como no experimento do m odulo Dice Rolling, o experimento desse m odulo e composto por peers que s ao aplica co es console executando localmente. Cada peer est a escutando em uma porta e est a conectado com todos os outros peers. A aplica ca o console apresenta os seguintes comandos: closedcard: gera uma carta fechada para o jogador; opencard: gera uma carta aberta para o jogador; opencardtotable: gera uma carta aberta para a mesa; hand: retorna uma tabela que mostra as cartas que est ao na m ao do jogador. Cada linha da tabela cont em o ndice que e utilizado em outros comandos, o valor da carta criptografado e o valor da carta; peerhand > peername: retorna a m ao do outro jogador. peername identica o jogador. Exemplo: peerhand > alice; tablecards: retorna as cartas da mesa; insertclosedcard > index: insere uma carta da m ao de volta ao baralho. O par ametro index identica a carta da m ao do jogador; discardopencard > index: descarta uma carta de forma aberta. O par ametro index identica a carta da m ao do jogador; discardclosedcard > index: descarta uma carta de forma fechada. par ametro index identica a carta da m ao do jogador; O O par ametro

getclosedcard > peername > index: escolhe e pega uma carta da m ao do outro jogador. O par ametro peername identica o jogador, e o par ametro index identica a carta da m ao do jogador; 92

receiveclosedcard > peername: recebe uma carta da m ao do outro jogador. O par ametro peername identica o jogador. Exemplo: receiveclosedcard > alice; Para obter as medidas de interesse, foram escolhidos quatro jogos para o experimento: jogo da Maior Carta, jogo de P oquer, jogo de Sete e Meio e Escopa. O primeiro jogo, jogo da Maior Carta, e bem simples. Cada jogador retira uma carta aberta do baralho, e ganha quem retirar a maior carta. O segundo jogo, jogo de P oquer, especicamente a varia c ao chamada Texas holdem, tem o seguinte procedimento: inicialmente, cada jogador recebe duas cartas fechadas, e ent ao os jogadores fazem a primeira rodada de aposta. Tr es cartas abertas s ao geradas para a mesa. Outra rodada de aposta ocorre. Outra carta aberta e gerada para a mesa, seguida por outra rodada de aposta. Por m, mais uma carta aberta e gerada para a mesa, e ocorre a u ltima rodada de aposta. Nesse experimento, h a o interesse somente nas jogadas do p oquer, e n ao nas rodadas de aposta. No terceiro jogo, jogo de Sete e Meio, os jogadores devem tentar somar sete e meio com as cartas da sua m ao ou tentar chegar o mais pr oximo poss vel, mas sempre evitando ultrapassar o valor de sete e meio. Nesse jogo e utilizado um baralho de 40 cartas. Inicialmente, cada jogador recebe uma carta fechada. Em seguida, cada jogador pode comprar do baralho quantas cartas quiser para tentar chegar o mais pr oximo do valor sete e meio. No quarto e u ltimo jogo, Escopa, o baralho e composto por 40 cartas. Os jogadores recebem 3 cartas fechadas a cada rodada. Na primeira rodada tamb em s ao geradas 4 cartas abertas para compor a mesa. Ao m de cada rodada todos os jogadores jogaram as suas 3 cartas na mesa. Um jogo com 3 jogadores tem no m aximo 2 rodadas. Para os tr es primeiros jogos foram executadas 100 partidas, variando o n umero de jogadores entre 2, 3, 4 e 5 jogadores. Para o jogo Escopa utilizou-se 2 e 3 jogadores. Mais ainda, foi executado mais 100 jogos para o jogo de Maior Carta utilizando a abordagem proposta neste trabalho que evita colis oes num jogo com cartas abertas. Com isso ser a poss vel medir o ganho de performance dessa abordagem. Tamb em foi executado mais 100 jogos para o jogo Escopa com a abordagem proposta neste trabalho que evita gerar na rodada seguinte as cartas que foram abertas nas rodadas anteriores. Dessa forma, foram executadas 400 partidas para cada um dos tr es primeiros jogos, 200 partidas para o jogo de Escopa, 400 partidas para o jogo de Maior Carta sem colis ao e tamb em mais 200 partidas para o jogo de Escopa que evita colis ao com as cartas que j a foram geradas em rodadas anteriores. Portanto, o n umero total de partidas no experimento e 2.000 partidas. Como forma de automatizar a execu c ao das partidas, foi necess ario a participa c ao de um peer com o papel de maestro, ou seja, que coordenasse as jogadas de uma partida dependendo do tipo de jogo. Esse peer maestro envia mensagens para os jogadores de forma que 93

estes executem as jogadas de acordo com a regras do jogo. Assim que um jogador termina sua jogada, o peer maestro e noticado e outro jogador assume a jogada.

5.3.2

Resultados

Os gr acos abaixo mostram os resultados6 da execu ca o das 2.000 partidas do experimento para os quatro tipos de jogos: jogo da Maior Carta, jogo de P oquer, jogo de Sete e Meio e Escopa. As Figuras 5.10, 5.11, 5.12 e 5.13 apresentam o tr afego m edio e o desvio padr ao em bytes utilizado por jogada. As Figuras 5.14, 5.15, 5.16 e 5.17 apresentam o n umero m edio e o desvio padr ao de colis oes por jogada. As Figuras 5.18, 5.19, 5.20 e 5.21 apresentam o tempo m edio e o desvio padr ao para as opera c oes de criptograa por jogada. A Figura 5.22 apresenta o tempo m edio e o desvio padr ao para pegar uma carta aberta do baralho. A Figura 5.23 apresenta o tempo m edio e o desvio padr ao para gerar uma carta aberta do baralho para a mesa. Finalmente, as Figuras 5.24, 5.25 e 5.26 apresentam o tempo m edio e o desvio padr ao para pegar uma carta fechada do baralho. As Figuras 5.10, 5.11, 5.12 e 5.12 mostram que os valores de tr afego m edio por jogada s ao semelhantes nos quatro jogos. Interessante perceber que mesmo o tr afego m edio do jogo Maior Carta seja semelhante aos outros jogos, seu desvio padr ao e muito menor, pois comparando a m edia de colis oes nas Figuras 5.14, 5.15, 5.16 e 5.16, o jogo de Maior Carta tem a menor m edia de colis ao entre os jogos, ou seja, menos mensagens s ao trocadas e menos bytes s ao trafegados. Por outro lado, nos jogos de P oquer e Sete e Meio o desvio padr ao aumenta ` a medida que o n umero de jogadores cresce, pois o n umero m edio de colis oes tamb em est a aumentando. Da mesma forma, o jogo Escopa apresenta o maior desvio padr ao entre todos os jogos, pois a colis ao e muito maior devido ` a quantidade maior de cartas geradas no jogo de Escopa em rela ca o aos outros jogos. A Tabela 5.4 apresenta os resultados, em porcentagem, do aumento de performance na execu c ao do jogo de Maior Carta com o protocolo sem colis ao. Como para 2 jogadores n ao houve colis ao, n ao houve nenhuma melhoria. Por em, para 3, 4 e 5 jogadores, houve uma melhora signicativa que aumentou a ` medida em que o n umero m edio de colis ao foi maior. Da mesma forma, a Tabela 5.5 apresenta os resultados do aumento de performance na execu ca o do jogos Escopa no modo que evita colis ao com as cartas que foram geradas nas rodadas anteriores.
6

Os resultados s ao apresentados em detalhes no Ap endice A.2.

94

Tabela 5.4: Aumento de performance no jogo de Maior Carta sem colis ao M etrica / Jogadores Tr afego m edio Tempo m edio de criptograa Tempo m edio para gerar carta aberta 2 0% 0% 0% 3 1,15% 4,43% 6,20% 4 1,17% 6,50% 7,93% 5 1,21% 7,08% 8,15%

Tabela 5.5: Aumento de performance no jogo Escopa no modo sem colis ao com as rodadas anteriores M etrica / Jogadores Tr afego m edio Colis ao Tempo m edio de criptograa Tempo m edio para gerar carta fechada 2 0,99% 1,38% 2,07% 2,54% 3 4,60% 6,38% 5,30% 6,49%

Figura 5.10: Tr afego m edio por jogada no jogo de Maior Carta

Figura 5.11: Tr afego m edio por jogada no jogo de Poker 95

Figura 5.12: Tr afego m edio por jogada no jogo de Sete e Meio

Figura 5.13: Tr afego m edio por jogada no jogo Escopa

Figura 5.14: M edia de colis ao por jogada no jogo de Maior Carta

96

Figura 5.15: M edia de colis ao por jogada no jogo de Poker

Figura 5.16: M edia de colis ao por jogada no jogo de Sete e Meio

Figura 5.17: M edia de colis ao por jogada no jogo Escopa

97

Figura 5.18: Tempo m edio de criptograa por jogada no jogo de Maior Carta

Figura 5.19: Tempo m edio de criptograa por jogada no jogo de Poker

Figura 5.20: Tempo m edio de criptograa por jogada no jogo de Sete e Meio

98

Figura 5.21: Tempo m edio de criptograa por jogada no jogo Escopa

Figura 5.22: Tempo m edio para gerar uma carta aberta por jogada no jogo de Maior Carta

Figura 5.23: Tempo m edio para gerar uma carta aberta na mesa por jogada no jogo de Poker 99

Figura 5.24: Tempo m edio para gerar uma carta fechada por jogada no jogo de Poker

Figura 5.25: Tempo m edio para gerar uma carta fechada por jogada no jogo de Sete e Meio

100

Figura 5.26: Tempo m edio para gerar uma carta fechada por jogada no jogo Escopa

101

Cap tulo 6 Conclus ao


Este cap tulo aborda as considera c oes nais referentes a este trabalho, suas contribui co es e perspectivas futuras.

6.1

Considera co es acerca do trabalho

Este trabalho apresentou um estudo sobre criptograa, especicamente sobre protocolos criptogr acos que s ao utilizados para resolver um determinado problema entre dois ou mais participantes. Mais ainda, este trabalho prop os uma biblioteca que implementa um conjunto de protocolos criptogr acos de suporte a a co es em jogos num ambiente ponto-a-ponto. Protocolos criptogr acos est ao relacionados ` a comunica c ao entre participantes e que t em o objetivo de prover seguran ca. Como alguns exemplos de uso de um protocolo criptogr aco est ao o protocolo de autentica ca o em um sistema; protocolo de deni ca o das chaves utilizadas em uma sess ao de comunica c ao; protocolo de particionamento e distribui c ao de um segredo entre os participantes; protocolo para jogar par ou mpar, moeda ou dados; protocolo de jogar cartas, entre outros. No entanto, mesmo possuindo potencial em diferentes tipos de aplica ca o, existe uma car encia de bibliotecas que documentam, implementam e distribuam protocolos criptogr acos que endere cam a co es em jogos em um ambiente ponto-a-ponto. Para tal, este trabalho prop os uma biblioteca de suporte a a c oes em jogos em um ambiente ponto-a-ponto, precisamente a co es relacionadas a jogos de dados e de cartas. A biblioteca foi composta por dois m odulos chamados Dice Rolling e Mental Poker. O primeiro m odulo prov e uma interface simples de usar que permite dois ou mais jogadores executarem um c alculo conjunto e distribu do para jogar dados. Al em de permitir gerar os dados a partir de uma nota ca o de dados e tamb em consultar qualquer resultado de um hist orico de jogadas, o usu ario desse m odulo pode estend elo para interpretar outras nota co es de dados que o pr oprio usu ario dene e tamb em permite sobrescrever o pr oprio protocolo criptogr aco com outra implementa ca o. 102

O segundo m odulo, por meio de uma interface tamb em simples de usar, prov e a capacidade dos jogadores executarem em conjunto diversas opera c oes relacionadas a um jogo de cartas, como pegar uma carta aberta ou fechada do baralho, jogar uma carta na mesa, descartar uma carta, entre outras. De fato, a implementa c ao deste m odulo e a primeira implementa ca o conhecida do protocolo de cartas proposto por GOLLE (2005). Al em disso, este trabalho tamb em prop os e implementou diversas opera co es que estendem o protocolo de GOLLE (2005). A biblioteca proposta neste trabalho e descrita em detalhes por meio de modelos e das decis oes de engenharia de software utilizadas para modelar a sua arquitetura. Mais ainda, foi conduzida uma an alise de complexidade dos algoritmos de cada opera ca o. Por m, foram realizados experimentos utilizando a biblioteca proposta a m de analisar o desempenho de cada opera ca o quando o n umero de jogadores aumenta. De fato os resultados est ao de acordo com a an alise de complexidade realizada.

6.2

Contribui co es

A primeira contribui c ao deste trabalho e a biblioteca proposta para dar suporte a a co es que envolvem sorte em jogos em um ambiente ponto-a-ponto. As contribui c oes deste trabalho podem ser listadas a partir de cada m odulo da biblioteca: M odulo Dice Rolling : Proposta de protocolo para jogar dados com n jogadores; C alculo da complexidade da opera c ao de jogar dado; Proposta do modo de jogar dados em lote para reduzir o custo da opera c ao; Especica ca o do m odulo da biblioteca por meio de modelo de dados e de diagrama de sequ encias; Implementa c ao do m odulo da biblioteca especicado; Explica ca o do uso do m odulo da biblioteca e tamb em dos poss veis pontos de extens ao do m odulo; Avalia c ao da opera ca o de jogar dado no modo normal e em lote por meio da simula ca o de jogos reais com varia ca o do n umero de jogadores. M odulo Mental Poker : Primeira implementa ca o conhecida do protocolo de GOLLE (2005), incluindo tamb em a reimplementa c ao de todos os outros protocolos e algoritmos utilizados pelo protocolo de GOLLE (2005), como o protocolo de igualdade de 103

texto de JAKOBSSON e SCHNORR (1999), o protocolo de gera c ao distribu da de chaves de PEDERSEN (1991) e o algoritmo de chave p ublica ELGAMAL (1985); No trabalho de GOLLE (2005) n ao h a uma verica c ao do protocolo de igualdade de texto de JAKOBSSON e SCHNORR (1999) para testar se uma carta e igual a outra. Dessa forma, este trabalho descreve em detalhes, incluindo prova matem atica, de como o protocolo de igualdade de texto funciona e porque e utilizado para testar se uma carta e igual a outra sem revelar as cartas; Explica ca o, na pr atica (se ca o 4.3), do funcionamento e como deve ser implementado o algoritmo de igualdade de texto de JAKOBSSON e SCHNORR (1999) aplicado ao protocolo de GOLLE (2005); Proposta e implementa ca o de v arias opera co es uilizadas em jogos reais que estendem o protocolo de GOLLE (2005), como: jogadores geram uma carta para a mesa de forma aberta, jogador joga carta de sua m ao na mesa de forma aberta, jogador coloca uma carta de sua m ao novamente no baralho, jogador Pi escolhe e pega carta da m ao do jogador Pj , jogador Pi recebe carta da m ao do jogador Pj que foi escolhida pelo pr oprio jogador Pj , jogador descarta carta de sua m ao no monte de descarte de forma aberta ou fechada, jogadores incluem cartas do monte de descarte de novo no baralho; C alculo da complexidade de cada opera ca o proposta; C alculo da complexidade de cada opera ca o do protocolo de GOLLE (2005); Proposta de eliminar a colis ao do protocolo de GOLLE (2005) quando o jogo cont em somente cartas abertas; Proposta que reduz o n umero de colis oes do protocolo de GOLLE (2005) quando as cartas s ao abertas durante as rodadas de um jogo, permitindo o uso de menos cartas a cada rodada; Especica ca o do m odulo da biblioteca por meio de modelo de dados e de diagrama de sequ encias; Implementa c ao do m odulo da biblioteca especicado; Explica ca o do uso do m odulo da biblioteca; Avalia c ao de cada opera ca o proposta e implementada por meio da simula c ao de jogos reais com varia ca o do n umero de jogadores, vericando as complexidades calculadas. 104

6.3

Limita c oes e trabalhos futuros

De fato a biblioteca de suporte a a co es em jogos ponto-a-ponto proposta neste trabalho pode ser melhorada, ampliada e aprimorada. Para o m odulo Mental Poker, um trabalho futuro seria desenvolver alguma abordagem para evitar a etapa que, por meio do algoritmo de teste de igualdade de texto, verica se uma carta j a foi gerada durante o jogo. De fato esse passo eleva o protocolo de gera ca o de cartas de 2 3 uma complexidade O(n ) para O(n ), ent ao eliminar o teste de igualdade de texto aumenta consideravelmente o desempenho das opera c oes. Para um jogo que utiliza somente cartas abertas, este trabalho conseguiu propor uma abordagem para eliminar o passo que verica se uma carta j a foi gerada. No entanto, esta proposta e limitada, pois se existirem cartas fechadas no jogo, a proposta n ao funciona. Portanto, eliminar o teste de igualdade de texto em um jogo que utiliza cartas fechadas e um desao que requer melhorias no protocolo ou at e mesmo a utiliza ca o de outros protocolos criptogr acos. Como outro trabalho futuro est a a amplia ca o da biblioteca para abranger mais tipos de a co es que podem ser utilizadas em jogos ponto-a-ponto, como o leil ao e o gerenciamento de recursos nitos. Para a c oes envolvendo leil ao, o jogo Ra1 , por exemplo, utiliza pr aticas de leil ao como mecanismo pelo qual os jogadores decidem em adquirir determinados itens durante o jogo. O trabalho de FRANKLIN e REITER (1996) apresenta uma proposta de protocolo distribu do que endere ca a co es em um leil ao com o objetivo de garantir que as apostas somente sejam reveladas ao m do per odo de apostas, que a casa de leil ao tem a garantia de receber o pagamento do vencedor e que somente o vencedor consiga resgatar o item leiloado. O protocolo tamb em prov e prote ca o tanto para a casa de leil ao quanto para os apostadores contra trapa cas de outros apostadores maliciosos. As a c oes de gerenciamento de recursos nitos garantem, por exemplo, que em um jogo composto por 10 diamantes, nenhum jogador possua mais de 10 diamantes, ou que a soma dos diamantes que os jogadores possuem n ao seja maior que 10 diamantes. O protocolo tamb em deve garantir que nenhum jogador consiga trapacear criando mais recursos indevidamente, mas deve permitir que recursos sejam trocados entre os jogadores. O protocolo tamb em deve identicar e punir o jogador que tentar utilizar o mesmo recurso mais de uma vez. O conceito mais pr oximo desse tipo de protocolo e denido como dinheiro virtual ou 2 dinheiro eletr onico descrito detalhadamente em CHAUM (1982) e CHAUM (1988).

1 2

http://boardgamegeek.com/boardgame/12/ra Tradu c ao para o termo em ingl es digital cash

105

Refer encias Bibliogr acas


AL-OQILY, I., KARMOUCH, A., 2007, Policy-Based Context-Aware Overlay Networks. In: Global Information Infrastructure Symposium, 2007. GIIS 2007. First International, pp. 85 92, july. doi: 10.1109/GIIS.2007. 4404172. BARNETT, A., SMART, N. P., 2003, Mental Poker Revisited. In: Paterson, K. G. (Ed.), IMA Int. Conf., v. 2898, Lecture Notes in Computer Science, pp. 370383. Springer. ISBN: 3-540-20663-9. BLAKLEY, G., 1979, Safeguarding cryptographic keys. In: Proceedings of the 1979 AFIPS National Computer Conference, pp. 313317, Monval, NJ, USA. AFIPS Press. BLUM, M., 1982, Coin Flipping by Telephone - A Protocol for Solving Impossible Problems. In: COMPCON, pp. 133137. IEEE Computer Society. Dispon vel em: <http://dblp.uni-trier.de/db/conf/compcon/ compcon1982.html#Blum82>. BRASSARD, G., CHAUM, D., CREPEAU, C., 1988, Minimum Disclosure Proofs of Knowledge. J. Comput. Syst. Sci., v. 37, n. 2, pp. 156 189. Dispon vel em: <http://dblp.uni-trier.de/db/journals/jcss/ jcss37.html#BrassardCC88>. CASTRO, M., DRUSCHEL, P., GANESH, A. J., et al., 2002, Secure Routing for Structured Peer-to-Peer Overlay Networks. In: Culler, D. E., Druschel, P. (Eds.), OSDI. USENIX Association. ISBN: 978-1-45030111-4. Dispon vel em: <http://dblp.uni-trier.de/db/conf/osdi/ osdi2002.html#CastroDGRW02>. CHAUM, D., 1982, Blind Signatures for Untraceable Payments. In: Crypto, v. 82, pp. 199203. CHAUM, D. L., 1988. Blind signature systems. jul. 19. US Patent 4,759,063.

106

COMMUNITIES, E., 2012, Rolling Dice. Dispon vel em: <http://www. crockford.com/ec/Chap6RollingDice.html>. Acesso em: 9 de set. 2012. COUTINHO, S. C., 2003, N umeros Inteiros e Criptograa RSA. 2 ed. , Instituto Nacional de Matem atica Pura e Aplicada, IMPA. ISBN: 8524401249. CRAMER, R., GENNARO, R., SCHOENMAKERS, B., 1997, A Secure and Optimally Ecient Multi-Authority Election Scheme. In: Fumy, W. (Ed.), EUROCRYPT, v. 1233, Lecture Notes in Computer Science, pp. 103118. Springer. ISBN: 3-540-62975-0. CREPEAU, C., 1985, A Secure Poker Protocol that Minimizes the Eect of Player Coalitions. In: Williams, H. C. (Ed.), CRYPTO, v. 218, Lecture Notes in Computer Science, pp. 7386. Springer. ISBN: 3-540-16463-4. CREPEAU, C., 1986, A Zero-Knowledge Poker Protocol That Achieves Condentiality of the Players Strategy or How to Achieve an Electronic Poker Face. In: Odlyzko, A. M. (Ed.), CRYPTO, v. 263, Lecture Notes in Computer Science, pp. 239247. Springer. CREPEAU, C., 2012, Commitment. Dispon vel em: <http://crypto.cs. mcgill.ca/~crepeau/PDF/Commit.pdf>. Acesso em: 4 de ago. 2012. DELFS, H., KNEBL, H., 2002, Introduction to Cryptography: Principles and Applications. Springer. ISBN: 3-540-42278-1. DIFFIE, W., HELLMAN, M. E., 1976, New directions in cryptography. IEEE Transactions on Information Theory, v. 22, n. 6, pp. 644654. Dispon vel em: <http://dblp.uni-trier.de/db/journals/tit/tit22. html#DiffieH76>. EDWARDS, J., 1994, Implementing Electronic Poker: A Practical Exercise in Zero-Knowledge Interactive Proofs. Tese de Mestrado, Department of Computer Science, University of Kentucky. ELGAMAL, T., 1985, A Public Key Cryptosystem and a Signature Scheme Based on Discrete Logarithms, CRYPTO, v. IT-31, n. 4 (July), pp. 469472. FORTUNE, S., MERRITT, M., 1984, Poker Protocols. In: Blakley, G. R., Chaum, D. (Eds.), CRYPTO, v. 196, Lecture Notes in Computer Science, pp. 454464. Springer. ISBN: 3-540-15658-5.

107

FRANKLIN, M. K., REITER, M. K., 1996, The design and implementation of a secure auction service, Software Engineering, IEEE Transactions on, v. 22, n. 5, pp. 302312. FREEMAN, A., JONES, A., 2003, Programming .NET Security. 1 ed. , OReilly Media. ISBN: 0596004427. GAMMA, E., HELM, R., JOHNSON, R., et al., 1995, Design patterns: elements of reusable object-oriented software. Boston, MA, USA, Addison-Wesley Longman Publishing Co., Inc. ISBN: 0-201-63361-2. GOLDREICH, O., LEVIN, L. A., 1989, A Hard-Core Predicate for all One-Way Functions. In: Johnson, D. S. (Ed.), STOC, pp. 2532. ACM. ISBN: 0-89791-307-8. Dispon vel em: <http://dblp.uni-trier.de/db/conf/ stoc/stoc89.html#GoldreichL89>. GOLDWASSER, S., MICALI, S., 1982, Probabilistic encryption & how to play mental poker keeping secret all partial information. In: Proceedings of the fourteenth annual ACM symposium on Theory of computing, pp. 365377. ACM. GOLLE, P., 2005, Dealing Cards in Poker Games. In: ITCC (1), pp. 506511. IEEE Computer Society. Dispon vel em: <http://dblp.uni-trier.de/ db/conf/itcc/itcc2005-1.html#Golle05>. HARDY, G. G. H., WRIGHT, E. M., 1979, An Introduction to the Theory of Numbers. Oxford University Press. IRELAND, K., ROSEN, M., 1990, A Classical Introduction to Modern Number Theory, v. 84. Springer. JAKOBSSON, M., SCHNORR, C.-P., 1999, Ecient Oblivious Proofs of Correct Exponentiation. In: Proceedings of the IFIP TC6/TC11 Joint Working Conference on Secure Information Networks: Communications and Multimedia Security, CMS 99, pp. 7186, Deventer, The Netherlands, The Netherlands. Kluwer, B.V. ISBN: 0-7923-8600-0. JGAMMON, 2012, Biblioteca JGammon. Dispon vel em: <http://sourceforge. net/projects/jgam/#screenshots>. Acesso em: 9 de set. 2012. KIPM, 2013, Standard Dice Notation. Dispon vel em: <http://homepage. ntlworld.com/dice-play/Notation.htm>. Acesso em: 6 de abril 2013.

108

KUBIATOWICZ, J., 2003, Extracting guarantees from chaos. Commun. ACM, v. 46, n. 2, pp. 3338. Dispon vel em: <http://dblp.uni-trier.de/ db/journals/cacm/cacm46.html#Kubiatowicz03>. LIPTON, R., 1981, How to Cheat at Mental Poker. Proceedings of the AMS Short Course in Criptography. LUA, E. K., CROWCROFT, J., PIAS, M., et al., 2005, A survey and comparison of peer-to-peer overlay network schemes. IEEE Communications Surveys and Tutorials, v. 7, n. 1-4, pp. 7293. Dispon vel em: <http://dblp. uni-trier.de/db/journals/comsur/comsur7.html#LuaCPSL05>. MENEZES, A., V. OORSHOT, P., VANSTONE, S., 1996, Handbook of Applied Cryptography. CRC Press. MEYER, B., 1988, Object-Oriented Software Construction, 1st edition. PrenticeHall. ISBN: 0-13-629031-0. MILLER, G. L., 1976, Riemanns hypothesis and tests for primality, Journal of computer and system sciences, v. 13, n. 3, pp. 300317. NACCACHE, D., STERN, J., 1997, A new public-key cryptosystem. In: Advances in CryptologyEUROCRYPT97, pp. 2736. Springer. NAOR, M., 1991, Bit Commitment Using Pseudorandomness. J. Cryptology, v. 4, n. 2, pp. 151158. Dispon vel em: <http://dblp.uni-trier.de/ db/journals/joc/joc4.html#Naor91>. NAPSTER, 2012, Napster. Dispon vel em: <http://www.napster.com>. Acesso em: 10 de jun. 2012. NIVEN, I., ZUCKERMAN, H. S., MONTGOMERY, H. L., 2008, An Introduction to the Theory of Numbers. John Wiley & Sons. ORAM, A., 2001, Peer-to-peer: Harnessing the benets of a disruptive technology. Sebastopol, CA, OReilly. PAILLIER, P., 1999, Public-key cryptosystems based on composite degree residuosity classes. In: Advances in cryptologyEUROCRYPT99, pp. 223 238. Springer. PEDERSEN, T. P., 1991, A Threshold Cryptosystem without a Trusted Party (Extended Abstract). In: Davies, D. W. (Ed.), EUROCRYPT, v. 547, Lecture Notes in Computer Science, pp. 522526. Springer. ISBN: 3-54054620-0. 109

RABIN, M. O., 1980, Probabilistic algorithm for testing primality, Journal of Number Theory, v. 12, n. 1, pp. 128 138. ISSN: 0022-314X. RATNASAMY, S., FRANCIS, P., HANDLEY, M., et al., 2001, A scalable content-addressable network. In: Proceedings of the 2001 conference on Applications, technologies, architectures, and protocols for computer communications, pp. 161172. ACM. RISSON, J., MOORS, T., 2007. Survey of Research towards Robust Peer-to-Peer Networks: Search Methods. RFC 4981 (Informational), set. Dispon vel em: <http://www.ietf.org/rfc/rfc4981.txt>. RIVEST, R. L., ADLEMAN, L., DERTOUZOS, M. L., 1978a, On data banks and privacy homomorphisms, Foundations of secure computation, v. 32, n. 4, pp. 169178. RIVEST, R. L., SHAMIR, A., ADLEMAN, L. M., 1978b, A Method for Obtaining Digital Signatures and Public-Key Cryptosystems. Commun. ACM, v. 21, n. 2, pp. 120126. Dispon vel em: <http://dblp.uni-trier.de/ db/journals/cacm/cacm21.html#RivestSA78>. ROUSSOPOULOS, M., BAKER, M., ROSENTHAL, D. S. H., et al., 2003, 2 P2P or Not 2 P2P? CoRR, v. cs.NI/0311017. ROWSTRON, A., DRUSCHEL, P., 2001, Pastry: Scalable, distributed object location and routing for large-scale peer-to-peer systems, IFIP/ACM International Conference on Distributed Systems Platforms (Middleware), v. 11, pp. 329350. SCHINDELHAUER, C., 1998, A Toolbox for Mental Card Games. t ecnico, University of Lubeck. Relat orio

SCHNEIER, B., 1996, Applied cryptography - protocols, algorithms, and source code in C (2. ed.). Wiley. ISBN: 978-0-471-11709-4. SCHOLLMEIER, R., 2001, A Denition of Peer-to-Peer Networking for the Classication of Peer-to-Peer Architectures and Applications. In: Graham, R. L., Shahmehri, N. (Eds.), Peer-to-Peer Computing, pp. 101102. IEEE Computer Society. ISBN: 0-7695-1503-7. Dispon vel em: <http: //dblp.uni-trier.de/db/conf/p2p/p2p2001.html#Schollmeier01>. SHAMIR, A., 1979, How to Share a Secret. Commun. ACM, v. 22, n. 11, pp. 612 613. Dispon vel em: <http://dblp.uni-trier.de/db/journals/cacm/ cacm22.html#Shamir79>. 110

SHAMIR, A., RIVEST, R. L., ADLEMAN, L. M., 1979. Mental Poker. Technical Report MIT-LCS-TM-125, Massachusetts Institute of Technology. STAMER, H., 2013, SecureSkat. Uma implementa c ao criptogracamente segura do jogo Skat. Dispon vel em: <http://savannah.nongnu.org/projects/ secureskat/>. Acesso em: 7 de julho de 2013. STAMER, H., 2005, Ecient Electronic Gambling: An Extended Implementation of the Toolbox for Mental Card Games. In: Wolf, C., Lucks, S., Yau, P.W. (Eds.), WEWoRC, v. 74, LNI, pp. 112. GI. ISBN: 3-88579-403-9. STEINMETZ, R., WEHRLE, K., 2005, Peer-to-peer systems and applications. Berlin [u.a.], Springer. ISBN: 3-540-29192-X. STOICA, I., MORRIS, R., KARGER, D., et al., 2001, Chord: A Scalable PeerTo-Peer Lookup Service for Internet Applications, Computer Communication Review, v. 31, n. 4 (out.), pp. 149160. TEBAA, M., EL HAJJI, S., EL GHAZI, A., 2012, Homomorphic Encryption Applied to the Cloud Computing Security. In: Proceedings of the World Congress on Engineering, v. 1. WALLACH, D. S., 2002, A Survey of Peer-to-Peer Security Issues. In: Okada, M., Pierce, B. C., Scedrov, A., et al. (Eds.), ISSS, v. 2609, Lecture Notes in Computer Science, pp. 4257. Springer. ISBN: 3-540-00708-3. Dispon vel em: <http://dblp.uni-trier.de/db/conf/isss2/isss2002. html#Wallach02>. WANG, C., LI, B., 2003, Peer-to-Peer Overlay Networks: A Survey. Relat orio t ecnico. WINTER, S., 2007, A Brief History of Dice. Dispon vel em: <http://www. wizards.com/default.asp?x=dnd/alumni/20070302a>. Acesso em: 6 de abril 2013. ZHAO, B., KUBIATOWICZ, J., JOSEPH, A., 2001, Tapestry: An Infrastructure for Fault-tolerant Wide-area Location and Routing, Computer, v. 74.

111

Ap endice A Resultados do experimento


A.1 Dice Rolling

Tabela A.1: Resultados das m etricas no jogo Dungeons & Dragons no modo normal 2 peers 0,006530884 0,00461839 0,00121727 0,000406531 3 peers 0,013994751 0,006322008 0,002535283 0,0002569 4 peers 0,079799609 0,015130991 0,001966699 0,000273228 5 peers 0,2144569880 0,0211467824 0,002457099 0,000294198

Tempo m edio (s) do tempo m edio (s) Tempo m edio de criptograa (s) do tempo m edio de criptograa (s) Tr afego m edio (B) do tr afego m edio (B) Total de mensagens

3734,039168 178,1331278 4

22663,62497 135,5823034 20

37260,91723 854,0635073 42

63698,85404 1189,303457 72

112

Tabela A.2: Resultados das m etricas no jogo Dungeons & Dragons no modo em lote 2 peers 0,004238889 0,003753315 0,000790073 0,000330383 3 peers 0,007122888 0,004343218 0,000914734 0,000202357 4 peers 0,051794163 0,012296792 0,001276491 0,00022205 5 peers 0,1391939175 0,0245454332 0,001594787 0,000239092

Tempo m edio (s) do tempo m edio (s) Tempo m edio de criptograa (s) do tempo m edio de criptograa (s) Tr afego m edio (B) do tr afego m edio (B) Total de mensagens

2423,588732 144,7668544 4

11551,03266 449,4158267 20

24184,30421 694,0881178 42

41343,92222 966,5339763 72

Tabela A.3: Resultados das m etricas no jogo Pathnder no modo normal 2 peers 0,005729893 0,003536699 0,001067976 0,000311315 3 peers 0,010386213 0,004502086 0,001231611 0,000185288 4 peers 0,068797757 0,011615463 0,001615602 0,000205603 5 peers 0,1873652562 0,0182771320 0,002137564 0,000216393

Tempo m edio (s) do tempo m edio (s) Tempo m edio de criptograa (s) do tempo m edio de criptograa (s) Tr afego m edio (B) do tr afego m edio (B) Total de mensagens

3276,071978 136,4118592 4

15700,54451 463,8009908 20

32560,69146 608,820068 42

55844,92296 879,238309 72

113

Tabela A.4: Resultados das m etricas no jogo Pathnder no modo em lote 2 peers 0,004236111 0,001835552 0,000680208 0,000245941 3 peers 0,007683564 0,004777831 0,000911127 0,000196636 4 peers 0,050895545 0,01232689 0,001195198 0,000218196 5 peers 0,1391601260 0,0166852960 0,001594787 0,000239092

Tempo m edio (s) do tempo m edio (s) Tempo m edio de criptograa (s) do tempo m edio de criptograa (s) Tr afego m edio (B) do tr afego m edio (B) Total de mensagens

2409,16338 134,495767 4

11615,02648 492,2080154 20

24087,90939 646,1092653 42

41343,92222 966,5339763 72

Tabela A.5: Resultados das m etricas no jogo Vampire The Masquerade no modo normal Tempo m edio (s) do tempo m edio (s) Tempo m edio de criptograa (s) do tempo m edio de criptograa (s) Tr afego m edio (B) do tr afego m edio (B) Total de mensagens 2 peers 0,020508293 0,008493845 0,003822475 0,000747665 3 peers 0,038141194 0,00959858 0,005749246 0,005491224 4 peers 0,255129483 0,027021272 0,005749246 0,005491224 5 peers 0,7203376849 0,0578665116 0,007649461 0,00051619

11725,63613 327,6109404 4

67564,37616 2272,038157 20

67564,37616 2272,038157 42

200046,2258 2212,12194 72

114

Tabela A.6: Resultados das m etricas no jogo Vampire The Masquerade no modo em lote 2 peers Tempo m edio (s) do tempo m edio (s) Tempo m edio de criptograa (s) do tempo m edio de criptograa (s) Tr afego (B) m edio 0,004238889 0,003753315 0,000790073 0,000330383 3 peers 0,007883459 0,004241483 0,00118832 0,002426498 4 peers 0,052733083 0,011940336 0,001211452 0,00015571 5 peers 0,2053505802 0,0446852960 0,001594787 0,000239092

2423,588732 144,7668544 4

12775,43284 1057,895845 20

26821,00787 2041,032036 42

41343,92222 966,5339763 72

do tr afego m edio (B) Total de mensagens

A.2

Mental Poker

115

Tabela A.7: Resultados das m etricas no jogo Maior Carta 2 peers 0,01109049 3 peers 0,026415405 4 peers 0,047748037 5 peers 0,072606976

Tempo m edio para gerar carta aberta (s) do tempo m edio para gerar carta aberta (s) Tempo m edio de criptograa (s) do tempo m edio de criptograa (s) Tr afego m edio (B) do tr afego m edio (B) Colis ao m edia (B) da colis ao m edia

0,008931798

0,024011464

0,03341112

0,047123501

0,006642213 0,00616958

0,011943959 0,011744748

0,017433254 0,015026583

0,02703301 0,023614288

7880,285 154,876124 0 0

20547,07383 11620,708454 0,033557 0,180086012

37691,1 2838,530873 0,04 0,195959179

57930,12 2585,481288 0,0505 0,077226938

116

Tabela A.8: Resultados das m etricas no jogo P oquer 2 peers 0,021803915 3 peers 0,058754123 4 peers 0,068273101 5 peers 0,113370206

Tempo m edio para gerar carta fechada (s) do tempo m edio para gerar carta fechada (s) Tempo m edio para gerar carta aberta na mesa(s) do tempo m edio para gerar carta aberta na mesa (s) Tempo m edio de criptograa (s) do tempo m edio de criptograa (s) Tr afego m edio (B) do tr afego m edio (B) Colis ao m edia (B) da colis ao m edia

0,01835094

0,041317747

0,036119103

0,05709661

0,060105696

0,12176581

0,140861398

0,235610475

0,02944398

0,054249242

0,051727173

0,103290351

0,037948616 0,028218048

0,059734877 0,050192575

0,055415122 0,039310466

0,07770165 0,067457178

8023,502222 4192,026523 0,082222222 0,305351447

19814,64275 11549,69346 0,189189189 0,534348923

36036,80769 20171,97828 0,22 0,478643918

55593,52933 30579,96354 0,2406 0,494934159

117

Tabela A.9: Resultados das m etricas no jogo Sete e Meio 2 peers 0,029869 3 peers 0,063784405 4 peers 0,114987555 5 peers 0,18032327

Tempo m edio para gerar carta fechada (s) do tempo m edio para gerar carta fechada (s) Tempo m edio de criptograa (s) do tempo m edio de criptograa (s) Tr afego m edio (B) do tr afego m edio (B) Colis ao m edia (B) da colis ao m edia

0,028272747

0,038930024

0,086893326

0,13145472

0,022867739 0,021002652

0,034692011 0,028537259

0,062937553 0,062368056

0,102335676 0,100332421

7306,815287 3215,181998 0,027600849 0,163826257

17650,8 10180,9948 0,025165563 0,187425409

33111,04134 23031,34187 0,109359606 0,356309883

49998,78392 37208,18901 0,098333333 0,342048567

118

Tabela A.10: Resultados das m etricas no jogo Escopa 2 peers 0,180733115 3 peers 0,23159646

Tempo m edio para gerar carta fechada (s) do tempo m edio para gerar carta fechada (s) Tempo m edio de criptograa (s) do tempo m edio de criptograa (s) Tr afego m edio (B) do tr afego m edio (B) Colis ao m edia (B) da colis ao m edia

0,078238796

0,138238796

0,085270001 0,060190098

0,1527506 0,103140484

8021,787402 7225,610588 0,166144201 0,371513849

20202,71212 17545,69404 0,31986532 0,707530773

119