estudo e medicao do consumo de energia de algoritmos criptograficos do mi bench
DESCRIPTION
TCC no DCOMP/UFS do aluno Lealdo Santos Neto, em Novembro de 2010TRANSCRIPT
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
ESTUDO E MEDIÇÃO DO CONSUMO DE ENERGIA DE ALGORITMOS CRIPTOGRÁFICOS DO MIBENCH
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
ESTUDO E MEDIÇÃO DO CONSUMO DE ENERGIA DE ALGORITMOS CRIPTOGRÁFICOS DO MIBENCH
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. ................................................................................................51 Tabela 3.20. Gráficos obtidos ao executar o algoritmo Blowfish no processo de decriptaçã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. ................................................................................................54 Tabela 3.22. Gráficos obtidos ao executar o algoritmo Blowfish no processo de decriptaçã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
Tabela 3.5. Resultados da execução do algoritmo Blowfish (chave de 256 bits) usando a
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
Tabela 3.6. Resultados da execução do algoritmo Blowfish (chave de 448 bits) usando a
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.
3.3.1. Algoritmo SHA-1
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
3.3.2. Algoritmo Blowfish
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
E entrada1 9139751 72 286,17 D entrada1 8736254 66 256,07 E entrada 2 45674310 359 1426,95 D entrada 2 43658955 330 1284,66
Chave 3
E entrada1 10125532 78 316,82 D entrada1 9728480 73 286,68 E entrada 2 50602953 391 1582,38 D entrada 2 48619729 363 1389,89
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.
3.4.1. Algoritmo SHA-1
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
Arquivo entrada2 Tempo entre execuções 0,16 s Tempo por execução 0,05 s Variação de Voltagem 0,96 V Potência Média durante execução
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
3.4.2. Algoritmo Blowfish
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
Chave2 – 256 bits Encriptação 3.7 3.19
Decriptação 3.8 3.20
Chave3 – 448 bits Encriptação 3.9 3.21
Decriptação 3.10 3.22
(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
algoritmo Blowfish usando chave de 32 bits para as entradas: (a) entrada1, (b)
entrada2, (c) Money.mp3 e (d) vídeo.MPG.
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
Arquivo entrada1 Tempo entre execuções 0,2 s Tempo por execução 0,04 s Variação de Voltagem 1,48 V Potência Média durante execução
45,33 W
Consumo 1,81 J
Blowfish – Encriptação – Chave 32 bits
Arquivo entrada2 Tempo entre execuções 0,2 s Tempo por execução 0,09 s Variação de Voltagem 1,64 V Potência Média durante execução
49,45 W
Consumo 4,45 J
Blowfish – Encriptação – Chave 32 bits
Arquivo Money.mp3 Tempo entre execuções 0,2 s Tempo por execução 0,6 s Variação de Voltagem 1,72 V Potência Média durante execução
51,45 W
Consumo 30,87 J
Blowfish – Encriptação – Chave 32 bits
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
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.
Blowfish – Decriptação – Chave 32 bits
Arquivo entrada1 Tempo entre execuções 0,2 s Tempo por execução 0,04 s Variação de Voltagem 1,48 V Potência Média durante execução
45,33 W
Consumo 1,81 J
Blowfish – Decriptação – Chave 32 bits
Arquivo entrada2 Tempo entre execuções 0,2 s Tempo por execução 0,08 s Variação de Voltagem 1,64 V Potência Média durante execução
49,45 W
Consumo 3,96 J
Blowfish – Decriptação – Chave 32 bits
Arquivo Money.mp3 Tempo entre execuções 0,2 s Tempo por execução 0,5 s Variação de Voltagem 1,72 V Potência Média durante execução
51,45 W
Consumo 25,72 J
Blowfish – Decriptação – Chave 32 bits
Arquivo vídeo.MPG Tempo entre execuções 0,5 s Tempo por execução 5,1 s Variação de Voltagem 1,84 V Potência Média durante execução
54,37 W
Consumo 277,29 J
(a) (b)
(c) (d)
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.
(a) (b)
(c) (d)
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.
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.
Blowfish – Encriptação – Chave 256 bits
Arquivo entrada1 Tempo entre execuções 0,2 s Tempo por execução 0,04 s Variação de Voltagem 1,48 V Potência Média durante execução
45,33 W
Consumo 1,81 J
Blowfish – Encriptação – Chave 256 bits
Arquivo entrada2 Tempo entre execuções 0,2 s Tempo por execução 0,08 s Variação de Voltagem 1,64 V Potência Média durante execução
49,45 W
Consumo 3,96 J
Blowfish – Encriptação – Chave 256 bits
Arquivo Money.mp3 Tempo entre execuções 0,2 s Tempo por execução 0,5 s Variação de Voltagem 1,72 V Potência Média durante execução
51,45 W
Consumo 25,72 J
Blowfish – Encriptação – Chave 256 bits
Arquivo vídeo.MPG Tempo entre execuções 0,5 s Tempo por execução 5,2 s Variação de Voltagem 1,84 V Potência Média durante execução
54,37 W
Consumo 282,73 J
Tabela 3.20. Gráficos obtidos ao executar o algoritmo Blowfish no processo de
decriptação usando chave de 256 bits e dados da interpretação dos mesmos.
Blowfish – Decriptação – Chave 256 bits
Arquivo entrada1 Tempo entre execuções 0,18 s Tempo por execução 0,04 s Variação de Voltagem 1,48 V Potência Média durante execução
45,33 W
Consumo 1,81 J
Blowfish – Decriptação – Chave 256 bits
Arquivo entrada2 Tempo entre execuções 0,2 s Tempo por execução 0,08 s Variação de Voltagem 1,64 V Potência Média durante execução
49,45 W
Consumo 3,96 J
Blowfish – Decriptação – Chave 256 bits
Arquivo Money.mp3 Tempo entre execuções 0,2 s Tempo por execução 0,5 s Variação de Voltagem 1,72 V Potência Média durante execução
51,45 W
Consumo 25,72 J
Blowfish – Decriptação – Chave 256 bits
Arquivo vídeo.MPG Tempo entre execuções 0,5 s Tempo por execução 5,2 s Variação de Voltagem 1,84 V Potência Média durante execução
54,37 W
Consumo 282,73 J
(a) (b)
(c) (d)
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.
(a) (b)
(c) (d)
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.
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.
Blowfish – Encriptação – Chave 448 bits
Arquivo entrada1 Tempo entre execuções 0,2 s Tempo por execução 0,04 s Variação de Voltagem 1,48 V Potência Média durante execução
45,33 W
Consumo 1,81 J
Blowfish – Encriptação – Chave 448 bits
Arquivo entrada2 Tempo entre execuções 0,2 s Tempo por execução 0,08 s Variação de Voltagem 1,64 V Potência Média durante execução
49,45 W
Consumo 3,96 J
Blowfish – Encriptação – Chave 448 bits
Arquivo Money.mp3 Tempo entre execuções 0,2 s Tempo por execução 0,5 s Variação de Voltagem 1,72 V Potência Média durante execução
51,45 W
Consumo 25,72 J
Blowfish – Encriptação – Chave 448 bits
Arquivo vídeo.MPG Tempo entre execuções 0,5 s Tempo por execução 5,2 s Variação de Voltagem 1,84 V Potência Média durante execução
54,37 W
Consumo 282,73 J
Tabela 3.22. Gráficos obtidos ao executar o algoritmo Blowfish no processo de
decriptação usando chave de 448 bits e dados da interpretação dos mesmos.
Blowfish – Decriptação – Chave 448 bits
Arquivo entrada1 Tempo entre execuções 0,18 s Tempo por execução 0,04 s Variação de Voltagem 1,48 V Potência Média durante execução
45,33 W
Consumo 1,81 J
Blowfish – Decriptação – Chave 448 bits
Arquivo entrada2 Tempo entre execuções 0,2 s Tempo por execução 0,08 s Variação de Voltagem 1,64 V Potência Média durante execução
49,45 W
Consumo 3,96 J
Blowfish – Decriptação – Chave 448 bits
Arquivo Money.mp3 Tempo entre execuções 0,2 s Tempo por execução 0,55 s Variação de Voltagem 1,72 V Potência Média durante execução
51,45 W
Consumo 28,29 J
Blowfish – Decriptação – Chave 448 bits
Arquivo vídeo.MPG Tempo entre execuções 0,5 s Tempo por execução 5,1 s Variação de Voltagem 1,84 V Potência Média durante execução
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
entrada2 NA NA 1329,95 NA
entrada1 NA NA 238,68 NA
entrada2 NA NA 1159,58 NA
entrada1 NA NA 286,17 NA
entrada2 NA NA 1426,95 NA
entrada1 NA NA 256,07 NA
entrada2 NA NA 1284,66 NA
entrada1 NA NA 316,82 NA
entrada2 NA NA 1582,38 NA
entrada1 NA NA 286,68 NA
entrada2 NA NA 1389,89 NA
Rijndael Encriptação
Chave1
Rijndael Decriptação
Chave1
Rijndael Decriptação
Chave3
Rijndael Encriptação
Chave2
Rijndael Decriptação
Chave2
Rijndael Encriptação
Chave3
SHA NA
Blowfish Encriptação
Chave1
Blowfish Decriptação
Chave1
Blowfish Encriptação
Chave2
Blowfish Decriptação
Chave2
Blowfish Encriptação
Chave3
Blowfish Decriptação
Chave3
Tabela 3.25. Comparativo do consumo (em µJ) dos algoritmos estudados por byte do
arquivo de entrada.
Algoritmo Chave Arquivo Metodologia 1 Metodologia 2 Metodologia 3 Metodologia 4
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
entrada1 NA NA 2584,67 NA
entrada2 NA NA 2597,56 NA
entrada1 NA NA 2330,86 NA
entrada2 NA NA 2264,80 NA
entrada1 NA NA 2794,63 NA
entrada2 NA NA 2787,01 NA
entrada1 NA NA 2500,68 NA
entrada2 NA NA 2509,10 NA
entrada1 NA NA 3093,95 NA
entrada2 NA NA 3090,59 NA
entrada1 NA NA 2799,61 NA
entrada2 NA NA 2714,63 NARijndael Decriptação Chave3
Rijndael Encriptação Chave2
Rijndael Decriptação Chave2
Rijndael Encriptação Chave3
Blowfish Decriptação Chave3
Rijndael Encriptação Chave1
Rijndael Decriptação Chave1
Blowfish Encriptação Chave2
Blowfish Decriptação Chave2
Blowfish Encriptação Chave3
SHA NA
Blowfish Encriptação Chave1
Blowfish Decriptação Chave1
Tabela 3.26. Comparativo do tempo de execução (em s) obtidos nas diferentes
metodologias aplicadas.
Algoritmo Chave Arquivo Metodologia 1 Metodologia 2 Metodologia 3 Metodologia 4
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
Blowfish Encriptação
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
Blowfish Decriptação
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
Blowfish Encriptação
Chave2
entrada1 0,023 NA 164,000 0,040
entrada2 0,070 NA 799,000 0,080
Money.mp3 0,488 NA NA 0,500
vídeo.MPG 4,896 NA NA 5,200
Blowfish Decriptação
Chave2
entrada1 0,019 NA 165,000 0,040
entrada2 0,070 NA 795,000 0,080
Money.mp3 0,497 NA NA 0,500
vídeo.MPG 4,962 NA NA 5,200
Blowfish Encriptação
Chave3
entrada1 0,022 NA 164,000 0,040
entrada2 0,071 NA 799,000 0,080
Money.mp3 0,487 NA NA 0,500
vídeo.MPG 4,786 NA NA 5,200
Blowfish Decriptação
Chave3
entrada1 0,021 NA 163,000 0,040
entrada2 0,073 NA 797,000 0,080
Money.mp3 0,488 NA NA 0,550
vídeo.MPG 4,771 NA NA 5,100
Rijndael Encriptação
Chave1 entrada1 NA NA 66,000 NA
entrada2 NA NA 329,000 NA
Rijndael Decriptação
Chave1 entrada1 NA NA 60,000 NA
entrada2 NA NA 299,000 NA
Rijndael Encriptação
Chave2 entrada1 NA NA 72,000 NA
entrada2 NA NA 359,000 NA
Rijndael Decriptação
Chave2 entrada1 NA NA 66,000 NA
entrada2 NA NA 330,000 NA
Rijndael Encriptação
Chave3 entrada1 NA NA 78,000 NA
entrada2 NA NA 391,000 NA
Rijndael Decriptação Chave3
entrada1 NA NA 73,000 NA
entrada2 NA NA 363,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); }