Considerações Finais

Neste capítulo, seguimos a apresentação feita no Capítulo 7 (General Cryptographic Protocols) de GOLDREICH (2004) que trata da computação segura de uma funcionalidade qualquer.

Inicialmente, chegamos a um procedimento para computar uma funcionalidade qualquer em um modelo de segurança limitado (Seção 4.2). Nele, o adversário é semi-honesto e o canal de comunicação é ponto-a-ponto. A ideia básica desse procedimento é tratar a funcionalidade como um circuito lógico (ou uma série de operações sobre o F2) e conduzir uma avaliação privada

desse circuito, procedendo uma porta lógica por vez.

Um adversário semi-honesto pode modelar comportamentos reais e, por isso, esse primeiro resultado é de interesse por si só. No entanto, nós o utilizamos como etapa auxiliar para alcançar segurança no chamado modelo padrão, no qual não se faz restrições aos poderes do adversário. Partindo de um protocolo seguro contra um adversário semi-honesto aplicamos uma série de três procedimentos, ou compiladores, para gerar um protocolo seguro no modelo padrão.

Dois desses procedimentos, o pré-compilador e o pós-compilador, lidam apenas mu- danças dos tipos de canais de comunicação. O resultado central da Seção 4.3, portanto é o compilador principal. Ele tem o papel de forçar o comportamento semi-honesto fortalecido ao adversário malicioso. Esse comportamento reflete o que pode e o que não pode ser esperado da segurança do protocolo final. Em particular, é impossível garantir que a execução não será abortada e, portanto, que o protocolo final é justo.

Por fim, resumimos o efeito dessa restrição de comportamento com o Teorema 4.89, o qual estabelece que qualquer funcionalidade pode ser computada de maneira segura na presença de um adversário malicioso.

106 5 COMPUTAÇÃO JUSTA

Começaremos este capítulo discutindo o resultado que estabelece a existência de funcio- nalidades para as quais não existem protocolos justos. Uma maneira de contornar esse resultado negativo, como discutiremos na Seção 5.2, é a adoção de definições relaxadas de justiça. Esses relaxamentos têm como objetivo possibilitar que protocolos, de forma geral, alcancem pelo menos algum grau de justiça.

Na Seção 5.3 nós definiremos a noção de justiça monetária que será adotada no restante deste trabalho. Ela se baseia no pagamento de multas como forma de compensar os participantes honestos e penalizar os desonestos quando a justiça tradicional de um protocolo é quebrada. A escolha dessa definição possibilita o emprego direto de transações Bitcoin na construção de protocolos justos.

5.1 Impossibilidade Geral

No Capítulo 4 apresentamos um importante resultado sobre a computação segura de uma funcionalidade qualquer. No entanto, esse resultado contém uma ressalva importante: a tolerância à quebra de justiça. Isso se deve ao fato de o modelo ideal, que é nosso referencial de segurança, dar ao adversário a possibilidade de privar os participantes honestos de receberem suas saídas1. Protocolos seguros nesse modelo (ou seja, seguros segundo a Definição 4.37) possuem o que se chama de segurança com (tolerância ao) aborto (security with (agreement on) abort), em oposição à segurança com justiça perfeita (complete fairness).

À primeira vista, a falta de justiça dos protocolos do Capítulo 4 poderia ser atribuída apenasà capacidade do adversário abortar. No entanto, essa não é uma análise precisa. É possível construir protocolos perfeitamente justos, mesmo na presença de um adversário com tal capacidade, desde que a maioria dos participantes seja honesta2.

Esse resultado positivo, por sua vez, poderia sugerir que as construções utilizadas no Capítulo 4 não são ótimas e que trabalhos futuros poderiam generalizar a justiça perfeita para qualquer cenário. Infelizmente, esse não é o caso, como mostra CLEVE (1986). Esse trabalho demonstra que a funcionalidade de cara ou coroa (coin flipping), em particular, não pode ser computada com justiça perfeita, concluindo, portanto, que nem toda funcionalidade o pode.

Esse resultado é especialmente forte porque a funcionalidade de cara ou coroa, apesar de simples, é importante na criação de protocolos mais complexos. Nela, dois participantes têm como objetivo escolher um bit (ou jogar um moeda) com distribuição uniforme, isto é, com um viés desprezível. Ela pode ser definida formalmente como a seguir.

Definição 5.90 (Funcionalidade cara ou coroa). Sejam A e B dois participantes e n um parâmetro de segurança. Definimos o viés de um bit b como vi´es(b)def= Pr[b = 0] −1₂. A 2-funcionalidade

1_{O modelo ideal de execução, no caso de adversários maliciosos, é apresentado na Definição 4.34.} 2_{Uma forma de construir tais protocolos é descrita por GOLDREICH (2004).}

de cara ou coroa, f_c/c, é definida como a seguir: f_c/c(1n_{, 1}n₎def_{= (b}

A, bB),

com bA, bB∈ {0,1}, Pr[bA= bB] = 1 (ou seja, bA= bB) e vi´es(bA), vi´es(bB) desprezíveis em n

(ou seja, vi´es(bA), vi´es(bB)≤ O



1 nk



para todo k).

Na verdade, CLEVE (1986) considera uma versão relaxada de f_c/c, ou seja, uma versão que não pode ser mais difícil que a própria f_c/c. De maneira geral, provar que a versão relaxada de f_c/cnão admite um protocolo perfeitamente justo fortalece ainda mais seu resultado negativo.

Nessa versão relaxada, as saídas bAe bBsó precisam ser iguais com probabilidade maior

ou igual a 50%. Ou seja, a restrição “Pr[bA= bB] = 1” da Definição 5.90 é substituída pela

restrição “Pr[bA = bB]≥ 1₂+ ε”, para algum ε predefinido. Note que isso torna a definição

significativamente mais fraca. Em particular, qualquer implementação para f_c/cserve também como implementação para sua versão relaxada, mas o contrário não é verdadeiro. Definimos formalmente esse relaxamento a seguir.

Definição 5.91 (Funcionalidade cara ou coroa relaxada). Sejam A e B dois participantes, n um parâmetro de segurança e ε_{∈ [0,}1₂] um valor predefinido. Definimos a versão relaxada de fc/c

como a 2-funcionalidade fε c/ctal que: fε c/c(1n, 1n) def = (bA, bB),

com bA, bB∈ {0,1}, Pr[bA= bB]≥ 1₂+ ε e vi´es(bA), vi´es(bB) desprezíveis em n.

Um protocolo seguro para computar fε

c/ctem que, em particular, garantir que a saída

de um participante honesto tenha sempre um viés desprezível. E é isso que impede essa funcionalidade de ser computada com justiça perfeita. Registramos essa impossibilidade no teorema a seguir.

Teorema 5.92 (Impossibilidade de CLEVE (1986)). Não é possível computar fε

c/ccom justiça

perfeita.

Demonstração. A prova formal deste teorema pode ser encontrada no Apêndice A. Apresentare- mos aqui apenas uma argumentação informal.

A ideia geral dessa prova é considerar um protocolo Π qualquer para computar fε c/cem

r(n) rodadas, em que n é um parâmetro de segurança. A partir daí, cria-se 2r(n) + 1 estratégias maliciosas para o participante A e 2r(n) para o participante B. A idéia dessas estratégias é emular o comportamento honesto do participante correspondente até a rodada i, com i_{∈ {1,··· ,r(n)}, e} então abortar.

Consideramos, em seguida, os protocolos resultantes da substituição de um participante honesto por cada uma das 4r(n) + 1 estratégias desonestas. Com isso, podemos calcular a média ∆ dos vieses causados nas saídas dos participantes honestos por cada protocolo resultante. Pode