DOCSLIB.ORG

EAX' Cipher Mode (May 2011)

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
EAX' Cipher Mode (May 2011) EAX’ Cipher Mode (May 2011) Authors Avygdor Moise, Edward Beroset, Tom Phinney, Martin Burns, Members, ANSI C12 SC17 Committee Abstract— We propose a block-cipher mode of operation that description of EAX’. The description of EAX’ was extracted optimizes protection in small embedded automation devices that from ANSI C12.22 [1]. have both extremely large and extremely small messages, in which the canonical form of message addressing information, Note that EAX’ is described herein with references to using needed in forming nonces, has almost unbounded length. AES-128 as the block cipher. However, the EAX’ mode could be utilized with other underlying block ciphers. The term I. INTRODUCTION EAX’ implies that it is a derivative of EAX, utilizing a common mathematical notion of the suffix “’”. The ANSI C12.22 Protocol Specification for Interfacing to Data Communication Networks [1] utilizes the EAX’ (EAX- II. EAX’ PROPERTIES RELATIVE TO CCM PROPERTIES prime) Cipher Mode. The motivation for this work was the somewhat unique requirements of supervisory control and data The NIST version of CCM has four functional restrictions acquisition (SCADA) messaging associated with Automated (which EAX lacks) and one common implementation Meter Reading (AMR) that operate in the context of an restriction that make it less appropriate for use in ANSI Advanced Metering Infrastructure (AMI), the principle use of C12.22: this standard. However, these unique requirements may be Nonce length: CCM has a fixed maximum nonce input size applicable to many small embedded devices communicating in of 13 bytes. The ANSI C12.22 Message format requires use SCADA environments. of ApTitles [9] [10] and other information that may exceed 50 The developers of the standard were aware of several bytes, all of which must be included in the nonce in a manner challenges for the protection of very large and very small and unpredictable to an attacker. EAX directly processes nonces repetitive messages that conform to the ANSI C12.22 of arbitrary and variable size. standard, due largely to the almost unbounded length of the Nonce unpredictability: CCM generates nonces that are message addressing information specified by the associated predictable to an attacker, making it trivial for an attacker to protocol, which must be used in nonce formation when determine that two distinct messages under the same key are applying this proposed mode to that messaging. This paper using the same nonce value. This makes it imperative that the introduces this Cipher Mode and its capabilities and nonce construction never duplicate a nonce value, even after advantages. the compression step that would be required to reduce the CCM is a NIST-standardized Authenticated Encryption with large ANSI C12.22 nonce inputs to the required CCM 13-byte Associated Data (AEAD) cryptographic mode developed for nonce. EAX computes a nonce value that is unpredictable to IEEE 802.11, now also used by IEEE 802.15.4 [7]. This mode an attacker, in a range of 2128 nonce values, so no special has been suggested for similar applications to ANSI C12.22. protection need be taken against duplicate nonce values However, several obstacles to the use of this mode have been (provided that the inputs to the nonce computation do not identified with respect to messaging specific to ANSI C12.22. duplicate). These shortcomings have been addressed in part by the EAX “Online” capability: “CCM requires that the entire message mode description [3], and further by the present EAX’ mode. be available before authentication and plaintext encryption can Additionally, CCM is constrained by its definition to begin, requiring that an entire message be buffered before applicability only with the AES-128 block cipher, a constraint CCM can be applied. ANSI C12.22 can have message sizes of relaxed in EAX and EAX’. many thousand bytes, with maximum sizes exceeding 60,000 GCM is a second NIST-standardized parallelizable Authenti- bytes. Together these features make it difficult to use add-on cated Encryption with Associated Data (AEAD) cryptographic hardware or software for existing ANSI C12.22 mode developed for applications requiring high-speed crypto- implementations, to minimize time to initial deployment of the graphy [8]. This mode also has been suggested for similar new standard. EAX has "online" capability, which makes it applications to ANSI C12.22. However, significant obstacles suitable for use in add-on hardware or software serial link to the use of this mode also have been identified with respect encryptors. to messaging specific to C12.22. These shortcomings have Authenticate-before-decrypt: CCM requires that the entire been addressed in part by the EAX mode description [3], and, received message be decrypted before it can be authenticated. further by the present EAX’ mode. Thus the extra processing required to decrypt Ciphertext must This paper introduces these issues, their resolutions, and the be applied whether the received message authenticates or not. EAX authenticates the Ciphertext rather than the plaintext, so this extra processing is required only for messages that have EAX’ Cipher Mode (May 2011) 2 been authenticated. This reduces the ability of an attacker to 1. ISSUE: Reduction of EAX' to two input strings – mount a DoS (denial of service) attack on the receiving Non-inclusion of CMACk(0n-11 || pad(nullString) ) when device, causing it to consume significant resources before the EAX input H is null. determining that the received message is invalid. n-1 Hardware non-support of canonicalized messages: Some JUSTIFICATION: CMACk(0 1 || pad(nullString) ) is modem chips such as many of those for IEEE 802.15.4 precisely CBCk(01271 || (10127 XOR dbl(dbl(ECBk(0)) )), provide hardware support for CCM-mode transmission and which is a key-dependent constant. A predictable-to-an- reception when the message to be CCM-authenticated consists attacker XOR of a key-dependent constant that is the exactly of the message Cleartext and plaintext, in that order, output of a keyed PRP, into a key-dependent variable that that is to be sent or that was received. However, ANSI C12.22 is itself a combination of keyed PRP outputs, does not requires that the authenticated message use canonical forms of strengthen the cryptanalytic resistance of the computation, ApTitles, and exclude the <calling-AP-title-element> (the because the dimensionality of the resultant composite ApTitle of the message originator) when it was added by a PRP is identical to that without the inclusion. Therefore proxy C12.22 Relay. The resultant software-based sequencing its exclusion does not weaken the cryptanalytic resistance of invocations of the underlying hardware block cipher (e.g. of the computation. AES-128) implementation is equivalent to that required for 2. ISSUE: Exclusion of the ciphertext tag input from a EAX. null plainext string – Conditional non-inclusion of CMAC (0n-210 || CTR (N, nullString)) when the EAX III. JUSTIFICATIONS FOR THE EAX' OPTIMIZATIONS k k input M is null. This section provides justifications for the simplifications of EAX’ over the basic EAX mode specified by [3]. These JUSTIFICATION: CTRk(N, nullString) is the null simplifications are motivated by a desire to reduce the number string. Thus CMAC (0n-210 || pad(CTR (N, nullString)) of AES block encryptions required by EAX, and to reduce the k k n-2 n-1 amount of per-key-related storage needed by a time-optimized ) is precisely CBCk(0 10 || (10 XOR implementation, without significantly weakening the dbl(dbl(ECBk(0))))), which is a key-dependent constant. cryptographic strength and resistance to attack that EAX A predictable-to-an-attacker conditional XOR of a key- offers. The EAX' optimizations reduce the required per-key dependent constant that is the output of a keyed PRP, into storage for a time-optimized implementation from those of a key-dependent variable that is itself a combination of unmodified EAX by K+4B+2T bytes per key (88 bytes when keyed PRP outputs, does not strengthen the cryptanalytic AES-128 is the block cipher) to K+2B bytes per key (48 bytes resistance of the computation, because the dimensionality when AES-128 is the block cipher), where K is the key size of of the resultant composite PRP is identical to that without the underlying block cipher, B is the block size of that block the inclusion. Therefore the conditional exclusion of this XOR does not weaken the cryptanalytic resistance of the cipher, and T is the desired authentication tag size, all in bytes. computation. For space-optimized implementations, where only K bytes of storage per key are required, these optimizations eliminate 3. ISSUE: Simplified nonce incrementation in CTR- either three extra invocations of AES per message when mode processing – Forcing two bits of the initial nonce <epsem-data> secrecy is used [1], or five extra invocations input to a CTR-mode keyed encryption to zero, to when it is not used. eliminate inter-word carries, reduces the average number BACKGROUND: Block ciphers such as AES-128 are of messages that can be encrypted before nonce reuse keyed pseudo-random permutations (PRPs), which map a without reducing the maximum message length that can block-size input (e.g., 16 bytes = 128 bits) to a block-size be protected. output. The strength and ability to resist cryptanalysis of JUSTIFICATION: Rogaway [6] introduced a similar composite cryptographic modes which use this block cipher optimization in his SIV combined authentication and are directly related to the strength and ability to resist encryption mode, which was developed after EAX and cryptanalysis of the underlying PRP. Analysis of a new mode which has also been submitted to NIST. The resulting must examine its impact on increasing or decreasing this reduction in the average number of messages is at most a strength, as well as any avenues of cryptanalytic attack that factor of four.
Load more

Recommended publications
  • Analysis of Selected Block Cipher Modes for Authenticated Encryption
    Analysis of Selected Block Cipher Modes for Authenticated Encryption by Hassan Musallam Ahmed Qahur Al Mahri Bachelor of Engineering (Computer Systems and Networks) (Sultan Qaboos University) – 2007 Thesis submitted in fulfilment of the requirement for the degree of Doctor of Philosophy School of Electrical Engineering and Computer Science Science and Engineering Faculty Queensland University of Technology 2018 Keywords Authenticated encryption, AE, AEAD, ++AE, AEZ, block cipher, CAESAR, confidentiality, COPA, differential fault analysis, differential power analysis, ElmD, fault attack, forgery attack, integrity assurance, leakage resilience, modes of op- eration, OCB, OTR, SHELL, side channel attack, statistical fault analysis, sym- metric encryption, tweakable block cipher, XE, XEX. i ii Abstract Cryptography assures information security through different functionalities, es- pecially confidentiality and integrity assurance. According to Menezes et al. [1], confidentiality means the process of assuring that no one could interpret infor- mation, except authorised parties, while data integrity is an assurance that any unauthorised alterations to a message content will be detected. One possible ap- proach to ensure confidentiality and data integrity is to use two different schemes where one scheme provides confidentiality and the other provides integrity as- surance. A more compact approach is to use schemes, called Authenticated En- cryption (AE) schemes, that simultaneously provide confidentiality and integrity assurance for a message. AE can be constructed using different mechanisms, and the most common construction is to use block cipher modes, which is our focus in this thesis. AE schemes have been used in a wide range of applications, and defined by standardisation organizations. The National Institute of Standards and Technol- ogy (NIST) recommended two AE block cipher modes CCM [2] and GCM [3].
    [Show full text]
  • The EAX Mode of Operation
    A preliminary version of this papers appears in Fast Software Encryption ’04, Lecture Notes in Computer Science, vol. ?? , R. Bimal and W. Meier ed., Springer-Verlag, 2004. This is the full version. The EAX Mode of Operation (A Two-Pass Authenticated-Encryption Scheme Optimized for Simplicity and Efficiency) ∗ † ‡ M. BELLARE P. ROGAWAY D. WAGNER January 18, 2004 Abstract We propose a block-cipher mode of operation, EAX, for solving the problem of authenticated-encryption with associated-data (AEAD). Given a nonce N, a message M, and a header H, our mode protects the privacy of M and the authenticity of both M and H. Strings N, M, and H are arbitrary bit strings, and the mode uses 2|M|/n + |H|/n + |N|/n block-cipher calls when these strings are nonempty and n is the block length of the underlying block cipher. Among EAX’s characteristics are that it is on-line (the length of a message isn’t needed to begin processing it) and a fixed header can be pre-processed, effectively removing the per-message cost of binding it to the ciphertext. EAX is obtained by first creating a generic-composition method, EAX2, and then collapsing its two keys into one. EAX is provably secure under a standard complexity-theoretic assumption. The proof of this fact is novel and involved. EAX is an alternative to CCM [26], which was created to answer the wish within standards bodies for a fully-specified and patent-free AEAD mode. As such, CCM and EAX are two-pass schemes, with one pass for achieving privacy and one for authenticity.
    [Show full text]
  • Security Policy: Informacast Java Crypto Library
    FIPS 140-2 Non-Proprietary Security Policy: InformaCast Java Crypto Library FIPS 140-2 Non-Proprietary Security Policy InformaCast Java Crypto Library Software Version 3.0 Document Version 1.2 June 26, 2017 Prepared For: Prepared By: Singlewire Software SafeLogic Inc. 1002 Deming Way 530 Lytton Ave, Suite 200 Madison, WI 53717 Palo Alto, CA 94301 www.singlewire.com www.safelogic.com Document Version 1.2 © Singlewire Software Page 1 of 35 FIPS 140-2 Non-Proprietary Security Policy: InformaCast Java Crypto Library Abstract This document provides a non-proprietary FIPS 140-2 Security Policy for InformaCast Java Crypto Library. Document Version 1.2 © Singlewire Software Page 2 of 35 FIPS 140-2 Non-Proprietary Security Policy: InformaCast Java Crypto Library Table of Contents 1 Introduction .................................................................................................................................................. 5 1.1 About FIPS 140 ............................................................................................................................................. 5 1.2 About this Document.................................................................................................................................... 5 1.3 External Resources ....................................................................................................................................... 5 1.4 Notices .........................................................................................................................................................
    [Show full text]
  • How to Enhance the Security of the 3GPP Confidentiality and Integrity
    How to Enhance the Security of the 3GPP Confidentiality and Integrity Algorithms Tetsu Iwata and Kaoru Kurosawa Dept. of Computer and Information Sciences, Ibaraki University 4–12–1 Nakanarusawa, Hitachi, Ibaraki 316-8511, Japan {iwata, kurosawa}@cis.ibaraki.ac.jp Abstract. We consider the 3GPP confidentiality and integrity schemes that were adopted by Universal Mobile Telecommunication System, an emerging standard for third generation wireless communications. The schemes, known as f8 and f9, are based on the block cipher KASUMI. Although previous works claim security proofs for f8 and f9, where f9 is a generalized version of f9, it was shown that these proofs are incorrect; it is impossible to prove f8 and f9 secure under the standard PRP assumption on the underlying block cipher. Following the results, it was shown that it is possible to prove f8 and f9 secure if we make the assumption that the underlying block cipher is a secure PRP-RKA against a certain class of related-key attacks; here f8 is a generalized version of f8. Needless to say, the assumptions here are stronger than the standard PRP assumptions, and it is natural to seek a practical way to modify f8 and f9 to establish security proofs under the standard PRP assumption. In this paper, we propose f8+ and f9+, slightly mod- ified versions of f8 and f9, but they allow proofs of security under the standard PRP assumption. Our results are practical in the sense that we insist on the minimal modifications; f8+ is obtained from f8 by setting the key modifier to all-zero, and f9+ is obtained from f9 by setting the key modifier to all-zero, and using the encryptions of two constants in the CBC MAC computation.
    [Show full text]
  • Optimizing Authenticated Encryption Algorithms
    Masaryk University Faculty of Informatics Optimizing authenticated encryption algorithms Master’s Thesis Ondrej Mosnáček Brno, Fall 2017 Masaryk University Faculty of Informatics Optimizing authenticated encryption algorithms Master’s Thesis Ondrej Mosnáček Brno, Fall 2017 This is where a copy of the official signed thesis assignment and a copy ofthe Statement of an Author is located in the printed version of the document. Declaration Hereby I declare that this paper is my original authorial work, which I have worked out on my own. All sources, references, and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source. Ondrej Mosnáček Advisor: Ing. Milan Brož i Acknowledgement I would like to thank my advisor, Milan Brož, for his guidance, pa- tience, and helpful feedback and advice. Also, I would like to thank my girlfriend Ludmila, my family, and my friends for their support and kind words of encouragement. If I had more time, I would have written a shorter letter. — Blaise Pascal iii Abstract In this thesis, we look at authenticated encryption with associated data (AEAD), which is a cryptographic scheme that provides both confidentiality and integrity of messages within a single operation. We look at various existing and proposed AEAD algorithms and compare them both in terms of security and performance. We take a closer look at three selected candidate families of algorithms from the CAESAR competition. Then we discuss common facilities provided by the two most com- mon CPU architectures – x86 and ARM – that can be used to implement cryptographic algorithms efficiently.
    [Show full text]
  • On the Security of CTR + CBC-MAC NIST Modes of Operation – Additional CCM Documentation
    On the Security of CTR + CBC-MAC NIST Modes of Operation { Additional CCM Documentation Jakob Jonsson? jakob [email protected] Abstract. We analyze the security of the CTR + CBC-MAC (CCM) encryption mode. This mode, proposed by Doug Whiting, Russ Housley, and Niels Ferguson, combines the CTR (“counter”) encryption mode with CBC-MAC message authentication and is based on a block cipher such as AES. We present concrete lower bounds for the security of CCM in terms of the security of the underlying block cipher. The conclusion is that CCM provides a level of privacy and authenticity that is in line with other proposed modes such as OCB. Keywords: AES, authenticated encryption, modes of operation. Note: A slightly different version of this paper will appear in the Proceedings from Selected Areas of Cryptography (SAC) 2002. 1 Introduction Background. Block ciphers are popular building blocks in cryptographic algo­ rithms intended to provide information services such as privacy and authenticity. Such block-cipher based algorithms are referred to as modes of operation. Exam­ ples of encryption modes of operation are Cipher Block Chaining Mode (CBC) [23], Electronic Codebook Mode (ECB) [23], and Counter Mode (CTR) [9]. Since each of these modes provides privacy only and not authenticity, most applica­ tions require that the mode be combined with an authentication mechanism, typically a MAC algorithm [21] based on a hash function such as SHA-1 [24]. For example, a popular cipher suite in SSL/TLS [8] combines CBC mode based on Triple-DES [22] with the MAC algorithm HMAC [26] based on SHA-1.
    [Show full text]
  • AUTHENTICATED ENCRYPTION in HARDWARE by Milind M. Parelkar
    AUTHENTICATED ENCRYPTION IN HARDWARE by Milind M. Parelkar A Thesis Submitted to the Graduate Faculty of George Mason University in Partial Ful¯llment of the the Requirements for the Degree of Master of Science Electrical and Computer Engineering Committee: Dr. Kris Gaj, Thesis Director Dr. William Sutton Dr. Peter Pachowicz Andre Manitius, Chairman, Department of Electrical and Computer Engineering Lloyd J. Gri±ths, Dean, School of Information Technology and Engineering Date: Fall 2005 George Mason University Fairfax, VA Authenticated Encryption in Hardware A thesis submitted in partial ful¯llment of the requirements for the degree of Master of Science at George Mason University By Milind M. Parelkar Bachelor of Engineering University of Mumbai(Bombay), India, 2002 Director: Dr. Kris Gaj, Associate Professor Department of Electrical and Computer Engineering Fall 2005 George Mason University Fairfax, VA ii Copyright °c 2005 by Milind M. Parelkar All Rights Reserved iii Acknowledgments I would like to thank Dr. Kris Gaj for helping me throughout the course of this research. Special thanks to Pawel Chodowiec, without whose help, it would have been very di±cult to come up with good results, on time. iv Table of Contents Page Abstract . xii 1 Authenticated Encryption - Introduction and Motivation . 1 1.1 Cryptographic Goals . 1 1.2 What is Authenticated - Encryption? . 2 1.3 Target Applications for Authenticated - Encryption . 7 1.3.1 Encryption and Authentication of FPGA Bitstream . 7 1.3.2 Authenticated - Encryption in 802.11 Wireless LANs . 11 1.4 Authentication Techniques . 12 1.4.1 Hash Functions . 12 1.4.2 Message Authentication Codes (MACs) .
    [Show full text]
  • AES-CCM Brief
    FEATURES AES-CCM Encrypts and decrypts using the AES Rijndael Block Cipher Algorithm AES-CCM Authenticated Encrypt/Decrypt Engine Implemented according to the National Institute of Standards and Technology (NIST) Special The AES-CCM encryption IP core implements hardware Rijndael encoding and decoding in Publication 800-38D compliance with the NIST Advanced Encryption Standard. It processes 128-bit blocks, and is NIST Certified programmable for 128-, 192-, and 256-bit key lengths. Employs Counter with CBC- MAC CCM stands for Counter with CBC- MAC mode. CCM is a generic authenticate-and-encrypt mode (CCM) block cipher mode. CBC-MAC is utilized to generate an authentication string while CTR mode Processes 128-bit data in 32-bit is used to encrypt. blocks Two architectural versions are available to suit system requirements. The Standard version Employs user-programmable key size of 128, 192, or 256 bits (AES-CCM-S) is more compact, using a 32-bit datapath and requiring 44/52/60 clock cycles Two architectural versions: for each data block (128/192/256-bit cipher key, respectively). The Fast version (AES-CCM-F) o achieves higher throughput, using a 128-bit datapath and requiring 11/13/15 clock cycles for Standard is more compact: 32-bit data path size each data block. Processes each 128-bit data block The AES-CCM cores are fully synchronous designs, have been evaluated in a variety of in 44/52/60 clock cycles for 128/192/256-bit cipher keys, technologies, and are available optimized for ASICs or FPGAs. respectively Applications o Fast yields higher transmission rates: The AES-CCM can be utilized for a variety of encryption applications including protected 128-bit data path network routers, electronic financial transactions, secure wireless communications, secure Processes each 128-bit block in video surveillance systems, and encrypted data storage.
    [Show full text]
  • 1 Block Cipher Modes of Operation from a Hardware Implementation Perspective
    1 Block Cipher Modes of Operation from a Hardware Implementation Perspective Debrup Chakraborty and Francisco Rodr´ıguez-Henr´ıquez Computer Science Department Centro de Investigaci´on y de Estudios Avanzados del IPN Av. Instituto Polit´ecnico Nacional No. 2508, M´exico D.F. e-mail:{debrup,francisco}@cs.cinvestav.mx 1.1 Introduction Block ciphers are one of the most important primitives in cryptology. They are based on well-understood mathematical and cryptographic principles. Due to their inherent efficiency, these ciphers are used in many kinds of applications which require bulk encryption at high speed. Generally speaking, a block cipher consists of at least two closely related algo- rithms: block encryption and block decryption. Block encryption takes as an input a fixed-length block (known as the plaintext) and transform it into another block of the same length (known as the ciphertext) under the action of a fixed secret key that may or may not have the same length of the plaintext. A block cipher must be invertible in the sense that by using the block decryption algorithm it should be always possible to recover the original plaintext from the ciphertext and the secret key. Figure 1.1 shows schematically the situation just described. We stress that once that the plain- text has been encrypted using a given key then, a successful decryption can only be performed by knowing that key. Due to this feature, block ciphers are classified as a secret or symmetric key primitives. Formally a block cipher is considered to be secure if it behaves like a strong pseudorandom permutation, i.e., a block cipher is secure if an adversary cannot dis- tinguish its output from a randomly chosen permutation.
    [Show full text]
  • Multi-IP-Based Soc Design Including CCM Security Mode of Operation
    Master Thesis ICT/ECS-2006-71 Multi-IP-Based SoC Design Including CCM Security Mode of Operation By Solmaz Ghaznavi A thesis presented to the University of Waterloo and KTH University in the fulfillment of the thesis requirement for the degree of Master of Science in System on-Chip Design Waterloo, Ontario, Canada, 2006 © Solmaz Ghaznavi, 2006 Supervisor: Professor Cathy Gebotys Examiner: Professor Axel Jantsch I hereby declare that I am the sole author of this thesis. I authorize the University of Waterloo and KTH University to lend this thesis to other institutions or individuals for the purpose of scholarly research. I further authorize the University of Waterloo and KTH University to reproduce this thesis by photocopying or by other means, in total or in print, at the request of other institutions is individuals for the purpose of scholarly research. ii Abstract Embedding security in many mobile electronic devices is of great importance. With the emergence of powerful self-contained FPGAs which include microprocessors, memory etc. for SoC designs, it has shifted focus to these programmable platforms. A co-design approach can be used to optimize speed, area and power consumption by partitioning function onto the on-chip microprocessor and programmable logic blocks. FPGAs typically provide higher efficiency compared to software. On the other hand they offer more flexibility and much lower design and debug costs compared to specifically-built hardware. This thesis mainly implements CCM security mode of operation on a FPGA platform by using the AES encryption algorithm, it then builds a complete SoC that is based on multi IP cores including CCM.
    [Show full text]
  • The Helion Basic Guide to AES Encryption in Hardware
    The Helion basic guide to AES encryption in hardware What is AES? During September 1997, the National Institute of Standards and Technology (NIST), the main standards body in the US, issued an open request for submissions for a new Advanced Encryption Standard (AES). The idea was that AES would be a new encryption standard to replace the existing Data Encryption Standard (DES), which had been in place for more than two decades. In August 1998, a number of potential candidates were selected from the submissions, and then in August 1999, these were further selected to become a shortlist of five finalists. In October 2000, one of these five algorithms, “Rijndael”, was chosen as the new AES. This decision was then fully ratified by the NIST in November 2001, at which point AES became the encryption algorithm of choice for all new commercial developments requiring a high degree of data security. What is AES like from the outside? Rijndael is what is known as a “Block Cipher” with multiple options for its block and key size. The NIST approved AES is a subset of these options; the block size is fixed at 128-bits, but the key may be either 128, 192 or 256-bits in length. As their name suggests, Block Ciphers only process data in blocks. In the case of AES this means that it is capable of encrypting plaintext data in blocks of 128-bits using any of the specified key sizes; in broad terms, the bigger the keysize, the higher the security. It is generally accepted that 128-bit keys will provide a sufficient level of security for most commercial applications, though longer keys seem to be specified more and more for the latest applications.
    [Show full text]
  • Mcoe: a Family of Almost Foolproof On-Line Authenticated Encryption Schemes
    McOE: A Family of Almost Foolproof On-Line Authenticated Encryption Schemes Ewan Fleischmann, Christian Forler, and Stefan Lucks Bauhaus-University Weimar, Germany {ewan.fleischmann,christian.forler,stefan.lucks}@uni-weimar.de Abstract. On-Line Authenticated Encryption (OAE) combines privacy with data integrity and is on-line computable. Most block cipher-based schemes for Authenticated Encryption can be run on-line and are prov- ably secure against nonce-respecting adversaries. But they fail badly for more general adversaries. This is not a theoretical observation only – in practice, the reuse of nonces is a frequent issue1. In recent years, cryptographers developed misuse-resistant schemes for Authenticated Encryption. These guarantee excellent security even against general adversaries which are allowed to reuse nonces. Their dis- advantage is that encryption can be performed in an off-line way, only. This paper considers OAE schemes dealing both with nonce-respecting and with general adversaries. It introduces McOE,anefficientdesignfor OAE schemes. For this we present in detail one of the family members, McOE-X, which is a design solely based on a standard block cipher. As all the other member of the McOE family, it provably guarantees reasonable security against general adversaries as well as standard security against nonce-respecting adversaries. Keywords: authenticated encryption, on-line encryption, provable se- curity, misuse resistant. 1 Introduction On-Line Authenticated Encryption (OAE). Application software often requires a network channel that guarantees the privacy and authenticity of data be- ing communicated between two parties. Cryptographic schemes able to meet both of these goals are commonly referred to as Authenticated Encryption (AE) schemes.
    [Show full text]