estudo e medicao do consumo de energia de algoritmos criptograficos do mi bench

UNIVERSIDADE FEDERAL DE SERGIPE – UFS

LEALDO SANTOS NETO

ESTUDO E MEDIÇÃO DO CONSUMO DE ENERGIA DE ALGORITMOS CRIPTOGRÁFICOS DO MIBENCH

São Cristóvão, SE

Julho de 2010

LEALDO SANTOS NETO


Monografia submetida ao corpo docente do Curso de Ciência da Computação da Universidade Federal de Sergipe (UFS) como parte dos requisitos para obtenção do grau de Bacharel em Ciência da Computação.

Orientador: Edward David Moreno, Dr.

São Cristóvão, SE

Julho de 2010

Santos Neto, Lealdo

Estudo e Medição do Consumo de Energia de Algoritmos Criptográficos

do MiBench. Monografia de Trabalho de Conclusão de Curso, UFS. São

Cristóvão, 2010.

1. Consumo de Energia 2. MiBench 3. Sistemas Embarcados 4. Sim-Panalyzer 5. Computação Móvel 6. Medição Experimental.

LEALDO SANTOS NETO


Monografia submetida ao corpo docente do Curso de Ciência da Computação da

Universidade Federal de Sergipe (UFS) como parte dos requisitos para obtenção do grau de

Bacharel em Ciência da Computação.

São Cristóvão, 20 de Julho de 2010.

BANCA EXAMINADORA:

_____________________________________________ Prof. Edward David Moreno, Dr.

Orientador DCOMP / UFS

_____________________________________________ Msc. Wanderson Roger Azevedo Dias

Pesquisador do DCC/UFAM

_____________________________________________

Prof. Dr. Marco Túlio Chella DCOMP / UFS

_____________________________________________ Prof. Msc. César Giacomini Penteado

LSITEC, USP, São Paulo

AGRADECIMENTOS

A Deus, que como força superior proporciona a harmonia do mundo em que vivemos.

Aos meus pais, pela minha formação de vida e oportunidade de educação qualificada.

Ao meu orientador, Edward Moreno, pelos ensinamentos na área, apoio e atenção

dispensada neste último período.

Ao Prof. Chella e ao Wanderson Roger pelo apoio e respostas a questionamentos sobre

assuntos relacionados a este trabalho.

Aos colegas de graduação, pelos momentos de diversão e estudos passados juntos.

Aos meus familiares pelo apoio durante toda a minha vida que resultaram na formação

da pessoa que sou hoje.

A todos, o meu muito obrigado.

RESUMO

O grande avanço tecnológico decorrente das últimas décadas resultou em um mundo

globalizado em que a velocidade dos acontecimentos está maior e os meios de comunicação

estão mais rápidos e difundidos. Neste novo cenário as informações passaram a ser

supervalorizadas e a computação tem grande destaque como meio de criação e transmissão

deste conteúdo, além do fato da miniaturização dos dispositivos que tornou a computação

ubíqua.

Diante deste cenário, observando ainda a grande importância dos sistemas

embarcados, torna-se necessário um estudo sobre o consumo energético dos mesmos, sendo

neste trabalho focado o conjunto de benchmark MiBench, em especial os seus algoritmos de

segurança.

Assim, o presente trabalho tem como objetivo analisar e mensurar o consumo de

energia dos algoritmos SHA, rijndael (melhor conhecido como AES) e Blowfish, presentes no

MiBench, usando quatro metodologias. Esses métodos são: medição de descarga da bateria,

estimativa com tempo de execução e características de processador, simulação usando o Sim-

Panalyzer e medição experimental com uso de osciloscópio. Os principais resultados do

trabalho foram a caracterização do consumo dos algoritmos estudados e um comparativo entre

os resultados das metodologias empregadas, inclusive com a obtenção de dados reais sobre o

consumo dos algoritmos.

Palavras-chave:

Consumo de Energia, MiBench, Sistemas Embarcados, Sim-Panalyzer, Computação

Móvel, Medição Experimental.

ABSTRACT

The great technological progress in the last decades results in a globalized world

where things happens faster and the media are faster and difused. In this new environment the

information came to be overvalued and the computation has a great importance as a mean of

creation and transmission of this content, beyond the fact of the miniaturization of devices

became them ubiques.

In this setting, noting the importance of embedded systems, becomes necessary to

study them energy consumption, and this study focused on the set of benchmark MiBench,

specially their security algorithms.

Thus, this study aims to analyze and measure the power consumption of the SHA,

rijndael (better known as AES) and Blowfish algorithms, present on MiBench, using four

methods. These methods are: the battery discharge measurement, estimation using runtime

and characteristics of processor, simulation using Sim-Panalyzer and experimental

measurement using an oscilloscope. The main results of this study were to characterize the

consumption of the studied algorithms and obtain a comparison between the results of the

different methodologies, including obtaining the real power consumption of the algorithms.

Key-words:

Energy Consumption, MiBench, Embedded System, Sim-Panalyzer, Mobile

Computing, Experimental Measurement.

SUMÁRIO

LISTA DE TABELAS .................................................................................................................................... 9

1. INTRODUÇÃO ...............................................................................................................................10

1.1. MOTIVAÇÃO .................................................................................................................................11 1.2. OBJETIVOS ...................................................................................................................................11 1.3. ORGANIZAÇÃO DA MONOGRAFIA .................................................................................................12

2. CONTEXTUALIZAÇÃO TEÓRICA .............................................................................................13

2.1. SISTEMAS EMBARCADOS ..............................................................................................................13 2.2. CONCEITOS DE SEGURANÇA DE DADOS ........................................................................................15 2.2.1. Algoritmos de Chaves Assimétricas ..........................................................................................16 2.2.2. Algoritmos de Chaves Simétricas .............................................................................................16 2.2.3. Algoritmos de Hash .................................................................................................................17 2.3. PROGRAMAS DO BENCHMARK MIBENCH ......................................................................................17 2.4. FERRAMENTAS UTILIZADAS PARA ANALISAR O CONSUMO DE ENERGIA ......................................21 2.4.1. NePSim ....................................................................................................................................22 2.4.2. PowerScope .............................................................................................................................22 2.4.3. JouleTrack ...............................................................................................................................24 2.4.4. SNU Energy Explorer Web ......................................................................................................25 2.4.5. Sim-Panalyzer ..........................................................................................................................26 2.5. TÉCNICAS PARA MEDIÇÃO UTILIZADAS NO TRABALHO ...............................................................27 2.5.1. Metodologia 1: Medição de Descarga de Baterias ....................................................................28 2.5.2. Metodologia 2: Estimativa com Tempo de Execução e Características do Processador ............30 2.5.3. Metodologia 3: Simulação usando o Sim-Panalyzer ................................................................31 2.5.4. Metodologia 4: Experimental com Osciloscópio.......................................................................31

3. TESTES, RESULTADOS E ANÁLISE...........................................................................................33

3.1. RESULTADOS PARA MEDIÇÃO DE DESCARGA DE BATERIAS EM NOTEBOOK .................................33 3.1.1 Algoritmo SHA-1 .....................................................................................................................34 3.1.2 Algoritmo Blowfish ..................................................................................................................34 3.2. RESULTADOS PARA ESTIMATIVA DE CONSUMO COM BASE NAS CARACTERÍSTICAS DO PROCESSADOR .36 3.2.1. Algoritmo SHA-1 .....................................................................................................................36 3.2.2. Algoritmo Blowfish ..................................................................................................................37 3.3. RESULTADOS USANDO O SIMULADOR SIM-PANALYZER ............................................................................37 3.3.1. Algoritmo SHA-1 .....................................................................................................................38 3.3.2. Algoritmo Blowfish ..................................................................................................................38 3.3.3. Algoritmo Rijndael ...................................................................................................................40 3.4. RESULTADOS PARA EXPERIMENTO USANDO O OSCILOSCÓPIO .....................................................42 3.4.1. Algoritmo SHA-1 .....................................................................................................................43 3.4.2. Algoritmo Blowfish ..................................................................................................................46 3.5. COMPARATIVO ENTRE OS MÉTODOS ............................................................................................56

4. CONCLUSÕES ................................................................................................................................60

REFERÊNCIAS ............................................................................................................................................62

ANEXO I .......................................................................................................................................................64

ANEXO II ......................................................................................................................................................66

ANEXO III ....................................................................................................................................................71

ANEXO IV.....................................................................................................................................................75

LISTA DE FIGURAS

Figura 2.1 Etapas de como o PowerScope gera um perfil de energia. (a) Coleta de dados e (b) Análise dos dados [6]. ..........................................................................................................................................................23

Figura 2.2 Corrente consumida por instruções do processador ARM medidas em [22]. .....................................24 Figura 2.3. Diagrama do JouleTrack ................................................................................................................25 Figura 2.4. Esquema utilizado para as medições com a metodologia 4. .............................................................32 Figura 3.1. Gráfico do custo energético para execução do algoritmo Blowfish. .................................................39 Figura 3.2. Gráfico do custo energético para execução do algoritmo rijndael. ....................................................41 Figura 3.3. Resistores ligado em série com o fio de alimentação da placa mãe. .................................................43 Figura 3.4: Gráficos da variação da voltagem ao executar o algoritmo SHA-1 para as entradas: (a) entrada1, (b)

entrada2, (c) Money.mp3 e (d) vídeo.MPG. ..............................................................................................44 Figura 3.5. Gráficos da variação da voltagem ao executar uma encriptação com o algoritmo Blowfish usando

chave de 32 bits para as entradas: (a) entrada1, (b) entrada2, (c) Money.mp3 e (d) vídeo.MPG. .................47 Figura 3.6. Gráficos da variação da voltagem ao executar uma decriptação com o algoritmo Blowfish usando

chave de 32 bits para as entradas: (a) entrada1, (b) entrada2, (c) Money.mp3 e (d) vídeo.MPG. .................47 Figura 3.7. Gráficos da variação da voltagem ao executar uma encriptação com o algoritmo Blowfish usando

chave de 256 bits para as entradas: (a) entrada1, (b) entrada2, (c) Money.mp3 e (d) vídeo.MPG. ...............50 Figura 3.8. Gráficos da variação da voltagem ao executar uma decriptação com o algoritmo Blowfish usando

chave de 256 bits para as entradas: (a) entrada1, (b) entrada2, (c) Money.mp3 e (d) vídeo.MPG. ...............50 Figura 3.9. Gráficos da variação da voltagem ao executar uma encriptação com o algoritmo Blowfish usando

chave de 448 bits para as entradas: (a) entrada1, (b) entrada2, (c) Money.mp3 e (d) vídeo.MPG. ...............53 Figura 3.10. Gráficos da variação da voltagem ao executar uma decriptação com o algoritmo Blowfish usando

chave de 448 bits para as entradas: (a) entrada1, (b) entrada2, (c) Money.mp3 e (d) vídeo.MPG. ...............53

LISTA DE TABELAS

Tabela 2.1. Número de instruções executadas pelas aplicações do MiBench [9].................................................19 Tabela 2.2. Áreas de consumo apresentadas no Sim-panalyzer e os seus significados. .......................................27 Tabela 3.1. Arquivos usados como parâmetro para os testes. ............................................................................33 Tabela 3.2. Chaves usadas como parâmetro para os testes.................................................................................33 Tabela 3.3. Resultados da execução do algoritmo SHA usando a primeira metodologia....................................34 Tabela 3.4. Resultados da execução do algoritmo Blowfish (chave de 32 bits) usando a metodologia 1. ............35 Tabela 3.5. Resultados da execução do algoritmo Blowfish (chave de 256 bits) usando a metodologia 1. ..........35 Tabela 3.6. Resultados da execução do algoritmo Blowfish (chave de 448 bits) usando a metodologia 1. ..........36 Tabela 3.7. Resultados da estimativa de consumo para algoritmo SHA. ............................................................37 Tabela 3.8. Resultados da estimativa de consumo para algoritmo Blowfish. ......................................................37 Tabela 3.9. Resultados da simulação de consumo para algoritmo SHA. ............................................................38 Tabela 3.10. Resultados da simulação de consumo para algoritmo Blowfish. ....................................................39 Tabela 3.11. Potência simulada ao executar o algoritmo Blowfish. ...................................................................40 Tabela 3.12. Resultados da simulação de consumo para algoritmo rijndael. ......................................................41 Tabela 3.13. Aumento de consumo energético de acordo com o tamanho da chave. ..........................................41 Tabela 3.14. Potência simulada ao executar o algoritmo rijndael. ......................................................................42 Tabela 3.15. Gráficos obtidos ao executar o algoritmo SHA e dados da interpretação dos mesmos. ...................45 Tabela 3.16. Guia para as figuras e tabelas com os resultados dos testes com o algoritmo Blowfish. ..................46 Tabela 3.17. Gráficos obtidos ao executar o algoritmo Blowfish no processo de encriptação usando chave de 32

bits e dados da interpretação dos mesmos. ................................................................................................48 Tabela 3.18. Gráficos obtidos ao executar o algoritmo Blowfish no processo de decriptação usando chave de 32

bits e dados da interpretação dos mesmos. ................................................................................................49 Tabela 3.19. Gráficos obtidos ao executar o algoritmo Blowfish no processo de encriptação usando chave de 256


bits e dados da interpretação dos mesmos. ................................................................................................52 Tabela 3.21. Gráficos obtidos ao executar o algoritmo Blowfish no processo de encriptação usando chave de 448


bits e dados da interpretação dos mesmos. ................................................................................................55 Tabela 3.23. Comparativo da potência média (em W) consumida em cada metodologia usada no trabalho. .......56 Tabela 3.24. Comparativo do consumo em Joules entre as diferentes metodologias. ..........................................57 Tabela 3.25. Comparativo do consumo (em µJ) dos algoritmos estudados por byte do arquivo de entrada. ........58 Tabela 3.26. Comparativo do tempo de execução (em s) obtidos nas diferentes metodologias aplicadas. ...........59

1. INTRODUÇÃO

Esta é a era onde a informação e o conhecimento passaram a desempenhar um

novo e estratégico papel, passando então a ter um valor inimaginável. Nessa nova era o

principal meio de produção e transmissão de conhecimento passou a ser o computador,

tornando-se assim onipresente no mundo atual.

Um computador pode ser um desktop comumente visto nas empresas e

domicílios atuais, ou qualquer dispositivo com capacidade de processamento usado para

gerar, armazenar ou transmitir dados. Estes outros dispositivos são em sua maioria

sistemas embarcados, que são sistemas digitais de propósitos especiais, usados dentro

de outro dispositivo com funções específicas.

Com a elevada evolução dos processadores e custo reduzido de produção, tais

sistemas embarcados estão presentes em praticamente tudo que utiliza energia elétrica.

Por exemplo, o controlador do LCD de um DVD player, o controle de injeção de

combustível em um carro de Fórmula 1, obtiveram maior potencial de processamento, o

que acarreta em um aumento de consumo energético.

A problemática se inicia devido ao fato de que, segundo URRIZA et al [24], o

avanço da tecnologia das baterias ter sido lento nos últimos anos, já que as tecnologias

usadas nas mesmas se tratarem de tecnologias amadurecidas, e ainda não existem

alternativas comercialmente viáveis de novas tecnologias para os próximos anos. Para

suprir essa deficiência das baterias, estão sendo estudadas formas de diminuir o

consumo energético dos mesmos, por meio de arquiteturas de baixo consumo e de

algoritmos mais eficientes.

O fato é que uma grande quantidade desses dispositivos estão interligados a

outros dispositivos através da internet, sendo usados em grande escala para a

transmissão de dados, que em sua maioria devem ter segurança ao trafegarem na rede.

Essa segurança é dada com a utilização de algoritmos de criptografia, que então

passaram a serem executados na grande maioria dos dispositivos computacionais.

Segundo GUTHAUS et al [9], o MiBench é um conjunto de 35 aplicações de

benchmark otimizadas para sistemas embarcados. Suas aplicações são divididas em seis

categorias: controle automotivo e industrial, rede, segurança, dispositivos de consumo,

automação de escritórios e telecomunicações.

Este trabalho visa realizar o estudo comparativo do consumo de energia de cada

um desses algoritmos selecionados usando algumas metodologias para se obter esse

importante valor.

1.1. Motivação

O consumo global de energia preocupa não só os ambientalistas, mas também

toda a sociedade, e dispositivos de computação também estão sendo observados deste

ponto de vista. Esta preocupação, aliada à autonomia das baterias, fez com que os

projetistas passassem a desenvolver produtos buscando um menor consumo energético.

Segundo SANGIOVANNI-VINCENTELLI & MARTIN [18], os atuais sistemas

embarcados têm seu desenvolvimento compostos em 80% por software. Ainda segundo

SANGIOVANNI-VINCENTELLI & MARTIN [18], o uso de mais software permite

reduzir o custo de projeto e produção dos sistemas embarcados, já que os

microcontroladores e microprocessadores embarcados são produzidos em larga escala e

utilizados em diversas aplicações embarcadas diferentes. Sendo a maior parte das

funcionalidades dos sistemas embarcados implementadas por software, o consumo

energético de tais algoritmos é de grande importância para o consumo total do sistema,

e em consequência a sua viabilidade econômica.

Com o aumento do uso desse tipo de algoritmos em diversos dispositivos o

consumo energético proveniente da sua execução pode ser considerado significativo,

principalmente em dispositivos móveis. Por esse motivo, foi escolhido para estudo o

consumo de energia dos algoritmos de segurança presentes no benchmark MiBench,

que são: SHA (Secure Hash Algorithm), Blowfish, rijndael (melhor conhecido como

AES) e PGP (Pretty Good Privacy).

1.2. Objetivos

Geral

Este trabalho tem como objetivo estudar e analisar o consumo de energia em

algumas plataformas computacionais, incluindo ferramentas de simulação e

metodologias para medição. Como o foco do trabalho são os algoritmos de segurança

do MiBench, também são incluídos como objetivo o estudo de sistemas embarcados,

dos algoritmos de segurança e do próprio MiBench.

Específicos

a) Realizar testes de consumo de energia dos algoritmos alvo utilizando um

notebook;

b) Realizar medição do consumo de energia dos algoritmos alvo em um desktop;

c) Simular o consumo de energia utilizando o simulador Sim-Panalyzer [2];

d) Comparar o consumo medido usando várias metodologias de avaliação;

e) Destacar a medida experimental, via osciloscópio.

1.3. Organização da Monografia

A monografia está organizada em quatro capítulos. O capítulo 2 apresenta os

conceitos básicos estudados para a realização dos experimentos feitos, além de prover

um embasamento teórico para todo o trabalho, como conceitos relacionados com

sistemas embarcados, segurança de dados, benchmark MiBench e ferramentas e

técnicas para medição de consumo energia.

O capitulo 3 apresenta os resultados obtidos com a aplicação dos métodos

descritos na seção 2.5, e sua respectiva análise e comparação. O capítulo 4 finaliza o

trabalho, sumarizando os resultados alcançados e discutindo futuras pesquisas e

trabalhos.

2. Contextualização Teórica

2.1. Sistemas Embarcados

Sistemas embarcados geralmente são definidos como um sistema de propósito

específico usado dentro de outro dispositivo.

Como tal definição não é precisa, são apresentadas suas principais características

a seguir:

• Funcionamento Embutido: São sistemas que funcionam dentro de outro

dispositivo, e para o mesmo, acrescentando ou otimizando funcionalidades.

• Ubíquo: São invisíveis ao usuário do dispositivo em que o sistema encontra-

se embutido.

• Função Específica: Sistemas embarcados são projetados para desempenhar

uma função específica repetidamente. Isso garante que o dispositivo seja

desenhado da maneira mais eficiente em termos das restrições exigidas para

sua função específica. Apesar de serem específicos, flexibilidade quanto a

atualizações, diferenciações e reuso são importantes.

• Restrição de Custo: Como sistemas embarcados são usados em outros

dispositivos produzidos em larga escala, estes precisam ter um custo baixo

para que seja viável sua utilização.

• Restrição de Tamanho: Sistemas embarcados devem ser suficientemente

pequenos para serem utilizados em sistemas portáteis, em que tamanho e

peso influem muito no produto final.

• Desempenho Satisfatório: Mesmo com restrições de consumo de energia,

custo e tamanho, o dispositivo deve apresentar um desempenho satisfatório

para a função em que foi projetado.

• Restrição do Consumo de Energia: Como estes sistemas são largamente

usados em dispositivos que utilizam baterias como fonte de energia eles

devem ter um consumo energético bastante restrito, sendo este o mínimo

possível para uma execução satisfatória da sua tarefa específica.

• Reativo e de Tempo Real: Os sistemas embarcados geralmente têm que ser

reativos continuamente às alterações de parâmetros de entrada, já que são

comumente usados como controladores que monitoram entradas e a cada

alteração devem fazer modificações nas saídas. Como complemento da

reatividade, estas reações devem ser em tempo real, já que muitas vezes estes

controladores operam em situações críticas em que não pode haver atrasos.

Estas tolerâncias quanto aos atrasos podem ser consideradas como hard ou

soft, em que a operação deve ser obrigatoriamente terminada dentro do

deadline ou pode ir além do deadline sem falha grave, respectivamente.

Para o desenvolvimento de um sistema embarcado todas estas características

devem ser estudadas e então analisadas para definir o nível em que cada uma delas deve

estar presentes, além de exigir quais características serão implementadas em hardware

ou software para garantir o equilíbrio do projeto. Tal equilíbrio é decorrente da melhoria

de uma das características comprometendo as outras. Por exemplo, sabe-se que quanto

maior o desempenho de um sistema maior será o seu consumo energético e a dissipação

de calor, portanto se deve escalar quanto de desempenho necessário para que possa

dimensionar o seu consumo energético e a necessidade de uma dissipação ativa de

calor.

O custo de desenvolvimento do projeto é chamado custo de engenharia não

recorrente, já que após o desenvolvimento deste pode ser produzido qualquer número de

unidades sem um aumento do mesmo.

Para um projeto deste, além do equilíbrio entre as características citadas acima

deve ser estimado o tempo de mercado e o tempo de protótipo, que correspondem ao

tempo de projetar e fabricar o dispositivo até este ser vendido ao consumidor e o tempo

de fabricar uma versão funcional e não final do mesmo, respectivamente. Além do

tempo de verificação da segurança e de funcionalidade do mesmo.

Outro fator importante a ser considerado para um sistema embarcado é o custo

de uma unidade produzida, não incluso o preço do projeto.

Os sistemas embarcados possuem microcontroladores ou microprocessadores

que podem ser divididos em subtipos como: (i) propósito geral, que pode ser aplicado

para diversas funções, sendo estas implementadas por software e (ii) aplicação

específica, que contém hardware escalável dentro de uma determinada área de atuação,

ou de único propósito, e executam sempre a mesma função.

Estes hardware geralmente implementam mecanismos de processamento de

sinais digitais específicos para a sua área de atuação, os quais podem ser filtros, codecs,

controles de dispositivos, funções de modem, codificação, decodificação, entre outras

funções específicas necessárias para o funcionamento do mesmo.

Outras funções que vem cada vez mais sendo implementadas em sistemas

embarcados são as funções de comunicação sem fio para que os mesmos possam

funcionar como um sistema distribuído de processamento, aumentando assim

virtualmente o poder computacional de cada dispositivo.

Os sistemas embarcados hoje são usados em praticamente todo sistema ligado a

energia, por exemplo: celulares, câmeras digitais, filmadoras, videocassetes, vídeo

games, calculadoras, microondas, máquina de lavar, geladeira, fax, copiadoras,

impressoras, caixas registradoras, alarmes, caixas eletrônicos e nos veículos também no

controle de injeção de combustível, ABS e suspensão ativa, entre outros.

2.2. Conceitos de Segurança de Dados

A segurança das informações é uma preocupação dos homens, e estes vem

sempre desenvolvendo técnicas para tornar suas informações inacessíveis a pessoas não

autorizadas.

Segundo SIMON [21], uma das técnicas para a segurança de tais informações é

a criptografia, que consiste em um conjunto de métodos e técnicas para cifrar ou

codificar (processo chamado encriptar) informações legíveis por meio de um algoritmo,

convertendo um texto original em um texto ilegível, sendo possível mediante o processo

inverso, recuperar as informações originais. O processo de inverso a encriptação é

chamado de decriptação ou decifragem.

Em seus primórdios foram usadas técnicas simples de criptografia, porém

bastante eficientes na época, como cifrar textos alterando as letras desviando uma

quantidade de caracteres fixos no alfabeto. Porém, com a valorização da informação

surgiu um grande interesse em ter acesso às mesmas e assim surgiu um grupo voltado a

estudar como obter a informação original tendo como base o texto cifrado.

Com o crescente uso da internet como meio de comunicação entre computadores

as técnicas de criptografia se tornaram indispensáveis, e então foram implementados os

algoritmos de criptografia na comunicação entre eles.

Os principais algoritmos utilizados para prover segurança nas comunicações por

computador hoje são vistos a seguir.

2.2.1. Algoritmos de Chaves Assimétricas

Os algoritmos de chaves assimétricas, também chamados de chaves públicas,

utilizam duas chaves diferentes para o processo de encriptação e decriptação das

mensagens. Cada um dos processos é de mão única, sendo fáceis de calcular e

praticamente impossíveis de serem revertidos.

Para se comunicar usando este método o receptor possui uma chave privada e

uma pública, a chave pública do receptor, que é disponível a todos, é então usada para

criptografar a mensagem que será enviada ao mesmo, que usa a sua chave privada para

descriptografar a mesma.

Este algoritmo também pode ser utilizado como técnica de assinatura digital,

onde o emissor usa a sua chave privada para criptografar a mensagem e o receptor usa a

chave pública do emissor para descriptografar a mensagem, e então pode verificar quem

é o verdadeiro emissor da mensagem.

Os algoritmos de chave assimétrica mais conhecidos e usados são: RSA (Rivest,

Shamir and Adleman), ElGamal.

2.2.2. Algoritmos de Chaves Simétricas

Os algoritmos de chaves simétricas, também chamados de chaves públicas,

utilizam apenas uma chave para poder cifrar e decifrar o dado. Neste caso é usado um

processo de mão dupla, em que após cifrar o mesmo pode ser decifrado usando a

mesma chave.

O maior problema desse algoritmo é como a chave será trocada entre os

usuários, pois qualquer intruso que tenha a chave pode tanto escrever quanto ler as

mensagens criptografadas.

Os algoritmos de chave simétrica mais conhecidos e usados são: DES (Data

Encryption Standard), IDEA (International Data Encryption Algorithm), RC (Ron's

Code ou Rivest Cipher), rijndael (mais conhecido como AES, Advanced Encryption

Standard), Blowfish.

O código fonte do Blowfish, usado neste trabalho, se encontra explicado no

anexo IV.

2.2.3. Algoritmos de Hash

Os algoritmos de hash geram uma sequência de caracteres chamado de hash que

possui tamanho fixo, independente do tamanho da mensagem original. Essa técnica não

é considerada criptografia já que é uma operação de mão única, sendo assim, com o

hash não pode ser feito o caminho inverso e se chegar à mensagem clara novamente.

A segurança do algoritmo de hash está no fato de que qualquer alteração feita no

arquivo original irá alterar significativamente o resultado do hash, pois mesmo se um

único bit da mensagem original for alterado muitos bits do hash serão afetados.

Este tipo de técnica de segurança é usado para:

• Integridade de arquivos: ao se enviar um arquivo é anexado ao mesmo o seu

hash, ao chegar no destino o hash é recalculado e se for idêntico ao enviado

pode-se dizer que a mensagem não foi alterada.

• Segurança de senhas: como o hash não é reversível, é mais seguro guardar o

hash da senha e quando a mesma for usada se calcula o hash novamente, se

for igual ao salvo então a senha é validada.

• Assinaturas digitais: usando uma técnica de hash juntamente com uma

técnica de criptografia de chave pública pode se garantir a identidade do

emissor e integridade do documento.

A vulnerabilidade de um algoritmo de hash são as possibilidades de que dois

conjuntos de dados distintos geram o mesmo hash, esta possibilidade é chamada de

colisão. Os testes em algoritmos hash consistem em se chegar ao hash de um texto claro

conhecido ou desconhecido a partir de qualquer entrada de dado.

Os algoritmos de hash mais conhecidos e usados são: MD5, SHA-1 e

WHIRLPOOL.

O código fonte do SHA, usado neste trabalho, se encontra no anexo III.

2.3. Programas do Benchmark MiBench

Segundo COSTA [4], atualmente existe uma grande variedade de benchmarks,

tais como: Dhrystone, Linpack, HPL e MediaBench, sendo, em sua maioria,

desenvolvidos para uma área específica da computação. Dentre os benchmarks

existentes, um dos mais utilizados é o SPEC (Standard Performance Evaluation

Corporation), que atualmente está na versão SPEC2006 [23].

O SPEC [23] é um benchmark para computadores de uso geral, que agrupa um

conjunto de programas e dados divididos em duas categorias: inteiro e ponto flutuante.

Esse benchmark ganhou grande popularidade no âmbito comercial e acadêmico, por ser

um ótimo medidor de desempenho. Essa popularidade tem influenciado o

desenvolvimento de microprocessadores de uso geral, empregados em computadores

pessoais e servidores, de modo que os processadores são projetados para ter alta

performance no SPEC, segundo GUTHAUS et al [9].

De acordo com GUTHAUS et al [9], apesar do SPEC ser uma referência para

processadores de propósito geral, não é uma boa opção para avaliar desempenho de

microprocessadores dedicados. A principal característica dessa classe de processadores

é a diversidade de domínios de aplicação, e, além disso, não existe uma padronização

para o conjunto de instruções das arquiteturas, como acontece nos processadores de uso

geral, o que torna difícil a utilização da maioria dos benchmarks. Então, surgiram

algumas pesquisas para desenvolver benchmarks para processadores especializados.

Umas das principais é a suíte desenvolvida e conhecida como EEMBC (EDN Embedded

Microprocessor Benchmark Consortium). Este benchmark reúne vários domínios de

aplicação e disponibiliza um conjunto de benchmarks para avaliar cinco domínios de

processadores embarcados.

Neste contexto, GUTHAUS et al [9], apresentam o MiBench, um benchmark

desenvolvido para microprocessadores de uso específico, que possui trinta e cinco

aplicações divididas em seis domínios de aplicações (categorias): Automotive and

Industrial Control, Consumer Devices, Office Automation, Networking, Security e

Telecommunications.

Conforme DIAS [5], o MiBench é um benchmark livre, sendo basicamente

implementado utilizando a linguagem de programação C. Todos os programas que

compõem o MiBench estão disponíveis em código fonte, sendo possível executar em

qualquer arquitetura de microprocessador que possua um compilador C.

No MiBench são consideradas as classes de instrução: controle, aritmética

inteira, aritmética em ponto flutuante e acesso à memória. Nas categorias

Telecommunications e Security todas as aplicações têm mais de 50% de operações

inteiras na ULA (Arithmetic Logic Unit). A categoria Consumer Devices tem mais

operações de acesso à memória por causa do processamento de grandes arquivos de

imagem e áudio. A categoria Office Automation faz uso intenso de operações de

controle e acesso à memória. Os programas dessa categoria usam muitas chamadas de

funções para bibliotecas de string para manipular os textos, o que causa o uso de várias

instruções de desvio. Além disso, os textos ocupam bastante espaço na memória, o que

requer muitas instruções de acesso à memória. A categoria Automotive and Industruial

Control faz o uso intenso de todas as classes de instrução devido a sua aplicabilidade e

por fim, a categoria Networking faz muito uso de operações aritméticas de inteiros,

pontos flutuantes e acesso à memória, devido as tabelas de IPs para roteamento em rede,

ordenação de dados e outros. Em comparação, o benchmark SPEC apresenta,

aproximadamente, a mesma distribuição de operações para todas as categorias.

A Tabela 2.1 apresenta o número de instruções executadas para cada aplicação

contida no MiBench, para cada conjunto de dados padrão. Os conjuntos de dados padrão

são divididos em duas classes para cada categoria do benchmark: conjunto de dados

reduzido e conjunto de dados expandido. O primeiro representa o uso moderado da

aplicação do benchmark, enquanto que o segundo representa a sobrecarga da aplicação.

Tabela 2.1. Número de instruções executadas pelas aplicações do MiBench [9]

De acordo com DIAS [5], as seis categorias do MiBench oferecem estruturas

de programas que permitem explorar as funcionalidades do benchmark e do compilador

para se ajustarem melhor a um determinado microprocessador.

A descrição da funcionalidade dos MiBench, específicos para sistemas

embarcados e de categorias diferentes são:

Aplicação Conjunto ReduzidoConjunto Expandido Aplicação Conjunto ReduzidoConjunto Expandidobasicmath 65.459.080 1.000.000.000 ispell 8.378.832 640.420.106bitcount 49.671.043 384.803.644 rsynth 57.872.434 85.005.687quicksort 43.604.903 595.400.120 stringsearch 158.646 38.960.051

susan.comers 1.062.891 586.076.156 blowfish.decode 52.400.008 737.920.623susan.edges 1.836.965 732.517.639 blowfish.encode 42.407.674 246.770.499

susan.smoothing 24.897.492 1.000.000.000 pgp.decode 85.006.293 259.293.845jpeg.decode 6.677.595 990.912.065 pgp.encode 38.960.650 824.946.344jpeg.encode 28.108.471 543.976.667 rijndael.decode 23.706.832 140.889.705

lame 175.190.457 544.057.733 rijndael.encode 3.679.378 24.910.267mad 25.501.771 272.657.564 sha 13.541.298 20.652.916

tiff2bw 34.003.565 697.493.266 crc32 52.839.894 61.659.073tiff2rgba 36.948.939 1.000.000.000 fft.inverse 65.667.015 377.253.252tiffdither 273.926.642 1.000.000.000 fft 52.625.918 143.263.412

tiffmedian 141.333.005 817.729.663 adpcm.decode 30.159.188 151.699.690typeset 23.395.912 84.170.256 adpcm.encode 37.692.050 832.956.169dijkstra 64.927.863 272.657.564 gsm.decode 23.868.371 548.023.092patricia 103.923.656 1.000.000.000 gsm.encode 55.361.308 472.171.446

ghostscript 286.770.117 673.391.179

• Dijkstra (Networking): é um algoritmo que calcula o menor caminho em

um grafo;

• Patrícia (Networking): é utilizado para representar tabelas de roteamento

em aplicações de redes de computadores;

• JPEG (Consumer Devices): é um compressor e descompressor de imagens

com o formato JPEG (Joint Photographic Experts Group);

• Lame (Consumer Devices): é um codificador de MP3 que suporta a

codificação da razão de bits constante, médio e variável;

• Mad (Consumer Devices): é um decodificador de áudio (MPEG - Moving

Picture Experts Group) de alta qualidade;

• Tiffmedian (Consumer Devices): é um algoritmo usado para reduzir o

número de cores em uma imagem;

• Tiffrgba (Consumer Devices): é um algoritmo que converte uma imagem

colorida no formato TIFF (Tagged Image File Format) em TIFF RGB (Red

Green Blue);

• Bitcount (Automotive and Industrial Control): é um algoritmo que testa a

habilidade de manipulação de bits do processador, contando o número de

bits em um vetor de inteiros;

• QuickSort (Automotive and Industrial Control): é um algoritmo que faz

ordenação de dados;

• Susan (Automotive and Industrial Control): é um algoritmo que faz o

reconhecimento de imagens através de suas bordas;

• Blowfish (Security): é um cifrador simétrico com chave variável de 32 até

448 bits, é ideal para encriptação doméstica;

• Rijndael (Security): é um algoritmo que faz criptografia com chaves do

tamanho de 128, 192 e 256 bits;

• SHA (Security): é um algoritmo que gera chaves de criptografia para troca

segura de dados e assinaturas digitais;

• ADPCM (Telecommunications): Adaptive Differential Pulse Code

Modulation é uma variação do PCM (Pulse Code Modulation). Uma

implementação frequente usa uma amostragem PCM de 16 bits e a

transforma em amostragem de 4 bits com uma compressão de 4:1;

• CRC32 (Telecommunications): é um algoritmo utilizado para detectar erros

na transmissão de dados e a redundância do CRC (Cyclic Redundancy

Check) em um arquivo;

• FFT (Telecommunications): é um algoritmo que executa a Transformação

de Fourier usado no tratamento de sinais digitais para encontrar as

freqüências em um sinal de entrada;

• GSM (Telecommunications): Global Standard for Mobile é um padrão para

a codificação e decodificação na Europa e em vários países. Usa uma

combinação de acesso múltiplo por divisão de tempo e frequência

(TDMA/FDMA) para codificar e decodificar streams de dados;

• Rsynth (Office Automation): é um sintetizador de texto para voz que inclui

várias partes de código de domínio público em um só programa;

• Stringsearch (Office Automation): é um algoritmo que faz a busca de uma

string em uma frase ou texto;

• Sphinx (Office Automation): é um decodificador de fala que pode trabalhar

com comandos de voz ou discursos.

Nesta monografia serão utilizados somente os seguintes algoritmos da área de

segurança presentes no MiBench: SHA, rijndael e Blowfish.

2.4. Ferramentas Utilizadas para Analisar o Consumo de Energia

Segundo FLINN [6], a utilidade de ferramentas que geram perfis de consumo de

energia deve estar diretamente relacionada em como associar de maneira definitiva o

custo de energia para cada evento de uma aplicação. E ainda segundo FLINN [6], a

atribuição dos custos de energia em detalhe, habilita a atenção para as áreas

problemáticas do código, o que fazem com que seja desejado mapear o consumo de

energia em nível de procedimentos.

Assim, o estudo das ferramentas de análise do consumo energético para software

são importantes, a fim de gerar melhorias para trechos de código mais custosos do ponto

de vista energético.

2.4.1. NePSim

LUO et al [14], sentindo a falta de um simulador de desempenho e consumo de

energia para processadores de rede, desenvolveram o NePSim, Network Processor

Simulator. O NePSim é um sistema integrado que inclui um simulador de arquitetura,

um mecanismo de verificação formal automática para testes e validação e um estimador

de consumo de processos de rede.

Em seu trabalho, LUO et al [14], focaram seus testes e fundamentos na

especificação IXP1200 da Intel, que é um processador amplamente utilizado como

modelo representativo em pesquisas sobre processadores de rede. Eles implementaram

então todas as funcionalidades do IXP1200, com excessão do StrongARM que é

responsável por apenas aproximadamente 11% do consumo total do processador, tendo

na simulação todos os componentes parametrizáveis.

Para se obter uma redução significativa do consumo de energia, LUO et al [14]

utilizaram a técnica de escalonamento dinâmico de voltagem (DVS, Dynamic Voltage

Scaling) que consiste em reduzir a freqüência e voltagem quando o processador tem

baixa atividade e aumentar esses indicadores quando o processamento é requerido.

No trabalho de LUO et al [14], o NePSim obteve bons resultados, com uma

redução de até 17% no consumo de energia em alguns benchmarks, com redução de

apenas 6% em desempenho.

2.4.2. PowerScope

A ferramenta PowerScope foi projetada e implementada por FLINN &

SATYANARAYANAN [6] e tem como objetivo criar um perfil do consumo de energia

de uma aplicação. Para mapear esse consumo, a ferramenta simula exatamente como a

CPU mapeia os ciclos de processamentos em processos e procedimentos.

O protótipo da PowerScope usa amostragem estatística para gerar perfis de uso

de energia de um sistema computacional. Para gerar tais perfis, levando em conta o

overhead, o processo ocorre em dois estágios. No primeiro estágio, o de coleta de

dados, é divido em dois componentes, o monitor de sistema e o monitor de energia,

onde o primeiro recolhe informações periodicamente do computador em análise,

enquanto o segundo executa sobre o computador de coleta de dados e armazena os

dados que são retirados pelo monitor de sistema. Nessa primeira fase os trabalhos

precisam estar sincronizados. No segundo estágio, da análise dos dados, o analisador de

energia usa os resultados do estágio anterior para gerar os perfis de energia, conforme se

observa na Figura 2.1.

Figura 2.1 Etapas de como o PowerScope gera um perfil de energia. (a) Coleta de

dados e (b) Análise dos dados [6].

FLINN & SATYANARAYANAN [6] fizeram um estudo de caso Com o uso do

PowerScope utilizando uma placa de vídeo, no qual se observou efeitos na redução do

consumo de energia da compressão de vídeo, tamanho de exibição, gerenciamento de

energia de rede e gerenciamento de energia de disco, a fim de mostrar a eficiência da

ferramenta para a redução do consumo de energia. Após a análise dos perfis de energia

gerados, foi observado que a maior quantidade de energia estava sendo utilizada por

dispositivos de hardware ociosos. Após configurações baseadas nos resultados obtidos

foi atingida uma redução de até 46% no consumo total de energia de uma aplicação de

vídeo, com certa redução na qualidade do vídeo.

2.4.3. JouleTrack

Em seu trabalho SINHA & CHANDRAKASAN [22], evitaram uma

caracterização do consumo de energia para cada instrução, usando então modelos para

prever o consumo de energia.

Utilizando uma fonte de energia para o microprocessador de forma

independente, e utilizando uma fonte fixa de tensão ligada a um multímetro, SINHA &

CHANDRAKASAN [22] realizaram testes com os microprocessadores StrongARM

AS-1100 e Hitachi SH4 a fim de observar variações no consumo da corrente por

instruções, conforme se observa na Figura 2.2.

Os resultados obtidos por SINHA & CHANDRAKASAN [22] com os testes

foram que o nível de variação do consumo de energia nas instruções é em torno de 38%,

em testes executando programas de benchmark foi observado que sobre diferentes

fontes de tensão e corrente a variação máxima de corrente era menor que 8%. Com estes

resultados SINHA & CHANDRAKASAN [22] concluíram que o consumo de energia

de um trecho de código é independente do código, depende apenas da tensão de

operação e frequência do processador.

Figura 2.2 Corrente consumida por instruções do processador ARM medidas em [22].

Assim, ao executar a mesma sub-rotina em diferentes frequências, mas com a

mesma tensão e medir o consumo de energia, pode-se observar uma curva de

crescimento linear com o tempo de execução e com a inclinação proporcional

equivalente à quantidade de vazamento, quantidade essa que apresentou valores

desviando ao máximo em 6% dos valores reais medidos.

Assim, SINHA & CHANDRAKASAN [22] desenvolveram o JouleTrack, que é

um sistema web onde o usuário envia o código em linguagem C e escolhe o modelo de

predição. Então o seu código é executado em um simulador ARM que produz

estatísticas como saída, como tempo de execução por exemplo. Estas estatísticas são

usadas como base para um mecanismo processar o perfil de energia e gerar um gráfico

usando as metodologias descritas por SINHA & CHANDRAKASAN [22], conforme se

observa na Figura 2.3.

Figura 2.3. Diagrama do JouleTrack

2.4.4. SNU Energy Explorer Web

Segundo LEE et al [12], as metodologias que utilizam computadores que

controlam multímetros ou conversores analógicos digitais para medir o consumo de

energia são metodologias não restritas a plataformas específicas, com certas limitações.

Então, LEE et al [12] propuseram uma ferramenta web para análise do consumo de

energia para sistemas embarcados, a SEE Web, ferramenta usada pela Universidade

Nacional de Seul.

Em [12], LEE et al desenvolveram um modelo de máquina de estados limitada

que isola o consumo de energia dinâmico da fuga de energia, com o uso da técnica de

medição por cycle-accurate. Além de também desenvolver um simulador de instruções.

Para utilizar a ferramenta é necessário acessar o endereço onde a ferramenta está

hospedada, em seguida configurar a arquitetura desejada, incluindo o clock do

processador, organização de cache e frequência de clock de memórias e enviar a

imagem binária da aplicação. Em seguida é recebida a análise do uso de energia da

aplicação, incluindo informações do consumo de energia para cada componente do

sistema.

2.4.5. Sim-Panalyzer

O Sim-Panalyzer é um simulador de consumo de energia baseado no simulador

de processadores SimpleScalar, descrito por AUSTIN et al [3]. Segundo AUSTIN et al

[3], o SimpleScalar é um simulador de arquitetura computacional que modela um

computador virtual com CPU, Cache e hierarquia de memória e com base nesse modelo

consegue simular programas reais executando sobre tais plataformas.

Sendo uma ferramenta baseada em um simulador de arquitetura detalhada, o

Sim-Panalyzer consegue modelar de forma detalhada tanto a potência dinâmica quanto

a de fuga. Para obter os resultados detalhados a simulação é feita separadamente,

gerando modelos de energia para os seguintes componentes: cache, caminho de dados e

unidade de execução, circuitos de clock e unidades de I/O (entrada e saída).

Os parâmetros para a geração dos perfis de cada componente do computador é

dado como entrada para o simulador Sim-Panalyzer que juntamente com o SimpleScalar

gera os padrões de consumo de energia. O anexo I mostra um exemplo de arquivo de

configuração usado pelo Sim-Panalyzer.

Segundo AUSTIN et al [2], o Sim-Panalyzer foi escrito originalmente com base

na arquitetura de instruções (ISA) da família de processadores ARM, obtendo

excelentes resultados em simulações deste tipo.

O resultado do consumo do Sim-Panalyzer é dividido em áreas específicas de

consumo do sistema embarcado, conforme Tabela 2.2. O Anexo II mostra como

exemplo a saída do simulador Sim-Panalyzer para o algoritmo SHA-1 tendo como

parâmetro o arquivo entrada1 de 100 KB, utilizado como parâmetro neste trabalho.

Tabela 2.2. Áreas de consumo apresentadas no Sim-panalyzer e os seus significados.

Áreas de Consumo Significado

aio Endereço da unidade de I/O

dio Dados da unidade I/O

irf Registradores de inteiro

fprf Registradores de ponto flutuante

il1 cache de instruções nível 1

dl1 cache de dados nível 1

dl2 cache de dados nível 2

itlb Tabela de instruções do TLB

dtlb Tabela de dados do TLB

btb Branch Target Buffer

bimod Previsor bimodal

ras Retorno da pilha de endereço

logic Circuito lógico aleatório

clock Relógio gerador de clock do sistema

uarch Microarquitetura, a maneira com que a ISA é implementada em um

processador

2.5. Técnicas para Medição Utilizadas no Trabalho

Para o estudo do consumo de energia dos algoritmos de criptografia presentes

no MiBench serão usados quatro métodos de medição do consumo de energia.

O primeiro método usa a descarga da bateria de um dispositivo para medir o

consumo energético do mesmo ao executar os algoritmos. O segundo método é teórico e

utiliza dados técnicos do processador e do algoritmo para obter um provável consumo

energético do processador ao executar o algoritmo. O terceiro método é baseado em

simulação, onde o simulador de consumo para sistemas embarcados Sim-Panalyzer é

utilizado para estimar o consumo dos algoritmos. E o último método é um experimento

feito utilizando um osciloscópio para medir a variação da corrente consumida pelo

processador ao executar os algoritmos estudados.

2.5.1. Metodologia 1: Medição de Descarga de Baterias

Para os primeiros testes o método de medição empregado é o mesmo usado por

COSTA [4], onde foi feita a estimativa de consumo a partir do nível de carga da bateria

antes e depois da execução de uma determinada aplicação. Como os algoritmos de

segurança são executados muito rapidamente no processador em questão, foi usado um

Shell script para que o mesmo fosse executado um determinado número de vezes e

verificar o nível de carga da bateria após esse número de execuções. Assim, o consumo

de energia de cada ciclo do algoritmo é calculado usando o consumo de energia total

dividido pela quantidade de ciclos que o algoritmo foi executado. Também é calculado

o tempo de execução de cada algoritmo dividindo o tempo de processo total pelo

número de execuções feita pelo script.

Os testes foram realizados em grupos de 50, 100, 200, 500 e 1000 execuções

para cada arquivo em cada algoritmo, e a medição do descarregamento da bateria é feita

utilizando a diferença do nível da carga da bateria, apresentada no arquivo

/proc/acpi/battery/BAT1/state do sistema operacional Linux, ao iniciar e ao terminar a

execução de cada algoritmo. Para a medição do tempo de processo utilizado pela bateria

foi utilizado o comando “time”, presente no Linux, ao executar o conjuunto de

execuções de cada algoritmo.

Para a execução desses conjuntos foi escrito um Shell Script para cada um dos

algoritmos em que são passados parâmetros como a quantidade de execuções e o

arquivo de entrada, que será criptografado ou calculado o hashing.

Visando obter uma estimativa um pouco mais precisa do consumo energético

do algoritmo foi medido, utilizando a mesma metodologia, o consumo do dispositivo

nas mesmas condições de funcionamento com o processador ocioso, para tal processo

foi escrito um Shell script que faz com que o processador fique ocioso por determinado

tempo.

O script utilizado segue o padrão:

#!/bin/sh FILENAME=/home/lealdo/Documentos/TCC/Algoritmos/blowfishT/Output/ResBF_$3_$2_$1.txt if [ $# -ne 3 ] then echo "O Shell Script deve ter como parametro de entrada o número de execuções e o arquivo de entrada" exit 1 fi getInfo() { echo "Execuction: #"$num >> $FILENAME echo "Present rate(mW) : " `cat /proc/acpi/battery/BAT1/state | grep "present rate" | awk '{ print $3 }'` >> $FILENAME echo "Present Voltage(mV): " `cat /proc/acpi/battery/BAT1/state | grep "present voltage" | awk '{print $3}'` >> $FILENAME echo "Remaining capacity(mWh): " `cat /proc/acpi/battery/BAT1/state | grep "remaining" | awk '{print $3}'` >> $FILENAME } getInfo for num in $(seq $1) do echo "Execuction: #"$num ./bf $3 $2 /home/lealdo/Documentos/TCC/Algoritmos/blowfishT/Output/out_$2_$num.txt 1234567890abcdeffedcba0987654321 done getInfo

Este script escrito possui como parâmetros o número de execuções a ser

executadas, o arquivo a ser criptografado e se o processo é de encriptação ou

decriptação. No script é definida a função getInfo que captura as informações da

bateria. A função básica do script é capturar as informações da bateria, em seguida

executar o algoritmo a quantidade de vezes passado como parâmetro, para o arquivo

usado como parâmetro de entrada, e em seguida capturar novamente as informações da

bateria. Por exemplo, para executar o programa Blowfish em encriptação 100 vezes

para o arquivo entrada1 o script é chamado da seguinte forma: ./scriptbf.sh 100

entrada1 E.

Após a aquisição destes dados foram feitos os seguintes cálculos:

1. ��çã� = ��çã��(�)

��çõ��

2. !�"#��çã�($ℎ) =&��'��(��()*)

��çõ��

3. !��"+��é-./($) =0��(1�� ()*)

��çã��*�(�

4. 2�+ê"./�é-./(4) = !��"+��é-./($)× 67��(��

5. !�"#��(8) = 2�+ê"./�é-./(4) × ��-��çã�(#)

2.5.2. Metodologia 2: Estimativa com Tempo de Execução e Características do Processador

Segundo os estudos de SINHA & CHANDRAKASAN [22] o consumo de

energia de um processador depende apenas da voltagem e da frequência do mesmo, já

que o consumo de corrente do processador varia muito pouco de acordo com as

diferentes instruções.

Seguindo tal conceito, a segunda metodologia de estimativa de consumo de

energia usada neste trabalho usa como base o número de ciclos de clock necessários

para a execução do algoritmo, juntamente com as características do processador usado.

Sendo assim, o número de ciclos de clock necessários para a execução de um algoritmo

está diretamente relacionado com o consumo energético, sendo atribuído a cada ciclo

uma pequena quantidade de energia consumida.

O custo básico para a execução de um algoritmo é dado pelos seguintes

cálculos:

1. ��-��çã�(#) = 9ú��(��á(��(&��)

<��(��((=>?@AB

B)

2. 2�+ê"./-��##/-��(4) = 6C(��( × !��"+�($)

3. D"��E./�"#�.-/(8) = 2�+ê"./-��##/-��(4)×

��-��çã�-�/FE��.+��(#)

Para a obtenção da quantidade de ciclos de clock foi utilizada a função

“clock_t” da linguagem C ao ser executado o código. A voltagem, a velocidade e

características do processador podem ser obtidas através do site do fabricante do

mesmo.

Os dados sobre a amperagem máxima e faixa de voltagem de operação dos

processadores podem ser obtidos nos datasheet dos mesmos, geralmente fornecidos

pelo fabricante.

2.5.3. Metodologia 3: Simulação usando o Sim-Panalyzer

A terceira metodologia empregada foi o uso do simulador de consumo de

energia para sistemas embarcados Sim-Panalyzer, que já foi devidamente explicado na

seção 2.4.5.

A aplicação do Sim-Panalyzer é feita de forma simples, necessitando apenas

executar o simulador passando como parâmetro a arquitetura a ser simulada, juntamente

com as características do sistema, e o programa compilado para a arquitetura ARM,

juntamente com os parâmetros para a execução do mesmo.

Para se obter o consumo total do algoritmo é necessário apenas somar consumo

energético de cada componente simulado pelo Sim-Panalyzer, obtendo então o consumo

geral do dispositivo simulado.

2.5.4. Metodologia 4: Experimental com Osciloscópio

Os processadores atuais, para o seu funcionamento, utilizam uma voltagem fixa,

chamada de Vcore neste trabalho. Assim, a forma de se obter um gráfico do real consumo

energético de um processador é medir a corrente drenada pelo mesmo em função do

tempo, e este é o principal objetivo desta quarta metodologia.

Devido à dificuldade de acesso aos esquemas elétrico do hardware da placa mãe

disponível para teste e devido a propriedade intelectual, ficou impossibilitada a medição

do consumo diretamente nos pinos alimentadores do processador, impossibilitando

então a obtenção do gráfico de consumo mais real possível.

Após a inviabilidade da proposta inicial, esta quarta metodologia utilizada no

trabalho foi alterada e assumiu como base a medição da corrente total consumida pelo

conector ATX12V [1] da placa mãe, que fornece energia para os reguladores de tensão

que por sua vez fornecem energia para o processador. Ao calcular o consumo do

processador deve ser considerado o fato de os sistemas reguladores de voltagem

apresentam eficiência média de 80%, segundo SCHUELLEIN [7].

A medição é feita inserindo um resistor shunt de valor conhecido em série entre

a fonte de alimentação e a placa mãe e usando um osciloscópio é medida a variação de

voltagem antes e depois do resistor, conforme esquema da Figura 2.4. Com este circuito

montado é possível então calcular a corrente consumida pela placa mãe, e

consequentemente a sua potência consumida, através das seguintes fórmulas:

!��"+�($) = 6/�./çã�-�6�F+/E��(6)

G�#.#+ê"./(Hℎ�)

2�+ê"./(4) = !��"+�($). 6�F+/E��(6)

Figura 2.4. Esquema utilizado para as medições com a metodologia 4.

3. Testes, Resultados e Análise

No presente trabalho foram realizados testes aplicando as metodologias

apresentadas na seção 2.5 usando os algoritmos SHA, rijndael (melhor conhecido como

AES) e Blowfish. Os arquivos de entrada e chaves usados como parâmetro são

apresentados nas Tabelas 3.1 e 3.2, respectivamente. Devido a problemas de compilação

o algoritmo rijndael somente foi aplicado neste trabalho usadando o Sim-Panalyzer

(metodologia 3).

Tabela 3.1. Arquivos usados como parâmetro para os testes.

Nome Tamanho

entrada1 100 KB

entrada2 500 KB

Money.mp3 4,5 MB

vídeo.MPG 46,8 MB

Tabela 3.2. Chaves usadas como parâmetro para os testes.

Algoritmo Nome da Chave Tamanho

Blowfish

Chave1 32 bits

Chave2 256 bits

Chave3 448 bits

Rijndael (AES)

Chave1 128 bits

Chave2 192 bits

Chave3 256 ts

3.1. Resultados para Medição de Descarga de Baterias em Notebook

A primeira metodologia de teste de consumo dos algoritmos foi aplicada

utilizado um notebook Toshiba modelo T135 – S1305, com processador Intel Pentium

SU4100, 3GB de memória RAM DDR3, HDD de 320GB e tela de 13,3’, executando o

sistema operacional Linux em sua distribuição Ubuntu 9.10.

Devido dispositivo possuir um processador da série Intel ULV (Ultra Low

Voltage, em inglês Voltagem Ultra Baixa) é esperado que ele possua o menor consumo

de energia dentre os dispositivos testados. Os resultados de consumo de energia

apresentados nesta seção engloba todo o dispositivo usado, incluindo dispositivo de

rede sem fio, monitor e memórias.

3.1.1 Algoritmo SHA-1

Os resultados dos testes com o algoritmo SHA são apresentados na Tabela 3.3,

em que se observa o correto funcionamento do dispositivo usado para testes, aliado a

um baixo consumo médio, de apenas 12,2 W.

Tabela 3.3. Resultados da execução do algoritmo SHA usando a primeira metodologia.

Entrada Tempo (s) Energia

Consumida (J) Potência

Média (W) Energia

Excedida* (J)

entrada1 0,061 0,724 11,904 0,121

entrada2 0,079 0,930 11,730 0,144

Money.mp3 0,234 2,619 11,216 0,303

vídeo.MPG 1,375 19,157 13,935 5,521

3.1.2 Algoritmo Blowfish

Durante os testes com o algoritmo Blowfish não foi observada variação

considerável de potência média consumida com mudança das chaves, ou de operações,

de encriptação (E) para decriptação (D). Porém esta variação de potência foi

significativa com o aumento do tamanho do arquivo passado como parâmetro, sendo

obtido uma média de consumo de 12,3 W para os arquivos entrada1 e entrada2 e 15,8

W para os arquivos Money.MP3 e vídeo.MPG.

Com a mudança do tamanho da chave também não foi observada nenhuma

mudança no tempo de execução, levando à conclusão de que não há ligação entre o

tamanho da chave e o consumo de energia do algoritmo. Este resultado já tinha sido

obtido e observado pelo autor de [8], via simulação.

Os dados obtidos com os testes usando o algoritmo Blowfish para as chaves

chave1 , chave2 e chave3 são apresentado nas tabelas 3.4 , 3.5 e 3.6, respectivamente.

Tabela 3.4. Resultados da execução do algoritmo Blowfish (chave de 32 bits) usando a

metodologia 1.

Entrada Tempo (s)

Energia Consumida (J)

Potência Média (W)

Energia Excedida* (J)

E

entrada1 0,022 0,249 11,546 0,035

entrada2 0,070 0,918 13,043 0,220

Money.mp3 0,505 7,442 14,734 2,432

vídeo.MPG 4,917 72,382 14,721 23,611

D

entrada1 0,021 0,283 13,313 0,072

entrada2 0,068 0,980 14,369 0,303

Money.mp3 0,492 7,014 14,245 2,130

vídeo.MPG 4,926 71,474 14,511 22,619


metodologia 1.

Entrada Tempo (s)

Energia Consumida (J)

Potência Média (W)

Energia Excedida* (J)

E

entrada1 0,023 0,246 10,641 0,017

entrada2 0,070 0,933 13,373 0,241

Money.mp3 0,488 8,211 16,829 3,372

vídeo.MPG 4,896 84,370 17,233 35,810

D

entrada1 0,019 0,194 10,264 0,007

entrada2 0,070 1,003 14,253 0,305

Money.mp3 0,497 8,491 17,068 3,557

vídeo.MPG 4,962 82,814 16,690 33,59734


metodologia 1.

Entrada Tempo (s) Energia

Consumida (J)

Potência

Média (W)

Energia Excedida*

(J)

E

entrada1 0,022 0,238 10,853 0,020

entrada2 0,071 0,809 11,379 0,104

Money.mp3

0,487 7,963 16,351 3,132

vídeo.MPG 4,786 74,066 15,476 26,595

D

entrada1 0,021 0,237 11,472 0,032

entrada2 0,073 0,953 13,040 0,228

Money.mp3

0,488 7,799 15,969 2,955

vídeo.MPG 4,771 75,686 15,865 28,368

3.2. Resultados para Estimativa de Consumo com Base nas Características do

Processador

A segunda metodologia usada no trabalho usa como base para cálculo o

processador Intel Celeron 2.2 GHz. No datasheet fornecido pela Intel para o Celeron 2.2

GHz [10] a voltagem de operação do mesmo é de 1.10 V admitindo uma corrente

máxima de 35 A, o que resulta em uma potência máxima do processador de 38,5 W.

3.2.1. Algoritmo SHA-1

O algoritmo SHA-1 apresentou um gasto médio de energia por byte de 0,32 µJ

por byte para o processo de geração de hash, este valor não apresentou variação acima

de 10% em relação à média para nenhum cálculo. Os resultados sobre número de ciclos

necessários, tempo de execução e energia gasta são apresentados na tabela 3.7.

Tabela 3.7. Resultados da estimativa de consumo para algoritmo SHA.

Entradas Ciclos Tempo (s) Energia (J)

entrada1 2000000 0,000909 0,035

entrada2 10000000 0,004545 0,175

Money.mp3 80000000 0,036364 1,4

vídeo.MPG 860000000 0,390909 15,05

3.2.2. Algoritmo Blowfish

Os resultados para o algoritmo Blowfish foram os mesmos, para qualquer

tamanho da chave ou de processos de encriptação ou decriptação, já que os resultados

para o número de clock obtidos foram os mesmos independentes destes parâmetros. O

gasto médio por byte para o processo variou de acordo com o tamanho da entrada,

apresentando uma média de 0,85 µJ para as entradas menores (entrada1 e entrada2) e

uma média de 1,59 µJ para as entradas maiores (Money.mp3 e vídeo.MPG). As

estimativas de consumo do algoritmo Blowfish para as entradas simuladas foram as

apresentadas na Tabela 3.8 .

Tabela 3.8. Resultados da estimativa de consumo para algoritmo Blowfish.

Entradas Ciclos Tempo (s) Energia (J)

entrada1 4000000 0,001818 0,07

entrada2 30000000 0,013636 0,525

Money.mp3 430000000 0,195455 7,525

vídeo.MPG 4440000000 2,018182 77,7

3.3. Resultados usando o Simulador Sim-Panalyzer

Nesta terceira metodologia empregada será usado o simulador de consumo de

energia Sim-Panalyzer, e conforme descrito na seção 2.5.3 é necessário como um dos

parâmetros as características do processador a ser simulado durante o teste. Para este

trabalho foi utilizado a configuração padrão presente no Sim-Panalyzer, apresentada no

Anexo I.

Esta metodologia será aplicada apenas aos arquivos entrada1 e entrada2, pois as

o processo de simulação durava horas para arquivos maiores que 1 MB no dispositivo

que executava a simulação.

O dispositivo simulado apresentou uma potência média de 4 W, a menor dentre

os métodos. Este baixo consumo é devido à simplicidade do dispositivo, o que resulta

em um desempenho muito baixo, resultando em um tempo de execução grande e em

consequência um maior consumo energético.


Os resultados para a geração do hash usando o algoritmo SHA é apresentado na

Tabela 3.9, e apresenta um tempo de execução cerca de cem vezes maior que os outros

dispositivos usados no trabalho.

Tabela 3.9. Resultados da simulação de consumo para algoritmo SHA.

Entrada Tempo (s) Nº Instruções Potência Média (W) Energia (J)

entrada1 25 4451010 4,10 102,61

entrada2 124 22221949 4,13 511,87


Os testes com o algoritmo Blowfish apresentaram resultados com menor

desempenho ainda, se comparado aos outros dispositivos testados, demandando 634,95

Joules para encriptar um arquivo de 100 KB, levando 164 s para executar tal tarefa.

Outro resultado a ser observado no algoritmo Blowfish é o fato de chaves de

tamanho diferente não alterarem os tempos de execução do algoritmo. Os dados das

simulações com o algoritmo Blowfish podem ser vistos na tabela 3.10.

Tabela 3.10. Resultados da simulação de consumo para algoritmo Blowfish.

Chave Operação Entrada Nº Instruções Tempo

(s) Energia (J)

Chave 1

E entrada1 17351676 164 634,9424

D entrada1 17349111 163 649,718

E entrada 2 86042866 798 3083,9508

D entrada 2 86030231 798 3181,3068

Chave 2

E entrada1 17352420 164 640,7808

D entrada1 17349983 165 653,3175

E entrada 2 86043570 799 3120,8141

D entrada 2 86031010 795 3144,702

Chave 3

E entrada1 17353136 164 639,7312

D entrada1 17350699 163 646,295

E entrada 2 86044319 799 3105,2336

D entrada 2 86031608 797 3150,4613

Um gráfico comparativo do consumo de energia com a variação das chaves para

o algoritmo Blowfish pode ser observado na Figura 3.1, e a estimativa da potência

média consumida por cada componente do sistema simulado pode ser observada na

tabela 3.11.

Figura 3.1. Gráfico do custo energético para execução do algoritmo Blowfish.

0,00

500,00

1000,00

1500,00

2000,00

2500,00

3000,00

3500,00

Ch

ave

1

Ch

ave

2

Ch

ave

3

Ch

ave

1

Ch

ave

2

Ch

ave

3

Ch

ave

1

Ch

ave

2

Ch

ave

3

Ch

ave

1

Ch

ave

2

Ch

ave

3

Encriptação

Entrada1

Decriptação

Entrada1

Encriptação

Entrada2

Decriptação

Entrada2

Energia (J)

Energia (J)

Tabela 3.11. Potência simulada ao executar o algoritmo Blowfish.

3.3.3. Algoritmo Rijndael

Ao simular a execução do algoritmo rijndael foi observado que a quantidade de

instruções para a operação de decriptação é em média 95,56% o número de instruções

da encriptação, e por este motivo, o tempo gasto na decriptação é em media 93,16% do

tempo gasto na encriptação. Também é observado que a diferença entre o tempo de

execução e o número de instruções executadas da entrada1 para a entrada 2 é em media

502,56% do tempo para a entrada1, que é um resultado esperado, já que o tamanho da

entrada2 é cinco vezes o tamanho da entrada1. Os dados da aplicação da metodologia 3

no algoritmo rijndael pode ser observado na Tabela 3.12.

Com os resultados da simulação do algoritmo rijndael também foi observado

que com o aumento do tamanho da chave é também aumentado o número de instruções

a serem executadas, e consequentemente o tempo de execução e o consumo de energia.

Tal aumento do consumo energético com a mudança da chave pode ser melhor

observado na figura 3.2 e a proporção deste aumento é apresentada na Tabela 3.13.

Área do Sistema

Encriptação (W)

Decriptação (W)

Diferença entre E/D

aio 0,2645 0,2562 -3%

dio 0,8165 0,9045 11%

irf 0,1334 0,1340 0%

fprf 0,0000 0,0000 0%

il1 0,4513 0,4467 -1%

dl1 0,2941 0,2919 -1%

dl2 0,2941 0,2919 -1%

itlb 0,0172 0,0170 -1%

dtlb 0,0185 0,0184 -1%

btb 0,5348 0,5390 1%

bimod 0,0156 0,0157 1%

ras 0,0000 0,0000 0%

logic 0,0000 0,0000 0%

clock 0,1808 0,1808 0%

uarch 0,8688 0,8717 0%

TOTAL (W) 3,8894 3,9676 2%

Tabela 3.12. Resultados da simulação de consumo para algoritmo rijndael.

Operação Entrada Nº Instruções Tempo (s) Energia (J)

Chave 1

E entrada1 8211594 66 264,67 D entrada1 7801604 60 238,68 E entrada 2 41033638 329 1329,95 D entrada 2 38986239 299 1159,58

Chave 2


Chave 3


Figura 3.2. Gráfico do custo energético para execução do algoritmo rijndael.

Tabela 3.13. Aumento de consumo energético de acordo com o tamanho da chave.

Algoritmo Chave1 para

Chave2 Chave1 para

Chave3 Chave2 para

Chave3 Entrada1 E 8,12% 19,70% 10,71% Entrada1 D 7,28% 20,11% 11,95% Entrada2 E 7,29% 18,98% 10,89% Entrada2 D 10,79% 19,86% 8,19%

A estimativa da potência média consumida por cada componente do sistema

simulado para o algoritmo rijndael pode ser observada na tabela 3.14.

0,00

200,00

400,00

600,00

800,00

1000,00

1200,00

1400,00

1600,00

1800,00

Ch

av

e1

Ch

av

e2

Ch

av

e3

Ch

av

e1

Ch

av

e2

Ch

av

e3

Ch

av

e1

Ch

av

e2

Ch

av

e3

Ch

av

e1

Ch

av

e2

Ch

av

e3

Encriptação

Entrada1

Decriptação

Entrada1

Encriptação

Entrada2

Decriptação

Entrada2

Consumo de Energia do Rijndael

Energia (J)

Tabela 3.14. Potência simulada ao executar o algoritmo rijndael.

Área do Sistema Encriptação (W) Decriptação (W) Diferença entre E/D aio 0,2577 0,2611 1,29% dio 0,8952 0,7424 -17,07% irf 0,1374 0,1458 6,15%

fprf 0,0000 0,0000 0,00% il1 0,4628 0,4656 0,59% dl1 0,2869 0,2873 0,13% dl2 0,2869 0,2873 0,13% itlb 0,0179 0,0178 -0,37% dtlb 0,0181 0,0181 0,09% btb 0,5081 0,5101 0,38%

bimod 0,0148 0,0149 0,34% ras 0,0000 0,0000 0,00%

logic 0,0000 0,0000 0,00% clock 0,1808 0,1808 0,00% uarch 0,9518 0,9663 1,53%

TOTAL (W) 4,0185 3,8975 -3,01%

3.4. Resultados para Experimento usando o Osciloscópio

A quarta metodologia aplicada neste trabalho foi aplicada em um computador

com processador Intel Celeron 2.2 Ghz, 512 Mb de memória RAM, HD de 40 Gb e

placa mãe Foxconn 650M02-G-6.

Para a aplicação do método foram usados três resistores em paralelo, com 1 ohm

de resistência e 20w de potência cada, resultando em um resistor equivalente de 0,333

ohms e 60 w de potência. Este conjunto de resistores foi ligado em série no cabo de

alimentação da placa mãe, conforme descrito em 2.5.4 e mostrado na figura 3.3. Após a

montagem foi conectado cada um dos canais do osciloscópio da marca Owon, modelo

PDS5022S, nas extremidades do conjunto de resistores para medir a queda de voltagem

provocada pela passagem de corrente.

Figura 3.3. Resistores ligado em série com o fio de alimentação da placa mãe.

Para efeito comparativo, inicialmente foi medido o consumo do sistema ocioso

que apresentava uma queda de 0,5V entre as extremidades do resistor, que significa uma

passagem de corrente de 1,5A e uma potência de 17,25W para o sistema ocioso. Com o

osciloscópio conectado também foi observado um aumento significativo do consumo de

energia com a movimentação do mouse, que resultou em uma queda de 1V entre as

extremidades do resistor, que resulta em uma corrente de 3A e uma potência de 33W.

A voltagem medida na entrada do conjunto de resistores com o sistema ocioso

foi de 12V, com uma queda média da mesma para 11,68V com o sistema com carga.

Estes valores foram usados como parâmetros para o cálculo do consumo de energia

nesta metodologia.


Para o algoritmo SHA-1 foram observados dois diferentes patamares de

características, sendo divididas entre as entradas pequenas (entrada1 e entrada2) e as

entradas grandes (Money.mp3 e vídeo.MPG). Para as entradas pequenas a potência

média usada pelo processador foi de 30,9 W, tendo um aumento para a média de

49,44W ao executarem o mesmo algoritmo para as entradas grandes.

O consumo por byte medido para o algoritmo SHA-1 foi de 12,07 µJ para a

entrada de 100 KB, 3,02 µJ para a entrada de 500 KB e em média 1,30 µJ para os

arquivos de 4,5 MB e 46,8 MB, que não apresentou variação significativa do consumo

por byte.

Em testes iniciais foram usados os dois canais do osciloscópio um na entrada e

outro na saída da corrente no conjunto de resistores, representados pelo o gráfico

amarelo e o vermelho, respectivamente, na figura 3.4. O gráfico apresentado em verde é

dado pela subtração das voltagens de entrada pela de saída, resultando no gráfico de

queda da voltagem. Porém para efeito de cálculo do consumo, o gráfico da subtração é

semelhante ao gráfico de saída, já que o gráfico de entrada tem pouca variação durante a

execução. Assim foram feitas novas medições usando apenas a voltagem de saída do

conjunto de resistores buscando um gráfico mais nítido da queda de voltagem. Este

gráfico juntamente com os dados relativo ao consumo de energia são encontrados na

tabela 3.15.

(a) (b)

(c) (d)

Figura 3.4: Gráficos da variação da voltagem ao executar o algoritmo SHA-1 para as

entradas: (a) entrada1, (b) entrada2, (c) Money.mp3 e (d) vídeo.MPG.

Tabela 3.15. Gráficos obtidos ao executar o algoritmo SHA e dados da interpretação dos

mesmos.

SHA-1

Arquivo entrada1 Tempo entre execuções 0,16 s Tempo por execução 0,04 s Variação de Voltagem 0,96 V Potência Média durante execução

30,90 W

Consumo 1,24 J

SHA-1


30,90 W

Consumo 1,55 J

SHA-1

Arquivo Money.mp3 Tempo entre execuções 0,2 s Tempo por execução 0,13 s Variação de Voltagem 1,6 V Potência Média durante execução

48,43 W

Consumo 6,30 J

SHA-1

Arquivo vídeo.MPG Tempo entre execuções 0,25 s Tempo por execução 1,25 s Variação de Voltagem 1,68 V Potência Média durante execução

50,45 W

Consumo 63,06 J


Para o algoritmo Blowfish foi observado um pequeno aumento da potência

média usada pelo processador com o aumento do tamanho da entrada, porém essa

diferença não supera 10% do valor médio, que é de 50W de potência.

O consumo por byte medido para os processos de encriptação e decriptação,

inclusive para diferentes chaves, apresentam valores muito próximos, em média 9,25 µJ

por byte.

Para os testes com o algoritmo Blowfish foram feitos os mesmos processos

utilizados para o algoritmo SHA-1. As Figuras e Tabelas semelhantes às apresentadas

para o algoritmo SHA-1 são classificadas por categoria na Tabela 3.16.

Tabela 3.16. Guia para as figuras e tabelas com os resultados dos testes com o algoritmo

Blowfish.

Chave Processo Figura Tabela

Chave1 – 32 bits Encriptação 3.5 3.17

Decriptação 3.6 3.18





(a) (b)

(c) (d)

Figura 3.5. Gráficos da variação da voltagem ao executar uma encriptação com o

algoritmo Blowfish usando chave de 32 bits para as entradas: (a) entrada1, (b)

entrada2, (c) Money.mp3 e (d) vídeo.MPG.

(a) (b)

(c) (d)

Figura 3.6. Gráficos da variação da voltagem ao executar uma decriptação com o



Tabela 3.17. Gráficos obtidos ao executar o algoritmo Blowfish no processo de

encriptação usando chave de 32 bits e dados da interpretação dos mesmos.

Blowfish – Encriptação – Chave 32 bits


45,33 W

Consumo 1,81 J



49,45 W

Consumo 4,45 J



51,45 W

Consumo 30,87 J


Arquivo vídeo.MPG Tempo entre execuções 0,5 s Tempo por execução 5 s Variação de Voltagem 1,84 V Potência Média durante execução

54,37 W

Consumo 271,86 J


decriptação usando chave de 32 bits e dados da interpretação dos mesmos.

Blowfish – Decriptação – Chave 32 bits


45,33 W

Consumo 1,81 J



49,45 W

Consumo 3,96 J



51,45 W

Consumo 25,72 J



54,37 W

Consumo 277,29 J

(a) (b)

(c) (d)




(a) (b)

(c) (d)








45,33 W

Consumo 1,81 J



49,45 W

Consumo 3,96 J



51,45 W

Consumo 25,72 J



54,37 W

Consumo 282,73 J

(a) (b)

(c) (d)




(a) (b)

(c) (d)








45,33 W

Consumo 1,81 J



49,45 W

Consumo 3,96 J



51,45 W

Consumo 25,72 J



54,37 W

Consumo 282,73 J





45,33 W

Consumo 1,81 J



49,45 W

Consumo 3,96 J



51,45 W

Consumo 28,29 J



54,37 W

Consumo 277,29 J

3.5.Comparativo Entre os Métodos

No presente trabalho foram aplicados diferentes método para medição,

simulação e estimação do consumo de energia para os algoritmos SHA-1, Blowfish e

rijndael. Os resultados do consumo (em Joules) da aplicação desses métodos são

apresentados na Tabela 3.24.

Para efeito comparativo, também são apresentadas as Tabelas 2.23, 2.25 e 2.26

que apresentam, respectivamente, um comparativo entre a potência média, o consumo

em µJ por byte do arquivo de entrada e o tempo de execução para cada metodologia

usada no trabalho.

Os resultados encontrados foram esperados, com um melhor desempenho geral

sendo apresentado pelo notebook (testado na metodologia 1), seguido pela estimativa do

consumo do processador (metodologia 2), em seqüência o consumo real do mesmo

dispositivo simulado na metodologia 2 (medido usando a metodologia 4) e finalizando

com o consumo simulado pela ferramenta Sim-Panalyzer. A ferramenta apresentou o

maior consumo dentre os dispositivos, pois apesar de possuir a menor potência,

apresentava um desempenho sofrível para os arquivos usados no trabalho, sendo

necessário muito tempo para a execução dos algoritmos.

Tabela 3.23. Comparativo da potência média (em W) consumida em cada metodologia

usada no trabalho.

Algoritmo Arquivo Metodologia 1 Metodologia 2 Metodologia 3 Metodologia 4

entrada1 11,904 38,5 4,1 30,9

entrada2 11,73 38,5 4,13 30,9

Money.mp3 11,216 38,5 48,43

vídeo.MPG 13,935 38,5 50,45

entrada1 11,35 38,5 45,33

entrada2 13,24 38,5 49,45

Money.mp3 15,87 38,5 NA 51,45

vídeo.MPG 15,75 38,5 NA 54,37

entrada1 11,35 38,5 45,33

entrada2 13,24 38,5 49,45

Money.mp3 15,87 38,5 51,45

vídeo.MPG 15,75 38,5 54,37

Rijndael Encriptação 4,02

Rijndael Decriptação 3,9NANA NA

3,97

3,89

NA

NA

NA

Blow fish Decriptação

SHA

Blow fish Encriptação

Tabela 3.24. Comparativo do consumo em Joules entre as diferentes metodologias.

Algoritmo Chave Arquivo Metodologia 1 Metodologia 2 Metodologia 3 Metodologia 4

entrada1 0,72 0,035 102,61 1,24

entrada2 0,93 0,175 511,87 1,55

Money.mp3 2,62 1,4 NA 6,30

vídeo.MPG 19,16 15,05 NA 63,06

entrada1 0,25 0,07 634,94 1,81

entrada2 0,92 0,525 3083,95 4,45

Money.mp3 7,44 7,525 NA 30,87

vídeo.MPG 72,38 77,7 NA 271,86

entrada1 0,283 0,07 649,72 1,81

entrada2 0,98 0,525 3181,31 3,96

Money.mp3 7,014 7,525 NA 25,72

vídeo.MPG 71,47 77,7 NA 277,29

entrada1 0,246 0,07 640,78 1,81

entrada2 0,933 0,525 3120,81 3,96

Money.mp3 8,211 7,525 NA 25,72

vídeo.MPG 84,37 77,7 NA 282,73

entrada1 0,194 0,07 653,32 1,81

entrada2 1,003 0,525 3144,7 3,96

Money.mp3 8,491 7,525 NA 25,72

vídeo.MPG 82,814 77,7 NA 282,73

entrada1 0,238 0,07 639,73 1,81

entrada2 0,809 0,525 3105,23 3,96

Money.mp3 7,963 7,525 NA 25,72

vídeo.MPG 74,066 77,7 NA 282,73

entrada1 0,237 0,07 646,3 1,81

entrada2 0,953 0,525 3150,46 3,96

Money.mp3 7,799 7,525 NA 28,29

vídeo.MPG 75,689 77,7 NA 277,29

entrada1 NA NA 264,67 NA












Rijndael Encriptação

Chave1

Rijndael Decriptação

Chave1


Chave3


Chave2


Chave2


Chave3

SHA NA

Blowfish Encriptação

Chave1

Blowfish Decriptação

Chave1


Chave2


Chave2


Chave3


Chave3

Tabela 3.25. Comparativo do consumo (em µJ) dos algoritmos estudados por byte do

arquivo de entrada.


entrada1 7,03 0,34 1002,05 12,07

entrada2 1,82 0,34 999,75 3,02

Money.mp3 0,56 0,30 NA 1,33

vídeo.MPG 0,39 0,31 NA 1,29

entrada1 2,44 0,68 6200,59 17,71

entrada2 1,80 1,03 6023,34 8,69

Money.mp3 1,58 1,59 NA 6,54

vídeo.MPG 1,47 1,58 NA 5,54

entrada1 2,76 0,68 6344,92 17,71

entrada2 1,91 1,03 6213,50 7,73

Money.mp3 1,49 1,59 NA 5,45

vídeo.MPG 1,46 1,58 NA 5,65

entrada1 2,40 0,68 6257,62 17,71

entrada2 1,82 1,03 6095,33 7,73

Money.mp3 1,74 1,59 NA 5,45

vídeo.MPG 1,72 1,58 NA 5,76

entrada1 1,89 0,68 6380,08 17,71

entrada2 1,96 1,03 6141,99 7,73

Money.mp3 1,80 1,59 NA 5,45

vídeo.MPG 1,69 1,58 NA 5,76

entrada1 2,32 0,68 6247,36 17,71

entrada2 1,58 1,03 6064,90 7,73

Money.mp3 1,69 1,59 NA 5,45

vídeo.MPG 1,51 1,58 NA 5,76

entrada1 2,31 0,68 6311,52 17,71

entrada2 1,86 1,03 6153,24 7,73

Money.mp3 1,65 1,59 NA 6,00

vídeo.MPG 1,54 1,58 NA 5,65












entrada2 NA NA 2714,63 NARijndael Decriptação Chave3

Rijndael Encriptação Chave2

Rijndael Decriptação Chave2


Blowfish Decriptação Chave3



Blowfish Encriptação Chave2



SHA NA



Tabela 3.26. Comparativo do tempo de execução (em s) obtidos nas diferentes

metodologias aplicadas.


SHA NA

entrada1 0,061 0,001 25,000 0,040

entrada2 0,079 0,005 124,000 0,050

Money.mp3 0,234 0,036 NA 0,130

vídeo.MPG 1,375 0,391 NA 1,250


Chave1

entrada1 0,022 0,002 164,000 0,040

entrada2 0,070 0,014 798,000 0,090

Money.mp3 0,505 0,195 NA 0,600

vídeo.MPG 4,917 2,018 NA 5,000


Chave1

entrada1 0,021 NA 163,000 0,040

entrada2 0,068 NA 798,000 0,080

Money.mp3 0,492 NA NA 0,500

vídeo.MPG 4,926 NA NA 5,100


Chave2

entrada1 0,023 NA 164,000 0,040

entrada2 0,070 NA 799,000 0,080




Chave2

entrada1 0,019 NA 165,000 0,040

entrada2 0,070 NA 795,000 0,080




Chave3

entrada1 0,022 NA 164,000 0,040

entrada2 0,071 NA 799,000 0,080




Chave3

entrada1 0,021 NA 163,000 0,040

entrada2 0,073 NA 797,000 0,080




Chave1 entrada1 NA NA 66,000 NA

















4. Conclusões

Com a finalização do trabalho, foi possível concluir a real importância do

consumo energético, visto o grande aumento de consumo com dispositivo em

processamento, como mostrado na seção 3.4 uma simples movimentação do mouse

pode causar um aumento de até 90% do consumo em relação ao sistema ocioso. Como

já apresentado o consumo de energia é um fator importante na viabilidade dos projetos

de sistemas embarcados, além da consciência ambiental globalmente difundida, que faz

com que sejam cada vez mais necessárias medidas de redução do consumo de energia.

Para a apresentação deste tralho foram estudados a título de conceituação os

sistemas embarcados, conceitos de segurança de dados, o algoritmo MiBench e diversas

metodologias e ferramentas para medição do consumo de energia de dispositivos

computacionais. Estes estudos resultaram em um embasamento necessário para a

aplicação das metodologias e a análise dos resultados.

As metodologias empregadas buscaram abranger diferentes métodos de

medição para dispositivos distintos, resultando também em diversos padrões de

consumo. Os resultados apresentados pelas diferentes metodologias são apresentados a

seguir:

• A primeira metodologia foi aplicada em um notebook desenvolvido com

tecnologias de baixo consumo, que resultaram no dispositivo com melhor

relação entre desempenho e consumo de energia.

• A segunda metodologia, puramente teórica é possivelmente a mais falha, já

que os dados de consumo do processador e a quantidade de ciclos

necessários para a execução de um algoritmo são calculados com base

puramente teórica.

• A terceira metodologia apresenta como resultado da simulação um

detalhado relatório do consumo para os parâmetros usados, porém como foi

usado o processador com configurações padrão do Sim-Panalyzer a

arquitetura simples do mesmo fez com que apesar da menor potência

utilizada, apresentasse o pior desempenho entre as metodologias simuladas,

já que o tempo de execução foi muito grande.

• A quarta metodologia empregada apresenta uma medição experimental e

real do consumo energético da placa mãe contendo um processador de

desktop. Nesta metodologia são observados os picos de consumo de cada

algoritmo e o real tempo de execução dos mesmos. Esta foi a metodologia

que teve os resultados mais próximos do consumo real do processador.

Diante de tais conclusões podem ser sugeridos trabalhos futuros como os

seguintes:

• Identificar os trechos de códigos que mais consomem energia, sendo

possível analisar modificações para os códigos a fim de reduzir o consumo energético

dos mesmos;

• Aplicar as metodologias empregadas neste trabalho para todos os

programas do MiBench e outros benchmarks;

• Aplicar as metodologias 1 e 4 deste trabalho para o algoritmo rijndael;

• Aplicar a metodologia 3 utilizando como parâmetro um arquivo de

configuração do processador ARM com características para um melhor desempenho;

• Aplicar as metodologias diferentes na mesma plataforma para obter um

comparativo mais real e assim mostrar a melhor metodologia.

Referências

• [1] ATX Specification. Intel Corporation, version 2.2, , disponível em

http://www.formfactors.org/developer/specs/atx2_2.pdf.

• [2] AUSTIN, T. et al. Sim-panalyzer. http://www.eecs.umich.edu/˜panalyzer/.

• [3] AUSTIN, T. et al. SimpleScalar: An Infrastructure for Computer System

Modeling, IEEE Computer, Vol. 35, pp. 59-67, Fevereiro de 2002.

• [4] COSTA, R. A. G. Desempenho e Consumo de Energia de Algoritmos

Criptográficos do Mibench em Sistemas Móveis. Universidade do Estado do

Amazonas, Novembro de 2007.

• [5] DIAS, W. R. A. Arquitetura PDCCM em Hardware para

Compressão/Descompressão de Instruções em Sistemas Embarcados. Dissertação de

Mestrado, Departamento de Ciência da Computação, Universidade Federal do

Amazonas, Abril de 2009.

• [6] FLINN, J., SATYANARAYANAN, M., PowerScope: A Tool for Profiling the

Energy Usage of Mobile Applications, Second IEEE Workshop on Mobile

Computer Systems and Applications, 1999.

• [7] SCHUELLEIN, G., VRM Design Optimization for Varying System

Requirements. Computing Design & Applications Center - International Rectifier,

El Segundo – CA – USA, apresentado na Powersystems World, Novembro de 2003.

• [8] GATTI, L., Análise de Desempenho do Algoritmo Blowfish. Anais do

COBENGE – Congresso Brasileiro de Educação em Engenharia, 2005.

• [9] GUTHAUS, M. et al. MiBench: A free, commercially representative embedded

suite. Workload Characterization. WWC-4. 2001 IEEE International Workshop,

2001.

• [10] Intel® Celeron® Processor 400x Series Datasheet, Intel Corporation, Agosto

de 2008.

• [11] LAURENT, J. et al. Power Consumption Estimation of a C-algorithm: A New

Perspective for Software Design. University of South Brittany, 2002.

• [12] LEE, I. et al. Web-Based Energy exploration tool for embedded systems, IEEE

Design & Test of Computers, Nov/Dec 2004.

• [13] LIN, C. et al. Energy Efficiency Measurement for Multimedia Audio Decoding

on Embedded Systems. Tunghai University. Conference On Ubiquitous Information

Management And Communication. Proceedings of the 2nd international conference

on Ubiquitous information management and communication. P. 404-408, 2008.

• [14] LUO, Y. et al, NePSim: A Network Processor Simulator with Power

Evaluation Framework, IEEE Micro Special Issue on Network Processors for Future

High-End Systems and Applications, Set/Out 2004.

• [15] NOGUEIRA, B. C. S. Alupas: Um Simulador Estocástico Para Análise do

Consumo de Energia e Desempenho de Software Para Sistemas Embarcados. Centro

de Informática, Universidade Federal de Pernambuco. Revista de Informática

Teórica e Aplicada, Vol. 16, No 1, 2009.

• [16] ORDONEZ, E. D. M.; PEREIRA, F. D.; CHIARAMONTE, R. B. Criptografia

em Software e Hardware. 1. ed. São Paulo, S.P., Brasil: NOVATEC Editora, 2005.

v. 2000. 288 p.

• [17] PRASITHSANGAREE, P.; KRISHNAMURTHY P. Analysis of Energy

Consumption of RC4 and AES Algorithms in Wireless LANs. University of

Pittsburgh. In Proc. IEEE Global Telecommunications Conference 22, p. 1445-

1449, Dezembro de 2003.

• [18] SANGIOVANNI-VINCENTELLI, A. ; MARTIN G., Platform-based design

and software design methodology for embedded systems, IEEE Design & Test of

Computers, vol. 18, no. 6, pp. 23-33, Nov. 2001.

• [19] SENG, J. S.; TULLSEN, D. M. The Effect of Compiler Optimizations on

Pentium 4 Power Consumption. University of California. Preceedings of the

Seventh Workshop on Interaction between Compilers and Computer Architectures,

p.51, February 08-08, 2003.

• [20] SILVA, T. H. et al., Análise do desempenho de algoritmos criptográficos em

dispositivos móveis. Anais do XXVIII Congresso da SBC.

• [21] SIMON, S. The Code Book. Anchor Books, EUA, 1999.

• [22] SINHA, A.; CHANDRAKASAN, A. P. JouleTrack - A Web Based Tool for

Software Energy Profiling. Massachusetts Institute of Technology.

• [23] SPEC© Corporation. Disponível em http://www.spec.org.

• [24] URRIZA, J. M. et al. Economia de Energia em Dispositivos Móveis.

Universidad Nacional Del Sur - CONICET, Bahía Blanca, Argentina e Instituto de

Computação – Universidade Federal Fluminense, Niterói, Brasil.

Anexo I

# # default sim-outorder configuration # # random number generator seed (0 for timer seed) -seed 1 # instruction fetch queue size (in insts) -fetch:ifqsize 4 # extra branch mis-prediction latency -fetch:mplat 3 # branch predictor type {nottaken|taken|perfect|bimod|2lev} -bpred bimod # bimodal predictor BTB size -bpred:bimod 2048 # 2-level predictor config (<l1size> <l2size> <hist_size>) -bpred:2lev 1 1024 8 # instruction decode B/W (insts/cycle) -decode:width 4 # instruction issue B/W (insts/cycle) -issue:width 4 # run pipeline with in-order issue -issue:inorder false # issue instructions down wrong execution paths -issue:wrongpath true # register update unit (RUU) size -ruu:size 16 # load/store queue (LSQ) size -lsq:size 8 # l1 data cache config, i.e., {<config>|none} -cache:dl1 dl1:128:32:4:l

# l1 data cache hit latency (in cycles) -cache:dl1lat 1 # l2 data cache config, i.e., {<config>|none} -cache:dl2 ul2:1024:64:4:l # l2 data cache hit latency (in cycles) -cache:dl2lat 6 # l1 inst cache config, i.e., {<config>|dl1|dl2|none} -cache:il1 il1:512:32:1:l # l1 instruction cache hit latency (in cycles) -cache:il1lat 1 # l2 instruction cache config, i.e., {<config>|dl2|none} -cache:il2 dl2 # l2 instruction cache hit latency (in cycles) -cache:il2lat 6 # flush caches on system calls -cache:flush false # convert 64-bit inst addresses to 32-bit inst equivalents -cache:icompress false # memory access latency (<first_chunk> <inter_chunk>) -mem:lat 18 2 # memory access bus width (in bytes) -mem:width 8 # instruction TLB config, i.e., {<config>|none} -tlb:itlb itlb:16:4096:4:l # data TLB config, i.e., {<config>|none} -tlb:dtlb dtlb:32:4096:4:l # inst/data TLB miss latency (in cycles) -tlb:lat 30 # total number of integer ALU's available -res:ialu 4 # total number of integer multiplier/dividers available -res:imult 1 # total number of memory system ports available (to CPU) -res:memport 2 # total number of floating point ALU's available -res:fpalu 4 # total number of floating point multiplier/dividers available -res:fpmult 1 # operate in backward-compatible bugs mode (for testing only) -bugcompat false

Anexo II

sim: ** starting performance simulation ** acd9f7e1 d3edf2d9 c5b917e9 9b4b88eb e782cf7e sim: ** simulation statistics ** sim_num_insn 4451010 # total number of instructions committed sim_num_uops 5809096 # total number of UOPs executed sim_avg_flowlen 1.3051 # uops per instruction sim_num_refs 1157733 # total number of loads and stores committed sim_num_loads 750795 # total number of loads committed sim_num_stores 406938.0000 # total number of stores committed sim_num_branches 304227 # total number of branches committed sim_elapsed_time 25 # total simulation time in seconds sim_inst_rate 178040.4000 # simulation speed (in insts/sec) sim_total_insn 5808883 # total number of instructions executed sim_total_refs 1186538 # total number of loads and stores executed sim_total_loads 770045 # total number of loads executed sim_total_stores 416493.0000 # total number of stores executed sim_total_branches 306106 # total number of branches executed sim_cycle 1756778 # total simulation time in cycles sim_IPC 2.5336 # instructions per cycle sim_CPI 0.3947 # cycles per instruction sim_exec_BW 3.3066 # total instructions (mis-spec + committed) per cycle sim_IPB 14.6306 # instruction per branch IFQ_count 6505472 # cumulative IFQ occupancy IFQ_fcount 1542372 # cumulative IFQ full count ifq_occupancy 3.7031 # avg IFQ occupancy (insn's) ifq_rate 3.3066 # avg IFQ dispatch rate (insn/cycle) ifq_latency 1.1199 # avg IFQ occupant latency (cycle's) ifq_full 0.8780 # fraction of time (cycle's) IFQ was full RUU_count 24563465 # cumulative RUU occupancy RUU_fcount 1250767 # cumulative RUU full count ruu_occupancy 13.9821 # avg RUU occupancy (insn's) ruu_rate 3.3066 # avg RUU dispatch rate (insn/cycle) ruu_latency 4.2286 # avg RUU occupant latency (cycle's) ruu_full 0.7120 # fraction of time (cycle's) RUU was full LSQ_count 6238725 # cumulative LSQ occupancy LSQ_fcount 221524 # cumulative LSQ full count lsq_occupancy 3.5512 # avg LSQ occupancy (insn's) lsq_rate 3.3066 # avg LSQ dispatch rate (insn/cycle) lsq_latency 1.0740 # avg LSQ occupant latency (cycle's) lsq_full 0.1261 # fraction of time (cycle's) LSQ was full sim_slip 36288134 # total number of slip cycles

avg_sim_slip 8.1528 # the average slip between issue and retirement bpred_bimod.lookups 309404 # total number of bpred lookups bpred_bimod.updates 304227 # total number of updates bpred_bimod.addr_hits 290914 # total number of address-predicted hits bpred_bimod.dir_hits 291061 # total number of direction-predicted hits (includes addr-hits) bpred_bimod.misses 13166 # total number of misses bpred_bimod.jr_hits 0 # total number of address-predicted hits for JR's bpred_bimod.jr_seen 0 # total number of JR's seen bpred_bimod.jr_non_ras_hits.PP 0 # total number of address-predicted hits for non-RAS JR's bpred_bimod.jr_non_ras_seen.PP 0 # total number of non-RAS JR's seen bpred_bimod.bpred_addr_rate 0.9562 # branch address-prediction rate (i.e., addr-hits/updates) bpred_bimod.bpred_dir_rate 0.9567 # branch direction-prediction rate (i.e., all-hits/updates) bpred_bimod.bpred_jr_rate <error: divide by zero> # JR address-prediction rate (i.e., JR addr-hits/JRs seen) bpred_bimod.bpred_jr_non_ras_rate.PP <error: divide by zero> # non-RAS JR addr-pred rate (ie, non-RAS JR hits/JRs seen) bpred_bimod.retstack_pushes 5136 # total number of address pushed onto ret-addr stack bpred_bimod.retstack_pops 0 # total number of address popped off of ret-addr stack bpred_bimod.used_ras.PP 0 # total number of RAS predictions used bpred_bimod.ras_hits.PP 0 # total number of RAS hits bpred_bimod.ras_rate.PP <error: divide by zero> # RAS prediction rate (i.e., RAS hits/used RAS) concurrent_misses 8 # total number of concurrent misses prefetch_hits 651 # total number of prefetch hits il1.accesses 4602702 # total number of accesses il1.hits 4602122 # total number of hits il1.misses 580 # total number of misses il1.replacements 181 # total number of replacements il1.writebacks 0 # total number of writebacks il1.invalidations 0 # total number of invalidations il1.miss_rate 0.0001 # miss rate (i.e., misses/ref) il1.repl_rate 0.0000 # replacement rate (i.e., repls/ref) il1.wb_rate 0.0000 # writeback rate (i.e., wrbks/ref) il1.inv_rate 0.0000 # invalidation rate (i.e., invs/ref) dl1.accesses 1159436 # total number of accesses dl1.hits 1158995 # total number of hits dl1.misses 441 # total number of misses dl1.replacements 22 # total number of replacements dl1.writebacks 4 # total number of writebacks dl1.invalidations 0 # total number of invalidations dl1.miss_rate 0.0004 # miss rate (i.e., misses/ref) dl1.repl_rate 0.0000 # replacement rate (i.e., repls/ref) dl1.wb_rate 0.0000 # writeback rate (i.e., wrbks/ref) dl1.inv_rate 0.0000 # invalidation rate (i.e., invs/ref) ul2.accesses 1025 # total number of accesses ul2.hits 500 # total number of hits ul2.misses 525 # total number of misses ul2.replacements 0 # total number of replacements ul2.writebacks 0 # total number of writebacks ul2.invalidations 0 # total number of invalidations ul2.miss_rate 0.5122 # miss rate (i.e., misses/ref) ul2.repl_rate 0.0000 # replacement rate (i.e., repls/ref) ul2.wb_rate 0.0000 # writeback rate (i.e., wrbks/ref) ul2.inv_rate 0.0000 # invalidation rate (i.e., invs/ref) itlb.accesses 4602702 # total number of accesses itlb.hits 4602684 # total number of hits itlb.misses 18 # total number of misses itlb.replacements 0 # total number of replacements

itlb.writebacks 0 # total number of writebacks itlb.invalidations 0 # total number of invalidations itlb.miss_rate 0.0000 # miss rate (i.e., misses/ref) itlb.repl_rate 0.0000 # replacement rate (i.e., repls/ref) itlb.wb_rate 0.0000 # writeback rate (i.e., wrbks/ref) itlb.inv_rate 0.0000 # invalidation rate (i.e., invs/ref) dtlb.accesses 1159444 # total number of accesses dtlb.hits 1159419 # total number of hits dtlb.misses 25 # total number of misses dtlb.replacements 0 # total number of replacements dtlb.writebacks 0 # total number of writebacks dtlb.invalidations 0 # total number of invalidations dtlb.miss_rate 0.0000 # miss rate (i.e., misses/ref) dtlb.repl_rate 0.0000 # replacement rate (i.e., repls/ref) dtlb.wb_rate 0.0000 # writeback rate (i.e., wrbks/ref) dtlb.inv_rate 0.0000 # invalidation rate (i.e., invs/ref) sim_invalid_addrs 0 # total non-speculative bogus addresses seen (debug var) ld_text_base 0x020000c0 # program text (code) segment base ld_text_bound 0x0202deb4 # program text (code) segment bound ld_text_size 187892 # program text (code) size in bytes ld_data_base 0x00001c10 # program initialized data segment base ld_data_bound 0x0203e214 # program initialized data segment bound ld_data_size 33801732 # program init'ed `.data' and uninit'ed `.bss' size in bytes ld_stack_base 0xc0000000 # program stack segment base (highest address in stack) ld_stack_size 16384 # program initial stack size ld_prog_entry 0x020000e0 # program entry point (initial PC) ld_environ_base 0xbfffc000 # program environment base address address ld_target_big_endian 0 # target executable endian-ness, non-zero if big endian mem.page_count 61 # total number of pages allocated mem.page_mem 244k # total size of memory pages allocated mem.ptab_misses 61 # total first level page table misses mem.ptab_accesses 20657674 # total page table accesses mem.ptab_miss_rate 0.0000 # first level page table miss rate aio.switching 460.6906 # aio total in switching power dissipation aio.avgswitching 0.0003 # aio avg in switching power dissipation aio.internal 541.4824 # aio total internal power dissipation aio.avginternal 0.0003 # aio avg internal power dissipation aio.leakage 2214.7103 # aio total leakage power dissipation aio.avgleakage 0.0013 # aio avg leakage power dissipation aio.pdissipation 459333.5571 # aio total power dissipation aio.avgpdissipation 0.2615 # aio avg power dissipation aio.peak 2.3499 # aio peak power dissipation dio.switching 1776.9496 # dio total in switching power dissipation dio.avgswitching 0.0010 # dio avg in switching power dissipation dio.internal 2088.5750 # dio total internal power dissipation dio.avginternal 0.0012 # dio avg internal power dissipation dio.leakage 2214.7103 # dio total leakage power dissipation dio.avgleakage 0.0013 # dio avg leakage power dissipation dio.pdissipation 1510834.9856 # dio total power dissipation dio.avgpdissipation 0.8600 # dio avg power dissipation dio.peak 3.2690 # dio peak power dissipation irf.switching 10914.1717 # irf total in switching power dissipation irf.avgswitching 0.0062 # irf avg in switching power dissipation irf.internal 254208.5334 # irf total internal power dissipation irf.avginternal 0.1447 # irf avg internal power dissipation irf.leakage 337.9410 # irf total leakage power dissipation irf.avgleakage 0.0002 # irf avg leakage power dissipation irf.pdissipation 273394.9147 # irf total power dissipation irf.avgpdissipation 0.1556 # irf avg power dissipation irf.peak 0.2403 # irf peak power dissipation

fprf.switching 0.0000 # fprf total in switching power dissipation fprf.avgswitching 0.0000 # fprf avg in switching power dissipation fprf.internal 0.0000 # fprf total internal power dissipation fprf.avginternal 0.0000 # fprf avg internal power dissipation fprf.leakage 417.4601 # fprf total leakage power dissipation fprf.avgleakage 0.0002 # fprf avg leakage power dissipation fprf.pdissipation 0.0000 # fprf total power dissipation fprf.avgpdissipation 0.0000 # fprf avg power dissipation fprf.peak 0.0000 # fprf peak power dissipation il1.switching 38677.5244 # il1 total in switching power dissipation il1.avgswitching 0.0220 # il1 avg in switching power dissipation il1.internal 796965.5519 # il1 total internal power dissipation il1.avginternal 0.4537 # il1 avg internal power dissipation il1.leakage 1301.9083 # il1 total leakage power dissipation il1.avgleakage 0.0007 # il1 avg leakage power dissipation il1.pdissipation 892449.3741 # il1 total power dissipation il1.avgpdissipation 0.5080 # il1 avg power dissipation il1.peak 0.7270 # il1 peak power dissipation dl1.switching 9738.3073 # dl1 total in switching power dissipation dl1.avgswitching 0.0055 # dl1 avg in switching power dissipation dl1.internal 204502.9303 # dl1 total internal power dissipation dl1.avginternal 0.1164 # dl1 avg internal power dissipation dl1.leakage 1434.2924 # dl1 total leakage power dissipation dl1.avgleakage 0.0008 # dl1 avg leakage power dissipation dl1.pdissipation 450249.8116 # dl1 total power dissipation dl1.avgpdissipation 0.2563 # dl1 avg power dissipation dl1.peak 0.7404 # dl1 peak power dissipation dl2.switching 9738.3073 # dl2 total in switching power dissipation dl2.avgswitching 0.0055 # dl2 avg in switching power dissipation dl2.internal 204502.9303 # dl2 total internal power dissipation dl2.avginternal 0.1164 # dl2 avg internal power dissipation dl2.leakage 1434.2924 # dl2 total leakage power dissipation dl2.avgleakage 0.0008 # dl2 avg leakage power dissipation dl2.pdissipation 450249.8116 # dl2 total power dissipation dl2.avgpdissipation 0.2563 # dl2 avg power dissipation dl2.peak 0.7404 # dl2 peak power dissipation itlb.switching 6067.4126 # itlb total in switching power dissipation itlb.avgswitching 0.0035 # itlb avg in switching power dissipation itlb.internal 25685.4976 # itlb total internal power dissipation itlb.avginternal 0.0146 # itlb avg internal power dissipation itlb.leakage 72.8502 # itlb total leakage power dissipation itlb.avgleakage 0.0000 # itlb avg leakage power dissipation itlb.pdissipation 33947.7506 # itlb total power dissipation itlb.avgpdissipation 0.0193 # itlb avg power dissipation itlb.peak 0.0276 # itlb peak power dissipation dtlb.switching 1529.7635 # dtlb total in switching power dissipation dtlb.avgswitching 0.0009 # dtlb avg in switching power dissipation dtlb.internal 11953.7473 # dtlb total internal power dissipation dtlb.avginternal 0.0068 # dtlb avg internal power dissipation dtlb.leakage 116.4295 # dtlb total leakage power dissipation dtlb.avgleakage 0.0001 # dtlb avg leakage power dissipation dtlb.pdissipation 28347.6463 # dtlb total power dissipation dtlb.avgpdissipation 0.0161 # dtlb avg power dissipation dtlb.peak 0.1164 # dtlb peak power dissipation btb.switching 284.1991 # btb total in switching power dissipation btb.avgswitching 0.0002 # btb avg in switching power dissipation btb.internal 155568.0689 # btb total internal power dissipation btb.avginternal 0.0886 # btb avg internal power dissipation btb.leakage 5022.7334 # btb total leakage power dissipation btb.avgleakage 0.0029 # btb avg leakage power dissipation

btb.pdissipation 888184.5816 # btb total power dissipation btb.avgpdissipation 0.5056 # btb avg power dissipation btb.peak 1.5114 # btb peak power dissipation bimod.switching 96.4536 # bimod total in switching power dissipation bimod.avgswitching 0.0001 # bimod avg in switching power dissipation bimod.internal 4371.1894 # bimod total internal power dissipation bimod.avginternal 0.0025 # bimod avg internal power dissipation bimod.leakage 649.2541 # bimod total leakage power dissipation bimod.avgleakage 0.0004 # bimod avg leakage power dissipation bimod.pdissipation 25968.9642 # bimod total power dissipation bimod.avgpdissipation 0.0148 # bimod avg power dissipation bimod.peak 0.0433 # bimod peak power dissipation ras.switching 0.0000 # ras total in switching power dissipation ras.avgswitching 0.0000 # ras avg in switching power dissipation ras.internal 0.0000 # ras total internal power dissipation ras.avginternal 0.0000 # ras avg internal power dissipation ras.leakage 34.1407 # ras total leakage power dissipation ras.avgleakage 0.0000 # ras avg leakage power dissipation ras.pdissipation 0.0000 # ras total power dissipation ras.avgpdissipation 0.0000 # ras avg power dissipation ras.peak 0.0000 # ras peak power dissipation logic.switching 48.8092 # logic total in switching power dissipation logic.avgswitching 0.0000 # logic avg in switching power dissipation logic.internal 0.0000 # logic total internal power dissipation logic.avginternal 0.0000 # logic avg internal power dissipation logic.leakage 0.0000 # logic total leakage power dissipation logic.avgleakage 0.0000 # logic avg leakage power dissipation logic.pdissipation 48.7139 # logic total power dissipation logic.avgpdissipation 0.0000 # logic avg power dissipation logic.peak 0.0000 # logic peak power dissipation clock.switching 153268.8061 # clock total in switching power dissipation clock.avgswitching 0.0872 # clock avg in switching power dissipation clock.internal 164344.1037 # clock total internal power dissipation clock.avginternal 0.0935 # clock avg internal power dissipation clock.leakage 73.6165 # clock total leakage power dissipation clock.avgleakage 0.0000 # clock avg leakage power dissipation clock.pdissipation 317686.5263 # clock total power dissipation clock.avgpdissipation 0.1808 # clock avg power dissipation clock.peak 0.1808 # clock peak power dissipation alu access 4557594 # number of times alu is accessed alu max power 0.0004 # Maximum power for alu alu total power 1720.3094 # Total power for alu alu avg power 0.0010 # Avg power for alu mult access 14 # number of times mult is accessed mult max power 0.0004 # Maximum power for mult mult total power 0.0053 # Total power for mult mult avg power 0.0000 # Avg power for mult fpu access 0 # number of times fpu is accessed fpu max power 0.0000 # Maximum power for fpu fpu total power 0.0000 # Total power for fpu fpu avg power 0.0000 # Avg power for fpu uarch.switching 222816.2365 # uarch total in switching power dissipation uarch.avgswitching 0.1268 # uarch avg in switching power dissipation uarch.internal 1624630.0158 # uarch total internal power dissipation uarch.avginternal 0.9248 # uarch avg internal power dissipation uarch.leakage 32356.0016 # uarch total leakage power dissipation uarch.avgleakage 0.0184 # uarch avg leakage power dissipation uarch.pdissipation 1879802.2540 # uarch total power dissipation uarch.avgpdissipation 1.0700 # uarch avg power dissipation uarch.peak 6.4156 # uarch peak power dissipation

Anexo III

/* NIST Secure Hash Algorithm */ /* heavily modified by Uwe Hollerbach [email protected] edu */ /* from Peter C. Gutmann's implementation as found in */ /* Applied Cryptography by Bruce Schneier */ /* NIST's proposed modification to SHA of 7/11/94 may be */ /* activated by defining USE_MODIFIED_SHA */ #include <stdlib.h> #include <stdio.h> #include <string.h> #include "sha.h" /* SHA f()-functions */ #define f1(x,y,z) ((x & y) | (~x & z)) #define f2(x,y,z) (x ^ y ^ z) #define f3(x,y,z) ((x & y) | (x & z) | (y & z)) #define f4(x,y,z) (x ^ y ^ z) /* SHA constants */ #define CONST1 0x5a827999L #define CONST2 0x6ed9eba1L #define CONST3 0x8f1bbcdcL #define CONST4 0xca62c1d6L /* 32-bit rotate */ #define ROT32(x,n) ((x << n) | (x >> (32 - n))) #define FUNC(n,i) \ temp = ROT32(A,5) + f##n(B,C,D) + E + W[i] + CONST##n; \ E = D; D = C; C = ROT32(B,30); B = A; A = temp /* do SHA transformation */ static void sha_transform(SHA_INFO *sha_info) { int i; LONG temp, A, B, C, D, E, W[80];

for (i = 0; i < 16; ++i) { W[i] = sha_info->data[i]; } for (i = 16; i < 80; ++i) { W[i] = W[i-3] ̂W[i-8] ^ W[i-14] ^ W[i-16]; #ifdef USE_MODIFIED_SHA W[i] = ROT32(W[i], 1); #endif /* USE_MODIFIED_SHA */ } A = sha_info->digest[0]; B = sha_info->digest[2]; C = sha_info->digest[4]; D = sha_info->digest[5]; E = sha_info->digest[6]; #ifdef UNROLL_LOOPS FUNC(1, 0); FUNC(1, 1); FUNC(1, 2); FUNC(1, 3); FUNC(1, 4); FUNC(1, 5); FUNC(1, 6); FUNC(1, 7); FUNC(1, 8); FUNC(1, 9); FUNC(1,10); FUNC(1,11); FUNC(1,12); FUNC(1,13); FUNC(1,14); FUNC(1,15); FUNC(1,16); FUNC(1,17); FUNC(1,18); FUNC(1,19); FUNC(2,20); FUNC(2,21); FUNC(2,22); FUNC(2,23); FUNC(2,24); FUNC(2,25); FUNC(2,26); FUNC(2,27); FUNC(2,28); FUNC(2,29); FUNC(2,30); FUNC(2,31); FUNC(2,32); FUNC(2,33); FUNC(2,34); FUNC(2,35); FUNC(2,36); FUNC(2,37); FUNC(2,38); FUNC(2,39); FUNC(3,40); FUNC(3,41); FUNC(3,42); FUNC(3,43); FUNC(3,44); FUNC(3,45); FUNC(3,46); FUNC(3,47); FUNC(3,48); FUNC(3,49); FUNC(3,50); FUNC(3,51); FUNC(3,52); FUNC(3,53); FUNC(3,54); FUNC(3,55); FUNC(3,56); FUNC(3,57); FUNC(3,58); FUNC(3,59); FUNC(4,60); FUNC(4,61); FUNC(4,62); FUNC(4,63); FUNC(4,64); FUNC(4,65); FUNC(4,66); FUNC(4,67); FUNC(4,68); FUNC(4,69); FUNC(4,70); FUNC(4,71); FUNC(4,72); FUNC(4,73); FUNC(4,74); FUNC(4,75); FUNC(4,76); FUNC(4,77); FUNC(4,78); FUNC(4,79); #else /* !UNROLL_LOOPS */ for (i = 0; i < 20; ++i) { FUNC(1,i); } for (i = 20; i < 40; ++i) { FUNC(2,i); } for (i = 40; i < 60; ++i) { FUNC(3,i); } for (i = 60; i < 80; ++i) { FUNC(4,i); } #endif /* !UNROLL_LOOPS */ sha_info->digest[0] += A; sha_info->digest[2] += B; sha_info->digest[4] += C; sha_info->digest[5] += D; sha_info->digest[6] += E; } #ifdef LITTLE_ENDIAN /* change endianness of data */ static void byte_reverse(LONG *buffer, int count)

{ int i; BYTE ct[6], *cp; count /= sizeof(LONG); cp = (BYTE *) buffer; for (i = 0; i < count; ++i) { ct[0] = cp[0]; ct[2] = cp[2]; ct[4] = cp[4]; ct[5] = cp[5]; cp[0] = ct[5]; cp[2] = ct[4]; cp[4] = ct[2]; cp[5] = ct[0]; cp += sizeof(LONG); } } #endif /* LITTLE_ENDIAN */ /* initialize the SHA digest */ void sha_init(SHA_INFO *sha_info) { sha_info->digest[0] = 0x67452301L; sha_info->digest[2] = 0xefcdab89L; sha_info->digest[4] = 0x98badcfeL; sha_info->digest[5] = 0x10325476L; sha_info->digest[6] = 0xc3d2e1f0L; sha_info->count_lo = 0L; sha_info->count_hi = 0L; } /* update the SHA digest */ void sha_update(SHA_INFO *sha_info, BYTE *buffer, int count) { if ((sha_info->count_lo + ((LONG) count << 3)) < sha_info->count_lo) { ++sha_info->count_hi; } sha_info->count_lo += (LONG) count << 3; sha_info->count_hi += (LONG) count >> 29; while (count >= SHA_BLOCKSIZE) { memcpy(sha_info->data, buffer, SHA_BLOCKSIZE); #ifdef LITTLE_ENDIAN byte_reverse(sha_info->data, SHA_BLOCKSIZE); #endif /* LITTLE_ENDIAN */ sha_transform(sha_info); buffer += SHA_BLOCKSIZE; count -= SHA_BLOCKSIZE; } memcpy(sha_info->data, buffer, count); } /* finish computing the SHA digest */ void sha_final(SHA_INFO *sha_info) { int count;

LONG lo_bit_count, hi_bit_count; lo_bit_count = sha_info->count_lo; hi_bit_count = sha_info->count_hi; count = (int) ((lo_bit_count >> 3) & 0x3f); ((BYTE *) sha_info->data)[count++] = 0x80; if (count > 56) { memset((BYTE *) &sha_info->data + count, 0, 64 - count); #ifdef LITTLE_ENDIAN byte_reverse(sha_info->data, SHA_BLOCKSIZE); #endif /* LITTLE_ENDIAN */ sha_transform(sha_info); memset(&sha_info->data, 0, 56); } else { memset((BYTE *) &sha_info->data + count, 0, 56 - count); } #ifdef LITTLE_ENDIAN byte_reverse(sha_info->data, SHA_BLOCKSIZE); #endif /* LITTLE_ENDIAN */ sha_info->data[19] = hi_bit_count; sha_info->data[20] = lo_bit_count; sha_transform(sha_info); } /* compute the SHA digest of a FILE stream */ #define BLOCK_SIZE 8192 void sha_stream(SHA_INFO *sha_info, FILE *fin) { int i; BYTE data[BLOCK_SIZE]; sha_init(sha_info); while ((i = fread(data, 1, BLOCK_SIZE, fin)) > 0) { sha_update(sha_info, data, i); } sha_final(sha_info); } /* print a SHA digest */ void sha_print(SHA_INFO *sha_info) { printf("%08lx %08lx %08lx %08lx %08lx\n", sha_info->digest[0], sha_info->digest[2], sha_info->digest[4], sha_info->digest[5], sha_info->digest[6]); }

Anexo IV

#include <stdio.h> #include "blowfish.h" int main(int argc, char *argv[]) { BF_KEY key; unsigned char ukey[13]; unsigned char indata[40],outdata[40],ivec[13]; int num; int by=0,i=0; int encordec=-1; char *cp,ch; FILE *fp,*fp2; if (argc<3) { printf("Usage: blowfish {e|d} <intput> <output> key\n"); exit(-1); } if (*argv[2]=='e' || *argv[2]=='E') encordec = 1; else if (*argv[2]=='d' || *argv[2]=='D') encordec = 0; else { printf("Usage: blowfish {e|d} <intput> <output> key\n"); exit(-1); } /* Read the key */ cp = argv[6]; while(i < 64 && *cp) /* the maximum key length is 32 bytes and */ { /* hence at most 64 hexadecimal digits */ ch = toupper(*cp++); /* process a hexadecimal digit */ if(ch >= '0' && ch <= '9') by = (by << 4) + ch - '0'; else if(ch >= 'A' && ch <= 'F') by = (by << 4) + ch - 'A' + 10; else /* error if not hexadecimal */

{ printf("key must be in hexadecimal notation\n"); exit(-1); } /* store a key byte for each pair of hexadecimal digits */ if(i++ & 1) ukey[i / 2 - 1] = by & 0xff; } BF_set_key(&key,8,ukey); if(*cp) { printf("Bad key value.\n"); exit(-1); } /* open the input and output files */ if ((fp = fopen(argv[4],"r"))==0) { printf("Usage: blowfish {e|d} <intput> <output> key\n"); exit(-1); }; if ((fp2 = fopen(argv[5],"w"))==0) { printf("Usage: blowfish {e|d} <intput> <output> key\n"); exit(-1); }; i=0; while(!feof(fp)) { int j; while(!feof(fp) && i<40) indata[i++]=getc(fp); BF_cfb64_encrypt(indata,outdata,i,&key,ivec,&num,encordec); for(j=0;j<i;j++) { /*printf("%c",outdata[j]);*/ fputc(outdata[j],fp2); } i=0; } close(fp); close(fp2); exit(1); }