DOCSLIB.ORG

Lucky Thirteen: Breaking the TLS and DTLS Record Protocols

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Lucky Thirteen: Breaking the TLS and DTLS Record Protocols 2013 IEEE Symposium on Security and Privacy Lucky Thirteen: Breaking the TLS and DTLS Record Protocols Nadhem J. AlFardan and Kenneth G. Paterson Information Security Group, Royal Holloway, University of London Egham, Surrey TW20 0EX, UK Email: {nadhem.alfardan.2009, kenny.paterson}@rhul.ac.uk Abstract—The Transport Layer Security (TLS) protocol to build a secure channel for transporting application-layer aims to provide confidentiality and integrity of data in transit data. Other major components are the (D)TLS Handshake de facto across untrusted networks. TLS has become the secure Protocol, which is responsible for authentication, session protocol of choice for Internet and mobile applications. DTLS is a variant of TLS that is growing in importance. In this key establishment and ciphersuite negotiation, and the TLS paper, we present distinguishing and plaintext recovery attacks Alert Protocol, which carries error messages and manage- against TLS and DTLS. The attacks are based on a delicate ment traffic. Setting aside dedicated authenticated encryption timing analysis of decryption processing in the two protocols. algorithms (which are yet to see widespread support in TLS We include experimental results demonstrating the feasibility of or DTLS implementations), the (D)TLS Record Protocol the attacks in realistic network environments for several differ- ent implementations of TLS and DTLS, including the leading uses a MAC-Encode-Encrypt (MEE) construction. Here, the OpenSSL implementations. We provide countermeasures for plaintext data to be transported is first passed through a the attacks. Finally, we discuss the wider implications of our MAC algorithm (along with certain header bytes) to create attacks for the cryptographic design used by TLS and DTLS. a MAC tag. The supported MAC algorithms are all HMAC- Keywords-TLS, DTLS, CBC-mode encryption, timing attack, based, with MD5, SHA-1 and SHA-256 being the allowed plaintext recovery hash algorithms in TLS 1.2 [9]. Then an encoding step takes place. For the RC4 stream cipher, this just involves I. INTRODUCTION concatenation of the plaintext and the MAC tag, while for CBC-mode encryption (the other possible option), the TLS is arguably the most widely-used secure communica- plaintext, MAC tag, and some encryption padding of a tions protocol on the Internet today. Starting life as SSL, the specified format are concatenated. In the encryption step, protocol was adopted by the IETF and specified as TLS 1.0 the encoded plaintext is encrypted with the selected cipher. [7]. It has since evolved through TLS 1.1 [8] to the current In the case where CBC-mode is selected, the block cipher version TLS 1.2 [9]. Various other RFCs define additional is DES, 3DES or AES (with DES being deprecated in TLS TLS cryptographic algorithms and extensions. TLS is now 1.2). Following [18], we refer to this MEE construction as used for securing a wide variety of application-level traffic MEE-TLS-CBC. We provide greater detail on its operation and has become a serious rival to IPsec for general VPN in the (D)TLS Record Protocol in Section II. usage. It is widely supported in client and server software The widespread use of TLS (and the increasing use and in cryptographic libraries for embedded systems, mobile of DTLS) makes the continued study of the security of devices, and web application frameworks. these protocols of great importance. Indeed, the evolution The DTLS protocol is a close relative of TLS, developed of the TLS Record Protocol has largely been driven by from TLS by making minimal changes so as to allow it cryptographic attacks that have been discovered against it, to operate over UDP instead of TCP [16]. This makes including those in [25], [5], [17], [3], [4], [10], [18], [1]. DTLS suitable for use where the costs of TCP connection Of particular interest lately have been attacks based on the establishment and TCP retransmissions are not warranted, use of chained initialisation vectors (IVs) for CBC-mode for example, in voice and gaming applications. DTLS exists in SSL and TLS 1.0, in particular, the so-called BEAST in two versions, DTLS 1.0 [20], which roughly matches TLS attack [10] which has its roots in [23], [17], [3], [4]. This 1.1 and DTLS 1.2 [21], which aligns with TLS 1.2. attack achieved full plaintext recovery against TLS, but Both TLS and DTLS are actually protocol suites, rather only in scenarios where an attacker can gain access to a than single protocols. The main component of (D)TLS that chosen plaintext capability, perhaps by inducing the user to concerns us here is the Record Protocol, which uses sym- first download malicious javascript code into his browser. metric key cryptography (block ciphers, stream ciphers and Despite this strong requirement, the BEAST attack attracted MAC algorithms) in combination with sequence numbers significant industry and media attention in 2011. Amongst The second author’s research was supported by an EPSRC Leadership the possible countermeasures are upgrading to TLS 1.1 or Fellowship, EP/H005455/1. 1.2, the inclusion of a dummy zero-length message prior to 1081-6011/13 $26.00 © 2013 IEEE 526 DOI 10.1109/SP.2013.42 each real TLS message, or the abandonment of CBC-mode The applicability of the attacks is also implementation- encryption in favour of RC4 or an authenticated encryption dependent, because of the manner in which different imple- algorithm. mentations interpret the RFCs. We have investigated several The other major line of attacks against the TLS Record different open-source implementations of TLS and DTLS, Protocol comprises [25], [5], [17], [18], [1] and relates and found all of them to be vulnerable to our new attacks to how the padding that is required in MEE-TLS-CBC is or variants of them (or even old attacks in one case). handled during decryption. The problems here all stem from We have implemented a selection of the attacks in an the fact that the padding is added after the MAC has been experimental setting. As with earlier attacks, completely computed and so forms unauthenticated data in the encoded breaking TLS is challenging because the attacks create plaintext. Taken altogether, the attacks in [25], [5], [17], [18], “broken” TLS records and so consume many TLS sessions. [1] show that handling padding arising during decryption Nevertheless, our basic attack can extract full plaintext processing is a delicate and complex issue for MEE-TLS- for the current OpenSSL implementation of TLS assuming CBC. the attacker is located, say, in the same LAN segment as It is the case that all these attacks on CBC-mode in the targeted TLS client or server, using roughly 223 TLS TLS could be avoided by adopting RC4 or a dedicated sessions to reliably recover a block of plaintext in a multi- authenticated encryption mode, or perhaps by redesigning session attack scenario like that considered in [5]. Such a (D)TLS to use only an Encrypt-then-MAC construction. scenario is applicable when, for example, an application pro- However, RC4 is not an option for DTLS, and not NIST- tocol performs automatic TLS reconnection and password recommended for TLS [6]; meanwhile authenticated encryp- retransmission. Given its complexity, this basic attack would tion modes are only available in TLS 1.2, which is not seem to present only a theoretical threat. However, variants 1 yet widely supported. Redesigning (D)TLS would require of it are much more effective: even more radical changes than adopting TLS 1.2. So it would be fanciful to “wish away” MEE-TLS-CBC, and all • The distinguishing attacks against TLS are quite prac- the complexity that this entails: this is an option that is tical for OpenSSL, requiring just a handful of sessions firmly embedded in the TLS and DTLS RFCs, in widespread in order to reliably tell apart the encryptions of chosen use, and will remain so for the foreseeable future. On the messages. other hand, we might hope that after more than a decade of • Breaking DTLS implementations is fully practical even intensive study, we would have arrived at a point where we for a remote attacker, since we can exploit the fact that understand how to implement MEE-TLS-CBC securely. In DTLS errors are non-fatal to mount the attacks in a this paper, we show that this is not the case. single session, and reuse the amplification techniques from [1] to boost the delicate timing signals on which A. Our Results our attacks depend. We present a family of attacks that apply to CBC-mode • We also have more efficient partial plaintext recov- in all TLS and DTLS implementations that are compliant ery attacks on TLS and DTLS. For example, against with TLS 1.1 or 1.2, or with DTLS 1.0 or 1.2. They also OpenSSL TLS, an attacker who knows one byte of a apply to implementations of SSL 3.0 and TLS 1.0 that block in either of the last two byte positions can reliably incorporate padding oracle attack countermeasures (imple- recover each of the remaining bytes in that block using mentations that do not are of course already vulnerable to 216 sessions. known attacks). • The complexity of all our attacks can be reduced using The attacks come in various distinguishing, partial plain- language models and sequential statistical techniques text recovery, and full plaintext recovery flavours. For the as in [5], [10]. As a simple example, if the plaintext plaintext recovery attacks, no chosen-plaintext capability is is base64 encoded, as is the case for HTTP basic needed, in contrast to the BEAST attacks: the attacks can be access authentication and cookies, then the number of mounted by a standard man-in-the-middle (MITM) attacker TLS sessions needed to recover a block reduces from who sees only ciphertext and can inject ciphertexts of his roughly 223 to 219.
Load more

Recommended publications
  • Release 2.2.1 Kenneth Reitz
    Requests Documentation Release 2.2.1 Kenneth Reitz January 15, 2016 Contents 1 Testimonials 3 2 Feature Support 5 3 User Guide 7 3.1 Introduction...............................................7 3.2 Installation................................................8 3.3 Quickstart................................................9 3.4 Advanced Usage............................................. 15 3.5 Authentication.............................................. 25 4 Community Guide 29 4.1 Frequently Asked Questions....................................... 29 4.2 Integrations................................................ 30 4.3 Articles & Talks............................................. 30 4.4 Support.................................................. 30 4.5 Community Updates........................................... 31 4.6 Software Updates............................................. 31 5 API Documentation 49 5.1 Developer Interface........................................... 49 6 Contributor Guide 69 6.1 Development Philosophy......................................... 69 6.2 How to Help............................................... 70 6.3 Authors.................................................. 71 Python Module Index 77 i ii Requests Documentation, Release 2.2.1 Release v2.2.1. (Installation) Requests is an Apache2 Licensed HTTP library, written in Python, for human beings. Python’s standard urllib2 module provides most of the HTTP capabilities you need, but the API is thoroughly broken. It was built for a different time — and a different web.
    [Show full text]
  • The Web Never Forgets: Persistent Tracking Mechanisms in the Wild
    The Web Never Forgets: Persistent Tracking Mechanisms in the Wild Gunes Acar1, Christian Eubank2, Steven Englehardt2, Marc Juarez1 Arvind Narayanan2, Claudia Diaz1 1KU Leuven, ESAT/COSIC and iMinds, Leuven, Belgium {name.surname}@esat.kuleuven.be 2Princeton University {cge,ste,arvindn}@cs.princeton.edu ABSTRACT 1. INTRODUCTION We present the first large-scale studies of three advanced web tracking mechanisms — canvas fingerprinting, evercookies A 1999 New York Times article called cookies compre­ and use of “cookie syncing” in conjunction with evercookies. hensive privacy invaders and described them as “surveillance Canvas fingerprinting, a recently developed form of browser files that many marketers implant in the personal computers fingerprinting, has not previously been reported in the wild; of people.” Ten years later, the stealth and sophistication of our results show that over 5% of the top 100,000 websites tracking techniques had advanced to the point that Edward employ it. We then present the first automated study of Felten wrote “If You’re Going to Track Me, Please Use Cook­ evercookies and respawning and the discovery of a new ev­ ies” [18]. Indeed, online tracking has often been described ercookie vector, IndexedDB. Turning to cookie syncing, we as an “arms race” [47], and in this work we study the latest present novel techniques for detection and analysing ID flows advances in that race. and we quantify the amplification of privacy-intrusive track­ The tracking mechanisms we study are advanced in that ing practices due to cookie syncing. they are hard to control, hard to detect and resilient Our evaluation of the defensive techniques used by to blocking or removing.
    [Show full text]
  • Using Frankencerts for Automated Adversarial Testing of Certificate
    Using Frankencerts for Automated Adversarial Testing of Certificate Validation in SSL/TLS Implementations Chad Brubaker ∗ y Suman Janay Baishakhi Rayz Sarfraz Khurshidy Vitaly Shmatikovy ∗Google yThe University of Texas at Austin zUniversity of California, Davis Abstract—Modern network security rests on the Secure Sock- many open-source implementations of SSL/TLS are available ets Layer (SSL) and Transport Layer Security (TLS) protocols. for developers who need to incorporate SSL/TLS into their Distributed systems, mobile and desktop applications, embedded software: OpenSSL, NSS, GnuTLS, CyaSSL, PolarSSL, Ma- devices, and all of secure Web rely on SSL/TLS for protection trixSSL, cryptlib, and several others. Several Web browsers against network attacks. This protection critically depends on include their own, proprietary implementations. whether SSL/TLS clients correctly validate X.509 certificates presented by servers during the SSL/TLS handshake protocol. In this paper, we focus on server authentication, which We design, implement, and apply the first methodology for is the only protection against man-in-the-middle and other large-scale testing of certificate validation logic in SSL/TLS server impersonation attacks, and thus essential for HTTPS implementations. Our first ingredient is “frankencerts,” synthetic and virtually any other application of SSL/TLS. Server authen- certificates that are randomly mutated from parts of real cer- tication in SSL/TLS depends entirely on a single step in the tificates and thus include unusual combinations of extensions handshake protocol. As part of its “Server Hello” message, and constraints. Our second ingredient is differential testing: if the server presents an X.509 certificate with its public key.
    [Show full text]
  • Cache-Timing Attack Against Aes Crypto System - Countermeasures Review
    Edith Cowan University Research Online Australian Information Security Management Conference Conferences, Symposia and Campus Events 2014 Cache-timing attack against aes crypto system - countermeasures review Yaseen H. Taha University of Khartoum Settana M. Abdulh University of Khartoum Naila A. Sadalla University of Khartoum Huwaida Elshoush University of Khartoum Follow this and additional works at: https://ro.ecu.edu.au/ism Part of the Information Security Commons DOI: 10.4225/75/57b65fd1343d3 12th Australian Information Security Management Conference. Held on the 1-3 December, 2014 at Edith Cowan University, Joondalup Campus, Perth, Western Australia. This Conference Proceeding is posted at Research Online. https://ro.ecu.edu.au/ism/166 CACHE-TIMING ATTACK AGAINST AES CRYPTO SYSTEM - COUNTERMEASURES REVIEW Yaseen.H.Taha, Settana.M.Abdulh, Naila.A.Sadalla, Huwaida Elshoush University of Khartoum, Sudan [email protected], [email protected], [email protected], [email protected] Abstract Side channel attacks are based on side channel information, which is information that is leaked from encryption systems. Implementing side channel attacks is possible if and only if an attacker has access to a cryptosystem (victim) or can interact with cryptosystem remotely to compute time statistics of information that collected from targeted system. Cache timing attack is a special type of side channel attack. Here, timing information caused by cache effect is collected and analyzed by an attacker to guess sensitive information such as encryption key or plaintext. Cache timing attack against AES was known theoretically until Bernstein carry out a real implementation of the attack. Fortunately, this attack can be a success only by exploiting bad implementation in software or hardware, not for algorithm structure weaknesses, and that means attack could be prevented if proper implementation has been used.
    [Show full text]
  • Preventing Session Hijacking Using Encrypted One-Time-Cookies
    Preventing Session Hijacking using Encrypted One-Time-Cookies Renascence Tarafder Prapty 1, Shuhana Azmin 1 Md. Shohrab Hossain 1, Husnu S. Narman2 1Department of Computer Science and Engineering, Bangladesh University of Engineering and Technology, Bangladesh 2Weisberg Division of Computer Science, Marshall University, Huntington, WV, USA Email: [email protected],[email protected], [email protected], [email protected] Abstract—Hypertext Transfer Protocol (HTTP) cookies are cryptography-based techniques to achieve cookie confidential- pieces of information shared between HTTP server and client to ity and integrity. However, each mechanism lacks in one aspect remember stateful information for the stateless HTTP protocol or another. The scheme described in [1] does not achieve or to record a user’s browsing activity. Cookies are often used in web applications to identify a user and corresponding authen- cookie confidentiality. In [3], the web server is required to ticated session. Thus, stealing a cookie can lead to hijacking an store one-time keys that lead to key management problems. authenticated user’s session. To prevent this type of attack, a In [2] and [4], a one-time key is encrypted by the web server’s cookie protection mechanism is required. In this paper, we have public key. As public key encryption is computationally expen- proposed a secure and efficient cookie protection system. We have sive, these schemes are not efficient. [5] proposes the use of used one time cookies to prevent attacker from performing cookie injection. To ensure cookie integrity and confidentiality, we have cache cookies as an alternative to cookies for authentication of encrypted sensitive information in the cookie.
    [Show full text]
  • Protecting Encrypted Cookies from Compression Side-Channel Attacks
    Protecting encrypted cookies from compression side-channel attacks Janaka Alawatugoda1, Douglas Stebila1;2, and Colin Boyd3 1 School of Electrical Engineering and Computer Science, 2 School of Mathematical Sciences 1;2 Queensland University of Technology, Brisbane, Australia [email protected],[email protected] 3 Department of Telematics, Norwegian University of Science and Technology, Trondheim, Norway [email protected] December 28, 2014 Abstract Compression is desirable for network applications as it saves bandwidth; however, when data is compressed before being encrypted, the amount of compression leaks information about the amount of redundancy in the plaintext. This side channel has led to successful CRIME and BREACH attacks on web traffic protected by the Transport Layer Security (TLS) protocol. The general guidance in light of these attacks has been to disable compression, preserving confidentiality but sacrificing bandwidth. In this paper, we examine two techniques|heuristic separation of secrets and fixed-dictionary compression|for enabling compression while protecting high-value secrets, such as cookies, from attack. We model the security offered by these techniques and report on the amount of compressibility that they can achieve. 1This is the full version of a paper published in the Proceedings of the 19th International Conference on Financial Cryptography and Data Security (FC 2015) in San Juan, Puerto Rico, USA, January 26{30, 2015, organized by the International Financial Cryptography Association in cooperation with IACR. 1 Contents 1 Introduction 3 2 Definitions 6 2.1 Encryption and compression schemes.........................6 2.2 Existing security notions................................7 2.3 New security notions..................................7 2.4 Relations and separations between security notions.................8 3 Technique 1: Separating secrets from user inputs9 3.1 The scheme.......................................9 3.2 CCI security of basic separating-secrets technique.................
    [Show full text]
  • HTTP Cookie - Wikipedia, the Free Encyclopedia 14/05/2014
    HTTP cookie - Wikipedia, the free encyclopedia 14/05/2014 Create account Log in Article Talk Read Edit View history Search HTTP cookie From Wikipedia, the free encyclopedia Navigation A cookie, also known as an HTTP cookie, web cookie, or browser HTTP Main page cookie, is a small piece of data sent from a website and stored in a Persistence · Compression · HTTPS · Contents user's web browser while the user is browsing that website. Every time Request methods Featured content the user loads the website, the browser sends the cookie back to the OPTIONS · GET · HEAD · POST · PUT · Current events server to notify the website of the user's previous activity.[1] Cookies DELETE · TRACE · CONNECT · PATCH · Random article Donate to Wikipedia were designed to be a reliable mechanism for websites to remember Header fields Wikimedia Shop stateful information (such as items in a shopping cart) or to record the Cookie · ETag · Location · HTTP referer · DNT user's browsing activity (including clicking particular buttons, logging in, · X-Forwarded-For · Interaction or recording which pages were visited by the user as far back as months Status codes or years ago). 301 Moved Permanently · 302 Found · Help 303 See Other · 403 Forbidden · About Wikipedia Although cookies cannot carry viruses, and cannot install malware on 404 Not Found · [2] Community portal the host computer, tracking cookies and especially third-party v · t · e · Recent changes tracking cookies are commonly used as ways to compile long-term Contact page records of individuals' browsing histories—a potential privacy concern that prompted European[3] and U.S.
    [Show full text]
  • Sizzle: a Standards-Based End-To-End Security Architecture for the Embedded Internet
    Sizzle: A Standards-based end-to-end Security Architecture for the Embedded Internet Vipul Gupta, Matthew Millard,∗ Stephen Fung*, Yu Zhu*, Nils Gura, Hans Eberle, Sheueling Chang Shantz Sun Microsystems Laboratories 16 Network Circle, UMPK16 160 Menlo Park, CA 94025 [email protected], [email protected], [email protected] [email protected], {nils.gura, hans.eberle, sheueling.chang}@sun.com Abstract numbers of even simpler, more constrained devices (sen- sors, home appliances, personal medical devices) get con- This paper introduces Sizzle, the first fully-implemented nected to the Internet. The term “embedded Internet” is end-to-end security architecture for highly constrained em- often used to refer to the phase in the Internet’s evolution bedded devices. According to popular perception, public- when it is invisibly and tightly woven into our daily lives. key cryptography is beyond the capabilities of such devices. Embedded devices with sensing and communication capa- We show that elliptic curve cryptography (ECC) not only bilities will enable the application of computing technolo- makes public-key cryptography feasible on these devices, it gies in settings where they are unusual today: habitat mon- allows one to create a complete secure web server stack itoring [26], medical emergency response [31], battlefield including SSL, HTTP and user application that runs effi- management and home automation. ciently within very tight resource constraints. Our small Many of these applications have security requirements. footprint HTTPS stack needs less than 4KB of RAM and For example, health information must only be made avail- interoperates with an ECC-enabled version of the Mozilla able to authorized personnel (authentication) and be pro- web browser.
    [Show full text]
  • Arxiv:1911.09312V2 [Cs.CR] 12 Dec 2019
    Revisiting and Evaluating Software Side-channel Vulnerabilities and Countermeasures in Cryptographic Applications Tianwei Zhang Jun Jiang Yinqian Zhang Nanyang Technological University Two Sigma Investments, LP The Ohio State University [email protected] [email protected] [email protected] Abstract—We systematize software side-channel attacks with three questions: (1) What are the common and distinct a focus on vulnerabilities and countermeasures in the cryp- features of various vulnerabilities? (2) What are common tographic implementations. Particularly, we survey past re- mitigation strategies? (3) What is the status quo of cryp- search literature to categorize vulnerable implementations, tographic applications regarding side-channel vulnerabili- and identify common strategies to eliminate them. We then ties? Past work only surveyed attack techniques and media evaluate popular libraries and applications, quantitatively [20–31], without offering unified summaries for software measuring and comparing the vulnerability severity, re- vulnerabilities and countermeasures that are more useful. sponse time and coverage. Based on these characterizations This paper provides a comprehensive characterization and evaluations, we offer some insights for side-channel of side-channel vulnerabilities and countermeasures, as researchers, cryptographic software developers and users. well as evaluations of cryptographic applications related We hope our study can inspire the side-channel research to side-channel attacks. We present this study in three di- community to discover new vulnerabilities, and more im- rections. (1) Systematization of literature: we characterize portantly, to fortify applications against them. the vulnerabilities from past work with regard to the im- plementations; for each vulnerability, we describe the root cause and the technique required to launch a successful 1.
    [Show full text]
  • Some Comments on the First Round AES Evaluation Of
    Some Comments on the First Round AES Evaluation of RC6 1 2 1 Scott Contini , Ronald L. Rivest , M.J.B. Robshaw , 1 and Yiqun Lisa Yin 1 RSA Lab oratories, 2955 Campus Drive, San Mateo, CA 94403, USA fscontini,matt,yiqung@rsa. com 2 M.I.T. Lab oratory for Computer Science, 545 Technology Square, Cambridge, MA 02139, USA [email protected] 1 Intro duction The rst round of the AES pro cess is coming to an end. Since August of 1998, the cryptographic community has had the opp ortunity to consider each of the fteen prop osed AES candidates. In this note, we take the opp ortunity to answer some of the questions and to resp ond to some of the issues that have b een raised ab out the suitabilityofRC6 as an AES candidate. 2 Encryption/Decryption Performance of RC6 Since the publication of RC6 a variety of researchers and implementors have examined RC6 and considered its p erformance in a wide range of environments. 2.1 32-bit architectures RC6 is one of the fastest AES prop osals on 32-bit architectures, particularly so on the NIST reference platform of a 200 MHz Pentium Pro. It is argued by many that the most reasonable way to assess the p erformance of an algorithm is to consider its sp eed in an assembly language implementation. We agree that this is the case. However it is also interesting to consider how the p erformance of RC6 compares when using di erent compilers. It is imp ortant to note that to take advantage of compiler-sp eci c optimizations the source co de provided to the compiler might need to b e changed.
    [Show full text]
  • An Adaptive-Ciphertext Attack Against I XOR C Block Cipher Modes With
    A A-C A “I ⊕ C” B C M W O Jon Passki Tom Ritter [email protected] [email protected] May 24, 2012 Abstract Certain block cipher confidentiality modes are susceptible to an adaptive chosen-ciphertext attack against the underlying format of the plaintext. When the application decrypts altered ciphertext and attempts to process the manipulated plaintext, it may disclose information about intermediate values resulting in an oracle. In this paper we describe how to recognize and exploit such an oracle to decrypt ciphertext and control the decryption to result in arbitrary plaintext. We also discuss ways to mitigate and remedy the issue. 1 I Quoting from [1]: Adaptive chosen-ciphertext attacks on cryptographic protocols allow an attacker to decrypt a cipher- text C, getting the plaintext M, by submitting a series of chosen-ciphertexts C0= 6 C to an oracle which returns information on the decryption. The ciphertexts can be adaptively chosen so that information on previous decryptions is available before the next chosen ciphertext is submitted. Adaptive chosen-ciphertext attacks against different confidentiality modes are not novel. The CBC confidentiality mode can suffer from a side channel attack against padding verification [2], popularized by [3]. A variant of the Cipher Feedback (CFB) confidentiality mode has been attacked in different encryption mail protocols by [4, 5, 1], and the padding schemes of asymmetric ciphers are another source of such attacks [6, 7]. In some form, they rely on the use of an oracle that leaks or communicates information back to attackers. We examine four different confidentiality modes encrypting plaintext that is separated by a delimiter, and the absence or inclusion of that delimiter generates an oracle by the application.
    [Show full text]
  • Cs 255 (Introduction to Cryptography)
    CS 255 (INTRODUCTION TO CRYPTOGRAPHY) DAVID WU Abstract. Notes taken in Professor Boneh’s Introduction to Cryptography course (CS 255) in Winter, 2012. There may be errors! Be warned! Contents 1. 1/11: Introduction and Stream Ciphers 2 1.1. Introduction 2 1.2. History of Cryptography 3 1.3. Stream Ciphers 4 1.4. Pseudorandom Generators (PRGs) 5 1.5. Attacks on Stream Ciphers and OTP 6 1.6. Stream Ciphers in Practice 6 2. 1/18: PRGs and Semantic Security 7 2.1. Secure PRGs 7 2.2. Semantic Security 8 2.3. Generating Random Bits in Practice 9 2.4. Block Ciphers 9 3. 1/23: Block Ciphers 9 3.1. Pseudorandom Functions (PRF) 9 3.2. Data Encryption Standard (DES) 10 3.3. Advanced Encryption Standard (AES) 12 3.4. Exhaustive Search Attacks 12 3.5. More Attacks on Block Ciphers 13 3.6. Block Cipher Modes of Operation 13 4. 1/25: Message Integrity 15 4.1. Message Integrity 15 5. 1/27: Proofs in Cryptography 17 5.1. Time/Space Tradeoff 17 5.2. Proofs in Cryptography 17 6. 1/30: MAC Functions 18 6.1. Message Integrity 18 6.2. MAC Padding 18 6.3. Parallel MAC (PMAC) 19 6.4. One-time MAC 20 6.5. Collision Resistance 21 7. 2/1: Collision Resistance 21 7.1. Collision Resistant Hash Functions 21 7.2. Construction of Collision Resistant Hash Functions 22 7.3. Provably Secure Compression Functions 23 8. 2/6: HMAC And Timing Attacks 23 8.1. HMAC 23 8.2.
    [Show full text]