DOCSLIB.ORG

Hunting Invisible Salamanders: Cryptographic (In)Security with Attacker-Controlled Keys Paul Grubbs Cornell Tech, New York University, University of Michigan

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Hunting Invisible Salamanders: Cryptographic (In)Security with Attacker-Controlled Keys Paul Grubbs Cornell Tech, New York University, University of Michigan Hunting Invisible Salamanders: Cryptographic (in)Security with Attacker-Controlled Keys Paul Grubbs Cornell Tech, New York University, University of Michigan 1 About Me Now: PhD student in Next fall: starting This fall: starting Computer Science at as junior professor postdoc at NYU Cornell’s NYC campus at Michigan EECS 2 This Talk Intended audience: those who design, implement, and use cryptography. Others will find talk interesting and enjoyable but may lack some context. This is a talk about cryptography. This symbol: if you don’t understand Some of the slides involve math. all the details, don’t worry about it! 3 Authenticated Encryption Cat Picture ??? Agree on random key Encrypt message with using authenticated encryption (AE) (Galois/Counter Mode, Chacha20/Poly1305) If key is random + hidden: AE hides cat pictures, Core of protocols prevents modifications like TLS, IPSec, SSH 4 New Settings, New Needs Attacker Message Attacker chooses key(s) Encrypt message with using authenticated encryption (AE) (Galois/Counter Mode, Chacha20/Poly1305) Key isn’t random + hidden! What security do we need? Increasingly important setting for AE: What security do we expect? • Password-Based Encryption/PAKE • E2EE Group Messaging • Abuse Reporting in Encrypted Messaging 5 Overview Describe “attacker-controlled keys” setting + examples, explain committing security property AE needs Many widely-used AE schemes are not committing: can break for GCM, ChaCha20/Poly1305, others Attacks resulting from non-committing AE: - Inconsistent plaintexts in multi-receiver encryption - Invisible salamanders in Facebook’s message franking - Key recovery via partitioning oracle attacks Based on these research papers: Message Franking via Committing Authenticated Encryption G., Lu, Ristenpart. IACR CRYPTO17. https://eprint.iacr.org/2017/664 Fast Message Franking: From Invisible Salamanders to Encryptment Dodis, G., Ristenpart, Woodage. IACR CRYPTO18. https://eprint.iacr.org/2019/016 Partitioning Oracle Attacks Len, G., Ristenpart. In submission. 6 Overview Describe “attacker-controlled keys” setting + examples, explain committing security property AE needs Many widely-used AE schemes are not committing: can break for GCM, ChaCha20/Poly1305, others Attacks resulting from non-committing AE: - Inconsistent plaintexts in multi-receiver encryption - Invisible salamanders in Facebook’s message franking - Key recovery via partitioning oracle attacks Based on these research papers: Message Franking via Committing Authenticated Encryption G., Lu, Ristenpart. IACR CRYPTO17. https://eprint.iacr.org/2017/664 Fast Message Franking: From Invisible Salamanders to Encryptment Dodis, G., Ristenpart, Woodage. IACR CRYPTO18. https://eprint.iacr.org/2019/016 Partitioning Oracle Attacks Len, G., Ristenpart. In submission. 7 Attacker-Controlled Keys Cat Picture is hidden, has Try to learn message or lots of randomness change decryption output Attacker Message Message and encryption key both chosen by adversary 8 Example: Password-based AE They’re using password1! Guess Can’t decrypt! 123 … password1 456 Guess password1 Decryption succeeded! If attacker doesn’t Brute-force feasible if key is not very random know decryption key, (e.g. password/PIN) or if side channel leaks key bits can learn using (online) brute-force attack 9 Example: Reporting Plaintexts Can’t let the auditor see records… Fraudulent Records AE.Decrypt( , Fraudulent Records ) Auditor Decrypt outputs something other than fraudulent records Attacker chooses encryption and decryption key: tries to lie about ciphertext contents 10 Committing Security For AE Useful to imagine AE as a lockbox Intuition holds for hidden random key: ??? • Can’t see inside (confidentiality) • Can’t change contents (integrity) No matter the key, only one thing can come out when it’s unlocked 11 Committing Security For AE Useful to imagine AE as a lockbox Intuition holds for hidden random key: Committing security binds attacker • Can’t see inside (confidentiality) to a single AE decryption, prevents • Can’t change contents (integrity) invisible salamanders in ciphertexts Without this, AE lockboxes could unlock many ways… 12 Reporting Salamanders Committing AE Committing AE AE.Decrypt( , ) Auditor Decrypt fails - can’t report salamanders If AE is committing, attacker can’t lie about plaintext by choosing different key 13 Overview Describe “attacker-controlled keys” setting + examples, explain committing security property AE needs Many widely-used AE schemes are not committing: can break for GCM, ChaCha20/Poly1305, others Attacks resulting from non-committing AE: - Inconsistent plaintexts in multi-receiver encryption - Invisible salamanders in Facebook’s message franking - Key recovery via partitioning oracle attacks Based on these research papers: Message Franking via Committing Authenticated Encryption G., Lu, Ristenpart. IACR CRYPTO17. https://eprint.iacr.org/2017/664 Fast Message Franking: From Invisible Salamanders to Encryptment Dodis, G., Ristenpart, Woodage. IACR CRYPTO18. https://eprint.iacr.org/2019/016 Partitioning Oracle Attacks Len, G., Ristenpart. In submission. 14 Invisible Salamanders for CTR Mode Plaintext ⨁ Pad Derive Pad = IV Ciphertext Derive Pad’ ⨁ Pad’ = Plaintext’ 15 Galois/Counter Mode (GCM) Input GCM is a fast, modern AE. NIST/IEEE/ISO standard Message Uses AES-CTR + message authentication code (MAC) to prevent tampering AES-CTR MAC Decryption recomputes, checks tag, fails if tags do not match Output IV Message Tag To get invisible salamanders for GCM, need to find IV Message with same MAC output Tag for and AES-CTR MAC Salamander Input 16 Colliding GCM’s MAC MAC is polynomial evaluation + XOR. Fast but not collision-resistant (cf. SHA-256) IV 1. Split ciphertext into blocks (coefficients) MAC( , IV ): 1. C1 = Blocks( ) 2. Compute hash point (H) and pad (Pad) H = AES( , 0) 2. 3. Evaluate polynomial at H, then XOR Pad Pad = AES( , IV ) 2 (‘len’ is encoded ciphertext length) 3. Tag = C1*H + len*H + Pad Tag 17 Colliding GCM’s MAC Tag is a “simple” algebraic function of ciphertext: solve one equation to collide for two keys IV 1. Choose any IV MAC( , IV ): 2. For key , derive H1, Pad1 C1 = Blocks( ) H = AES( , 0) 3. For key , derive H2, Pad2 Pad = AES( , IV ) 4. Set tag equations equal, solve for C : 2 1 Tag = C1*H + len*H + Pad 2 C1*H1 + len*H1 + Pad1 2 Tag = C1*H2 + len*H2 + Pad2 Not true for collision-resistant Message Tag hashes like SHA-256 5. Let be C1 , recompute 6. Output IV Message Tag 2 2 C1*(H1 + H2 ) = len*(H1 + H2) + Pad1 + Pad2 2x = 6 One equation, 2 2 -1 one unknown! C1 = [len*(H1 + H2) + Pad1 + Pad2]*(H1 + H2 ) x = 3 18 From Two Keys to Many Colliding GCM’s MAC on two keys is pretty easy. Can even collide many (>>2) keys: use interpolation IV "#! $ MAC( , IV ): � ⋯ � �! ��� + ��� + ���� ∗ � ! ! ! ! C1 , …, Cm = Blocks( ) ⋮ ⋱ ⋮ ⋮ = ⋮ H = AES( , 0) "#! $ ��� + ���" + ���� ∗ �" Pad = AES( , IV ) � ⋯ � �" +2−� % % Tag = ∑� C�∗Hm + len*H + Pad One equation Tag As many variables as ciphertext blocks: per key can solve when m ≥ k in O(k2) time 2 2 C1*H1 + len*H1 + Pad1 = C1*H2 + len*H2 + Pad2 2 2 Polynomial MACs are very common: C1*(H1 + H2 ) = len*(H1 + H2) + Pad1 + Pad2 Poly1305 (libsodiumLinear Algebra, NaCL), GCM-SIV, etc. 2 2 -1 C1 = [len*(H1 + H2) + Pad1 + Pad2]*(H1 + H2 ) 19 </math> Colliding GCM’s MAC on two keys is pretty easy. Can even collide many (>>2) keys: use interpolation IV "#! $ MAC( , IV ): � ⋯ � �! ��� + ��� + ���� ∗ � ! ! ! ! C1 , …, Cm = Blocks( ) ⋮ ⋱ ⋮ ⋮ = ⋮ H = AES( , 0) "#! $ � ��� + ���" + ���� ∗ �" Pad = AES( , IV ) �% ⋯ �% " Tag +2−� 1. Widely-used AE schemes are not committing = ∑� C�∗Hm + len*H + Pad (though they are fine for use in TLS/IPSec/SSH!) One equation Tag As many2. variablesCrafting as ciphertextinvisible blocks:salamanders for them is easy 2 per key can solve3. whenOne ciphertextm ≥ k in O(k can) time have 100,000s+ invisible salamanders 2 (E.g., my colleague generated2 one with 131,072 correct decryptions) C1*H1 + len*H1 + Pad1 = C1*H2 + len*H2 + Pad2 2 2 Polynomial MACs are very common: C1*(H1 + H2 ) = len*(H1 + H2) + Pad1 + Pad2 Poly1305 (libsodiumLinear Algebra, NaCL), GCM-SIV, etc. 2 2 -1 C1 = [len*(H1 + H2) + Pad1 + Pad2]*(H1 + H2 ) 20 Overview Describe “attacker-controlled keys” setting + examples, explain committing security property AE needs Many widely-used AE schemes are not committing: can break for GCM, ChaCha20/Poly1305, others Attacks resulting from non-committing AE: - Inconsistent plaintexts in multi-receiver encryption - Invisible salamanders in Facebook’s message franking - Key recovery via partitioning oracle attacks Based on these research papers: Message Franking via Committing Authenticated Encryption G., Lu, Ristenpart. IACR CRYPTO17. https://eprint.iacr.org/2017/664 Fast Message Franking: From Invisible Salamanders to Encryptment Dodis, G., Ristenpart, Woodage. IACR CRYPTO18. https://eprint.iacr.org/2019/016 Partitioning Oracle Attacks Len, G., Ristenpart. In submission. 21 Multi-Receiver Encryption In group messaging applications, senders must encrypt and send messages to group Keys shared pairwise; only one ciphertext 22 Multi-Receiver Encryption In group messaging applications, senders must encrypt and send messages to group Keys shared pairwise; only one ciphertext Used by Whatsapp, Keybase, others Cat Picture Cat Picture Cat Picture 23 Multi-Receiver Encryption In group messaging applications, senders must encrypt and send messages to group Theoretical attack. Unclear if these are vulnerable (homework!) Keys shared pairwise; only one ciphertext
Load more

Recommended publications
  • FIPS 140-2 Non-Proprietary Security Policy
    Kernel Crypto API Cryptographic Module version 1.0 FIPS 140-2 Non-Proprietary Security Policy Version 1.3 Last update: 2020-03-02 Prepared by: atsec information security corporation 9130 Jollyville Road, Suite 260 Austin, TX 78759 www.atsec.com © 2020 Canonical Ltd. / atsec information security This document can be reproduced and distributed only whole and intact, including this copyright notice. Kernel Crypto API Cryptographic Module FIPS 140-2 Non-Proprietary Security Policy Table of Contents 1. Cryptographic Module Specification ..................................................................................................... 5 1.1. Module Overview ..................................................................................................................................... 5 1.2. Modes of Operation ................................................................................................................................. 9 2. Cryptographic Module Ports and Interfaces ........................................................................................ 10 3. Roles, Services and Authentication ..................................................................................................... 11 3.1. Roles .......................................................................................................................................................11 3.2. Services ...................................................................................................................................................11
    [Show full text]
  • The Missing Difference Problem, and Its Applications to Counter Mode
    The Missing Difference Problem, and its Applications to Counter Mode Encryption? Ga¨etanLeurent and Ferdinand Sibleyras Inria, France fgaetan.leurent,[email protected] Abstract. The counter mode (CTR) is a simple, efficient and widely used encryption mode using a block cipher. It comes with a security proof that guarantees no attacks up to the birthday bound (i.e. as long as the number of encrypted blocks σ satisfies σ 2n=2), and a matching attack that can distinguish plaintext/ciphertext pairs from random using about 2n=2 blocks of data. The main goal of this paper is to study attacks against the counter mode beyond this simple distinguisher. We focus on message recovery attacks, with realistic assumptions about the capabilities of an adversary, and evaluate the full time complexity of the attacks rather than just the query complexity. Our main result is an attack to recover a block of message with complexity O~(2n=2). This shows that the actual security of CTR is similar to that of CBC, where collision attacks are well known to reveal information about the message. To achieve this result, we study a simple algorithmic problem related to the security of the CTR mode: the missing difference problem. We give efficient algorithms for this problem in two practically relevant cases: where the missing difference is known to be in some linear subspace, and when the amount of data is higher than strictly required. As a further application, we show that the second algorithm can also be used to break some polynomial MACs such as GMAC and Poly1305, with a universal forgery attack with complexity O~(22n=3).
    [Show full text]
  • Nacl's Crypto Box in Hardware
    NaCl’s crypto_box in hardware Michael Hutter1;, Jürgen Schilling2, Peter Schwabe3, and Wolfgang Wieser2 ? 1 Rambus Cryptography Research Division 425 Market Street, 11th Floor, San Francisco, CA 94105, USA [email protected] 2 Graz University of Technology, IAIK Inffeldgasse 16a, A-8010, Graz, Austria [email protected],[email protected] 3 Radboud University Digital Security Group, PO Box 9010, 6500GL Nijmegen, The Netherlands [email protected] Abstract. This paper presents a low-resource hardware implementation of the widely used crypto_box function of the Networking and Cryptog- raphy library (NaCl). It supports the X25519 Diffie-Hellman key ex- change using Curve25519, the Salsa20 stream cipher, and the Poly1305 message authenticator. Our targeted application is a secure communica- tion between devices in the Internet of Things (IoT) and Internet servers. Such devices are highly resource-constrained and require carefully op- timized hardware implementations. We propose the first solution that enables 128-bit-secure public-key authenticated encryption on passively- powered IoT devices like WISP nodes. From a cryptographic point of view we thus make a first step to turn these devices into fully-fledged participants of Internet communication. Our crypto processor needs a silicon area of 14.6 kGEs and less than 40 µW of power at 1 MHz for a 130 nm low-leakage CMOS process technology. Keywords: Internet of Things, ASIC, Salsa20, Poly1305, Curve25519. 1 Introduction We need to empower computers with their own means of gathering in- formation, so they can see, hear and smell the world for themselves, in all its random glory. RFID and sensor technology enable computers to observe, identify and understand the world—without the limitations of human-entered data.
    [Show full text]
  • Comparing the Usability of Cryptographic Apis
    Comparing the Usability of Cryptographic APIs Yasemin Acar, Michael Backes, Sascha Fahl, Simson Garfinkel∗, Doowon Kimy, Michelle L. Mazureky, and Christian Stransky CISPA, Saarland University; ∗National Institute of Standards and Technology; yUniversity of Maryland, College Park Abstract—Potentially dangerous cryptography errors are well- Many researchers have used static and dynamic analysis documented in many applications. Conventional wisdom suggests techniques to identify and investigate cryptographic errors in that many of these errors are caused by cryptographic Appli- source code or binaries [2]–[6]. This approach is extremely cation Programming Interfaces (APIs) that are too complicated, have insecure defaults, or are poorly documented. To address this valuable for illustrating the pervasiveness of cryptographic problem, researchers have created several cryptographic libraries errors, and for identifying the kinds of errors seen most that they claim are more usable; however, none of these libraries frequently in practice, but it cannot reveal root causes. Conven- have been empirically evaluated for their ability to promote tional wisdom in the security community suggests these errors more secure development. This paper is the first to examine proliferate in large part because cryptography is so difficult for both how and why the design and resulting usability of different cryptographic libraries affects the security of code written with non-experts to get right. In particular, libraries and Application them, with the goal of understanding how to build effective Programming Interfaces (APIs) are widely seen as being future libraries. We conducted a controlled experiment in which complex, with many confusing options and poorly chosen 256 Python developers recruited from GitHub attempt common defaults (e.g.
    [Show full text]
  • Pynacl Release 1.4.0.Dev1
    PyNaCl Release 1.4.0.dev1 unknown Jun 02, 2019 CONTENTS 1 Features 3 2 Contents 5 2.1 Public Key Encryption..........................................5 2.2 Secret Key Encryption..........................................9 2.3 Digital Signatures............................................ 12 2.4 Hashing.................................................. 18 2.5 Password hashing............................................ 20 3 Support Features 25 3.1 Encoders................................................. 25 3.2 Exceptions................................................ 26 3.3 Utilities.................................................. 26 3.4 nacl.hash................................................. 27 3.5 nacl.pwhash............................................... 28 3.6 nacl.hashlib................................................ 33 3.7 Installation................................................ 34 3.8 Doing A Release............................................. 34 3.9 Reference vectors............................................ 35 3.10 Changelog................................................ 48 3.11 Indices and tables............................................ 50 Bibliography 51 Python Module Index 53 Index 55 i ii PyNaCl, Release 1.4.0.dev1 PyNaCl is a Python binding to libsodium, which is a fork of the Networking and Cryptography library. These libraries have a stated goal of improving usability, security and speed. It supports Python 2.7 and 3.4+ as well as PyPy 2.6+. CONTENTS 1 PyNaCl, Release 1.4.0.dev1 2 CONTENTS CHAPTER ONE
    [Show full text]
  • On Comparing Side‑Channel Properties of AES and Chacha20 on Microcontrollers
    This document is downloaded from DR‑NTU (https://dr.ntu.edu.sg) Nanyang Technological University, Singapore. On comparing side‑channel properties of AES and ChaCha20 on microcontrollers Najm, Zakaria; Jap, Dirmanto; Jungk, Bernhard; Picek, Stjepan; Bhasin, Shivam 2018 Najm, Z., Jap, D., Jungk, B., Picek, S., & Bhasin, S. (2018). On comparing side‑channel properties of AES and ChaCha20 on microcontrollers. 2018 IEEE Asia Pacific Conference on Circuits and Systems (APCCAS). doi:10.1109/APCCAS.2018.8605653 https://hdl.handle.net/10356/104628 https://doi.org/10.1109/APCCAS.2018.8605653 © 2018 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works. The published version is available at: https://doi.org/10.1109/APCCAS.2018.8605653 Downloaded on 30 Sep 2021 18:00:37 SGT On Comparing Side-channel Properties of AES and ChaCha20 on Microcontrollers Zakaria Najm1,2, Dirmanto Jap1, Bernhard Jungk3, Stjepan Picek2, and Shivam Bhasin1 1Temasek Laboratories, Nanyang Technological University, Singapore 2Delft University of Technology, Delft, The Netherlands 3Independent Researcher fzakaria.najm,djap,[email protected], bernhard@projectstarfire.de, [email protected] Abstract—Side-channel attacks are a real threat to many secure When considering countermeasures, it is also the nonlinear systems. In this paper, we consider two ciphers used in the operation which is expensive to implement protected against automotive industry – AES and ChaCha20 and we evaluate their side-channel attacks, unlike other linear components of the resistance against side-channel attacks.
    [Show full text]
  • Stream Cipher Designs: a Review
    SCIENCE CHINA Information Sciences March 2020, Vol. 63 131101:1–131101:25 . REVIEW . https://doi.org/10.1007/s11432-018-9929-x Stream cipher designs: a review Lin JIAO1*, Yonglin HAO1 & Dengguo FENG1,2* 1 State Key Laboratory of Cryptology, Beijing 100878, China; 2 State Key Laboratory of Computer Science, Institute of Software, Chinese Academy of Sciences, Beijing 100190, China Received 13 August 2018/Accepted 30 June 2019/Published online 10 February 2020 Abstract Stream cipher is an important branch of symmetric cryptosystems, which takes obvious advan- tages in speed and scale of hardware implementation. It is suitable for using in the cases of massive data transfer or resource constraints, and has always been a hot and central research topic in cryptography. With the rapid development of network and communication technology, cipher algorithms play more and more crucial role in information security. Simultaneously, the application environment of cipher algorithms is in- creasingly complex, which challenges the existing cipher algorithms and calls for novel suitable designs. To accommodate new strict requirements and provide systematic scientific basis for future designs, this paper reviews the development history of stream ciphers, classifies and summarizes the design principles of typical stream ciphers in groups, briefly discusses the advantages and weakness of various stream ciphers in terms of security and implementation. Finally, it tries to foresee the prospective design directions of stream ciphers. Keywords stream cipher, survey, lightweight, authenticated encryption, homomorphic encryption Citation Jiao L, Hao Y L, Feng D G. Stream cipher designs: a review. Sci China Inf Sci, 2020, 63(3): 131101, https://doi.org/10.1007/s11432-018-9929-x 1 Introduction The widely applied e-commerce, e-government, along with the fast developing cloud computing, big data, have triggered high demands in both efficiency and security of information processing.
    [Show full text]
  • Libsodium V1.0.12 and V1.0.13 Security Assessment
    Libsodium v1.0.12 and v1.0.13 Security Assessment Copyright © 2017 Cryptography Engineering LLC Contents 1 Executive Summary 2 2 Introduction 3 2.1 Scope . .3 2.2 Approach . .4 2.3 Classification and Severity Rating . .4 3 Findings 6 3.1 Summary of Findings . .6 3.2 Overview of Cryptographic Design . .7 3.3 Static Analysis Results . 11 3.4 Dynamic Analysis Results . 11 3.5 Detailed Findings . 12 3.5.1 SD-01: Randomness source on Windows based on unofficial APIs only 12 3.5.2 SD-02: Possible null pointer dereference in key exchange API . 12 3.5.3 SD-03: Potential issues with abort() to terminate program on error conditions . 13 3.5.4 SD-04: Potential risks with the custom RNG API . 13 3.5.5 SD-05: Missing APIs in the libsodium documentation . 14 3.5.6 SD-06: Lack of elliptic curves at higher security levels . 14 3.5.7 Formal Verification (In progress) . 15 3.5.8 Diffs between version 1.0.12 and 1.0.13 . 15 4 Conclusions 17 1 Executive Summary Libsodium1 is an open-source, easy-to-use fork of the C-language NaCl crypto library that is portable, cross-platform and provides many common cryptographic functions. These include public-key encryption, signatures, key derivation, password hashing, message authentication codes, stream ciphers, pseudo-random number generators, random number generation, and support for elliptic curves such as Curve25519. This review was funded by Private Internet AccessTM (PIA), although PIA did not direct the review or modify the results.
    [Show full text]
  • Deriving Chacha20 Key Streams from Targeted Memory Analysis
    Deriving ChaCha20 Key Streams From Targeted Memory Analysis Peter McLaren, William J Buchanan, Gordon Russell, Zhiyuan Tan School of Computing, Edinburgh Napier University, Edinburgh, UK. Abstract—There can be performance and vulnerability con- keys without impacting the target and for target applications cerns with block ciphers, thus stream ciphers can used as an alter- to be unaware of extraction. native. Although many symmetric key stream ciphers are fairly The rest of the paper is structured as follows. Section II resistant to side-channel attacks, cryptographic artefacts may exist in memory. This paper identifies a significant vulnerability discusses related research including side-channel studies and within OpenSSH and OpenSSL and which involves the discovery background on stream ciphers and ChaCha20 cipher imple- of cryptographic artefacts used within the ChaCha20 cipher. This mentations is presented in Section III. Section IV provides can allow for the cracking of tunneled data using a single targeted relevant details of the framework and its implementation is memory extraction. With this, law enforcement agencies and/or given in Section V. The results are presented and discussed in malicious agents could use the vulnerability to take copies of the encryption keys used for each tunnelled connection. The Section VI and conclusions drawn in Section VII. user of a virtual machine would not be alerted to the capturing of the encryption key, as the method runs from an extraction II. RELATED WORK of the running memory. Methods of mitigation include making This paper focuses on the decrypting network traffic en- cryptographic artefacts difficult to discover and limiting memory crypted with ChaCha20-Poly1305 cipher.
    [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]
  • Primus HSM E-Series
    The affordable hardware security module Primus HSM E-Series Market-leading price-performance ratio HSM Network Appliance as a replacement for PCIe cards Simple setup, configuration, and maintenance Tamper protection during transport, storage, and operation Scalable and flexible partitionable to your needs Designed, developed, and manufactured in Switzerland The E-Series of our Primus HSM offers high performance at an outstanding price. Connecting the devices to existing systems is just as easy as commissioning. Different performance classes The E-Series is available in various performance classes: E20, E60 and E150. It can be configu- red via the serial port or over the network with our Decanus remote terminal. Applications The devices of the E-Series are very versatile. Built as network appliances, they lack the disad- vantages of PCIe-based solutions like software dependance of PCIe host systems and the host system itself. The E-Series is ideally suited to secure financial transactions such as EBICS and PCI, access to the cloud (CASB), key management in the PKI environment, or to protect blockchain systems, crypto assets management. Functions The devices generate encryption keys, store and manage the distribution of these keys. Besides key management, they also perform authentication and encryption tasks. Multiple Primus HSM can be grouped together to support redundancy and load balancing. Each Primus HSM can also be partitioned for multiple users (multi-tenancy). Primus supports symmetric (AES, Camellia), asymmetric (RSA, ECC, Diffie-Hellman), and hashing (SHA-2, SHA-3) cryptographic algorithms. They can be seamlessly and easily integrated into any network environment. The Primus E-Se- ries HSM can be remote controlled with our Decanus Remote Control Terminal.
    [Show full text]
  • Chacha20 and Poly1305 Cipher Suites for TLS
    ChaCha20 and Poly1305 Cipher Suites for TLS Adam Langley Wan-Teh Chang Outline ● ChaCha20 stream cipher ● Poly1305 authenticator ● ChaCha20+Poly1305 AEAD construction ● TLS cipher suites ● Performance ChaCha20 stream cipher ● Designed by Dan J. Bernstein ● A variant of Salsa20 to improve diffusion ● Used in BLAKE, a SHA-3 finalist ● 256-bit key ● 64-bit nonce ● 64-bit block counter ● Outputs a 64-byte block of key stream and increments block counter in each invocation ● Plaintext is XOR’ed with the key stream ChaCha20 function constants key counter nonce Input S0 S1 S2 S3 S4 S5 S6 S7 State (16 words) S8 S9 S10 S11 S12 S13 S14 S15 Output key stream (64 bytes) Poly1305 authenticator ● A Wegman-Carter, one-time authenticator ● Designed by Dan J. Bernstein ● 256-bit key ● 128-bit output Poly1305 calculation Key (r, s): r => integer R, s => integer S Input is divided into 16-byte chunks C0 C1 C2 C3 C4 C5 . Cn-2 Cn-1 C0*R^n + C1*R^(n-1) + C2*R^(n-2) + … + Cn-2*R^2 + Cn-1*R mod (2^130- 5) Evaluate this polynomial with Horner’s Rule + S mod 2^128 AEAD construction ● The AEAD key is a ChaCha20 key ● For each nonce, derive: Poly1305 key = ChaCha20(000...0, counter=0) Discard the last 32 bytes of output ● A = additional data ● S = ChaCha20(plaintext, counter=1) ● T = Poly1305(A || len(A) || S || len(S)) ● Ciphertext = S || T TLS cipher suites ● Three forward secret, AEAD ciphers: ○ TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 ○ TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 ○ TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 ● No implicit nonce: fixed_iv_length
    [Show full text]