Estudo e medicao do consumo de energia de algoritmos criptograficos do mi bench
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

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

on

  • 414 views

TCC no DCOMP/UFS do aluno Lealdo Santos Neto, em Novembro de 2010

TCC no DCOMP/UFS do aluno Lealdo Santos Neto, em Novembro de 2010

Statistics

Views

Total Views
414
Views on SlideShare
414
Embed Views
0

Actions

Likes
0
Downloads
4
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Estudo e medicao do consumo de energia de algoritmos criptograficos do mi bench Document Transcript

  • 1. UNIVERSIDADE FEDERAL DE SERGIPE – UFS LEALDO SANTOS NETOESTUDO E MEDIÇÃO DO CONSUMO DE ENERGIA DE ALGORITMOS CRIPTOGRÁFICOS DO MIBENCH São Cristóvão, SE Julho de 2010
  • 2. LEALDO SANTOS NETOESTUDO 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
  • 3. 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.
  • 4. LEALDO SANTOS NETO ESTUDO E MEDIÇÃO DO CONSUMO DE ENERGIA DE ALGORITMOS CRIPTOGRÁFICOS DO MIBENCHMonografia submetida ao corpo docente do Curso de Ciência da Computação daUniversidade Federal de Sergipe (UFS) como parte dos requisitos para obtenção do grau deBacharel 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
  • 5. 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çãodispensada neste último período. Ao Prof. Chella e ao Wanderson Roger pelo apoio e respostas a questionamentos sobreassuntos 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çãoda pessoa que sou hoje. A todos, o meu muito obrigado.
  • 6. RESUMO O grande avanço tecnológico decorrente das últimas décadas resultou em um mundoglobalizado em que a velocidade dos acontecimentos está maior e os meios de comunicaçãoestão mais rápidos e difundidos. Neste novo cenário as informações passaram a sersupervalorizadas e a computação tem grande destaque como meio de criação e transmissãodeste conteúdo, além do fato da miniaturização dos dispositivos que tornou a computaçãoubíqua. Diante deste cenário, observando ainda a grande importância dos sistemasembarcados, torna-se necessário um estudo sobre o consumo energético dos mesmos, sendoneste trabalho focado o conjunto de benchmark MiBench, em especial os seus algoritmos desegurança. Assim, o presente trabalho tem como objetivo analisar e mensurar o consumo deenergia dos algoritmos SHA, rijndael (melhor conhecido como AES) e Blowfish, presentes noMiBench, 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 dotrabalho foram a caracterização do consumo dos algoritmos estudados e um comparativo entreos resultados das metodologias empregadas, inclusive com a obtenção de dados reais sobre oconsumo dos algoritmos. Palavras-chave: Consumo de Energia, MiBench, Sistemas Embarcados, Sim-Panalyzer, ComputaçãoMóvel, Medição Experimental.
  • 7. ABSTRACT The great technological progress in the last decades results in a globalized worldwhere things happens faster and the media are faster and difused. In this new environment theinformation came to be overvalued and the computation has a great importance as a mean ofcreation and transmission of this content, beyond the fact of the miniaturization of devicesbecame them ubiques. In this setting, noting the importance of embedded systems, becomes necessary tostudy 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 fourmethods. These methods are: the battery discharge measurement, estimation using runtimeand characteristics of processor, simulation using Sim-Panalyzer and experimentalmeasurement using an oscilloscope. The main results of this study were to characterize theconsumption of the studied algorithms and obtain a comparison between the results of thedifferent methodologies, including obtaining the real power consumption of the algorithms. Key-words: Energy Consumption, MiBench, Embedded System, Sim-Panalyzer, MobileComputing, Experimental Measurement.
  • 8. SUMÁRIOLISTA DE TABELAS .................................................................................................................................... 91. INTRODUÇÃO ...............................................................................................................................101.1. MOTIVAÇÃO .................................................................................................................................111.2. OBJETIVOS ...................................................................................................................................111.3. ORGANIZAÇÃO DA MONOGRAFIA .................................................................................................122. CONTEXTUALIZAÇÃO TEÓRICA .............................................................................................132.1. SISTEMAS EMBARCADOS ..............................................................................................................132.2. CONCEITOS DE SEGURANÇA DE DADOS ........................................................................................152.2.1. Algoritmos de Chaves Assimétricas ..........................................................................................162.2.2. Algoritmos de Chaves Simétricas .............................................................................................162.2.3. Algoritmos de Hash .................................................................................................................172.3. PROGRAMAS DO BENCHMARK MIBENCH ......................................................................................172.4. FERRAMENTAS UTILIZADAS PARA ANALISAR O CONSUMO DE ENERGIA ......................................212.4.1. NePSim ....................................................................................................................................222.4.2. PowerScope .............................................................................................................................222.4.3. JouleTrack ...............................................................................................................................242.4.4. SNU Energy Explorer Web ......................................................................................................252.4.5. Sim-Panalyzer ..........................................................................................................................262.5. TÉCNICAS PARA MEDIÇÃO UTILIZADAS NO TRABALHO ...............................................................272.5.1. Metodologia 1: Medição de Descarga de Baterias ....................................................................282.5.2. Metodologia 2: Estimativa com Tempo de Execução e Características do Processador ............302.5.3. Metodologia 3: Simulação usando o Sim-Panalyzer ................................................................312.5.4. Metodologia 4: Experimental com Osciloscópio.......................................................................313. TESTES, RESULTADOS E ANÁLISE...........................................................................................333.1. RESULTADOS PARA MEDIÇÃO DE DESCARGA DE BATERIAS EM NOTEBOOK .................................333.1.1 Algoritmo SHA-1 .....................................................................................................................343.1.2 Algoritmo Blowfish ..................................................................................................................343.2. RESULTADOS PARA ESTIMATIVA DE CONSUMO COM BASE NAS CARACTERÍSTICAS DO PROCESSADOR .363.2.1. Algoritmo SHA-1 .....................................................................................................................363.2.2. Algoritmo Blowfish ..................................................................................................................373.3. RESULTADOS USANDO O SIMULADOR SIM-PANALYZER............................................................................373.3.1. Algoritmo SHA-1 .....................................................................................................................383.3.2. Algoritmo Blowfish ..................................................................................................................383.3.3. Algoritmo Rijndael...................................................................................................................403.4. RESULTADOS PARA EXPERIMENTO USANDO O OSCILOSCÓPIO .....................................................423.4.1. Algoritmo SHA-1 .....................................................................................................................433.4.2. Algoritmo Blowfish ..................................................................................................................463.5. COMPARATIVO ENTRE OS MÉTODOS ............................................................................................564. CONCLUSÕES ................................................................................................................................60REFERÊNCIAS ............................................................................................................................................62ANEXO I .......................................................................................................................................................64ANEXO II ......................................................................................................................................................66ANEXO III ....................................................................................................................................................71ANEXO IV.....................................................................................................................................................75
  • 9. LISTA DE FIGURASFigura 2.1 Etapas de como o PowerScope gera um perfil de energia. (a) Coleta de dados e (b) Análise dos dados [6]. ..........................................................................................................................................................23Figura 2.2 Corrente consumida por instruções do processador ARM medidas em [22]. .....................................24Figura 2.3. Diagrama do JouleTrack ................................................................................................................25Figura 2.4. Esquema utilizado para as medições com a metodologia 4. .............................................................32Figura 3.1. Gráfico do custo energético para execução do algoritmo Blowfish. .................................................39Figura 3.2. Gráfico do custo energético para execução do algoritmo rijndael.....................................................41Figura 3.3. Resistores ligado em série com o fio de alimentação da placa mãe. .................................................43Figura 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. ..............................................................................................44Figura 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. .................47Figura 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. .................47Figura 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. ...............50Figura 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. ...............50Figura 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. ...............53Figura 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
  • 10. LISTA DE TABELASTabela 2.1. Número de instruções executadas pelas aplicações do MiBench [9].................................................19Tabela 2.2. Áreas de consumo apresentadas no Sim-panalyzer e os seus significados. .......................................27Tabela 3.1. Arquivos usados como parâmetro para os testes. ............................................................................33Tabela 3.2. Chaves usadas como parâmetro para os testes.................................................................................33Tabela 3.3. Resultados da execução do algoritmo SHA usando a primeira metodologia....................................34Tabela 3.4. Resultados da execução do algoritmo Blowfish (chave de 32 bits) usando a metodologia 1. ............35Tabela 3.5. Resultados da execução do algoritmo Blowfish (chave de 256 bits) usando a metodologia 1. ..........35Tabela 3.6. Resultados da execução do algoritmo Blowfish (chave de 448 bits) usando a metodologia 1. ..........36Tabela 3.7. Resultados da estimativa de consumo para algoritmo SHA. ............................................................37Tabela 3.8. Resultados da estimativa de consumo para algoritmo Blowfish. ......................................................37Tabela 3.9. Resultados da simulação de consumo para algoritmo SHA. ............................................................38Tabela 3.10. Resultados da simulação de consumo para algoritmo Blowfish. ....................................................39Tabela 3.11. Potência simulada ao executar o algoritmo Blowfish. ...................................................................40Tabela 3.12. Resultados da simulação de consumo para algoritmo rijndael. ......................................................41Tabela 3.13. Aumento de consumo energético de acordo com o tamanho da chave. ..........................................41Tabela 3.14. Potência simulada ao executar o algoritmo rijndael.......................................................................42Tabela 3.15. Gráficos obtidos ao executar o algoritmo SHA e dados da interpretação dos mesmos. ...................45Tabela 3.16. Guia para as figuras e tabelas com os resultados dos testes com o algoritmo Blowfish...................46Tabela 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. ................................................................................................48Tabela 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. ................................................................................................49Tabela 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. ................................................................................................51Tabela 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. ................................................................................................52Tabela 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. ................................................................................................54Tabela 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. ................................................................................................55Tabela 3.23. Comparativo da potência média (em W) consumida em cada metodologia usada no trabalho. .......56Tabela 3.24. Comparativo do consumo em Joules entre as diferentes metodologias. ..........................................57Tabela 3.25. Comparativo do consumo (em µJ) dos algoritmos estudados por byte do arquivo de entrada. ........58Tabela 3.26. Comparativo do tempo de execução (em s) obtidos nas diferentes metodologias aplicadas. ...........59
  • 11. 1. INTRODUÇÃO Esta é a era onde a informação e o conhecimento passaram a desempenhar umnovo e estratégico papel, passando então a ter um valor inimaginável. Nessa nova era oprincipal 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 edomicílios atuais, ou qualquer dispositivo com capacidade de processamento usado paragerar, armazenar ou transmitir dados. Estes outros dispositivos são em sua maioriasistemas embarcados, que são sistemas digitais de propósitos especiais, usados dentrode outro dispositivo com funções específicas. Com a elevada evolução dos processadores e custo reduzido de produção, taissistemas 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 decombustível em um carro de Fórmula 1, obtiveram maior potencial de processamento, oque acarreta em um aumento de consumo energético. A problemática se inicia devido ao fato de que, segundo URRIZA et al [24], oavanço da tecnologia das baterias ter sido lento nos últimos anos, já que as tecnologiasusadas nas mesmas se tratarem de tecnologias amadurecidas, e ainda não existemalternativas comercialmente viáveis de novas tecnologias para os próximos anos. Parasuprir essa deficiência das baterias, estão sendo estudadas formas de diminuir oconsumo energético dos mesmos, por meio de arquiteturas de baixo consumo e dealgoritmos mais eficientes. O fato é que uma grande quantidade desses dispositivos estão interligados aoutros dispositivos através da internet, sendo usados em grande escala para atransmissã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ãopassaram a serem executados na grande maioria dos dispositivos computacionais. Segundo GUTHAUS et al [9], o MiBench é um conjunto de 35 aplicações debenchmark otimizadas para sistemas embarcados. Suas aplicações são divididas em seiscategorias: controle automotivo e industrial, rede, segurança, dispositivos de consumo,automação de escritórios e telecomunicações.
  • 12. Este trabalho visa realizar o estudo comparativo do consumo de energia de cadaum desses algoritmos selecionados usando algumas metodologias para se obter esseimportante valor. 1.1. Motivação O consumo global de energia preocupa não só os ambientalistas, mas tambémtoda a sociedade, e dispositivos de computação também estão sendo observados desteponto de vista. Esta preocupação, aliada à autonomia das baterias, fez com que osprojetistas passassem a desenvolver produtos buscando um menor consumo energético. Segundo SANGIOVANNI-VINCENTELLI & MARTIN [18], os atuais sistemasembarcados têm seu desenvolvimento compostos em 80% por software. Ainda segundoSANGIOVANNI-VINCENTELLI & MARTIN [18], o uso de mais software permitereduzir o custo de projeto e produção dos sistemas embarcados, já que osmicrocontroladores e microprocessadores embarcados são produzidos em larga escala eutilizados em diversas aplicações embarcadas diferentes. Sendo a maior parte dasfuncionalidades dos sistemas embarcados implementadas por software, o consumoenergé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 oconsumo energético proveniente da sua execução pode ser considerado significativo,principalmente em dispositivos móveis. Por esse motivo, foi escolhido para estudo oconsumo de energia dos algoritmos de segurança presentes no benchmark MiBench,que são: SHA (Secure Hash Algorithm), Blowfish, rijndael (melhor conhecido comoAES) e PGP (Pretty Good Privacy). 1.2. Objetivos Geral Este trabalho tem como objetivo estudar e analisar o consumo de energia emalgumas plataformas computacionais, incluindo ferramentas de simulação emetodologias para medição. Como o foco do trabalho são os algoritmos de segurança
  • 13. 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 osconceitos básicos estudados para a realização dos experimentos feitos, além de proverum embasamento teórico para todo o trabalho, como conceitos relacionados comsistemas embarcados, segurança de dados, benchmark MiBench e ferramentas etécnicas para medição de consumo energia. O capitulo 3 apresenta os resultados obtidos com a aplicação dos métodosdescritos na seção 2.5, e sua respectiva análise e comparação. O capítulo 4 finaliza otrabalho, sumarizando os resultados alcançados e discutindo futuras pesquisas etrabalhos.
  • 14. 2. Contextualização Teórica 2.1. Sistemas Embarcados Sistemas embarcados geralmente são definidos como um sistema de propósitoespecífico usado dentro de outro dispositivo. Como tal definição não é precisa, são apresentadas suas principais característicasa 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
  • 15. 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ísticasdevem ser estudadas e então analisadas para definir o nível em que cada uma delas deveestar presentes, além de exigir quais características serão implementadas em hardwareou software para garantir o equilíbrio do projeto. Tal equilíbrio é decorrente da melhoriade uma das características comprometendo as outras. Por exemplo, sabe-se que quantomaior o desempenho de um sistema maior será o seu consumo energético e a dissipaçãode calor, portanto se deve escalar quanto de desempenho necessário para que possadimensionar o seu consumo energético e a necessidade de uma dissipação ativa decalor. O custo de desenvolvimento do projeto é chamado custo de engenharia nãorecorrente, já que após o desenvolvimento deste pode ser produzido qualquer número deunidades sem um aumento do mesmo. Para um projeto deste, além do equilíbrio entre as características citadas acimadeve ser estimado o tempo de mercado e o tempo de protótipo, que correspondem aotempo de projetar e fabricar o dispositivo até este ser vendido ao consumidor e o tempode fabricar uma versão funcional e não final do mesmo, respectivamente. Além dotempo de verificação da segurança e de funcionalidade do mesmo. Outro fator importante a ser considerado para um sistema embarcado é o custode uma unidade produzida, não incluso o preço do projeto. Os sistemas embarcados possuem microcontroladores ou microprocessadoresque podem ser divididos em subtipos como: (i) propósito geral, que pode ser aplicadopara diversas funções, sendo estas implementadas por software e (ii) aplicaçãoespecí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 desinais 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
  • 16. funções específicas necessárias para o funcionamento do mesmo. Outras funções que vem cada vez mais sendo implementadas em sistemasembarcados são as funções de comunicação sem fio para que os mesmos possamfuncionar como um sistema distribuído de processamento, aumentando assimvirtualmente o poder computacional de cada dispositivo. Os sistemas embarcados hoje são usados em praticamente todo sistema ligado aenergia, por exemplo: celulares, câmeras digitais, filmadoras, videocassetes, vídeogames, calculadoras, microondas, máquina de lavar, geladeira, fax, copiadoras,impressoras, caixas registradoras, alarmes, caixas eletrônicos e nos veículos também nocontrole 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 vemsempre desenvolvendo técnicas para tornar suas informações inacessíveis a pessoas nãoautorizadas. 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 oucodificar (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 processoinverso, 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émbastante eficientes na época, como cifrar textos alterando as letras desviando umaquantidade de caracteres fixos no alfabeto. Porém, com a valorização da informaçãosurgiu um grande interesse em ter acesso às mesmas e assim surgiu um grupo voltado aestudar como obter a informação original tendo como base o texto cifrado. Com o crescente uso da internet como meio de comunicação entre computadoresas técnicas de criptografia se tornaram indispensáveis, e então foram implementados osalgoritmos de criptografia na comunicação entre eles. Os principais algoritmos utilizados para prover segurança nas comunicações porcomputador hoje são vistos a seguir.
  • 17. 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 dasmensagens. Cada um dos processos é de mão única, sendo fáceis de calcular epraticamente impossíveis de serem revertidos. Para se comunicar usando este método o receptor possui uma chave privada euma pública, a chave pública do receptor, que é disponível a todos, é então usada paracriptografar a mensagem que será enviada ao mesmo, que usa a sua chave privada paradescriptografar 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 achave 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 umprocesso de mão dupla, em que após cifrar o mesmo pode ser decifrado usando amesma chave. O maior problema desse algoritmo é como a chave será trocada entre osusuários, pois qualquer intruso que tenha a chave pode tanto escrever quanto ler asmensagens criptografadas. Os algoritmos de chave simétrica mais conhecidos e usados são: DES (DataEncryption Standard), IDEA (International Data Encryption Algorithm), RC (RonsCode ou Rivest Cipher), rijndael (mais conhecido como AES, Advanced EncryptionStandard), Blowfish. O código fonte do Blowfish, usado neste trabalho, se encontra explicado noanexo IV.
  • 18. 2.2.3. Algoritmos de Hash Os algoritmos de hash geram uma sequência de caracteres chamado de hash quepossui 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 ohash 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 noarquivo 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 doisconjuntos de dados distintos geram o mesmo hash, esta possibilidade é chamada decolisão. Os testes em algoritmos hash consistem em se chegar ao hash de um texto claroconhecido ou desconhecido a partir de qualquer entrada de dado. Os algoritmos de hash mais conhecidos e usados são: MD5, SHA-1 eWHIRLPOOL. 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
  • 19. existentes, um dos mais utilizados é o SPEC (Standard Performance EvaluationCorporation), que atualmente está na versão SPEC2006 [23]. O SPEC [23] é um benchmark para computadores de uso geral, que agrupa umconjunto de programas e dados divididos em duas categorias: inteiro e ponto flutuante.Esse benchmark ganhou grande popularidade no âmbito comercial e acadêmico, por serum ótimo medidor de desempenho. Essa popularidade tem influenciado odesenvolvimento de microprocessadores de uso geral, empregados em computadorespessoais e servidores, de modo que os processadores são projetados para ter altaperformance no SPEC, segundo GUTHAUS et al [9]. De acordo com GUTHAUS et al [9], apesar do SPEC ser uma referência paraprocessadores de propósito geral, não é uma boa opção para avaliar desempenho demicroprocessadores 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çãopara o conjunto de instruções das arquiteturas, como acontece nos processadores de usogeral, o que torna difícil a utilização da maioria dos benchmarks. Então, surgiramalgumas pesquisas para desenvolver benchmarks para processadores especializados.Umas das principais é a suíte desenvolvida e conhecida como EEMBC (EDN EmbeddedMicroprocessor Benchmark Consortium). Este benchmark reúne vários domínios deaplicação e disponibiliza um conjunto de benchmarks para avaliar cinco domínios deprocessadores embarcados. Neste contexto, GUTHAUS et al [9], apresentam o MiBench, um benchmarkdesenvolvido para microprocessadores de uso específico, que possui trinta e cincoaplicações divididas em seis domínios de aplicações (categorias): Automotive andIndustrial Control, Consumer Devices, Office Automation, Networking, Security eTelecommunications. Conforme DIAS [5], o MiBench é um benchmark livre, sendo basicamenteimplementado utilizando a linguagem de programação C. Todos os programas quecompõem o MiBench estão disponíveis em código fonte, sendo possível executar emqualquer arquitetura de microprocessador que possua um compilador C. No MiBench são consideradas as classes de instrução: controle, aritméticainteira, aritmética em ponto flutuante e acesso à memória. Nas categoriasTelecommunications e Security todas as aplicações têm mais de 50% de operaçõesinteiras na ULA (Arithmetic Logic Unit). A categoria Consumer Devices tem maisoperações de acesso à memória por causa do processamento de grandes arquivos de
  • 20. imagem e áudio. A categoria Office Automation faz uso intenso de operações decontrole e acesso à memória. Os programas dessa categoria usam muitas chamadas defunções para bibliotecas de string para manipular os textos, o que causa o uso de váriasinstruções de desvio. Além disso, os textos ocupam bastante espaço na memória, o querequer muitas instruções de acesso à memória. A categoria Automotive and IndustruialControl faz o uso intenso de todas as classes de instrução devido a sua aplicabilidade epor 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çãocontida no MiBench, para cada conjunto de dados padrão. Os conjuntos de dados padrãosão divididos em duas classes para cada categoria do benchmark: conjunto de dadosreduzido e conjunto de dados expandido. O primeiro representa o uso moderado daaplicaçã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] Aplicação Conjunto ReduzidoConjunto Expandido Aplicação Conjunto ReduzidoConjunto Expandido basicmath 65.459.080 1.000.000.000 ispell 8.378.832 640.420.106 bitcount 49.671.043 384.803.644 rsynth 57.872.434 85.005.687 quicksort 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.623 susan.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.845 jpeg.decode 6.677.595 990.912.065 pgp.encode 38.960.650 824.946.344 jpeg.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.267 mad 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.073 tiff2rgba 36.948.939 1.000.000.000 fft.inverse 65.667.015 377.253.252 tiffdither 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.690 typeset 23.395.912 84.170.256 adpcm.encode 37.692.050 832.956.169 dijkstra 64.927.863 272.657.564 gsm.decode 23.868.371 548.023.092 patricia 103.923.656 1.000.000.000 gsm.encode 55.361.308 472.171.446 ghostscript 286.770.117 673.391.179 De acordo com DIAS [5], as seis categorias do MiBench oferecem estruturasde programas que permitem explorar as funcionalidades do benchmark e do compiladorpara se ajustarem melhor a um determinado microprocessador. A descrição da funcionalidade dos MiBench, específicos para sistemasembarcados e de categorias diferentes são:
  • 21. • 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;
  • 22. • 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 deseguranç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 deenergia deve estar diretamente relacionada em como associar de maneira definitiva ocusto de energia para cada evento de uma aplicação. E ainda segundo FLINN [6], aatribuição dos custos de energia em detalhe, habilita a atenção para as áreasproblemáticas do código, o que fazem com que seja desejado mapear o consumo deenergia em nível de procedimentos. Assim, o estudo das ferramentas de análise do consumo energético para softwaresão importantes, a fim de gerar melhorias para trechos de código mais custosos do pontode vista energético.
  • 23. 2.4.1. NePSim LUO et al [14], sentindo a falta de um simulador de desempenho e consumo deenergia para processadores de rede, desenvolveram o NePSim, Network ProcessorSimulator. 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 estimadorde consumo de processos de rede. Em seu trabalho, LUO et al [14], focaram seus testes e fundamentos naespecificação IXP1200 da Intel, que é um processador amplamente utilizado comomodelo representativo em pesquisas sobre processadores de rede. Eles implementaramentão todas as funcionalidades do IXP1200, com excessão do StrongARM que éresponsável por apenas aproximadamente 11% do consumo total do processador, tendona 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 VoltageScaling) que consiste em reduzir a freqüência e voltagem quando o processador tembaixa atividade e aumentar esses indicadores quando o processamento é requerido. No trabalho de LUO et al [14], o NePSim obteve bons resultados, com umaredução de até 17% no consumo de energia em alguns benchmarks, com redução deapenas 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 energiade uma aplicação. Para mapear esse consumo, a ferramenta simula exatamente como aCPU mapeia os ciclos de processamentos em processos e procedimentos. O protótipo da PowerScope usa amostragem estatística para gerar perfis de usode energia de um sistema computacional. Para gerar tais perfis, levando em conta o
  • 24. overhead, o processo ocorre em dois estágios. No primeiro estágio, o de coleta dedados, é 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 osdados que são retirados pelo monitor de sistema. Nessa primeira fase os trabalhosprecisam estar sincronizados. No segundo estágio, da análise dos dados, o analisador deenergia usa os resultados do estágio anterior para gerar os perfis de energia, conforme seobserva 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 doPowerScope utilizando uma placa de vídeo, no qual se observou efeitos na redução doconsumo de energia da compressão de vídeo, tamanho de exibição, gerenciamento deenergia de rede e gerenciamento de energia de disco, a fim de mostrar a eficiência daferramenta para a redução do consumo de energia. Após a análise dos perfis de energiagerados, foi observado que a maior quantidade de energia estava sendo utilizada pordispositivos de hardware ociosos. Após configurações baseadas nos resultados obtidosfoi atingida uma redução de até 46% no consumo total de energia de uma aplicação devídeo, com certa redução na qualidade do vídeo.
  • 25. 2.4.3. JouleTrack Em seu trabalho SINHA & CHANDRAKASAN [22], evitaram umacaracterização do consumo de energia para cada instrução, usando então modelos paraprever o consumo de energia. Utilizando uma fonte de energia para o microprocessador de formaindependente, e utilizando uma fonte fixa de tensão ligada a um multímetro, SINHA &CHANDRAKASAN [22] realizaram testes com os microprocessadores StrongARMAS-1100 e Hitachi SH4 a fim de observar variações no consumo da corrente porinstruções, conforme se observa na Figura 2.2. Os resultados obtidos por SINHA & CHANDRAKASAN [22] com os testesforam 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 diferentesfontes de tensão e corrente a variação máxima de corrente era menor que 8%. Com estesresultados SINHA & CHANDRAKASAN [22] concluíram que o consumo de energiade um trecho de código é independente do código, depende apenas da tensão deoperaçã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
  • 26. mesma tensão e medir o consumo de energia, pode-se observar uma curva decrescimento linear com o tempo de execução e com a inclinação proporcionalequivalente à quantidade de vazamento, quantidade essa que apresentou valoresdesviando 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 depredição. Então o seu código é executado em um simulador ARM que produzestatísticas como saída, como tempo de execução por exemplo. Estas estatísticas sãousadas como base para um mecanismo processar o perfil de energia e gerar um gráficousando as metodologias descritas por SINHA & CHANDRAKASAN [22], conforme seobserva 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 quecontrolam multímetros ou conversores analógicos digitais para medir o consumo deenergia 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
  • 27. energia para sistemas embarcados, a SEE Web, ferramenta usada pela UniversidadeNacional de Seul. Em [12], LEE et al desenvolveram um modelo de máquina de estados limitadaque isola o consumo de energia dinâmico da fuga de energia, com o uso da técnica demediçã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 doprocessador, organização de cache e frequência de clock de memórias e enviar aimagem binária da aplicação. Em seguida é recebida a análise do uso de energia daaplicação, incluindo informações do consumo de energia para cada componente dosistema. 2.4.5. Sim-Panalyzer O Sim-Panalyzer é um simulador de consumo de energia baseado no simuladorde processadores SimpleScalar, descrito por AUSTIN et al [3]. Segundo AUSTIN et al[3], o SimpleScalar é um simulador de arquitetura computacional que modela umcomputador virtual com CPU, Cache e hierarquia de memória e com base nesse modeloconsegue simular programas reais executando sobre tais plataformas. Sendo uma ferramenta baseada em um simulador de arquitetura detalhada, oSim-Panalyzer consegue modelar de forma detalhada tanto a potência dinâmica quantoa de fuga. Para obter os resultados detalhados a simulação é feita separadamente,gerando modelos de energia para os seguintes componentes: cache, caminho de dados eunidade 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 SimpleScalargera os padrões de consumo de energia. O anexo I mostra um exemplo de arquivo deconfiguração usado pelo Sim-Panalyzer. Segundo AUSTIN et al [2], o Sim-Panalyzer foi escrito originalmente com base
  • 28. na arquitetura de instruções (ISA) da família de processadores ARM, obtendoexcelentes resultados em simulações deste tipo. O resultado do consumo do Sim-Panalyzer é dividido em áreas específicas deconsumo do sistema embarcado, conforme Tabela 2.2. O Anexo II mostra comoexemplo a saída do simulador Sim-Panalyzer para o algoritmo SHA-1 tendo comoparâ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 Microarquitetura, a maneira com que a ISA é implementada em um uarch processador 2.5. Técnicas para Medição Utilizadas no Trabalho Para o estudo do consumo de energia dos algoritmos de criptografia presentesno MiBench serão usados quatro métodos de medição do consumo de energia.
  • 29. O primeiro método usa a descarga da bateria de um dispositivo para medir oconsumo energético do mesmo ao executar os algoritmos. O segundo método é teórico eutiliza dados técnicos do processador e do algoritmo para obter um provável consumoenergético do processador ao executar o algoritmo. O terceiro método é baseado emsimulação, onde o simulador de consumo para sistemas embarcados Sim-Panalyzer éutilizado para estimar o consumo dos algoritmos. E o último método é um experimentofeito utilizando um osciloscópio para medir a variação da corrente consumida peloprocessador 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 porCOSTA [4], onde foi feita a estimativa de consumo a partir do nível de carga da bateriaantes e depois da execução de uma determinada aplicação. Como os algoritmos desegurança são executados muito rapidamente no processador em questão, foi usado umShell script para que o mesmo fosse executado um determinado número de vezes everificar o nível de carga da bateria após esse número de execuções. Assim, o consumode energia de cada ciclo do algoritmo é calculado usando o consumo de energia totaldividido pela quantidade de ciclos que o algoritmo foi executado. Também é calculadoo tempo de execução de cada algoritmo dividindo o tempo de processo total pelonúmero de execuções feita pelo script. Os testes foram realizados em grupos de 50, 100, 200, 500 e 1000 execuçõespara cada arquivo em cada algoritmo, e a medição do descarregamento da bateria é feitautilizando 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 aexecução de cada algoritmo. Para a medição do tempo de processo utilizado pela bateriafoi utilizado o comando “time”, presente no Linux, ao executar o conjuunto deexecuções de cada algoritmo. Para a execução desses conjuntos foi escrito um Shell Script para cada um dosalgoritmos em que são passados parâmetros como a quantidade de execuções e oarquivo de entrada, que será criptografado ou calculado o hashing.
  • 30. Visando obter uma estimativa um pouco mais precisa do consumo energéticodo algoritmo foi medido, utilizando a mesma metodologia, o consumo do dispositivonas mesmas condições de funcionamento com o processador ocioso, para tal processofoi escrito um Shell script que faz com que o processador fique ocioso por determinadotempo. 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 serexecutadas, o arquivo a ser criptografado e se o processo é de encriptação oudecriptação. No script é definida a função getInfo que captura as informações dabateria. A função básica do script é capturar as informações da bateria, em seguidaexecutar o algoritmo a quantidade de vezes passado como parâmetro, para o arquivousado como parâmetro de entrada, e em seguida capturar novamente as informações dabateria. Por exemplo, para executar o programa Blowfish em encriptação 100 vezespara o arquivo entrada1 o script é chamado da seguinte forma: ./scriptbf.sh 100entrada1 E. Após a aquisição destes dados foram feitos os seguintes cálculos: ்௘௠௣௢ ௗ௘ ௘௫௘௖௨çã௢ ௧௢௧௔௟ (௦) 1. ܶ݁݉‫ݑܿ݁ݔ݁ ݎ݋݌ ݋݌‬çã‫ = ݋‬ ொ௨௔௡௧௜ௗ௔ௗ௘ ௗ௘ ௘௫௘௖௨çõ௘௦
  • 31. ஼௢௡௦௨௠௢ ௗ௔ ௕௔௧௘௥௜௔ ௧௢௧௔௟ (஺௛) 2. ‫ݑܿ݁ݔ݁ ݎ݋݌ ݋݉ݑݏ݊݋ܥ‬çã‫ܣ( ݋‬ℎ) = ொ௨௔௡௧௜ௗ௔ௗ௘ ௗ௘ ௘௫௘௖௨çõ௘௦ ா௡௘௥௚௜௔ ்௢௧௔௟ (஺௛) 3. ‫݉ ݁ݐ݊݁ݎݎ݋ܥ‬é݀݅ܽ (‫் = )ܣ‬௘௠௣௢ ௗ௘ ௘௫௘௖௨çã௢ ௧௢௧௔௟ ௘௠ ௛௢௥௔ 4. ܲ‫ݐ݋‬ê݊ܿ݅ܽ ݉é݀݅ܽ (ܹ ) = ‫݉ ݁ݐ݊݁ݎݎ݋ܥ‬é݀݅ܽ (‫ܸ × )ܣ‬஻௔௧௘௥௜௔ 5. ‫ݐ݋ܲ = )ܬ( ݋݉ݑݏ݊݋ܥ‬ê݊ܿ݅ܽ ݉é݀݅ܽ (ܹ ) × ܶ݁݉‫ݑܿ݁ݔ݁ ݁݀ ݋݌‬çã‫)ݏ( ݋‬ 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 deenergia 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 asdiferentes instruções. Seguindo tal conceito, a segunda metodologia de estimativa de consumo deenergia usada neste trabalho usa como base o número de ciclos de clock necessáriospara 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 algoritmoestá diretamente relacionado com o consumo energético, sendo atribuído a cada ciclouma pequena quantidade de energia consumida. O custo básico para a execução de um algoritmo é dado pelos seguintescálculos: ேú௠௘௥௢ ௗ௘ ௖௜௖௟௢௦ ௡௘௖௘௦௦á௥௜௢௦ (஼௜௖௟௢௦) 1. ܶ݁݉‫ݑܿ݁ݔ݁ ݁݀ ݋݌‬çã‫ = )ݏ( ݋‬ ಴೔೎೗೚ೞ ௏௘௟௢௖௜ௗ௔ௗ௘ ௗ௢ ௣௥௢௖௘௦௦௔ௗ௢௥ ( ) ೞ 2. ܲ‫ݐ݋‬ê݊ܿ݅ܽ ݀‫ܸ = ) ܹ( ݎ݋݀ܽݏݏ݁ܿ݋ݎ݌ ݋‬௉௥௢௖௘௦௦௔ௗ௢௥ × ‫)ܣ( ݁ݐ݊݁ݎݎ݋ܥ‬ 3. ‫ݐ݋ܲ = )ܬ( ܽ݀݅݉ݑݏ݊݋ܿ ܽ݅݃ݎ݁݊ܧ‬ê݊ܿ݅ܽ ݀‫× )ܹ( ݎ݋݀ܽݏݏ݁ܿ݋ݎ݌ ݋‬ ܶ݁݉‫ݑܿ݁ݔ݁ ݁݀ ݋݌‬çã‫)ݏ( ݋݉ݐ݅ݎ݋݈݃ܽ ݋݀ ݋‬ 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 ecaracterísticas do processador podem ser obtidas através do site do fabricante do
  • 32. mesmo. Os dados sobre a amperagem máxima e faixa de voltagem de operação dosprocessadores podem ser obtidos nos datasheet dos mesmos, geralmente fornecidospelo fabricante. 2.5.3. Metodologia 3: Simulação usando o Sim-Panalyzer A terceira metodologia empregada foi o uso do simulador de consumo deenergia para sistemas embarcados Sim-Panalyzer, que já foi devidamente explicado naseção 2.4.5. A aplicação do Sim-Panalyzer é feita de forma simples, necessitando apenasexecutar o simulador passando como parâmetro a arquitetura a ser simulada, juntamentecom 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 consumoenergético de cada componente simulado pelo Sim-Panalyzer, obtendo então o consumogeral 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 consumoenergético de um processador é medir a corrente drenada pelo mesmo em função dotempo, e este é o principal objetivo desta quarta metodologia. Devido à dificuldade de acesso aos esquemas elétrico do hardware da placa mãedisponível para teste e devido a propriedade intelectual, ficou impossibilitada a mediçãodo consumo diretamente nos pinos alimentadores do processador, impossibilitandoentã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
  • 33. trabalho foi alterada e assumiu como base a medição da corrente total consumida peloconector ATX12V [1] da placa mãe, que fornece energia para os reguladores de tensãoque por sua vez fornecem energia para o processador. Ao calcular o consumo doprocessador deve ser considerado o fato de os sistemas reguladores de voltagemapresentam eficiência média de 80%, segundo SCHUELLEIN [7]. A medição é feita inserindo um resistor shunt de valor conhecido em série entrea fonte de alimentação e a placa mãe e usando um osciloscópio é medida a variação devoltagem antes e depois do resistor, conforme esquema da Figura 2.4. Com este circuitomontado é possível então calcular a corrente consumida pela placa mãe, econsequentemente a sua potência consumida, através das seguintes fórmulas: ܸܽ‫ܽ݅ݎ‬çã‫) ܸ( ݉݁݃ܽݐ݈݋ܸ ݁݀ ݋‬ ‫ = )ܣ( ݁ݐ݊݁ݎݎ݋ܥ‬ ܴ݁‫ݐݏ݅ݏ‬ê݊ܿ݅ܽ (ܱℎ݉) ܲ‫ݐ݋‬ê݊ܿ݅ܽ (ܹ ) = ‫)ܸ( ݉݁݃ܽݐ݈݋ܸ .)ܣ( ݁ݐ݊݁ݎݎ݋ܥ‬ Figura 2.4. Esquema utilizado para as medições com a metodologia 4.
  • 34. 3. Testes, Resultados e Análise No presente trabalho foram realizados testes aplicando as metodologiasapresentadas na seção 2.5 usando os algoritmos SHA, rijndael (melhor conhecido comoAES) e Blowfish. Os arquivos de entrada e chaves usados como parâmetro sãoapresentados nas Tabelas 3.1 e 3.2, respectivamente. Devido a problemas de compilaçãoo 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 Chave1 32 bits Blowfish Chave2 256 bits Chave3 448 bits Chave1 128 bits Rijndael (AES) 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 aplicadautilizado um notebook Toshiba modelo T135 – S1305, com processador Intel PentiumSU4100, 3GB de memória RAM DDR3, HDD de 320GB e tela de 13,3’, executando osistema operacional Linux em sua distribuição Ubuntu 9.10.
  • 35. Devido dispositivo possuir um processador da série Intel ULV (Ultra LowVoltage, em inglês Voltagem Ultra Baixa) é esperado que ele possua o menor consumode energia dentre os dispositivos testados. Os resultados de consumo de energiaapresentados nesta seção engloba todo o dispositivo usado, incluindo dispositivo derede 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 aum baixo consumo médio, de apenas 12,2 W.Tabela 3.3. Resultados da execução do algoritmo SHA usando a primeira metodologia. Energia Potência Energia Entrada Tempo (s) Consumida (J) Média (W) 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çãoconsiderá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 foisignificativa com o aumento do tamanho do arquivo passado como parâmetro, sendoobtido uma média de consumo de 12,3 W para os arquivos entrada1 e entrada2 e 15,8W para os arquivos Money.MP3 e vídeo.MPG. Com a mudança do tamanho da chave também não foi observada nenhuma
  • 36. mudança no tempo de execução, levando à conclusão de que não há ligação entre otamanho da chave e o consumo de energia do algoritmo. Este resultado já tinha sidoobtido e observado pelo autor de [8], via simulação. Os dados obtidos com os testes usando o algoritmo Blowfish para as chaveschave1 , 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. Energia Potência Energia Entrada Tempo (s) Consumida (J) Média (W) Excedida* (J) entrada1 0,022 0,249 11,546 0,035 entrada2 0,070 0,918 13,043 0,220 E Money.mp3 0,505 7,442 14,734 2,432 vídeo.MPG 4,917 72,382 14,721 23,611 entrada1 0,021 0,283 13,313 0,072 entrada2 0,068 0,980 14,369 0,303 D Money.mp3 0,492 7,014 14,245 2,130 vídeo.MPG 4,926 71,474 14,511 22,619Tabela 3.5. Resultados da execução do algoritmo Blowfish (chave de 256 bits) usando a metodologia 1. Energia Potência Energia Entrada Tempo (s) Consumida (J) Média (W) Excedida* (J) entrada1 0,023 0,246 10,641 0,017 entrada2 0,070 0,933 13,373 0,241 E Money.mp3 0,488 8,211 16,829 3,372 vídeo.MPG 4,896 84,370 17,233 35,810 entrada1 0,019 0,194 10,264 0,007 entrada2 0,070 1,003 14,253 0,305 D Money.mp3 0,497 8,491 17,068 3,557 vídeo.MPG 4,962 82,814 16,690 33,59734
  • 37. Tabela 3.6. Resultados da execução do algoritmo Blowfish (chave de 448 bits) usando a metodologia 1. Energia Energia Potência Entrada Tempo (s) Consumida Excedida* Média (J) (J) (W) entrada1 0,022 0,238 10,853 0,020 entrada2 0,071 0,809 11,379 0,104 E 0,487 7,963 16,351 3,132 Money.mp3 vídeo.MPG 4,786 74,066 15,476 26,595 entrada1 0,021 0,237 11,472 0,032 entrada2 0,073 0,953 13,040 0,228 D 0,488 7,799 15,969 2,955 Money.mp3 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 oprocessador Intel Celeron 2.2 GHz. No datasheet fornecido pela Intel para o Celeron 2.2GHz [10] a voltagem de operação do mesmo é de 1.10 V admitindo uma correntemá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 µJpor byte para o processo de geração de hash, este valor não apresentou variação acimade 10% em relação à média para nenhum cálculo. Os resultados sobre número de ciclosnecessários, tempo de execução e energia gasta são apresentados na tabela 3.7.
  • 38. 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 qualquertamanho da chave ou de processos de encriptação ou decriptação, já que os resultadospara o número de clock obtidos foram os mesmos independentes destes parâmetros. Ogasto 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) euma média de 1,59 µJ para as entradas maiores (Money.mp3 e vídeo.MPG). Asestimativas de consumo do algoritmo Blowfish para as entradas simuladas foram asapresentadas 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 deenergia Sim-Panalyzer, e conforme descrito na seção 2.5.3 é necessário como um dosparâmetros as características do processador a ser simulado durante o teste. Para estetrabalho foi utilizado a configuração padrão presente no Sim-Panalyzer, apresentada no
  • 39. Anexo I. Esta metodologia será aplicada apenas aos arquivos entrada1 e entrada2, pois aso processo de simulação durava horas para arquivos maiores que 1 MB no dispositivoque executava a simulação. O dispositivo simulado apresentou uma potência média de 4 W, a menor dentreos métodos. Este baixo consumo é devido à simplicidade do dispositivo, o que resultaem um desempenho muito baixo, resultando em um tempo de execução grande e emconsequê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 naTabela 3.9, e apresenta um tempo de execução cerca de cem vezes maior que os outrosdispositivos 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 menordesempenho ainda, se comparado aos outros dispositivos testados, demandando 634,95Joules 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 detamanho diferente não alterarem os tempos de execução do algoritmo. Os dados dassimulações com o algoritmo Blowfish podem ser vistos na tabela 3.10.
  • 40. Tabela 3.10. Resultados da simulação de consumo para algoritmo Blowfish. Tempo Chave Operação Entrada Nº Instruções Energia (J) (s) E entrada1 17351676 164 634,9424 D entrada1 17349111 163 649,718 Chave 1 E entrada 2 86042866 798 3083,9508 D entrada 2 86030231 798 3181,3068 E entrada1 17352420 164 640,7808 D entrada1 17349983 165 653,3175 Chave 2 E entrada 2 86043570 799 3120,8141 D entrada 2 86031010 795 3144,702 E entrada1 17353136 164 639,7312 D entrada1 17350699 163 646,295 Chave 3 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 parao algoritmo Blowfish pode ser observado na Figura 3.1, e a estimativa da potênciamédia consumida por cada componente do sistema simulado pode ser observada natabela 3.11. Energia (J) 3500,00 3000,00 2500,00 2000,00 1500,00 1000,00 500,00 Energia (J) 0,00 Chave1 Chave2 Chave3 Chave1 Chave2 Chave3 Chave1 Chave2 Chave3 Chave1 Chave2 Chave3 Encriptação Decriptação Encriptação Decriptação Entrada1 Entrada1 Entrada2 Entrada2 Figura 3.1. Gráfico do custo energético para execução do algoritmo Blowfish.
  • 41. Tabela 3.11. Potência simulada ao executar o algoritmo Blowfish. Área do Encriptação Decriptação Diferença entre Sistema (W) (W) 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% 3.3.3. Algoritmo Rijndael Ao simular a execução do algoritmo rijndael foi observado que a quantidade deinstruções para a operação de decriptação é em média 95,56% o número de instruçõesda encriptação, e por este motivo, o tempo gasto na decriptação é em media 93,16% dotempo gasto na encriptação. Também é observado que a diferença entre o tempo deexecução e o número de instruções executadas da entrada1 para a entrada 2 é em media502,56% do tempo para a entrada1, que é um resultado esperado, já que o tamanho daentrada2 é cinco vezes o tamanho da entrada1. Os dados da aplicação da metodologia 3no algoritmo rijndael pode ser observado na Tabela 3.12. Com os resultados da simulação do algoritmo rijndael também foi observadoque com o aumento do tamanho da chave é também aumentado o número de instruçõesa 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 melhorobservado na figura 3.2 e a proporção deste aumento é apresentada na Tabela 3.13.
  • 42. Tabela 3.12. Resultados da simulação de consumo para algoritmo rijndael. Operação Entrada Nº Instruções Tempo (s) Energia (J) E entrada1 8211594 66 264,67 D entrada1 7801604 60 238,68Chave 1 E entrada 2 41033638 329 1329,95 D entrada 2 38986239 299 1159,58 E entrada1 9139751 72 286,17 D entrada1 8736254 66 256,07Chave 2 E entrada 2 45674310 359 1426,95 D entrada 2 43658955 330 1284,66 E entrada1 10125532 78 316,82 D entrada1 9728480 73 286,68Chave 3 E entrada 2 50602953 391 1582,38 D entrada 2 48619729 363 1389,89 Consumo de Energia do Rijndael 1800,00 1600,00 1400,00 1200,00 1000,00 800,00 600,00 400,00 Energia (J) 200,00 0,00 Chave1 Chave2 Chave3 Chave1 Chave2 Chave3 Chave1 Chave2 Chave3 Chave1 Chave2 Chave3 Encriptação Decriptação Encriptação Decriptação Entrada1 Entrada1 Entrada2 Entrada2 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. Chave1 para Chave1 para Chave2 para Algoritmo Chave2 Chave3 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 sistemasimulado para o algoritmo rijndael pode ser observada na tabela 3.14.
  • 43. 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 computadorcom processador Intel Celeron 2.2 Ghz, 512 Mb de memória RAM, HD de 40 Gb eplaca mãe Foxconn 650M02-G-6. Para a aplicação do método foram usados três resistores em paralelo, com 1 ohmde resistência e 20w de potência cada, resultando em um resistor equivalente de 0,333ohms e 60 w de potência. Este conjunto de resistores foi ligado em série no cabo dealimentação da placa mãe, conforme descrito em 2.5.4 e mostrado na figura 3.3. Após amontagem foi conectado cada um dos canais do osciloscópio da marca Owon, modeloPDS5022S, nas extremidades do conjunto de resistores para medir a queda de voltagemprovocada pela passagem de corrente.
  • 44. 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 ociosoque apresentava uma queda de 0,5V entre as extremidades do resistor, que significa umapassagem de corrente de 1,5A e uma potência de 17,25W para o sistema ocioso. Com oosciloscópio conectado também foi observado um aumento significativo do consumo deenergia com a movimentação do mouse, que resultou em uma queda de 1V entre asextremidades 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 ociosofoi 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 energianesta metodologia. 3.4.1. Algoritmo SHA-1 Para o algoritmo SHA-1 foram observados dois diferentes patamares decaracterísticas, sendo divididas entre as entradas pequenas (entrada1 e entrada2) e asentradas grandes (Money.mp3 e vídeo.MPG). Para as entradas pequenas a potênciamédia usada pelo processador foi de 30,9 W, tendo um aumento para a média de49,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 aentrada de 100 KB, 3,02 µJ para a entrada de 500 KB e em média 1,30 µJ para os
  • 45. arquivos de 4,5 MB e 46,8 MB, que não apresentou variação significativa do consumopor byte. Em testes iniciais foram usados os dois canais do osciloscópio um na entrada eoutro na saída da corrente no conjunto de resistores, representados pelo o gráficoamarelo 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 dequeda 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 aexecução. Assim foram feitas novas medições usando apenas a voltagem de saída doconjunto de resistores buscando um gráfico mais nítido da queda de voltagem. Estegráfico juntamente com os dados relativo ao consumo de energia são encontrados natabela 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.
  • 46. 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 30,90 W execução 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 30,90 W execução 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 48,43 W execução 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 50,45 W execução Consumo 63,06 J
  • 47. 3.4.2. Algoritmo Blowfish Para o algoritmo Blowfish foi observado um pequeno aumento da potênciamédia usada pelo processador com o aumento do tamanho da entrada, porém essadiferenç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 µJpor byte. Para os testes com o algoritmo Blowfish foram feitos os mesmos processosutilizados para o algoritmo SHA-1. As Figuras e Tabelas semelhantes às apresentadaspara 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 Encriptação 3.5 3.17 Chave1 – 32 bits Decriptação 3.6 3.18 Encriptação 3.7 3.19 Chave2 – 256 bits Decriptação 3.8 3.20 Encriptação 3.9 3.21 Chave3 – 448 bits Decriptação 3.10 3.22
  • 48. (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.
  • 49. 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 45,33 W execução 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 49,45 W execução 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 51,45 W execução 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 5s Variação de Voltagem 1,84 V Potência Média durante 54,37 W execução Consumo 271,86 J
  • 50. 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 45,33 W execução 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 49,45 W execução 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 51,45 W execução 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 54,37 W execução Consumo 277,29 J
  • 51. (a) (b) (c) (d)Figura 3.7. Gráficos da variação da voltagem ao executar uma encriptação com oalgoritmo 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 oalgoritmo Blowfish usando chave de 256 bits para as entradas: (a) entrada1, (b) entrada2, (c) Money.mp3 e (d) vídeo.MPG.
  • 52. 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 45,33 W execução 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 49,45 W execução 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 51,45 W execução 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 54,37 W execução Consumo 282,73 J
  • 53. 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 45,33 W execução 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 49,45 W execução 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 51,45 W execução 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 54,37 W execução Consumo 282,73 J
  • 54. (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.
  • 55. 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 45,33 W execução 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 49,45 W execução 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 51,45 W execução 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 54,37 W execução Consumo 282,73 J
  • 56. 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 45,33 W execução 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 49,45 W execução 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 51,45 W execução 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 54,37 W execução Consumo 277,29 J
  • 57. 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 erijndael. Os resultados do consumo (em Joules) da aplicação desses métodos sãoapresentados na Tabela 3.24. Para efeito comparativo, também são apresentadas as Tabelas 2.23, 2.25 e 2.26que apresentam, respectivamente, um comparativo entre a potência média, o consumoem µJ por byte do arquivo de entrada e o tempo de execução para cada metodologiausada no trabalho. Os resultados encontrados foram esperados, com um melhor desempenho geralsendo apresentado pelo notebook (testado na metodologia 1), seguido pela estimativa doconsumo do processador (metodologia 2), em seqüência o consumo real do mesmodispositivo simulado na metodologia 2 (medido usando a metodologia 4) e finalizandocom o consumo simulado pela ferramenta Sim-Panalyzer. A ferramenta apresentou omaior consumo dentre os dispositivos, pois apesar de possuir a menor potência,apresentava um desempenho sofrível para os arquivos usados no trabalho, sendonecessá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 SHA Money.mp3 11,216 38,5 48,43 NA vídeo.MPG 13,935 38,5 50,45 entrada1 11,35 38,5 45,33 3,89 entrada2 13,24 38,5 49,45 Blow fish Encriptação 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 3,97 entrada2 13,24 38,5 49,45 Blow fish Decriptação Money.mp3 15,87 38,5 51,45 NA vídeo.MPG 15,75 38,5 54,37 Rijndael Encriptação 4,02 NA NA NA NA Rijndael Decriptação 3,9
  • 58. Tabela 3.24. Comparativo do consumo em Joules entre as diferentes metodologias.Algoritmo Chave Arquivo Me todologia 1 Metodologia 2 Me todologia 3 Me todologia 4 entrada1 0,72 0,035 102,61 1,24 entrada2 0,93 0,175 511,87 1,55 SHA NA 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 Blowfish entrada2 0,92 0,525 3083,95 4,45 Chave1Encriptação 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 Blowfish entrada2 0,98 0,525 3181,31 3,96 Chave1Decriptação 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 Blowfish entrada2 0,933 0,525 3120,81 3,96 Chave2Encriptação 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 Blowfish entrada2 1,003 0,525 3144,7 3,96 Chave2Decriptação 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 Blowfish entrada2 0,809 0,525 3105,23 3,96 Chave3Encriptação 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 Blowfish entrada2 0,953 0,525 3150,46 3,96 Chave3Decriptação Money.mp3 7,799 7,525 NA 28,29 vídeo.MPG 75,689 77,7 NA 277,29 Rijndael entrada1 NA NA 264,67 NA Chave1Encriptação entrada2 NA NA 1329,95 NA Rijndael entrada1 NA NA 238,68 NA Chave1Decriptação entrada2 NA NA 1159,58 NA Rijndael entrada1 NA NA 286,17 NA Chave2Encriptação entrada2 NA NA 1426,95 NA Rijndael entrada1 NA NA 256,07 NA Chave2Decriptação entrada2 NA NA 1284,66 NA Rijndael entrada1 NA NA 316,82 NA Chave3Encriptação entrada2 NA NA 1582,38 NA Rijndael entrada1 NA NA 286,68 NA Chave3Decriptação entrada2 NA NA 1389,89 NA
  • 59. Tabela 3.25. Comparativo do consumo (em µJ) dos algoritmos estudados por byte do arquivo de entrada. Algoritmo Chave Arquivo Metodologia 1 Metodologia 2 Me todologia 3 Me todologia 4 entrada1 7,03 0,34 1002,05 12,07 entrada2 1,82 0,34 999,75 3,02 SHA NA 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,69Blowfish Encriptação Chave1 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,73Blowfish Decriptação Chave1 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,73Blowfish Encriptação Chave2 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,73Blowfish Decriptação Chave2 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,73Blowfish Encriptação Chave3 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,73Blowfish Decriptação Chave3 Money.mp3 1,65 1,59 NA 6,00 vídeo.MPG 1,54 1,58 NA 5,65 entrada1 NA NA 2584,67 NARijndael Encriptação Chave1 entrada2 NA NA 2597,56 NA entrada1 NA NA 2330,86 NARijndael Decriptação Chave1 entrada2 NA NA 2264,80 NA entrada1 NA NA 2794,63 NARijndael Encriptação Chave2 entrada2 NA NA 2787,01 NA entrada1 NA NA 2500,68 NARijndael Decriptação Chave2 entrada2 NA NA 2509,10 NA entrada1 NA NA 3093,95 NARijndael Encriptação Chave3 entrada2 NA NA 3090,59 NA entrada1 NA NA 2799,61 NARijndael Decriptação Chave3 entrada2 NA NA 2714,63 NA
  • 60. 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 entrada1 0,061 0,001 25,000 0,040 entrada2 0,079 0,005 124,000 0,050 SHA NA Money.mp3 0,234 0,036 NA 0,130 vídeo.MPG 1,375 0,391 NA 1,250 entrada1 0,022 0,002 164,000 0,040 Blowfish entrada2 0,070 0,014 798,000 0,090 Chave1Encriptação Money.mp3 0,505 0,195 NA 0,600 vídeo.MPG 4,917 2,018 NA 5,000 entrada1 0,021 NA 163,000 0,040 Blowfish entrada2 0,068 NA 798,000 0,080 Chave1Decriptação Money.mp3 0,492 NA NA 0,500 vídeo.MPG 4,926 NA NA 5,100 entrada1 0,023 NA 164,000 0,040 Blowfish entrada2 0,070 NA 799,000 0,080 Chave2Encriptação Money.mp3 0,488 NA NA 0,500 vídeo.MPG 4,896 NA NA 5,200 entrada1 0,019 NA 165,000 0,040 Blowfish entrada2 0,070 NA 795,000 0,080 Chave2Decriptação Money.mp3 0,497 NA NA 0,500 vídeo.MPG 4,962 NA NA 5,200 entrada1 0,022 NA 164,000 0,040 Blowfish entrada2 0,071 NA 799,000 0,080 Chave3Encriptação Money.mp3 0,487 NA NA 0,500 vídeo.MPG 4,786 NA NA 5,200 entrada1 0,021 NA 163,000 0,040 Blowfish entrada2 0,073 NA 797,000 0,080 Chave3Decriptação Money.mp3 0,488 NA NA 0,550 vídeo.MPG 4,771 NA NA 5,100 Rijndael entrada1 NA NA 66,000 NA Chave1Encriptação entrada2 NA NA 329,000 NA Rijndael entrada1 NA NA 60,000 NA Chave1Decriptação entrada2 NA NA 299,000 NA Rijndael entrada1 NA NA 72,000 NA Chave2Encriptação entrada2 NA NA 359,000 NA Rijndael entrada1 NA NA 66,000 NA Chave2Decriptação entrada2 NA NA 330,000 NA Rijndael entrada1 NA NA 78,000 NA Chave3Encriptação entrada2 NA NA 391,000 NA Rijndael entrada1 NA NA 73,000 NA Chave3Decriptação entrada2 NA NA 363,000 NA
  • 61. 4. Conclusões Com a finalização do trabalho, foi possível concluir a real importância doconsumo energético, visto o grande aumento de consumo com dispositivo emprocessamento, como mostrado na seção 3.4 uma simples movimentação do mousepode causar um aumento de até 90% do consumo em relação ao sistema ocioso. Comojá apresentado o consumo de energia é um fator importante na viabilidade dos projetosde sistemas embarcados, além da consciência ambiental globalmente difundida, que fazcom 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 ossistemas embarcados, conceitos de segurança de dados, o algoritmo MiBench e diversasmetodologias e ferramentas para medição do consumo de energia de dispositivoscomputacionais. Estes estudos resultaram em um embasamento necessário para aaplicação das metodologias e a análise dos resultados. As metodologias empregadas buscaram abranger diferentes métodos demedição para dispositivos distintos, resultando também em diversos padrões deconsumo. Os resultados apresentados pelas diferentes metodologias são apresentados aseguir: • 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.
  • 62. • 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 osseguintes: • Identificar os trechos de códigos que mais consomem energia, sendopossível analisar modificações para os códigos a fim de reduzir o consumo energéticodos mesmos; • Aplicar as metodologias empregadas neste trabalho para todos osprogramas 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 deconfiguração do processador ARM com características para um melhor desempenho; • Aplicar as metodologias diferentes na mesma plataforma para obter umcomparativo mais real e assim mostrar a melhor metodologia.
  • 63. 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
  • 64. 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.
  • 65. 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
  • 66. # 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 ALUs 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 ALUs 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
  • 67. Anexo IIsim: ** starting performance simulation **acd9f7e1 d3edf2d9 c5b917e9 9b4b88eb e782cf7esim: ** simulation statistics **sim_num_insn 4451010 # total number of instructions committedsim_num_uops 5809096 # total number of UOPs executedsim_avg_flowlen 1.3051 # uops per instructionsim_num_refs 1157733 # total number of loads and stores committedsim_num_loads 750795 # total number of loads committedsim_num_stores 406938.0000 # total number of stores committedsim_num_branches 304227 # total number of branches committedsim_elapsed_time 25 # total simulation time in secondssim_inst_rate 178040.4000 # simulation speed (in insts/sec)sim_total_insn 5808883 # total number of instructions executedsim_total_refs 1186538 # total number of loads and stores executedsim_total_loads 770045 # total number of loads executedsim_total_stores 416493.0000 # total number of stores executedsim_total_branches 306106 # total number of branches executedsim_cycle 1756778 # total simulation time in cyclessim_IPC 2.5336 # instructions per cyclesim_CPI 0.3947 # cycles per instructionsim_exec_BW 3.3066 # total instructions (mis-spec + committed) per cyclesim_IPB 14.6306 # instruction per branchIFQ_count 6505472 # cumulative IFQ occupancyIFQ_fcount 1542372 # cumulative IFQ full countifq_occupancy 3.7031 # avg IFQ occupancy (insns)ifq_rate 3.3066 # avg IFQ dispatch rate (insn/cycle)ifq_latency 1.1199 # avg IFQ occupant latency (cycles)ifq_full 0.8780 # fraction of time (cycles) IFQ was fullRUU_count 24563465 # cumulative RUU occupancyRUU_fcount 1250767 # cumulative RUU full countruu_occupancy 13.9821 # avg RUU occupancy (insns)ruu_rate 3.3066 # avg RUU dispatch rate (insn/cycle)ruu_latency 4.2286 # avg RUU occupant latency (cycles)ruu_full 0.7120 # fraction of time (cycles) RUU was fullLSQ_count 6238725 # cumulative LSQ occupancyLSQ_fcount 221524 # cumulative LSQ full countlsq_occupancy 3.5512 # avg LSQ occupancy (insns)lsq_rate 3.3066 # avg LSQ dispatch rate (insn/cycle)lsq_latency 1.0740 # avg LSQ occupant latency (cycles)lsq_full 0.1261 # fraction of time (cycles) LSQ was fullsim_slip 36288134 # total number of slip cycles
  • 68. avg_sim_slip 8.1528 # the average slip between issue and retirementbpred_bimod.lookups 309404 # total number of bpred lookupsbpred_bimod.updates 304227 # total number of updatesbpred_bimod.addr_hits 290914 # total number of address-predicted hitsbpred_bimod.dir_hits 291061 # total number of direction-predicted hits (includes addr-hits)bpred_bimod.misses 13166 # total number of missesbpred_bimod.jr_hits 0 # total number of address-predicted hits for JRsbpred_bimod.jr_seen 0 # total number of JRs seenbpred_bimod.jr_non_ras_hits.PP 0 # total number of address-predicted hits for non-RASJRsbpred_bimod.jr_non_ras_seen.PP 0 # total number of non-RAS JRs seenbpred_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 stackbpred_bimod.retstack_pops 0 # total number of address popped off of ret-addr stackbpred_bimod.used_ras.PP 0 # total number of RAS predictions usedbpred_bimod.ras_hits.PP 0 # total number of RAS hitsbpred_bimod.ras_rate.PP <error: divide by zero> # RAS prediction rate (i.e., RAS hits/usedRAS)concurrent_misses 8 # total number of concurrent missesprefetch_hits 651 # total number of prefetch hitsil1.accesses 4602702 # total number of accessesil1.hits 4602122 # total number of hitsil1.misses 580 # total number of missesil1.replacements 181 # total number of replacementsil1.writebacks 0 # total number of writebacksil1.invalidations 0 # total number of invalidationsil1.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 accessesdl1.hits 1158995 # total number of hitsdl1.misses 441 # total number of missesdl1.replacements 22 # total number of replacementsdl1.writebacks 4 # total number of writebacksdl1.invalidations 0 # total number of invalidationsdl1.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 accessesul2.hits 500 # total number of hitsul2.misses 525 # total number of missesul2.replacements 0 # total number of replacementsul2.writebacks 0 # total number of writebacksul2.invalidations 0 # total number of invalidationsul2.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 accessesitlb.hits 4602684 # total number of hitsitlb.misses 18 # total number of missesitlb.replacements 0 # total number of replacements
  • 69. itlb.writebacks 0 # total number of writebacksitlb.invalidations 0 # total number of invalidationsitlb.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 accessesdtlb.hits 1159419 # total number of hitsdtlb.misses 25 # total number of missesdtlb.replacements 0 # total number of replacementsdtlb.writebacks 0 # total number of writebacksdtlb.invalidations 0 # total number of invalidationsdtlb.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 baseld_text_bound 0x0202deb4 # program text (code) segment boundld_text_size 187892 # program text (code) size in bytesld_data_base 0x00001c10 # program initialized data segment baseld_data_bound 0x0203e214 # program initialized data segment boundld_data_size 33801732 # program inited `.data and uninited `.bss size in bytesld_stack_base 0xc0000000 # program stack segment base (highest address in stack)ld_stack_size 16384 # program initial stack sizeld_prog_entry 0x020000e0 # program entry point (initial PC)ld_environ_base 0xbfffc000 # program environment base address addressld_target_big_endian 0 # target executable endian-ness, non-zero if big endianmem.page_count 61 # total number of pages allocatedmem.page_mem 244k # total size of memory pages allocatedmem.ptab_misses 61 # total first level page table missesmem.ptab_accesses 20657674 # total page table accessesmem.ptab_miss_rate 0.0000 # first level page table miss rateaio.switching 460.6906 # aio total in switching power dissipationaio.avgswitching 0.0003 # aio avg in switching power dissipationaio.internal 541.4824 # aio total internal power dissipationaio.avginternal 0.0003 # aio avg internal power dissipationaio.leakage 2214.7103 # aio total leakage power dissipationaio.avgleakage 0.0013 # aio avg leakage power dissipationaio.pdissipation 459333.5571 # aio total power dissipationaio.avgpdissipation 0.2615 # aio avg power dissipationaio.peak 2.3499 # aio peak power dissipationdio.switching 1776.9496 # dio total in switching power dissipationdio.avgswitching 0.0010 # dio avg in switching power dissipationdio.internal 2088.5750 # dio total internal power dissipationdio.avginternal 0.0012 # dio avg internal power dissipationdio.leakage 2214.7103 # dio total leakage power dissipationdio.avgleakage 0.0013 # dio avg leakage power dissipationdio.pdissipation 1510834.9856 # dio total power dissipationdio.avgpdissipation 0.8600 # dio avg power dissipationdio.peak 3.2690 # dio peak power dissipationirf.switching 10914.1717 # irf total in switching power dissipationirf.avgswitching 0.0062 # irf avg in switching power dissipationirf.internal 254208.5334 # irf total internal power dissipationirf.avginternal 0.1447 # irf avg internal power dissipationirf.leakage 337.9410 # irf total leakage power dissipationirf.avgleakage 0.0002 # irf avg leakage power dissipationirf.pdissipation 273394.9147 # irf total power dissipationirf.avgpdissipation 0.1556 # irf avg power dissipationirf.peak 0.2403 # irf peak power dissipation
  • 70. fprf.switching 0.0000 # fprf total in switching power dissipationfprf.avgswitching 0.0000 # fprf avg in switching power dissipationfprf.internal 0.0000 # fprf total internal power dissipationfprf.avginternal 0.0000 # fprf avg internal power dissipationfprf.leakage 417.4601 # fprf total leakage power dissipationfprf.avgleakage 0.0002 # fprf avg leakage power dissipationfprf.pdissipation 0.0000 # fprf total power dissipationfprf.avgpdissipation 0.0000 # fprf avg power dissipationfprf.peak 0.0000 # fprf peak power dissipationil1.switching 38677.5244 # il1 total in switching power dissipationil1.avgswitching 0.0220 # il1 avg in switching power dissipationil1.internal 796965.5519 # il1 total internal power dissipationil1.avginternal 0.4537 # il1 avg internal power dissipationil1.leakage 1301.9083 # il1 total leakage power dissipationil1.avgleakage 0.0007 # il1 avg leakage power dissipationil1.pdissipation 892449.3741 # il1 total power dissipationil1.avgpdissipation 0.5080 # il1 avg power dissipationil1.peak 0.7270 # il1 peak power dissipationdl1.switching 9738.3073 # dl1 total in switching power dissipationdl1.avgswitching 0.0055 # dl1 avg in switching power dissipationdl1.internal 204502.9303 # dl1 total internal power dissipationdl1.avginternal 0.1164 # dl1 avg internal power dissipationdl1.leakage 1434.2924 # dl1 total leakage power dissipationdl1.avgleakage 0.0008 # dl1 avg leakage power dissipationdl1.pdissipation 450249.8116 # dl1 total power dissipationdl1.avgpdissipation 0.2563 # dl1 avg power dissipationdl1.peak 0.7404 # dl1 peak power dissipationdl2.switching 9738.3073 # dl2 total in switching power dissipationdl2.avgswitching 0.0055 # dl2 avg in switching power dissipationdl2.internal 204502.9303 # dl2 total internal power dissipationdl2.avginternal 0.1164 # dl2 avg internal power dissipationdl2.leakage 1434.2924 # dl2 total leakage power dissipationdl2.avgleakage 0.0008 # dl2 avg leakage power dissipationdl2.pdissipation 450249.8116 # dl2 total power dissipationdl2.avgpdissipation 0.2563 # dl2 avg power dissipationdl2.peak 0.7404 # dl2 peak power dissipationitlb.switching 6067.4126 # itlb total in switching power dissipationitlb.avgswitching 0.0035 # itlb avg in switching power dissipationitlb.internal 25685.4976 # itlb total internal power dissipationitlb.avginternal 0.0146 # itlb avg internal power dissipationitlb.leakage 72.8502 # itlb total leakage power dissipationitlb.avgleakage 0.0000 # itlb avg leakage power dissipationitlb.pdissipation 33947.7506 # itlb total power dissipationitlb.avgpdissipation 0.0193 # itlb avg power dissipationitlb.peak 0.0276 # itlb peak power dissipationdtlb.switching 1529.7635 # dtlb total in switching power dissipationdtlb.avgswitching 0.0009 # dtlb avg in switching power dissipationdtlb.internal 11953.7473 # dtlb total internal power dissipationdtlb.avginternal 0.0068 # dtlb avg internal power dissipationdtlb.leakage 116.4295 # dtlb total leakage power dissipationdtlb.avgleakage 0.0001 # dtlb avg leakage power dissipationdtlb.pdissipation 28347.6463 # dtlb total power dissipationdtlb.avgpdissipation 0.0161 # dtlb avg power dissipationdtlb.peak 0.1164 # dtlb peak power dissipationbtb.switching 284.1991 # btb total in switching power dissipationbtb.avgswitching 0.0002 # btb avg in switching power dissipationbtb.internal 155568.0689 # btb total internal power dissipationbtb.avginternal 0.0886 # btb avg internal power dissipationbtb.leakage 5022.7334 # btb total leakage power dissipationbtb.avgleakage 0.0029 # btb avg leakage power dissipation
  • 71. btb.pdissipation 888184.5816 # btb total power dissipationbtb.avgpdissipation 0.5056 # btb avg power dissipationbtb.peak 1.5114 # btb peak power dissipationbimod.switching 96.4536 # bimod total in switching power dissipationbimod.avgswitching 0.0001 # bimod avg in switching power dissipationbimod.internal 4371.1894 # bimod total internal power dissipationbimod.avginternal 0.0025 # bimod avg internal power dissipationbimod.leakage 649.2541 # bimod total leakage power dissipationbimod.avgleakage 0.0004 # bimod avg leakage power dissipationbimod.pdissipation 25968.9642 # bimod total power dissipationbimod.avgpdissipation 0.0148 # bimod avg power dissipationbimod.peak 0.0433 # bimod peak power dissipationras.switching 0.0000 # ras total in switching power dissipationras.avgswitching 0.0000 # ras avg in switching power dissipationras.internal 0.0000 # ras total internal power dissipationras.avginternal 0.0000 # ras avg internal power dissipationras.leakage 34.1407 # ras total leakage power dissipationras.avgleakage 0.0000 # ras avg leakage power dissipationras.pdissipation 0.0000 # ras total power dissipationras.avgpdissipation 0.0000 # ras avg power dissipationras.peak 0.0000 # ras peak power dissipationlogic.switching 48.8092 # logic total in switching power dissipationlogic.avgswitching 0.0000 # logic avg in switching power dissipationlogic.internal 0.0000 # logic total internal power dissipationlogic.avginternal 0.0000 # logic avg internal power dissipationlogic.leakage 0.0000 # logic total leakage power dissipationlogic.avgleakage 0.0000 # logic avg leakage power dissipationlogic.pdissipation 48.7139 # logic total power dissipationlogic.avgpdissipation 0.0000 # logic avg power dissipationlogic.peak 0.0000 # logic peak power dissipationclock.switching 153268.8061 # clock total in switching power dissipationclock.avgswitching 0.0872 # clock avg in switching power dissipationclock.internal 164344.1037 # clock total internal power dissipationclock.avginternal 0.0935 # clock avg internal power dissipationclock.leakage 73.6165 # clock total leakage power dissipationclock.avgleakage 0.0000 # clock avg leakage power dissipationclock.pdissipation 317686.5263 # clock total power dissipationclock.avgpdissipation 0.1808 # clock avg power dissipationclock.peak 0.1808 # clock peak power dissipationalu access 4557594 # number of times alu is accessedalu max power 0.0004 # Maximum power for alualu total power 1720.3094 # Total power for alualu avg power 0.0010 # Avg power for alumult access 14 # number of times mult is accessedmult max power 0.0004 # Maximum power for multmult total power 0.0053 # Total power for multmult avg power 0.0000 # Avg power for multfpu access 0 # number of times fpu is accessedfpu max power 0.0000 # Maximum power for fpufpu total power 0.0000 # Total power for fpufpu avg power 0.0000 # Avg power for fpuuarch.switching 222816.2365 # uarch total in switching power dissipationuarch.avgswitching 0.1268 # uarch avg in switching power dissipationuarch.internal 1624630.0158 # uarch total internal power dissipationuarch.avginternal 0.9248 # uarch avg internal power dissipationuarch.leakage 32356.0016 # uarch total leakage power dissipationuarch.avgleakage 0.0184 # uarch avg leakage power dissipationuarch.pdissipation 1879802.2540 # uarch total power dissipationuarch.avgpdissipation 1.0700 # uarch avg power dissipationuarch.peak 6.4156 # uarch peak power dissipation
  • 72. Anexo III/* NIST Secure Hash Algorithm *//* heavily modified by Uwe Hollerbach uh@alumni.caltech edu *//* from Peter C. Gutmanns implementation as found in *//* Applied Cryptography by Bruce Schneier *//* NISTs 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];
  • 73. 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)
  • 74. { 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;
  • 75. 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 8192void 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 %08lxn", sha_info->digest[0], sha_info->digest[2], sha_info->digest[4], sha_info->digest[5], sha_info->digest[6]);}
  • 76. Anexo IV#include <stdio.h>#include "blowfish.h"intmain(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> keyn"); 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> keyn"); 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 */
  • 77. { printf("key must be in hexadecimal notationn"); 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> keyn"); exit(-1);};if ((fp2 = fopen(argv[5],"w"))==0){ printf("Usage: blowfish {e|d} <intput> <output> keyn"); 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);}