Protocolo de Lyubashevsky II

Conforme mencionado na Se¸c˜ao 4.3.2, no artigo original, Lyubashevsky sugere alguns con- juntos de parˆametros para serem utilizados na pr´atica com seu protocolo. As implica¸c˜oes da varia¸c˜ao desses parˆametros no desempenho de execu¸c˜ao n˜ao s˜ao t˜ao simples de serem analisadas, pois n˜ao afetam apenas o tamanho das estruturas envolvidas, mas tamb´em a dimens˜ao de certos dom´ınios, ao restringir as normas m´aximas dos vetores.

0 1 2 3 4 5 6 Paralelismo funcional

Execução serial

tempo (s)

Figura 4.8: Implementa¸c˜oes do protocolo de Cayrel et al. com execu¸c˜ao serial e paraleliza¸c˜ao via OpenMP.

dimens˜oes s˜ao estabelecidas por n. Al´em disso, o parˆametro m ´e de grande importˆancia na defini¸c˜ao de p ≈ (2σ + 1)m_.2−128

n , que por sua vez determina a ordem de grandeza dos coeficientes dos polinˆomios. Por exemplo, nos casos em que n = 512, σ = 2047 e κ = 24, a mudan¸ca de m = 5 para m = 8 faz com que p passe de 259.8 _{para 2}95.8_.

Em geral, podemos dizer que o protocolo trabalha com vetores e polinˆomios com di- mens˜ao e grau, respectivamente, menores do que os anteriores, mas onde os elementos e coeficientes podem ser bem maiores. No caso, como a NTL foi desenvolvida para traba- lhar com inteiros de tamanho arbitr´ario, o desempenho dos programas parece ser mais afetado pelas dimens˜oes dos vetores e grau dos polinˆomios do que pelo tamanho de seus elementos/coeficientes.

Assim, para os parˆametros n = 512, m = 5 e p = 259.8 sugeridos pelo autor, o tempo total medido para o protocolo de Lyubashevsky foi bastante inferior (em m´edia 1.06s) ao das vers˜oes que utilizam a NTL dos outros dois protocolos, mas compar´avel ao tempo da implementa¸c˜ao com reticulados ideais em C do protocolo de Kawachi et al., que j´a sup˜oe que os inteiros envolvidos n˜ao ser˜ao t˜ao grandes.

4.4.4

Coment´arios Gerais

Quando executamos o protocolo de Cayrel et al. com n = 64 (o valor sugerido pelos autores para ser utilizado na pr´atica) e o comparamos com o protocolo de Kawachi et al. com o mesmo conjunto de parˆametros, notamos que o primeiro se mostrou um pouco mais r´apido quando consideramos reticulados gen´ericos (Figura 4.9a). Como o n´umero de valores de compromisso ´e diferente para estes dois protocolos (trˆes para o primeiro, contra cinco

do ´ultimo), por´em calculados a partir da mesma fun¸c˜ao, ´e esperado que o protocolo que envolva c´alculo de mais valores apresente um desempenho inferior, especialmente quando se leva em conta as informa¸c˜oes dogprof de que a maior fra¸c˜ao do tempo despendido pelo programa corresponde a esse tipo de opera¸c˜ao.

5.00 5.05 5.10 5.15 5.20 5.25

Kawachi et al. Cayrel et al.

tempo (s)

(a) Reticulados gen´ericos.

0 2 4 6 8 10

Kawachi et al. Cayrel et al.

tempo (s)

(b) Reticulados ideais. Figura 4.9: Tempo m´edio de execu¸c˜ao das implementa¸c˜oes n˜ao paralelizadas.

Por outro lado, quando comparamos as implementa¸c˜oes envolvendo reticulados ideais (Figura 4.9b), a diferen¸ca ´e levemente mais acentuada. Embora os algoritmos sejam semelhantes e utilizem a mesma fun¸c˜ao de compromisso, o n´umero de multiplica¸c˜oes substitu´ıdas por opera¸c˜oes com polinˆomios n˜ao ´e o mesmo, de forma que a passagem da vers˜ao com reticulados gen´ericos para ideais n˜ao produz efeitos idˆenticos para os dois protocolos.

O protocolo de Lyubashevsky, por sua constru¸c˜ao, permite somente o uso de reticula- dos ideais e, nesses casos, apresentou desempenho superior ao dos outros dois protocolos. Entretanto, conforme j´a comentado, isso se deve provavelmente ao uso das classes da NTL desenvolvidas para trabalhar com inteiros arbitrariamente grandes. Quando comparamos a implementa¸c˜ao de testes do protocolo de Lyubashevsky `a vers˜ao do protocolo de Kawa- chi et al. (empregando reticulados ideais) que n˜ao utiliza a NTL, o desempenho ´e bastante semelhante.

Em termos de dificuldade de programa¸c˜ao, como o protocolo de Lyubashevsky utiliza coeficientes grandes, implement´a-lo sem o aux´ılio de uma biblioteca adicional pode cons- tituir um trabalho bem mais ´arduo. No caso dos outros dois protocolos, podemos abrir

m˜ao deste recurso, ou ent˜ao buscar uma biblioteca que melhor se adeque `as necessidades de programa¸c˜ao, isto ´e, que efetue multiplica¸c˜oes ou a Transformada R´apida de Fourier eficientemente, mas sem supor o uso de inteiros grandes.

De qualquer modo, para uma compara¸c˜ao mais precisa entre os protocolos, outros parˆametros devem ser ajustados, tais como o n´umero de rodadas efetuadas. No cap´ıtulo seguinte, apresentaremos uma an´alise mais detalhada neste sentido.

Discuss˜ao

Ao estudar diversos algoritmos que compartilham uma mesma finalidade (no nosso caso, a identifica¸c˜ao de entidades), surge um interesse natural em determinar, de alguma forma, qual destes apresenta maiores vantagens ou ´e mais adequado para o uso na pr´atica. Neste cap´ıtulo, ser´a apresentada uma an´alise nesse sentido, tendo como objeto de discuss˜ao os protocolos abordados. Ser˜ao considerados tanto os dados coletados a partir do experi- mento de implementa¸c˜ao quanto as caracter´ısticas te´oricas levantadas no Cap´ıtulo 3.

Ainda, discutiremos sobre as diferentes categorias de otimiza¸c˜ao que podem ser apli- cadas aos protocolos, e seu impacto na tentativa de compara¸c˜ao dos mesmos. Al´em das melhorias cuja influˆencia buscamos testar no experimento de implementa¸c˜ao, ser˜ao men- cionadas algumas sugest˜oes adicionais para novas otimiza¸c˜oes.

Nessa mesma dire¸c˜ao, iremos apresentar algumas possibilidades de estender o trabalho aqui apresentado, seja na forma de otimiza¸c˜oes complementares, ou a partir da realiza¸c˜ao de diferentes formas de an´alise.