5.2.1
Especificac¸ ˜oes do
benchmark
e da m ´aquina
Para testar a viabilidade dos esquemas baseados em MLE explicados em 4.3.3, foi imple- mentado um programa espec´ıfico `a aplicac¸ ˜ao. O objetivo do mesmo passa pela medic¸ ˜ao de
tempos associados `as t ´ecnicas de comparac¸ ˜ao e a t ´ecnicas de baseline para interpretac¸ ˜ao de resultados.
Este benchmark foi implementado em Java1, consistindo em cerca de 1200 linhas de c ´odigo, sendo por volta de 400 dedicadas `a implementac¸ ˜ao das t ´ecnicas de MLE a serem utiliza- das. Foi utilizada a vers ˜ao de Java 1.6.0 27 com OpenJDK Runtime Environment (IcedTea6 1.12.6), SHA-256 para func¸ ˜oes de hash (2.2.1), AES, para func¸ ˜oes criptogr ´aficas sim ´etricas, em modo CBC com padding PKCS5 (2.2.2). Para paralelizac¸ ˜ao de processos foi utilizado a classe java.lang.Thread e, para aleatoriedade, a classe java.security.SecureRandom utilizando o construtor public SecureRandom() para inicializac¸ ˜ao do algoritmo.
Os diferentes testes abordados pelo benchmark foram executados numa m ´aquina com um processador Intel(R) Core(TM)2 Duo CPU T9300 @ 2.50GHz, com 4130Mb de mem ´oria RAM e sobre o sistema operativo Ubuntu 12.04.2 LTS.
5.2.2
Resultados da perspetiva do cliente
Para recolha de tempo de execuc¸ ˜ao foram gerados, aleatoriamente, 40 ficheiros, com tama- nho desde 250Kb a 10Mb (de 250Kb em 250Kb). Depois, foi repetida a operac¸ ˜ao a testar um n n ´umero de vezes para cada ficheiro gerado previamente, sendo medido o tempo de cada execuc¸ ˜ao. Dividindo a soma destas operac¸ ˜oes pelo n escolhido obteve-se a m ´edia, sendo posteriormente constru´ıdo um gr ´afico que ajuda a perceber como a operac¸ ˜ao reage a aumentos no tamanho dos ficheiros.
Deduplicac¸ ˜ao simples: o termo mais importante de comparac¸ ˜ao com t ´ecnicas de deduplicac¸ ˜ao ´e a deduplicac¸ ˜ao na sua forma mais simples. Para este teste ser ´a executado apenas uma operac¸ ˜ao de hash, tipicamente utilizada como termo de comparac¸ ˜ao entre dois ficheiros num sistema que contemple deduplicac¸ ˜ao. Como pode ser observado na figura 5.1, as operac¸ ˜oes de hash s ˜ao executadas inicialmente com tempo inferior a 4ms, crescendo linearmente com o aumentar do tamanho dos ficheiros. Neste caso, o tamanho de mensagem desta operac¸ ˜ao ser ´a apenas influenciado pela func¸ ˜ao de hash (que, para este caso com SHA-256, ser ´a 256 bits). Sendo a mensagem M = {0, 1}n, o tamanho das
mensagens ser ´a n + 256.
Figura 5.1: Tempos de execu¸c˜ao do processo de deduplica¸c˜ao para n opera¸c˜oes
Figura 5.3: Tempos de execu¸c˜ao do processo de cifragem HCE para n opera¸c˜oes
Cifragem simples: neste teste ser ´a executada uma operac¸ ˜ao de cifragem AES-CBC, utili-
zando uma chave aleat ´oria. O objectivo ´e obter um termo de comparac¸ ˜ao entre o custo de operac¸ ˜ao do esquema MLE com uma cifra standard sim ´etrica. Como pode ser observado na figura5.2, as operac¸ ˜oes executadas demoram, inicialmente, cerca de 10ms, crescendo linearmente com o aumento do tamanho dos ficheiros. Para uma mensagem M = {0, 1}n, o tamanho de mensagens ser ´a n.
MLE-HCE: neste teste ser ´a executado o esquema de MLE denominado HCE (A.5). Como pode ser observado na figura5.3, as operac¸ ˜oes iniciam num tempo de execuc¸ ˜ao de 25ms e, tal como os anteriores, v ˜ao aumentando linearmente. Os valores obtidos s ˜ao consisten- tes com o espect ´avel, uma vez que o processo sequencial seria uma operac¸ ˜ao de hash e uma de cifra sim ´etrica, sendo o adicional provocado pela inicializac¸ ˜ao de threads pela Java Virtual Machine (JVM). Para esta operac¸ ˜ao, deve ser considerado o agregado da operac¸ ˜ao de hash com a operac¸ ˜ao de cifragem. Sendo assim, temos que o tamanho das mensagens
´e n + 256.
Os tempos obtidos das operac¸ ˜oes de HCE s ˜ao congruentes com o seu comportamento
4.3.3. De um ponto de vista funcional, pode-se aproximar o tradeoff necess ´ario `a apli- cabilidade deste esquema ao de adicionar a operac¸ ˜ao b ´asica que falta a cada uma das abordagens. Isto significa que i. se quisermos partir de um sistema de deduplicac¸ ˜ao, de- vemos esperar uma degradac¸ ˜ao de performance ligeiramente superior a uma operac¸ ˜ao de
Tabela 5.1: Eficiˆencia da deduplica¸c˜ao com blocos de 400Kb e 1 byte de salt
cifragem, e que ii. se quisermos adicionar a funcionalidade de deduplicac¸ ˜ao a um sistema que j ´a realiza cifragem, esperamos um degradar de performance igual ´avel a pouco mais que uma operac¸ ˜ao de hash.
A n´ıvel de tamanhos de mensagem, o aumento ´e quase negligenci ´avel. No caso de um sistema que aplique cifragem, temos o aumento equivalente ao output da func¸ ˜ao de hash sendo este, pela pr ´opria natureza das func¸ ˜oes, reduzido.
5.2.3
Resultados da perspetiva do servidor
Para uma avaliac¸ ˜ao de efici ˆencia dos diferentes m ´etodos a serem testados, foi escolhida uma amostra previamente utilizada num estudo de deduplicac¸ ˜ao [45, 46]. Como seriam executadas v ´arias operac¸ ˜oes pesadas a n´ıvel de processamento, esta foi dividida em 8 sub-amostras. Estes resultados do benchmark podem ser consultados na tabela5.1. As primeiras tr ˆes colunas apresentam o n ´umero de ficheiros e o n ´umero de blocos verifica- dos em cada run, seguidas do tamanho da amostra avaliada. As operac¸ ˜oes do benchmark foram executadas para blocos de 400Kb.
Seguem-se colunas que apresentam os resultados da deduplicac¸ ˜ao a n´ıvel do ficheiro com- pleto (Whole File: WF) e a n´ıvel do bloco (Block : Bl). Ao contemplarem operac¸ ˜oes b ´asicas de deduplicac¸ ˜ao, as duas primeiras colunas de resultados v ˜ao permitir estabelecer um valor base de efic ´acia, quando comparadas `as restantes operac¸ ˜oes.
Imediatamente ap ´os a deduplicac¸ ˜ao encontram-se os resultados associados `a aplicac¸ ˜ao da t ´ecnica HCE, de maneira a poder avaliar um dos esquemas propostos por Bellare em [8] em termos de hits de deduplicac¸ ˜ao. Tamb ´em neste ponto vai ser contemplada a avaliac¸ ˜ao por ficheiro completo e por blocos.
De seguida, encontram-se os resultados dos esquemas CipherCE e MLESalted. O pri- meiro apenas faz sentido ser avaliado com ficheiros completos, uma vez que tenta fazer uso do header dos mesmos, enquanto que o segundo vai avaliar tanto ficheiros completos como por blocos. Para o mesmo, foi escolhido um tamanho de salt de 1 byte.
Finalmente, como comparac¸ ˜ao final, ´e avaliada a qualidade da deduplicac¸ ˜ao quando exe- cutadas operac¸ ˜oes de cifragem que n ˜ao estejam preparadas para deduplicac¸ ˜ao. Para este teste foi utilizado o AES-CBC.
Da referida tabela, podem tirar-se m ´ultiplas conclus ˜oes:
1. A efic ´acia da deduplicac¸ ˜ao segura (esquemas de MLE) ´e igual `a da deduplicac¸ ˜ao normal: 100%.
2. A deduplicac¸ ˜ao ´e inaplic ´avel com t ´ecnicas de cifragem habituais (AES-CBC): 0%. 3. A n´ıvel de poupanc¸a de espac¸o, as t ´ecnicas de deduplicac¸ ˜ao por blocos conseguem
atingir resultados superiores `as que contemplam apenas ficheiros inteiros. De notar que esta ´e uma carater´ıstica que pode melhorar com a diminuic¸ ˜ao do tamanho de blocos e que deve ser balanceada com o consequente aumento de processamento exigido.
4. A t ´ecnica de MLESalted, cujo objetivo passava por aumentar a entropia das mensa- gens, apresentou n´ıveis extremamente reduzidos de efic ´acia na deduplicac¸ ˜ao, tendo esta sido reduzida para valores entre 8% e 0.2%. Daqui pode-se tirar que acr ´escimos na entropia das mensagens resultam em valores baixos de deduplicac¸ ˜ao.
5. A t ´ecnica de CipherCE, que recorre ao primeiro bloco para derivar a chave, n ˜ao con- seguiu n´ıveis de efici ˆencia superiores ao da deduplicac¸ ˜ao por ficheiro completo. Isto significa que, na execuc¸ ˜ao deste benchmark, n ˜ao foram encontrados dois ficheiros com blocos deduplic ´aveis, que tivessem os primeiros blocos iguais.