DOCSLIB.ORG

Data Encryption Routines for the PIC18

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Data Encryption Routines for the PIC18 AN953 Data Encryption Routines for the PIC18 Author: David Flowers ENCRYPTION MODULE OVERVIEW Microchip Technology Inc. • Four algorithms to choose from, each with their own benefits INTRODUCTION • Advanced Encryption Standard (AES) This Application Note covers four encryption - Modules available in C, Assembly and algorithms: AES, XTEA, SKIPJACK® and a simple Assembly written for C encryption algorithm using a pseudo-random binary - Allows user to decide to include encoder, sequence generator. The science of cryptography decoder or both dates back to ancient Egypt. In today’s era of informa- - Allows user to pre-program a decryption key tion technology where data is widely accessible, into the code or use a function to calculate sensitive material, especially electronic data, needs to the decryption key be encrypted for the user’s protection. For example, a • Tiny Encryption Algorithm version 2 (XTEA) network-based card entry door system that logs the persons who have entered the building may be suscep- - Modules available in C and Assembly tible to an attack where the user information can be - Programmable number of iteration cycles stolen or manipulated by sniffing or spoofing the link • SKIPJACK between the processor and the memory storage - Module available in C device. If the information is encrypted first, it has a • Pseudo-random binary sequence generator XOR better chance of remaining secure. Many encryption encryption algorithms provide protection against someone reading - Modules available in C and Assembly the hidden data, as well as providing protection against tampering. In most algorithms, the decryption process - Allows user to change the feedback taps at will cause the entire block of information to be run-time destroyed if there is a single bit error in the block prior - KeyJump breaks the regular cycle of the to to decryption. increase the variability of the sequence • Out-of-the-box support for MPLAB® C 18 • Various compiling options to customize routines for a specific application - Available as a Microchip Application Maestro™ module to simplify customization 2005 Microchip Technology Inc. DS00953A-page 1 AN953 AES Overview/History/Background The Advanced Encryption Standard (AES) is a means of encrypting and decrypting data adopted by the National Institute of Standards and Technology (NIST) on October 2, 2000. In the late 1990s, NIST held a contest to initiate the development of encryption algorithms that would replace the Data Encryption Standard (DES). The contest tested the algorithms’ security and execution speed to determine which would be named the AES. The algorithm chosen is called the “Rijndael” algorithm after its two designers, Joan Daemen and Vincent Rijmen of Belgium. AES is a symmetric block cipher that utilizes a secret key to encrypt data. The implementation of AES in this application note is based on a 16-byte block of data and a 16-byte key size. DS00953A-page 2 2005 Microchip Technology Inc. AN953 ENCRYPTION FIGURE 1: AES ENCRYPT FLOWCHART ENCRYPTION Round Counter = 10 Rcon = 1 Key Addition S-Table Substitution Encode Row Shift True Round Counter = 1? False Encode Mix Column Encode Key Schedule Key Addition Round Counter - 1 Round Counter = 0? False True END 2005 Microchip Technology Inc. DS00953A-page 3 AN953 There are five basic subdivisions of the encryption flowchart. A detailed explanation of each will follow. The number of rounds needed in the transformation is taken from the following table. 16-Byte 24-Byte 32-Byte Block Block Block 16-byte key 10* 12 14 24-byte key 12 12 14 32-byte key 14 14 14 * Used in this implementation. This implementation of AES uses a 16-byte block and a 16-byte key and thus uses 10 rounds of encryption. On the last encryption round, the mix column subdivision is left out. The structures of the key and data blocks are shown below. TABLE 1: KEY MATRIX: Key [0] Key [4] Key [8] Key [12] Key [16] Key [20] Key [24] Key [28] Key [1] Key [5] Key [9] Key [13] Key [17] Key [21] Key [25] Key [29] Key [2] Key [6] Key [10] Key [14] Key [18] Key [22] Key [26] Key [30] Key [3] Key [7] Key [11] Key [15] Key [19] Key [23] Key [27] Key [31] TABLE 2: DATA MATRIX: Data [0] Data [4] Data [8] Data [12] Data [16] Data [20] Data [24] Data [28] Data [1] Data [5] Data [9] Data [13] Data [17] Data [21] Data [25] Data [29] Data [2] Data [6] Data [10] Data [14] Data [18] Data [22] Data [26] Data [30] Data [3] Data [7] Data [11] Data [15] Data [19] Data [23] Data [27] Data [31] To fit into the data matrix structure, the plain text to be encrypted needs to be broken into the appropriate size blocks, with any leftover space being padded. For example, take the following quote from “A Tale of Two Cities”, by Charles Dickens. “It was the best of times, it was the worst of times, …”. Broken into 16-byte blocks, the data would now look similar to this: EXAMPLE 1: PLAIN TEXT DIVIDED INTO 16-BYTE BLOCKS It was the best of times, it was the worst of ti mes, ... tuvwxyz(1) Note 1: If any of the blocks do not fit into the correct size matrix, the values must be padded at the end of the block. In this case, “tuvwxyz” is added to the end of the quote to complete the last block. Finally a key must be selected that is 128-bits long. For all of the examples in this document, the key will be [Charles Dickens]. With a key selected and the data sectioned off into appropriate size blocks, the encryption cycle may now begin. DS00953A-page 4 2005 Microchip Technology Inc. AN953 S-Table (Encryption Substitution Table): S-Table Substitution is a direct table lookup and replacement of the data. Below is the C code for this procedure: for(i=0;i<BLOCKSIZE;i++) { block[i]=STable[block[i]]; } The values of the table are defined in the following chart. TABLE 3: S-BOX OR ENCRYPTION SUBSTITUTION TABLE (VALUES IN HEXADECIMAL) y 00 10 20 30 40 50 60 70 80 90 A0 B0 C0 D0 E0 F0 00 63 7C 77 7B F2 6B 6F C5 30 01 67 2B FE D7 AB 76 01 CA 82 C9 7D FA 59 47 F0 AD D4 A2 AF 9C A4 72 C0 02 B7 FD 93 26 36 3F F7 CC 34 A5 E5 F1 71 D8 31 15 03 04 C7 23 C3 18 96 05 9A 07 12 80 E2 EB 27 B2 75 04 09 83 2C 1A 1B 6E 5A A0 52 3B D6 B3 29 E3 2F 84 05 53 D1 00 ED 20 FC B1 5B 6A CB BE 39 4A 4C 58 CF x 06 D0 EF AA FB 43 4D 33 85 45 F9 02 7F 50 3C 9F A8 07 51 A3 40 8F 92 9D 38 F5 BC B6 DA 21 10 FF F3 D2 08 CD 0C 13 EC 5F 97 44 17 C4 A7 7E 3D 64 5D 19 73 09 60 81 4F DC 22 2A 90 88 46 EE B8 14 DE 5E 0B DB 0A E0 32 3A 0A 49 06 24 5C C2 D3 AC 62 91 95 E4 79 0B E7 C8 37 6D 8D D5 4E A9 6C 56 F4 EA 65 7A AE 08 0C BA 78 25 2E 1C A6 B4 C6 E8 DD 74 1F 4B BD 8B 8A 0D 70 3E B5 66 48 03 F6 0E 61 35 57 B9 86 C1 1D 9E 0E E1 F8 98 11 69 D9 8E 94 9B 1E 87 E9 CE 55 28 DF 0F 8C A1 89 0D BF E6 42 68 41 99 2D 0F B0 54 BB 16 2005 Microchip Technology Inc. DS00953A-page 5 AN953 Xtime xtime(a) is a predefined linear feedback shift register 6. Column 3 is XORed with column 2: that repeats every 51 cycles. The operation is defined K12 ^= K8 as: K13 ^= K9 if(a<0x80) { K14 ^= K10 a<<=1; K15 ^= K11 } else Key Addition: { a=a<<1)^0x1b; Key addition is defined as each byte of the key XORed } with each of the corresponding data bytes. The key addition process is the same for both the encryption Key Schedule and decryption processes. The following is a C-code example: Each round of AES uses a different encryption key based on the previous encryption key. An example for(i=0;i<16;i++) follows that takes a given key and calculates the next { data[i] ^= key[i]; round’s key. } EXAMPLE 2: KEY GENERATION Row Shift Given the generic key: Row shift is a cyclical shift to the left of the rows in the data block according to the table below: K1 K4 K8 K12 K2 K5 K9 K13 TABLE 4: ENCRYPTION CYCLICAL K3 K6 K10 K14 SHIFT TABLE K4 K7 K11 K15 # shifts # shifts # shifts # shifts The key scheduling goes as follows: of row 0 of row 1 of row 2 of row 3 1. Column 0 is XORed with the S_Table lookup of 16-byte block 0 1 2 3 column 3: 24-byte block 0 1 2 3 K0 ^= S_Table[K13] 32-byte block 0 1 3 4 K1 ^= S_Table[K14] Note that this transformation is different for encryption K2 ^= S_Table[K15] and decryption. K3 ^= S_Table[K12] EXAMPLE 3: TRANSFORMATION 2. K0 is XORed with Rcon Given the original data: K0 ^= Rcon; 04812 3. Rcon is updated with the xtime of Rcon 15913 Rcon = xtime(Rcon); 2 6 10 14 (the starting value of Rcon is 0x01 for encoding) 371115 4.
Load more

Recommended publications
  • Atlantic Highly Migratory Species Stock Assessment and Fisheries Evaluation Report 2019
    Atlantic Highly Migratory Species Stock Assessment and Fisheries Evaluation Report 2019 U.S. Department of Commerce | National Oceanic and Atmospheric Administration | National Marine Fisheries Service 2019 Stock Assessment and Fishery Evaluation Report for Atlantic Highly Migratory Species Atlantic Highly Migratory Species Management Division May 2020 Highly Migratory Species Management Division NOAA Fisheries 1315 East-West Highway Silver Spring, MD 20910 Phone (301) 427-8503 Fax (301) 713-1917 For HMS Permitting Information and Regulations • HMS recreational fishermen, commercial fishermen, and dealer compliance guides: www.fisheries.noaa.gov/atlantic-highly-migratory-species/atlantic-hms-fishery- compliance-guides • Regulatory updates for tunas: hmspermits.noaa.gov For HMS Permit Purchase or Renewals Open Access Vessel Permits Issuer Permits Contact Information HMS Permit HMS Charter/Headboat, (888) 872-8862 Shop Atlantic Tunas (General, hmspermits.noaa.gov Harpoon, Trap), Swordfish General Commercial, HMS Angling (recreational) Southeast Commercial Caribbean Small (727) 824-5326 Regional Boat, Smoothhound Shark www.fisheries.noaa.gov/southeast/resources- Office fishing/southeast-fisheries-permits Greater Incidental HMS Squid Trawl (978) 281-9370 Atlantic www.fisheries.noaa.gov/new-england-mid- Regional atlantic/resources-fishing/vessel-and-dealer- Fisheries permitting-greater-atlantic-region Office Limited Access Vessel Permits Issuer Permits Contact Information HMS Permit Atlantic Tunas Purse Seine (888) 872-8862 Shop category hmspermits.noaa.gov
    [Show full text]
  • Optimizing the Block Cipher Resource Overhead at the Link Layer Security Framework in the Wireless Sensor Networks
    Proceedings of the World Congress on Engineering 2008 Vol I WCE 2008, July 2 - 4, 2008, London, U.K. Optimizing the Block Cipher Resource Overhead at the Link Layer Security Framework in the Wireless Sensor Networks Devesh C. Jinwala, Dhiren R. Patel and Kankar S. Dasgupta, data collected from different sensor nodes. Since the Abstract—The security requirements in Wireless Sensor processing of the data is done on-the-fly, while being Networks (WSNs) and the mechanisms to support the transmitted to the base station; the overall communication requirements, demand a critical examination. Therefore, the costs are reduced [2]. Due to the multi-hop communication security protocols employed in WSNs should be so designed, as and the in-network processing demanding applications, the to yield the optimum performance. The efficiency of the block cipher is, one of the important factors in leveraging the conventional end-to-end security mechanisms are not performance of any security protocol. feasible for the WSN [3]. Hence, the use of the standard In this paper, therefore, we focus on the issue of optimizing end-to-end security protocols like SSH, SSL [4] or IPSec [5] the security vs. performance tradeoff in the security protocols in WSN environment is rejected. Instead, appropriate link in WSNs. As part of the exercise, we evaluate the storage layer security architecture, with low associated overhead is requirements of the block ciphers viz. the Advanced Encryption required. Standard (AES) cipher Rijndael, the Corrected Block Tiny Encryption Algorithm (XXTEA) using the Output Codebook There are a number of research attempts that aim to do so.
    [Show full text]
  • Protocol Failure in the Escrowed Encryption Standard
    Protocol Failure in the Escrowed Encryption Standard Matt Blaze AT&T Bell Laboratories [email protected] August 20, 1994 Abstract The proposal, called the Escrowed Encryption Stan- dard (EES) [NIST94], includes several unusual fea- The Escrowed Encryption Standard (EES) de¯nes tures that have been the subject of considerable de- a US Government family of cryptographic processors, bate and controversy. The EES cipher algorithm, popularly known as \Clipper" chips, intended to pro- called \Skipjack", is itself classi¯ed, and implemen- tect unclassi¯ed government and private-sector com- tations of the cipher are available to the private sec- munications and data. A basic feature of key setup be- tor only within tamper-resistant modules supplied by tween pairs of EES processors involves the exchange of government-approved vendors. Software implementa- a \Law Enforcement Access Field" (LEAF) that con- tions of the cipher will not be possible. Although Skip- tains an encrypted copy of the current session key. The jack, which was designed by the US National Security LEAF is intended to facilitate government access to Agency (NSA), was reviewed by a small panel of civil- the cleartext of data encrypted under the system. Sev- ian experts who were granted access to the algorithm, eral aspects of the design of the EES, which employs a the cipher cannot be subjected to the degree of civilian classi¯ed cipher algorithm and tamper-resistant hard- scrutiny ordinarily given to new encryption systems. ware, attempt to make it infeasible to deploy the sys- By far the most controversial aspect of the EES tem without transmitting the LEAF.
    [Show full text]
  • KLEIN: a New Family of Lightweight Block Ciphers
    KLEIN: A New Family of Lightweight Block Ciphers Zheng Gong1, Svetla Nikova1;2 and Yee Wei Law3 1Faculty of EWI, University of Twente, The Netherlands fz.gong, [email protected] 2 Dept. ESAT/SCD-COSIC, Katholieke Universiteit Leuven, Belgium 3 Department of EEE, The University of Melbourne, Australia [email protected] Abstract Resource-efficient cryptographic primitives become fundamental for realizing both security and efficiency in embedded systems like RFID tags and sensor nodes. Among those primitives, lightweight block cipher plays a major role as a building block for security protocols. In this paper, we describe a new family of lightweight block ciphers named KLEIN, which is designed for resource-constrained devices such as wireless sensors and RFID tags. Compared to the related proposals, KLEIN has ad- vantage in the software performance on legacy sensor platforms, while its hardware implementation can be compact as well. Key words. Block cipher, Wireless sensor network, Low-resource implementation. 1 Introduction With the development of wireless communication and embedded systems, we become increasingly de- pendent on the so called pervasive computing; examples are smart cards, RFID tags, and sensor nodes that are used for public transport, pay TV systems, smart electricity meters, anti-counterfeiting, etc. Among those applications, wireless sensor networks (WSNs) have attracted more and more attention since their promising applications, such as environment monitoring, military scouting and healthcare. On resource-limited devices the choice of security algorithms should be very careful by consideration of the implementation costs. Symmetric-key algorithms, especially block ciphers, still play an important role for the security of the embedded systems.
    [Show full text]
  • Development of the Advanced Encryption Standard
    Volume 126, Article No. 126024 (2021) https://doi.org/10.6028/jres.126.024 Journal of Research of the National Institute of Standards and Technology Development of the Advanced Encryption Standard Miles E. Smid Formerly: Computer Security Division, National Institute of Standards and Technology, Gaithersburg, MD 20899, USA [email protected] Strong cryptographic algorithms are essential for the protection of stored and transmitted data throughout the world. This publication discusses the development of Federal Information Processing Standards Publication (FIPS) 197, which specifies a cryptographic algorithm known as the Advanced Encryption Standard (AES). The AES was the result of a cooperative multiyear effort involving the U.S. government, industry, and the academic community. Several difficult problems that had to be resolved during the standard’s development are discussed, and the eventual solutions are presented. The author writes from his viewpoint as former leader of the Security Technology Group and later as acting director of the Computer Security Division at the National Institute of Standards and Technology, where he was responsible for the AES development. Key words: Advanced Encryption Standard (AES); consensus process; cryptography; Data Encryption Standard (DES); security requirements, SKIPJACK. Accepted: June 18, 2021 Published: August 16, 2021; Current Version: August 23, 2021 This article was sponsored by James Foti, Computer Security Division, Information Technology Laboratory, National Institute of Standards and Technology (NIST). The views expressed represent those of the author and not necessarily those of NIST. https://doi.org/10.6028/jres.126.024 1. Introduction In the late 1990s, the National Institute of Standards and Technology (NIST) was about to decide if it was going to specify a new cryptographic algorithm standard for the protection of U.S.
    [Show full text]
  • State of the Art in Lightweight Symmetric Cryptography
    State of the Art in Lightweight Symmetric Cryptography Alex Biryukov1 and Léo Perrin2 1 SnT, CSC, University of Luxembourg, [email protected] 2 SnT, University of Luxembourg, [email protected] Abstract. Lightweight cryptography has been one of the “hot topics” in symmetric cryptography in the recent years. A huge number of lightweight algorithms have been published, standardized and/or used in commercial products. In this paper, we discuss the different implementation constraints that a “lightweight” algorithm is usually designed to satisfy. We also present an extensive survey of all lightweight symmetric primitives we are aware of. It covers designs from the academic community, from government agencies and proprietary algorithms which were reverse-engineered or leaked. Relevant national (nist...) and international (iso/iec...) standards are listed. We then discuss some trends we identified in the design of lightweight algorithms, namely the designers’ preference for arx-based and bitsliced-S-Box-based designs and simple key schedules. Finally, we argue that lightweight cryptography is too large a field and that it should be split into two related but distinct areas: ultra-lightweight and IoT cryptography. The former deals only with the smallest of devices for which a lower security level may be justified by the very harsh design constraints. The latter corresponds to low-power embedded processors for which the Aes and modern hash function are costly but which have to provide a high level security due to their greater connectivity. Keywords: Lightweight cryptography · Ultra-Lightweight · IoT · Internet of Things · SoK · Survey · Standards · Industry 1 Introduction The Internet of Things (IoT) is one of the foremost buzzwords in computer science and information technology at the time of writing.
    [Show full text]
  • Cryptographic Algorithms in Wearable Communications: an Empirical Analysis
    IEEE COMMUNICATIONS LETTERS, VOL. 23, NO. 11, NOVEMBER 2019 1931 Cryptographic Algorithms in Wearable Communications: An Empirical Analysis Kristtopher Coelho, Danilo Damião, Guevara Noubir, Alex Borges , Michele Nogueira , and José Nacif Abstract— In this letter, we assess the practical impact of tions and analytical models [5], [6]. Despite the importance of lightweight block and stream cipher algorithms on power con- those studies, an empirical study complements them offering sumption and hardware resources for wearable devices that own insights and knowledge, which can aid the design of more low computational resources. Differently from the literature, efficient and cost-effective solutions. Ours is the first to follow we present an empirical and hardware-driven evaluation of the most representative encryption algorithms with regard to the a hardware-driven and empirical evaluation, highlighting the requirements of wearable networks. We design and implement a impacts of the hardware specificity to cryptographic algo- cryptography library useful for wearable devices. Results confirm rithms in wearable devices. a strong correlation between the amount of logic/arithmetic Our analysis targets symmetric cryptography, where the operations, assembly instructions and power consumption for the communicating wearable devices share the session key used two evaluated platforms, and they highlight the need to design to encryption. Particularly, we focus our investigations on two encryption algorithms for wearable devices with high energy different classes of symmetric lightweight encryption algo- consumption efficiency, but strong security level similar to AES. rithms, as block ciphers [7], and stream cipher. For our Index Terms— Wearable devices, cryptographic algorithms, evaluation approach, we have designed and implemented a block cipher, stream cipher, and power consumption.
    [Show full text]
  • SEA a Scalable Encryption Algorithm for Small Embedded Applications
    SEA a Scalable Encryption Algorithm for Small Embedded Applications Fran»cois-Xavier Standaert1;2, Gilles Piret1, Neil Gershenfeld2, Jean-Jacques Quisquater1 1UCL Crypto Group Laboratoire de Micro¶electronique Universit¶eCatholique de Louvain Place du Levant, 3, B-1348 Louvain-La-Neuve, Belgium 2Center for Bits and Atoms Massachusetts Institute of Technology 20 Ames Street, Cambridge, MA 02139, USA fstandaert,piret,[email protected], [email protected] Abstract. Most present symmetric encryption algorithms result from a tradeo® between implementation cost and resulting performances. In ad- dition, they generally aim to be implemented e±ciently on a large variety of platforms. In this paper, we take an opposite approach and consider a context where we have very limited processing resources and throughput requirements. For this purpose, we propose low-cost encryption routines (i.e. with small code size and memory) targeted for processors with a limited instruction set (i.e. AND, OR, XOR gates, word rotation and mod- ular addition). The proposed design is parametric in the text, key and processor size, provably secure against linear/di®erential cryptanalysis, allows e±cient combination of encryption/decryption and “on-the-fly” key derivation. Target applications for such routines include any context requiring low-cost encryption and/or authentication. 1 Introduction Resource constrained encryption does not have a long history in symmetric cryp- tography. Noticeable examples of such ciphers are the Tiny Encryption Algo- rithm TEA [32] or Yuval's proposal [33]. However, both of them are relatively old and do not provide provable security against attacks such as linear and di®eren- tial cryptanalysis.
    [Show full text]
  • SYNOPSIS of BIOLOGICAL DATA on SKIPJACK Katsuwonus Pelamis (Linnaeus) 1758 (PACIFIC OCEAN)
    Species Synopsis No, 22 FAO Fisheries Biology Synopsis No, 65 FIb/S65 (Distribution restricted) SAST Tuna SYNOPSIS OF BIOLOGICAL DATA ON SKIPJACK Katsuwonus pelamis (Linnaeus) 1758 (PACIFIC OCEAN) Exposé synoptique sur la biologie du bonite à ventre rayé Katsuwonus palamis (Linnaeus) 1758 (Océan Pacifique) Sinopsis sobre la biología del bonito de vientre rayado Katsuwonus pelamis (Linnaeus) 1758 (Océano Pacífico) Prepared by KENNETH D, WALDRON U, S. Bureau of Commercial Fisheries Biological Laboratory Honolulu, Hawaii FISHERIES DIVISION, BIOLOGY BRANCH FOOD AND AGRICULTURE ORGANIZATION OF THE UNITED NATIONS Rome, 1963 695 FIb! S65 Skipjack 1:1 1 IDENTITY 'Body robust, naked outside the corselet; 1, 1 Taxonomy maxillary not concealed by preorbital; teeth present in jaws only; dorsal fins with only a short space between them, the anterior 1, 1, 1Definition (after Schultz, et al, spines of the first fin very high, decreasing 1960) rapidly in length; second dorsal and anal each followed by 7 or 8 finlets; pectoral not very Phylum CHORDATA long, placed at or near level of eye, with Subphylum Craniata about 26 or 27 rays." (Hildebrand, 1946). Superclass Gnatho stomata The foregoing statement is applicable to Class Osteichthys mature adults of the genus. Subclass Teleostomi Superorder Teleosteica Order Percomorphida - Species Katsuwonus pelamis Suborder Scombrina (Linnaeus) (Fig. 1) Family Scombridae "Head 3. 0 to 3,2; depth 3. 8 to 4.1; D. XIV Genus Katsuwonus or XV - I,13 or 14 - VIII; A. II,12 or 13 - VII; Species pelamis P. 26 or 27; vertebrae 40 (one specimen dissected).rnote: Both Kishinouye, 1923 and Some of the larger taxa under which skip- Godsil and Byers, 1944 give the number of jack have been listed are shown in Table I.
    [Show full text]
  • Bad Cryptography Bruce Barnett Who Am I?
    Bad Cryptography Bruce Barnett Who am I? • Security consultant @ NYSTEC • 22 years a research scientist @ GE’s R&D Center • 15 years software developer, system administrator @ GE and Schlumberger • I’m not a cryptographer • I attended a lot of talks at Blackhat/DEFCON • Then I took a course on cryptography……….. Who should attend this talk? • Project Managers • Computer programmers • Those that are currently using cryptography • Those that are thinking about using cryptography in systems and protocols • Security professionals • Penetration testers who don’t know how to test cryptographic systems and want to learn more • … and anybody who is confused by cryptography Something for everyone What this presentation is … • A gentle introduction to cryptography • An explanation why cryptography can’t be just “plugged in” • Several examples of how cryptography can be done incorrectly • A brief description of why certain choices are bad and how to exploit it. • A checklist of warning signs that indicate when “Bad Cryptography” is happening. Example of Bad Cryptography!!! Siren from snottyboy http://soundbible.com/1355-Warning-Siren.html What this talk is not about • No equations • No certificates • No protocols • No mention of SSL/TLS/HTTPS • No quantum cryptography • Nothing that can cause headaches • (Almost) no math used Math: Exclusive Or (XOR) ⊕ Your Cat Your Roommates' Will you have Cat kittens? No kittens No kittens Note that this operator can “go backwards” (invertible) What is encryption and decryption? Plain text Good Morning, Mr. Phelps
    [Show full text]
  • Key Escrow from a Safe Distance
    Key Escrow from a Safe Distance Looking Back at the Clipper Chip Matt Blaze University of Pennsylvania [email protected] ABSTRACT public information economy. In 1993, the US Government proposed a novel (and highly But there was a hitch. controversial) approach to cryptography, called key escrow. Securing information, the government reminded us, can Key escrow cryptosystems used standard symmetric- and be a double-edged sword. In the classic model for encrypted public- key ciphers, key management techniques and pro- communication, upstanding citizens Alice and Bob seek to tocols, but with one added feature: a copy of the current cryptographically protect their communication from Eve, an session key, itself encrypted with a key known to the gov- evildoing eavesdropper. But in a world where transparent ernment, was sent at the beginning of every encrypted com- cryptography is built in to every telephone, computer and munication stream. In this way, if a government wiretapper network node, giving the honest Alices and Bobs of the world encountered ciphertext produced under a key escrowed cryp- a mechanism to keep their secrets from Eve might also give tosystem, recovering the plaintext would be a simple matter the less savory the ability to evade legal surveillance. In of decrypting the session key with the government's key, re- other words, what if Eve is occasionally the good guy? gardless of the strength of the underlying cipher algorithms. And so even before the Web became synonymous with Key escrow was intended to strike a \balance" between the the Internet, before a single bit of encrypted SSL traffic was needs for effective communications security against bad guys generated, lines were being drawn for what would become on the one hand and the occasional need for the good guys an epic battle that would preoccupy a generation of cryp- to be able to recover meaningful content from (presumably) tographers.
    [Show full text]
  • An Efficient Implementation of the Blowfish Encryption Algorithm
    An Efficient Implementation of the Blowfish Encryption Algorithm A thesis submitted to the Graduate School of the University of Cincinnati In partial fulfillment of the requirements For the degree of Master of Science In the Department of Electrical and Computer Engineering Of the College of Engineering and Applied Sciences July 2014 By Ramya Krishna Addluri B.E, Electronics and Communications Engineering, University College of Engineering, Osmania University, India, 2011 Thesis Advisor and Committee Chair: Dr. Carla Purdy ABSTRACT Global networking and mobile computing are prevalent today, with the increase of communication methods such as telephones, computers, internet, broadcasting, etc. Because these transmission channels are open, there is no guarantee to avoid unauthorized access of the information through eavesdropping. Thus, several encryption algorithms have been designed for the security of the information being stored or transmitted. Several applications require such high throughputs for encryption and decryption that they cannot be executed on a regular general purpose microprocessor. FPGAs are a great platform for such implementations. We briefly study several cryptographic algorithms designed to prevent eavesdropping and then focus in detail on the Blowfish encryption algorithm. It is widely used in tools for password management, database security, email encryption etc. The algorithm is implemented in VHDL. It is then deployed onto a Nios II soft core processor on Altera DE1 board. Altera Quartus II is used to synthesize the design. Software based Huffman encoding is used to encode the input to the algorithm to reduce redundancy and to achieve lossless data compression. The results are analyzed. ii iii ACKNOWLEDGEMENT First of all, I would like to thank my advisor, Dr.
    [Show full text]