DOCSLIB.ORG

Verified Correctness and Security of Openssl HMAC Lennart Beringer, Princeton University; Adam Petcher, Harvard University and MIT Lincoln Laboratory; Katherine Q

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Verified Correctness and Security of OpenSSL HMAC Lennart Beringer, Princeton University; Adam Petcher, Harvard University and MIT Lincoln Laboratory; Katherine Q. Ye and Andrew W. Appel, Princeton University https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/beringer This paper is included in the Proceedings of the 24th USENIX Security Symposium August 12–14, 2015 • Washington, D.C. ISBN 978-1-939133-11-3 Open access to the Proceedings of the 24th USENIX Security Symposium is sponsored by USENIX Verified correctness and security of OpenSSL HMAC Lennart Beringer Adam Petcher Katherine Q. Ye Andrew W. Appel Princeton Univ. Harvard Univ. and Princeton Univ. Princeton Univ. MIT Lincoln Laboratory Abstract Implementation problems. The SHA program (in C) might incorrectly implement the SHA algorithm; We have proved, with machine-checked proofs in Coq, the HMAC program might incorrectly implement that an OpenSSL implementation of HMAC with SHA- the HMAC algorithm; the programs might be cor- 256 correctly implements its FIPS functional specifi- rect but permit side channels such as power analy- cation and that its functional specification guarantees sis, timing analysis, or fault injection. the expected cryptographic properties. This is the first machine-checked cryptographic proof that combines Specification mismatch. The specification of HMAC a source-program implementation proof, a compiler- or SHA used in the cryptographic-properties [15] correctness proof, and a cryptographic-security proof, proof might be subtly different from the one pub- with no gaps at the specification interfaces. lished as the specification of computer programs The verification was done using three systems within [28, 27]. The proofs about C programs might in- the Coq proof assistant: the Foundational Cryptogra- terpret the semantics of the C language differently phy Framework, to verify crypto properties of functional from the C compiler. specs; the Verified Software Toolchain, to verify C pro- grams w.r.t. functional specs; and CompCert, for verified Based on Bellare and Rogaway’s probabilistic game compilation of C to assembly language. framework [16] for cryptographic proofs, Halevi [30] ad- vocates creating an “automated tool to help us with the mundane parts of writing and checking common argu- 1 Introduction ments in [game-based] proofs.” Barthe et al. [13] present such a tool in the form of CertiCrypt, a framework that HMAC is a cryptographic authentication algorithm, the “enables the machine-checked construction and verifica- “Keyed-Hash Message Authentication Code,” widely tion” of proofs using the same game-based techniques, used in conjunction with the SHA-256 cryptographic written in code. Barthe et al.’s more recent EasyCrypt hashing primitive. The sender and receiver of a mes- system [12] is a more lightweight, user-friendly version sage m share a secret session key k. The sender com- (but not foundational, i.e., the implementation is not putes s = HMAC(k,m) and appends s to m. The receiver proved sound in any machine-checked general-purpose computes s = HMAC(k,m) and verifies that s = s. In logic). In this paper we use the Foundational Cryptogra- principle, a third party will not know k and thus cannot phy Framework (FCF) of Petcher and Morrisett [38]. compute s. Therefore, the receiver can infer that message But the automated tools envisioned by Halevi—and m really originated with the sender. built by Barthe et al. and Petcher—address only the What could go wrong? “algorithmic/cryptographic problems.” We also need Algorithmic/cryptographic problems. The compres- machine-checked tools for functional correctness of C sion function underlying SHA might fail to have programs—not just static analysis tools that verify the the cryptographic property of being a pseudoran- absence of buffer overruns. And we need the functional- dom function (PRF); the SHA algorithm might not correctness tools to connect, with machine-checked be the right construction over its compression func- proofs of equivalence, to the crypto-algorithm proofs. By tion; the HMAC algorithm might fail to have the 2015, proof systems for formally reasoning about crypto cryptographic property of being a PRF; we might algorithms and C programs have come far enough that it even be considering the wrong crypto properties. is now possible to do this. USENIX Association 24th USENIX Security Symposium 207 15. HMAC cryptographic Bold face security property indicates new results in 14. SHA cryptographic 16. Crypto security this paper security property proof (nobody knows 3. Bellare HMAC functional spec how to prove this) 4. Equivalence End-to-End Proof machine-checked 1. SHA functional spec 2. FIPS HMAC functional spec crypto-security 10. SHA API spec + implementation 12. HMAC API spec proof 11. Correctness 13. Correctness Proof 5. Verifiable C Proof program logic sha.c hmac.c 7. Soundness Proof 6. C operational CompCert semantics verified optimizing 9. Correctness C compiler Proof Figure 1: Architecture 8. Intel IA-32 of our assurance case. sha.s hmac.s operational semantics Here we present machine-checked proofs, in Coq, of done proofs of substantial C programs in proof assistants many components, connected and checked at their speci- [32, 29]. fication interfaces so that we get a truly end-to-end result: Our entire proof (including the algorithmic/crypto- Version 0.9.1c of OpenSSL’s HMAC and SHA-256 cor- graphic proofs, the implementation proofs, and the spec- rectly implements the FIPS 198-1 and FIPS 180-4 stan- ification matches) is done in Coq, so that we avoid mis- dards, respectively; and that same FIPS 198-1 HMAC understandings at interfaces. To prove our main theorem, standard is a PRF, subject to certain standard (unproved) we took these steps (cf. Figure 1): assumptions about the SHA-256 algorithm that we state 1. Formalized.[5] We use a Coq formalization of the formally and explicitly. FIPS 180-4 Secure Hash Standard [28] as a speci- Software is large, complex, and always under main- fication of SHA-256. (Henceforth, “formalized” or tenance; if we “prove” something about a real program “proved” implies “in the Coq proof assistant.”) then the proof (and its correspondence to the syntactic program) had better be checked by machine. Fortunately, 2. Formalized.* We have formalized the FIPS 198-1 as Godel¨ showed, checking a proof is a simple calcula- Keyed-Hash Message Authentication Code [27] as tion. Today, proof checkers can be simple trusted (and a specification of HMAC. (Henceforth, the * indi- trustworthy) kernel programs [7]. cates new work first reported in this paper; other- A proof assistant comprises a proof-checking kernel wise we provide a citation to previous work.) with an untrusted proof-development system. The sys- 3. Formalized.* We have formalized Bellare’s func- tem is typically interactive, relying on the user to build tional characterization of the HMAC algorithm. the overall structure of the proof and supply the impor- tant invariants and induction hypotheses, with many of 4. Proved.* We have proved the equivalence of FIPS the details filled in by tactical proof automation or by de- 198-1 with Bellare’s functional characterization of cision procedures such as SMT or Omega. HMAC. Coq is an open-source proof assistant under develop- 5. Formalized.[6] We use Verifiable C, a program logic ment since 1984. In the 21st century it has been used for (embedded in Coq) for specifying and proving func- practical applications such as Leroy’s correctness proof tional correctness of C programs. of an optimizing C compiler [34]. But note, that com- piler was not itself written in C; the proof theory of C 6. Formalized.[35] Leroy has formalized the opera- makes life harder, and only more recently have people tional semantics of the C programming language. 208 24th USENIX Security Symposium USENIX Association 7. Proved.[6] Verifiable C has been proved sound. Theorem. The assembly-language program, resulting That is, if you specify and prove any input-output from compiling OpenSSL 0.9.1c using CompCert, cor- property of your C program using Verifiable C, then rectly implements the FIPS standards for HMAC and that property actually holds in Leroy’s operational SHA, and implements a cryptographically secure PRF semantics of the C language. subject to the usual assumptions about SHA. Proof. Machine-checked, in Coq, by chaining together 8. Formalized.[35] Leroy has formalized the opera- specifications and proofs 1–16. Available open-source at tional semantics of the Intel x86 (and PowerPC and https://github.com/PrincetonUniversity/VST/, subdi- ARM) assembly language. rectories sha, fcf, hmacfcf. 9. Proved.[35] If the CompCert optimizing C compiler The trusted code base (TCB) of our system is quite translates a C program to assembly language, then small, comprising only items 1, 2, 8, 12, 14, 15. Items input-output property of the C program is preserved 4, 7, 9, 11, 13, 16 need not be trusted, because they are in the assembly-language program. proofs checked by the kernel of Coq. Items 3, 5, 6, 10 need not be trusted, because they are specification inter- 10. Formalized.[5] We rely on a formalization (in Ver- faces checked on both sides by Coq, as Appel [5, 8] § ifiable C) of the API interface of the OpenSSL explains. header file for SHA-256, including its semantic connection to the formalization of the FIPS Secure One needs to trust the Coq kernel and the software that compiles it; see Appel’s discussion [5, 12]. Hash Standard. § We do not analyze timing channels or other side chan- 11. Proved.[5] The C program implementing SHA-256, nels. But the programs we prove correct are standard lightly adapted from the OpenSSL implementation, C programs for which standard timing and side-channel has the input-output (API) properties specified by analysis tools and techniques can be used.
Recommended publications
  • Improved Cryptanalysis of the Reduced Grøstl Compression Function, ECHO Permutation and AES Block Cipher

    Improved Cryptanalysis of the Reduced Grøstl Compression Function, ECHO Permutation and AES Block Cipher

    Improved Cryptanalysis of the Reduced Grøstl Compression Function, ECHO Permutation and AES Block Cipher Florian Mendel1, Thomas Peyrin2, Christian Rechberger1, and Martin Schl¨affer1 1 IAIK, Graz University of Technology, Austria 2 Ingenico, France [email protected],[email protected] Abstract. In this paper, we propose two new ways to mount attacks on the SHA-3 candidates Grøstl, and ECHO, and apply these attacks also to the AES. Our results improve upon and extend the rebound attack. Using the new techniques, we are able to extend the number of rounds in which available degrees of freedom can be used. As a result, we present the first attack on 7 rounds for the Grøstl-256 output transformation3 and improve the semi-free-start collision attack on 6 rounds. Further, we present an improved known-key distinguisher for 7 rounds of the AES block cipher and the internal permutation used in ECHO. Keywords: hash function, block cipher, cryptanalysis, semi-free-start collision, known-key distinguisher 1 Introduction Recently, a new wave of hash function proposals appeared, following a call for submissions to the SHA-3 contest organized by NIST [26]. In order to analyze these proposals, the toolbox which is at the cryptanalysts' disposal needs to be extended. Meet-in-the-middle and differential attacks are commonly used. A recent extension of differential cryptanalysis to hash functions is the rebound attack [22] originally applied to reduced (7.5 rounds) Whirlpool (standardized since 2000 by ISO/IEC 10118-3:2004) and a reduced version (6 rounds) of the SHA-3 candidate Grøstl-256 [14], which both have 10 rounds in total.
  • IMPLEMENTATION and BENCHMARKING of PADDING UNITS and HMAC for SHA-3 CANDIDATES in FPGAS and ASICS by Ambarish Vyas a Thesis Subm

    IMPLEMENTATION and BENCHMARKING of PADDING UNITS and HMAC for SHA-3 CANDIDATES in FPGAS and ASICS by Ambarish Vyas a Thesis Subm

    IMPLEMENTATION AND BENCHMARKING OF PADDING UNITS AND HMAC FOR SHA-3 CANDIDATES IN FPGAS AND ASICS by Ambarish Vyas A Thesis Submitted to the Graduate Faculty of George Mason University in Partial Fulfillment of The Requirements for the Degree of Master of Science Computer Engineering Committee: Dr. Kris Gaj, Thesis Director Dr. Jens-Peter Kaps. Committee Member Dr. Bernd-Peter Paris. Committee Member Dr. Andre Manitius, Department Chair of Electrical and Computer Engineering Dr. Lloyd J. Griffiths. Dean, Volgenau School of Engineering Date: ---J d. / q /9- 0 II Fall Semester 2011 George Mason University Fairfax, VA Implementation and Benchmarking of Padding Units and HMAC for SHA-3 Candidates in FPGAs and ASICs A thesis submitted in partial fulfillment of the requirements for the degree of Master of Science at George Mason University By Ambarish Vyas Bachelor of Science University of Pune, 2009 Director: Dr. Kris Gaj, Associate Professor Department of Electrical and Computer Engineering Fall Semester 2011 George Mason University Fairfax, VA Copyright c 2011 by Ambarish Vyas All Rights Reserved ii Acknowledgments I would like to use this oppurtunity to thank the people who have supported me throughout my thesis. First and foremost my advisor Dr.Kris Gaj, without his zeal, his motivation, his patience, his confidence in me, his humility, his diverse knowledge, and his great efforts this thesis wouldn't be possible. It is difficult to exaggerate my gratitude towards him. I also thank Ekawat Homsirikamol for his contributions to this project. He has significantly contributed to the designs and implementations of the architectures. Additionally, I am indebted to my student colleagues in CERG for providing a fun environment to learn and giving invaluable tips and support.
  • Grøstl – a SHA-3 Candidate∗

    Grøstl – a SHA-3 Candidate∗

    Grøstl – a SHA-3 candidate∗ http://www.groestl.info Praveen Gauravaram1, Lars R. Knudsen1, Krystian Matusiewicz1, Florian Mendel2, Christian Rechberger2, Martin Schl¨affer2, and Søren S. Thomsen1 1Department of Mathematics, Technical University of Denmark, Matematiktorvet 303S, DK-2800 Kgs. Lyngby, Denmark 2Institute for Applied Information Processing and Communications (IAIK), Graz University of Technology, Inffeldgasse 16a, A-8010 Graz, Austria January 15, 2009 Summary Grøstl is a SHA-3 candidate proposal. Grøstl is an iterated hash function with a compression function built from two fixed, large, distinct permutations. The design of Grøstl is transparent and based on principles very different from those used in the SHA-family. The two permutations are constructed using the wide trail design strategy, which makes it possible to give strong statements about the resistance of Grøstl against large classes of cryptanalytic attacks. Moreover, if these permutations are assumed to be ideal, there is a proof for the security of the hash function. Grøstl is a byte-oriented SP-network which borrows components from the AES. The S-box used is identical to the one used in the block cipher AES and the diffusion layers are constructed in a similar manner to those of the AES. As a consequence there is a very strong confusion and diffusion in Grøstl. Grøstl is a so-called wide-pipe construction where the size of the internal state is signifi- cantly larger than the size of the output. This has the effect that all known, generic attacks on the hash function are made much more difficult. Grøstl has good performance on a wide range of platforms, and counter-measures against side-channel attacks are well-understood from similar work on the AES.
  • Lecture9.Pdf

    Lecture9.Pdf

    Merkle- Suppose H is a Damgaord hash function built from a secure compression function : several to build a function ways keyed : m : = H Ilm 1 . end FCK ) (k ) Prep key , " " ↳ - Insecure due to structure of Merkle : can mount an extension attack: H (KH m) can Barnyard given , compute ' Hlkllmllm ) by extending Merkle- Danged chain = : m : 2 . FCK ) 11k) Append key , Hlm ↳ - - to : Similar to hash then MAC construction and vulnerable same offline attack adversary finds a collision in the - - > Merkle and uses that to construct a for SHA I used PDF files Barnyard prefix forgery f , they ↳ - Structure in SHA I (can matches exploited collision demonstration generate arbitrary collisions once prefix ) ' = : FCK m - H on h 3. method , ) ( K HMH K) for reasonable randomness ( both Envelope pseudo assumptions e.g , : = - = i - - : F ( m m } : h K m h m k 4. nest ( ki ) H Ck H (k m ( , and m ( ) is a PRF both Two , kz , ) (ka HH , )) F- , ) ) Falk , ) , ) key , - of these constructions are secure PRFS on a variable size domain hash- based MAC ✓ a the - nest with correlated : HMAC is PRF / MAC based on two key (though keys) : = m H H ka m HMACCK ( K H ( , )) , ) , where k ← k ④ and kz ← k to , ipad opad and and are fixed ( in the HMAC standard) ipad opad strings specified I 0×36 repeated %x5C repeated : k . a Since , and ka are correlated need to make on h remains under Sety , stronger assumption security leg , pseudorandom related attack) Instantiations : denoted HMAC- H where H is the hash function Typically , HMAC- SHAI %" - - HMAC SHA256
  • Authenticated Key-Exchange: Protocols, Attacks, and Analyses

    Authenticated Key-Exchange: Protocols, Attacks, and Analyses

    The HMAC construction: A decade later Ran Canetti IBM Research What is HMAC? ● HMAC: A Message Authentication Code based on Cryptographic Hash functions [Bellare-C-Krawczyk96]. ● Developed for the IPSec standard of the Internet Engineering Task Force (IETF). ● Currently: - incorporated in IPSec, SSL/TLS, SSH, Kerberos, SHTTP, HTTPS, SRTP, MSEC, ... - ANSI and NIST standards - Used daily by all of us. Why is HMAC interesting? ● “Theoretical” security analysis impacts the security of real systems. ● Demonstrates the importance of modelling and abstraction in practical cryptography. ● The recent attacks on hash functions highlight the properties of the HMAC design and analysis. ● Use the HMAC lesson to propose requirements for the next cryptographic hash function. Organization ● Authentication, MACs, Hash-based MACs ● HMAC construction and analysis ● Other uses of HMAC: ● Pseudo-Random Functions ● Extractors ● What properties do we want from a “cryptographic hash function”? Authentication m m' A B The goal: Any tampering with messages should be detected. “If B accepts message m from A then A has sent m to B.” • One of the most basic cryptographic tasks • The basis for any security-conscious interaction over an open network Elements of authentication The structure of typical cryptographic solutions: • Initial entity authentication: The parties perform an initial exchange, bootstrapping from initial trusted information on each other. The result is a secret key that binds the parties to each other. • Message authentication: The parties use the key to authenticate exchanged messages via message authentication codes. Message Authentication Codes m,t m',t' A B t=FK(m) t' =? FK(m') • A and B obtain a common secret key K • A and B agree on a keyed function F • A sends t=FK(m) together with m • B gets (m',t') and accepts m' if t'=FK(m').
  • Security Analysis for MQTT in Internet of Things

    Security Analysis for MQTT in Internet of Things

    DEGREE PROJECT IN COMPUTER SCIENCE AND ENGINEERING, SECOND CYCLE, 30 CREDITS STOCKHOLM, SWEDEN 2018 Security analysis for MQTT in Internet of Things DIEGO SALAS UGALDE KTH ROYAL INSTITUTE OF TECHNOLOGY SCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE Security analysis for MQTT in Internet of Things DIEGO SALAS UGALDE Master in Network Services and Systems Date: November 22, 2018 Supervisor: Johan Gustafsson (Zyax AB) Examiner: Panos Papadimitratos (KTH) Swedish title: Säkerhet analys för MQTT i IoT School of Electrical Engineering and Computer Science iii Abstract Internet of Things, i.e. IoT, has become a very trending topic in re- search and has been investigated in recent years. There can be several different scenarios and implementations where IoT is involved. Each of them has its requirements. In these type IoT networks new com- munication protocols which are meant to be lightweight are included such as MQTT. In this thesis there are two key aspects which are under study: secu- rity and achieving a lightweight communication. We want to propose a secure and lightweight solution in an IoT scenario using MQTT as the communication protocol. We perform different experiments with different implementations over MQTT which we evaluate, compare and analyze. The results obtained help to answer our research questions and show that the proposed solution fulfills the goals we proposed in the beginning of this work. iv Sammanfattning "Internet of Things", dvs IoT, har blivit ett mycket trenderande ämne inom forskning och har undersökts de senaste åren. Det kan finnas flera olika scenarier och implementeringar där IoT är involverad. Var och en av dem har sina krav.
  • BLAKE2: Simpler, Smaller, Fast As MD5

    BLAKE2: Simpler, Smaller, Fast As MD5

    BLAKE2: simpler, smaller, fast as MD5 Jean-Philippe Aumasson1, Samuel Neves2, Zooko Wilcox-O'Hearn3, and Christian Winnerlein4 1 Kudelski Security, Switzerland [email protected] 2 University of Coimbra, Portugal [email protected] 3 Least Authority Enterprises, USA [email protected] 4 Ludwig Maximilian University of Munich, Germany [email protected] Abstract. We present the hash function BLAKE2, an improved version of the SHA-3 finalist BLAKE optimized for speed in software. Target applications include cloud storage, intrusion detection, or version control systems. BLAKE2 comes in two main flavors: BLAKE2b is optimized for 64-bit platforms, and BLAKE2s for smaller architectures. On 64- bit platforms, BLAKE2 is often faster than MD5, yet provides security similar to that of SHA-3: up to 256-bit collision resistance, immunity to length extension, indifferentiability from a random oracle, etc. We specify parallel versions BLAKE2bp and BLAKE2sp that are up to 4 and 8 times faster, by taking advantage of SIMD and/or multiple cores. BLAKE2 reduces the RAM requirements of BLAKE down to 168 bytes, making it smaller than any of the five SHA-3 finalists, and 32% smaller than BLAKE. Finally, BLAKE2 provides a comprehensive support for tree-hashing as well as keyed hashing (be it in sequential or tree mode). 1 Introduction The SHA-3 Competition succeeded in selecting a hash function that comple- ments SHA-2 and is much faster than SHA-2 in hardware [1]. There is nev- ertheless a demand for fast software hashing for applications such as integrity checking and deduplication in filesystems and cloud storage, host-based intrusion detection, version control systems, or secure boot schemes.
  • A (Second) Preimage Attack on the GOST Hash Function

    A (Second) Preimage Attack on the GOST Hash Function

    A (Second) Preimage Attack on the GOST Hash Function Florian Mendel, Norbert Pramstaller, and Christian Rechberger Institute for Applied Information Processing and Communications (IAIK), Graz University of Technology, Inffeldgasse 16a, A-8010 Graz, Austria [email protected] Abstract. In this article, we analyze the security of the GOST hash function with respect to (second) preimage resistance. The GOST hash function, defined in the Russian standard GOST-R 34.11-94, is an iter- ated hash function producing a 256-bit hash value. As opposed to most commonly used hash functions such as MD5 and SHA-1, the GOST hash function defines, in addition to the common iterated structure, a check- sum computed over all input message blocks. This checksum is then part of the final hash value computation. For this hash function, we show how to construct second preimages and preimages with a complexity of about 2225 compression function evaluations and a memory requirement of about 238 bytes. First, we show how to construct a pseudo-preimage for the compression function of GOST based on its structural properties. Second, this pseudo- preimage attack on the compression function is extended to a (second) preimage attack on the GOST hash function. The extension is possible by combining a multicollision attack and a meet-in-the-middle attack on the checksum. Keywords: cryptanalysis, hash functions, preimage attack 1 Introduction A cryptographic hash function H maps a message M of arbitrary length to a fixed-length hash value h. A cryptographic hash function has to fulfill the following security requirements: – Collision resistance: it is practically infeasible to find two messages M and M ∗, with M ∗ 6= M, such that H(M) = H(M ∗).
  • Improved Cryptanalysis of the Reduced Grøstl Compression Function, ECHO Permutation and AES Block Cipher

    Improved Cryptanalysis of the Reduced Grøstl Compression Function, ECHO Permutation and AES Block Cipher

    Improved Cryptanalysis of the Reduced Grøstl Compression Function, ECHO Permutation and AES Block Cipher Florian Mendel1,ThomasPeyrin2,ChristianRechberger1, and Martin Schl¨affer1 1 IAIK, Graz University of Technology, Austria 2 Ingenico, France [email protected], [email protected] Abstract. In this paper, we propose two new ways to mount attacks on the SHA-3 candidates Grøstl,andECHO, and apply these attacks also to the AES. Our results improve upon and extend the rebound attack. Using the new techniques, we are able to extend the number of rounds in which available degrees of freedom can be used. As a result, we present the first attack on 7 rounds for the Grøstl-256 output transformation1 and improve the semi-free-start collision attack on 6 rounds. Further, we present an improved known-key distinguisher for 7 rounds of the AES block cipher and the internal permutation used in ECHO. Keywords: hash function, block cipher, cryptanalysis, semi-free-start collision, known-key distinguisher. 1 Introduction Recently, a new wave of hash function proposals appeared, following a call for submissions to the SHA-3 contest organized by NIST [26]. In order to analyze these proposals, the toolbox which is at the cryptanalysts’ disposal needs to be extended. Meet-in-the-middle and differential attacks are commonly used. A recent extension of differential cryptanalysis to hash functions is the rebound attack [22] originally applied to reduced (7.5 rounds) Whirlpool (standardized since 2000 by ISO/IEC 10118-3:2004) and a reduced version (6 rounds) of the SHA-3 candidate Grøstl-256 [14], which both have 10 rounds in total.
  • Message Authentication Codes

    Message Authentication Codes

    MessageMessage AuthenticationAuthentication CodesCodes Was this message altered? Did he really send this? Raj Jain Washington University in Saint Louis Saint Louis, MO 63130 [email protected] Audio/Video recordings of this lecture are available at: http://www.cse.wustl.edu/~jain/cse571-11/ Washington University in St. Louis CSE571S ©2011 Raj Jain 12-1 OverviewOverview 1. Message Authentication 2. MACS based on Hash Functions: HMAC 3. MACs based on Block Ciphers: DAA and CMAC 4. Authenticated Encryption: CCM and GCM 5. Pseudorandom Number Generation Using Hash Functions and MACs These slides are based partly on Lawrie Brown’s slides supplied with William Stallings’s book “Cryptography and Network Security: Principles and Practice,” 5th Ed, 2011. Washington University in St. Louis CSE571S ©2011 Raj Jain 12-2 MessageMessage SecuritySecurity RequirementsRequirements Disclosure Traffic analysis Masquerade Content modification Sequence modification Timing modification Source repudiation Destination repudiation Message Authentication = Integrity + Source Authentication Washington University in St. Louis CSE571S ©2011 Raj Jain 12-3 PublicPublic--KeyKey AuthenticationAuthentication andand SecrecySecrecy A B’s Public A’s PrivateMessage B A Key Key B Double public key encryption provides authentication and integrity. Double public key Very compute intensive Crypto checksum (MAC) is better. Based on a secret key and the message. Can also encrypt with the same or different key. Washington University in St. Louis CSE571S ©2011 Raj Jain 12-4 MACMAC PropertiesProperties A MAC is a cryptographic checksum MAC = CK(M) Condenses a variable-length message M using a secret key To a fixed-sized authenticator Is a many-to-one function Potentially many messages have same MAC But finding these needs to be very difficult Properties: 1.
  • Advanced Meet-In-The-Middle Preimage Attacks: First Results on Full Tiger, and Improved Results on MD4 and SHA-2

    Advanced Meet-In-The-Middle Preimage Attacks: First Results on Full Tiger, and Improved Results on MD4 and SHA-2

    Advanced Meet-in-the-Middle Preimage Attacks: First Results on Full Tiger, and Improved Results on MD4 and SHA-2 Jian Guo1, San Ling1, Christian Rechberger2, and Huaxiong Wang1 1 Division of Mathematical Sciences, School of Physical and Mathematical Sciences, Nanyang Technological University, Singapore 2 Dept. of Electrical Engineering ESAT/COSIC, K.U.Leuven, and Interdisciplinary Institute for BroadBand Technology (IBBT), Kasteelpark Arenberg 10, B–3001 Heverlee, Belgium. [email protected] Abstract. We revisit narrow-pipe designs that are in practical use, and their security against preimage attacks. Our results are the best known preimage attacks on Tiger, MD4, and reduced SHA-2, with the result on Tiger being the first cryptanalytic shortcut attack on the full hash function. Our attacks runs in time 2188.8 for finding preimages, and 2188.2 for second-preimages. Both have memory requirement of order 28, which is much less than in any other recent preimage attacks on reduced Tiger. Using pre-computation techniques, the time complexity for finding a new preimage or second-preimage for MD4 can now be as low as 278.4 and 269.4 MD4 computations, respectively. The second-preimage attack works for all messages longer than 2 blocks. To obtain these results, we extend the meet-in-the-middle framework recently developed by Aoki and Sasaki in a series of papers. In addition to various algorithm-specific techniques, we use a number of conceptually new ideas that are applicable to a larger class of constructions. Among them are (1) incorporating multi-target scenarios into the MITM framework, leading to faster preimages from pseudo-preimages, (2) a simple precomputation technique that allows for finding new preimages at the cost of a single pseudo-preimage, and (3) probabilistic initial structures, to reduce the attack time complexity.
  • Deploying a New Hash Algorithm

    Deploying a New Hash Algorithm

    Deploying a New Hash Algorithm Steven M. Bellovin Eric K. Rescorla [email protected] [email protected] Columbia University Network Resonance Abstract It is clear that a transition to newer hash functions is necessary. The need is not immediate; however, it cannot The strength of hash functions such as MD5 and SHA-1 be postponed indefinitely. Our analysis indicates that sev- has been called into question as a result of recent discov- eral major Internet protocols were not designed properly eries. Regardless of whether or not it is necessary to move for such a transition. This paper presents our results. away from those now, it is clear that it will be necessary Although we don’t discuss the issue in detail, most of to do so in the not-too-distant future. This poses a number our work applies to deploying new signature algorithms of challenges, especially for certificate-based protocols. as well. If the signature algorithm is linked to a particular We analyze a numberof protocols, includingS/MIME and hash function, as DSA is tied to SHA-1, the two would TLS. All require protocol or implementation changes. We change together; beyond that, since signature algorithms explain the necessary changes, show how the conversion are almost always applied to the output of hash functions, can be done, and list what measures should be taken im- if there is no easy way to substitute a new hash algorithm mediately. there is almost certainly no way to substitute a new signa- ture algorithm, either. 1 Introduction 2 Background Nearly all major cryptographic protocols depend on the security of hash functions.