DOCSLIB.ORG

Analyse, Modellierung Und Hashcat-Basierte Implementierung Von Angriffen Auf Passwortgeschutzte¨ Systeme Unter Einbeziehung Des Faktors Mensch

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Analyse, Modellierung Und Hashcat-Basierte Implementierung Von Angriffen Auf Passwortgeschutzte¨ Systeme Unter Einbeziehung Des Faktors Mensch Analyse, Modellierung und hashcat-basierte Implementierung von Angriffen auf passwortgeschutzte¨ Systeme unter Einbeziehung des Faktors Mensch Bachelorarbeit im Studiengang Medieninformatik zur Erlangung des akademischen Grades Bachelor of Science Fachbereich Medien Hochschule Dusseldorf¨ Lukas Friedrichs Matrikel-Nr.: 526560 Datum: 10. September 2018 Erst- und Zweitprufer¨ Prof. Dr.-Ing. Holger Schmidt Prof. Dr.-Ing. M.Sc. Markus Dahm Eidesstattliche Erkl¨arung Ich erkl¨are hiermit an Eides statt, dass ich die vorliegende Bachelorarbeit selbst¨andig und ohne unzul¨assige fremde Hilfe angefertigt habe. Die verwendeten Quellen sind vollst¨andig zitiert. Diese Arbeit wurde weder in gleicher noch ¨ahnlicher Form einem anderen Prufungsamt¨ vorgelegt oder ver¨offentlicht. Ich erkl¨are mich ausdrucklich¨ da- mit einverstanden, dass diese Arbeit mittels eines Dienstes zur Erkennung von Pla- giaten uberpr¨ uft¨ wird. Ort, Datum Lukas Friedrichs Kontaktinformationen Lukas Friedrichs Rottberger Straße 201 42551 Velbert | [email protected] i Zusammenfassung Analyse, Modellierung und hashcat-basierte Implementierung von Angriffen auf passwortgeschutzte¨ Systeme unter Einbeziehung des Faktors Mensch Lukas Friedrichs In der vorliegenden Bachelorarbeit geht es um das menschliche Verhalten bei der Pass- worterstellung. Hierbei wird die M¨oglichkeit untersucht dieses menschliche Verhalten uber¨ die Software hashcat nachzubilden, um so Passw¨orter effizienter anzugreifen. Durch die Konzeption und den Test von Passwortangriffsszenarien, deren Fokus auf dem Faktor Mensch liegt, wird versucht aufzuzeigen, dass selbst sichere Passwortver- fahren, durch das individuelle Verhalten von Menschen an Sicherheit verlieren k¨onnen. Zudem werden die Tests der Szenarien Schw¨achen der Software hashcat aufzeigen, die im sp¨ateren Verlauf der Arbeit als Grundlage fur¨ die Entwicklung einer selbst- programmierten Erweiterung von hashcat dienen. ii Abstract Analysis, modeling and hashcat-based implementation of attacks on password-protected systems, in consideration of the human factor Lukas Friedrichs The present Bachelor-Thesis deals with human behavior concerning the creation of passwords. Hereby the possibility is examined to reproduce this human behavior through the software hashcat, so that passwords can be attacked more efficiently. Through the conception and testing of password-attack scenarios, when the focus is situated on the human factor, it will be examined to demonstrate that even secure password processes can lose their security through the individual behavior of humans. The tests of the scenarios will also show weaknesses of the hashcat software, which will later serve as the basis for the development of a self-programmed extension of hashcat. iii Inhaltsverzeichnis 1 Einleitung 1 1.1 Kontext und Motivation . .1 1.1.1 Passwortbasierte Authentifikation . .1 1.1.2 Menschen und Passw¨orter . .2 1.2 Wissenschaftlicher Beitrag . .3 1.3 Weiteres Vorgehen . .3 2 Aktueller Forschungsstand und Grundlagen 5 2.1 Was ist ein Passwort? . .5 2.2 Verfahren zum Bilden von Passw¨ortern . .6 2.2.1 Akronym-Methode . .6 2.2.2 Doppelwort-Methode . .6 2.2.3 Collage-Methode . .7 2.2.4 Zufallsmethode . .7 2.2.5 Diceware-Methode . .8 2.3 Faktoren der Passwortsicherheit . .8 2.3.1 Was ist ein gutes Passwort? . .9 2.3.2 Aufbau und L¨ange eines Passworts . .9 2.3.3 Entropie . 11 2.3.4 Mehrfaktor-Authentifikation . 12 2.3.5 Faktor Mensch . 12 2.4 Hashingverfahren und ihre Unterschiede . 14 2.4.1 Kryptographische Hashfunktionen . 14 2.4.2 Passwort-Hashing-Verfahren . 16 2.4.3 Hashwert-Kollision . 19 2.4.4 Salt . 19 2.4.5 Pepper . 19 2.5 Passwortangriffsverfahren . 20 2.5.1 Brute-Force-Methode . 20 2.5.2 W¨orterbuchangriff . 21 2.5.3 Online-/Offline-Angriffe . 21 2.5.4 Lookup-Tables . 22 2.5.5 Reverse-Lookup-Tables . 22 2.5.6 Rainbow-Tables . 23 2.5.7 GPU-basierte Angriffe . 23 2.5.8 Angriffe anhand von spezialisierter Hardware . 24 2.6 Software hashcat . 24 2.6.1 Einfuhrung¨ in die Software . 24 iv 2.6.2 Unterstutzte¨ Hashingverfahren . 25 2.6.3 Dictionary-Attack . 26 2.6.4 Combinator-Attack . 27 2.6.5 Brute-Force-Methode / Mask-Attack . 29 2.6.6 Hybrid-Attack . 32 2.6.7 Rule-based-Attack . 33 3 Angriffsszenarien und Optimierungen 36 3.1 Konzeption der Angriffsszenarien . 36 3.1.1 Szenario 1 - Name + Zahl . 38 3.1.2 Szenario 2 - bekannte, schwache Passw¨orter . 41 3.1.3 Szenario 3 - Passwortvorgaben des BSI . 43 3.1.4 Szenario 4 - Diceware . 46 3.2 Test der Szenarien, Analyse der Ergebnisse . 49 3.2.1 Szenario 1 - Name + Zahl . 49 3.2.2 Szenario 2 - bekannte Passw¨orter . 51 3.2.3 Szenario 3 - Passwortvorgaben des BSI . 53 3.2.4 Szenario 4 - Diceware . 55 3.3 Empfehlungen auf Basis der Testergebnisse . 57 3.3.1 Hashcat-Entscheidungsdiagramm . 58 3.4 Schwachstellen der Software . 60 3.4.1 Konzipierung einer L¨osung . 60 3.4.2 L¨osungsansatz Szenario 1 . 60 3.4.3 L¨osungsansatz Szenario 4 . 61 3.4.4 Umsetzung der L¨osungsans¨atze . 62 4 Implementierung 63 4.1 Entwicklungsprozess . 63 4.1.1 Anforderungen an die Software . 64 4.1.2 Entwurf . 64 4.1.3 Implementierung der Funktionen und Tests . 66 4.2 Systemanforderungen des Tools . 66 4.3 Wahl der Programmiersprache . 67 4.4 Verwendete Module . 67 4.4.1 Sys-Modul . 67 4.4.2 Os-Modul . 68 4.4.3 Docopt-Modul . 68 4.4.4 Subprocess-Modul . 70 4.4.5 Itertools-Modul . 70 4.4.6 Threading-Modul . 70 4.5 Implementierte Module und Funktionen . 70 4.5.1 Modul 1: HashcatXT.py . 71 4.5.2 Modul 2: tripple attack.py . 74 4.5.3 Modul 3: multi combinator.py . 76 4.6 Die Benutzeroberfl¨ache . 77 4.7 Funktionstests . 80 4.7.1 Funktionstest 1 . 80 4.7.2 Funktionstest 2 . 81 v 4.8 Anwendungsf¨alle . 82 5 Schlussfolgerung 83 5.1 Fazit . 83 5.2 Ausblick . 84 5.3 Pers¨onliches Schlusswort und Danksagung . 85 A Anwendungsf¨alle 86 A.1 Anwendungsfall 1 . 86 A.2 Anwendungsfall 2 . 87 B Hashcat 89 B.1 Unterstutzte¨ Algorithmen . 89 B.2 Funktionen fur¨ regelbasierte Angriffe . 95 C HashcatXT Programmcode 97 C.1 Modul hashcatXT.py . 97 C.2 Modul tripple attack.py . 106 C.3 Modul multi combinator.py . 107 vi Abbildungsverzeichnis 1.1 UML-Sequenzdiagramm zur passwortbasierten Authentifizierung . .2 2.1 Test eines vierstelligen Passworts, bei dem Zeichen aus allen vier m¨oglichen Zeichengruppen verwendet werden, anhand des Passwort Strength " Meters\des Unternehmens Kaspersky. (Quelle: https://password.kaspersky. com) . 10 2.2 xkcd-Comic, Gegenuberstellung¨ von Passphrases und Passw¨ortern (Quel- le: https://xkcd.com/936/) . 11 2.3 Aufbau einer Iteration von MD5 (Spitz, Pramateftakis und Swoboda, 2011, S. 103) . 15 2.4 Aufbau einer Iteration von SHA-2 (Quelle: https://de.wikipedia.org/wiki/SHA-2, abgerufen am 13.05.2018) 16 2.5 Schema eines Passwort-Hashing-Verfahrens, Hatzivasilis, Papaefstathiou und Manifavas, 2015, S. 4 . 17 2.6 Brute-Force-Rechenzeit eines MD5-Hashwerts (Quelle: https://de.wikipedia.org/wiki/Passwort) . 21 3.1 Hashcat-Entscheidungsdiagramm . 59 4.1 Wasserfallmodell zur Entwicklung von hashcatXT ........... 64 4.2 Ablaufdiagramm Tripple Attack . 65 4.3 Ablaufdiagramm Multi-Combinator-Attack . 66 4.4 Komponentendiagramm, Module und Funktionen von hashcatXT . 71 4.5 hashcatXT docopt Docstring . 72 4.6 Start von hashcatXT ohne Parameter . 77 4.7 Aufruf der Hilfeseite von hashcatXT ................... 78 4.8 Falsche Syntax beim Start von hashcatXT ............... 78 4.9 Starten eines Tripple-Angriffs . 79 4.10 Starten eines Multi-Combinator-Angriffs . 79 4.11 Funktionstest der Funktion tripple attack . 81 4.12 Starten eines Multi-Combinator-Angriffs . 82 B.1 Rule-Based-Attack Tabelle mit Funktionen (Quelle: https://hashcat.net/wiki/doku.php?id=rule based attack) . 95 B.2 Rule-Based-Attack Tabelle zum Abweisen von Passw¨ortern (Quelle: https://hashcat.net/wiki/doku.php?id=rule based attack) . 96 B.3 Rule-Based-Attack Tabelle mit Funktionen die nur mit hashcat kom- patibel sind (Quelle: https://hashcat.net/wiki/doku.php?id=rule based attack) . 96 vii Listings 2.1 Beispiel des Inkrement-Parameters . 31 2.2 Beispiel einer Regeldatei . 34 2.3 W¨orterbuch mit nur einem Passwort . 34 2.4 Rule-based-Attack - Passwortkandidaten . 34 3.1 Szenario 1 - Test 1 . 50 3.2 Szenario 1 - Test 2 . 50 3.3 Szenario 2 - Test 1 . 52 3.4 Szenario 2 - Test 2 . 52 3.5 Szenario 3 - Test 1 . 53 3.6 Szenario.
Load more

Recommended publications
  • Argon and Argon2
    Argon and Argon2 Designers: Alex Biryukov, Daniel Dinu, and Dmitry Khovratovich University of Luxembourg, Luxembourg [email protected], [email protected], [email protected] https://www.cryptolux.org/index.php/Password https://github.com/khovratovich/Argon https://github.com/khovratovich/Argon2 Version 1.1 of Argon Version 1.0 of Argon2 31th January, 2015 Contents 1 Introduction 3 2 Argon 5 2.1 Specification . 5 2.1.1 Input . 5 2.1.2 SubGroups . 6 2.1.3 ShuffleSlices . 7 2.2 Recommended parameters . 8 2.3 Security claims . 8 2.4 Features . 9 2.4.1 Main features . 9 2.4.2 Server relief . 10 2.4.3 Client-independent update . 10 2.4.4 Possible future extensions . 10 2.5 Security analysis . 10 2.5.1 Avalanche properties . 10 2.5.2 Invariants . 11 2.5.3 Collision and preimage attacks . 11 2.5.4 Tradeoff attacks . 11 2.6 Design rationale . 14 2.6.1 SubGroups . 14 2.6.2 ShuffleSlices . 16 2.6.3 Permutation ...................................... 16 2.6.4 No weakness,F no patents . 16 2.7 Tweaks . 17 2.8 Efficiency analysis . 17 2.8.1 Modern x86/x64 architecture . 17 2.8.2 Older CPU . 17 2.8.3 Other architectures . 17 3 Argon2 19 3.1 Specification . 19 3.1.1 Inputs . 19 3.1.2 Operation . 20 3.1.3 Indexing . 20 3.1.4 Compression function G ................................. 21 3.2 Features . 22 3.2.1 Available features . 22 3.2.2 Server relief . 23 3.2.3 Client-independent update .
    [Show full text]
  • CASH: a Cost Asymmetric Secure Hash Algorithm for Optimal Password Protection
    CASH: A Cost Asymmetric Secure Hash Algorithm for Optimal Password Protection Jeremiah Blocki Anupam Datta Microsoft Research Carnegie Mellon University August 23, 2018 Abstract An adversary who has obtained the cryptographic hash of a user's password can mount an offline attack to crack the password by comparing this hash value with the cryptographic hashes of likely password guesses. This offline attacker is limited only by the resources he is willing to invest to crack the password. Key-stretching techniques like hash iteration and memory hard functions have been proposed to mitigate the threat of offline attacks by making each password guess more expensive for the adversary to verify. However, these techniques also increase costs for a legitimate authentication server. We introduce a novel Stackelberg game model which captures the essential elements of this interaction between a defender and an offline attacker. In the game the defender first commits to a key-stretching mechanism, and the offline attacker responds in a manner that optimizes his utility (expected reward minus expected guessing costs). We then introduce Cost Asymmetric Secure Hash (CASH), a randomized key-stretching mechanism that minimizes the fraction of passwords that would be cracked by a rational offline attacker without increasing amortized authentication costs for the legitimate authentication server. CASH is motivated by the observation that the legitimate authentication server will typically run the authentication procedure to verify a correct password, while an offline adversary will typically use incorrect password guesses. By using randomization we can ensure that the amortized cost of running CASH to verify a correct password guess is significantly smaller than the cost of rejecting an incorrect password.
    [Show full text]
  • PHC: Status Quo
    PHC: status quo JP Aumasson @veorq / http://aumasson.jp academic background principal cryptographer at Kudelski Security, .ch applied crypto research and outreach BLAKE, BLAKE2, SipHash, NORX Crypto Coding Standard Password Hashing Competition Open Crypto Audit Project board member do you use passwords? this talk might interest you! Oct 2013 "hash" = 3DES-ECB( static key, password ) users' hint made the guess game easy... (credit Jeremi Gosney / Stricture Group) May 2014; "encrypted passwords" (?) last week that's only the reported/published cases Lesson if Adobe, eBay, and Avast fail to protect their users' passwords, what about others? users using "weak passwords"? ITsec people using "weak defenses"? developers using "weak hashes"? cryptographers, who never bothered? agenda 1. how (not) to protect passwords 2. the Password Hashing Competition (PHC) 3. the 24-2 PHC candidates 4. next steps, and how to contribute WARNING this is NOT about bikeshed topics as: password policies password managers password-strength meters will-technology-X-replace-passwords? 1. how (not) to protect passwords solution of the 60's store "password" or the modern alternative: obviously a bad idea (assuming the server and its DB are compromised) solution of the early 70's store hash("password") "one-way": can't be efficiently inverted vulnerable to: ● efficient dictionary attacks and bruteforce ● time-memory tradeoffs (rainbow tables, etc.) solution of the late 70's store hash("password", salt) "one-way": can't be efficiently inverted immune to time-memory tradeoffs vulnerable to: ● dictionary attacks and bruteforce (but has to be repeated for different hashes) solution of the 2000's store hash("password", salt, cost) "one-way": can't be efficiently inverted immune to time-memory tradeoffs inefficient dictionary attacks and bruteforce main ideas: ● be "slow" ● especially on attackers' hardware (GPU, FPGA) => exploit fast CPU memory access/writes PBKDF2 (Kaliski, 2000) NIST and PKCS standard in Truecrypt, iOS, etc.
    [Show full text]
  • Rifflescrambler – a Memory-Hard Password Storing Function ⋆
    RiffleScrambler – a memory-hard password storing function ? Karol Gotfryd1, Paweł Lorek2, and Filip Zagórski1;3 1 Wrocław University of Science and Technology Faculty of Fundamental Problems of Technology Department of Computer Science 2 Wrocław University Faculty of Mathematics and Computer Science Mathematical Institute 3 Oktawave Abstract. We introduce RiffleScrambler: a new family of directed acyclic graphs and a corresponding data-independent memory hard function with password independent memory access. We prove its memory hard- ness in the random oracle model. RiffleScrambler is similar to Catena – updates of hashes are determined by a graph (bit-reversal or double-butterfly graph in Catena). The ad- vantage of the RiffleScrambler over Catena is that the underlying graphs are not predefined but are generated per salt, as in Balloon Hashing. Such an approach leads to higher immunity against practical parallel at- tacks. RiffleScrambler offers better efficiency than Balloon Hashing since the in-degree of the underlying graph is equal to 3 (and is much smaller than in Ballon Hashing). At the same time, because the underlying graph is an instance of a Superconcentrator, our construction achieves the same time-memory trade-offs. Keywords: Memory hardness, password storing, Markov chains, mixing time. 1 Introduction In early days of computers’ era passwords were stored in plaintext in the form of pairs (user; password). Back in 1960s it was observed, that it is not secure. It took around a decade to incorporate a more secure way of storing users’ passwords – via a DES-based function crypt, as (user; fk(password)) for a se- cret key k or as (user; f(password)) for a one-way function.
    [Show full text]
  • SPHINCS: Practical Stateless Hash-Based Signatures
    SPHINCS: practical stateless hash-based signatures Daniel J. Bernstein1;3, Daira Hopwood2, Andreas Hülsing3, Tanja Lange3, Ruben Niederhagen3, Louiza Papachristodoulou4, Peter Schwabe4, and Zooko Wilcox O'Hearn2 1 Department of Computer Science University of Illinois at Chicago Chicago, IL 606077045, USA [email protected] 2 Least Authority 3450 Emerson Ave. Boulder, CO 803056452 USA [email protected],[email protected] 3 Department of Mathematics and Computer Science Technische Universiteit Eindhoven P.O. Box 513, 5600 MB Eindhoven, The Netherlands [email protected], [email protected], [email protected] 4 Radboud University Nijmegen Digital Security Group P.O. Box 9010, 6500 GL Nijmegen, The Netherlands [email protected], [email protected] Abstract. This paper introduces a high-security post-quantum stateless hash-based sig- nature scheme that signs hundreds of messages per second on a modern 4-core 3.5GHz Intel CPU. Signatures are 41 KB, public keys are 1 KB, and private keys are 1 KB. The signature scheme is designed to provide long-term 2128 security even against attackers equipped with quantum computers. Unlike most hash-based designs, this signature scheme is stateless, allowing it to be a drop-in replacement for current signature schemes. Keywords: post-quantum cryptography, one-time signatures, few-time signatures, hyper- trees, vectorized implementation 1 Introduction It is not at all clear how to securely sign operating-system updates, web-site certicates, etc. once an attacker has constructed a large quantum computer: RSA and ECC are perceived today as being small and fast, but they are broken in polynomial time by Shor's algorithm.
    [Show full text]
  • Hash Functions
    11 Hash Functions Suppose you share a huge le with a friend, but you are not sure whether you both have the same version of the le. You could send your version of the le to your friend and they could compare to their version. Is there any way to check that involves less communication than this? Let’s call your version of the le x (a string) and your friend’s version y. The goal is to determine whether x = y. A natural approach is to agree on some deterministic function H, compute H¹xº, and send it to your friend. Your friend can compute H¹yº and, since H is deterministic, compare the result to your H¹xº. In order for this method to be fool-proof, we need H to have the property that dierent inputs always map to dierent outputs — in other words, H must be injective (1-to-1). Unfortunately, if H is injective and H : f0; 1gin ! f0; 1gout is injective, then out > in. This means that sending H¹xº is no better/shorter than sending x itself! Let us call a pair ¹x;yº a collision in H if x , y and H¹xº = H¹yº. An injective function has no collisions. One common theme in cryptography is that you don’t always need something to be impossible; it’s often enough for that thing to be just highly unlikely. Instead of saying that H should have no collisions, what if we just say that collisions should be hard (for polynomial-time algorithms) to nd? An H with this property will probably be good enough for anything we care about.
    [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]
  • Forgery and Key Recovery Attacks for Calico
    Forgery and Key Recovery Attacks for Calico Christoph Dobraunig, Maria Eichlseder, Florian Mendel, Martin Schl¨affer Institute for Applied Information Processing and Communications Graz University of Technology Inffeldgasse 16a, A-8010 Graz, Austria April 1, 2014 1 Calico v8 Calico [3] is an authenticated encryption design submitted to the CAESAR competition by Christopher Taylor. In Calico v8 in reference mode, ChaCha-14 and SipHash-2-4 work together in an Encrypt-then-MAC scheme. For this purpose, the key is split into a Cipher Key KC and a MAC Key KM . The plaintext is encrypted with ChaCha under the Cipher Key to a ciphertext with the same length as the plaintext. Then, the tag is calculated as the SipHash MAC of the concatenated ciphertext and associated data. The key used for SipHash is generated by xoring the nonce to the (lower, least significant part of the) MAC Key: (C; T ) = EncCalico(KC k KM ; N; A; P ); where k is concatenation, and with ⊕ denoting xor, the ciphertext and tag are calculated vi C = EncChaCha-14(KC ; N; P ) T = MACSipHash-2-4(KM ⊕ N; C k A): Here, A; P; C denote associated data, plaintext and ciphertext, respectively, all of arbitrary length. T is the 64-bit tag, N the 64-bit nonce, and the 384-bit key K is split into a 256-bit encryption and 128-bit authentication part, K = KC k KM . 2 Missing Domain Separation As shown above, the tag is calculated over the concatenation C k A of ciphertext and asso- ciated data. Due to the missing domain separation between ciphertext and associated data in the generation of the tag, the following attack is feasible.
    [Show full text]
  • Differential Cryptanalysis of Siphash
    Differential Cryptanalysis of SipHash Christoph Dobraunig, Florian Mendel, and Martin Schl¨affer IAIK, Graz University of Technology, Austria [email protected] Abstract. SipHash is an ARX based message authentication code de- veloped by Aumasson and Bernstein. SipHash was designed to be fast on short messages. Already, a lot of implementations and applications for SipHash exist, whereas the cryptanalysis of SipHash lacks behind. In this paper, we provide the first published third-party cryptanalysis of SipHash regarding differential cryptanalysis. We use existing auto- matic tools to find differential characteristics for SipHash. To improve the quality of the results, we propose several extensions for these tools to find differential characteristics. For instance, to get a good probabil- ity estimation for differential characteristics in SipHash, we generalize the concepts presented by Mouha et al. and Velichkov et al. to calcu- late the probability of ARX functions. Our results are a characteristic for SipHash-2-4 with a probability of 2−236:3 and a distinguisher for the Finalization of SipHash-2-4 with practical complexity. Even though our results do not pose any threat to the security of SipHash-2-4, they sig- nificantly improve the results of the designers and give new insights in the security of SipHash-2-4. Keywords: message authentication code, MAC, cryptanalysis, differ- ential cryptanalysis, SipHash, S-functions, cyclic S-functions 1 Introduction A message authentication code (MAC) is a cryptographic primitive, which is used to ensure the integrity and the origin of messages. Normally, a MAC takes a secret key K and a message M as input and produces a fixed size tag T .A receiver of such a message-tag-pair verifies the authenticity of the message by simply recalculating the tag T for the message and compare it with the received one.
    [Show full text]
  • Lightweight Macs from Universal Hash Functions
    Lightweight MACs from Universal Hash Functions S´ebastienDuval Ga¨etanLeurent November 13, 2019 REASSURE Introduction Design of MAC611 Benchmarks Conclusion 2 / 21 Authentication I Need for lightweight crypto I Relatively few authentication solutions compared to encryption I Our goal: design a fast MAC, MAC611, for 32-bit micro-controllers Introduction Design of MAC611 Benchmarks Conclusion 3 / 21 MACs Message Authentication Code I Definition: Tag t = Hk (m) I Security: bound on the proba. that an adversary forges a valid tag MAC constructions: I Block-Cipher-based (CBC-MAC, PMAC) I Hash-Function-based (HMAC) I from scratch (Pelican MAC, Chaskey) I from Universal Hash Functions (GMAC, Poly1305-AES) Lightweight MACs Chaskey, SipHash, TuLP, LightMAC, QUARK, SPONGENT Aim for 64-bit security Introduction Design of MAC611 Benchmarks Conclusion 3 / 21 MACs Message Authentication Code I Definition: Tag t = Hk (m) I Security: bound on the proba. that an adversary forges a valid tag MAC constructions: I Block-Cipher-based (CBC-MAC, PMAC) I Hash-Function-based (HMAC) I from scratch (Pelican MAC, Chaskey) I from Universal Hash Functions (GMAC, Poly1305-AES) Lightweight MACs Chaskey, SipHash, TuLP, LightMAC, QUARK, SPONGENT Aim for 64-bit security Introduction Design of MAC611 Benchmarks Conclusion 4 / 21 [Almost] Universal Hash Functions A family H : A B is: ! "-almost universal ("-AU) m = m0 A; h H : h(m) = h(m0) " H 8 6 2 jf 2 gj ≤ j j "-almost XOR universal ("-AXU) m = m0 A; d B; h H : h(m) h(m0) = d " H 8 6 2 8 2 jf 2 ⊕ gj ≤ j j H "-AXU H "-AU,
    [Show full text]
  • Hash Pile Ups: Using Collisions to Identify Unknown Hash Functions
    Hash Pile Ups: Using Collisions to Identify Unknown Hash Functions R. Joshua Tobin David Malone School of Mathematics Hamilton Institute Trinity College Dublin, National University of Ireland, Ireland. Ireland. Email: [email protected] Email: [email protected] Abstract—Hash functions are often used to consistently assign 16 Xor Jenkins objects to particular resources, for example to load balancing Pearson in networks. These functions can be randomly selected from a 14 Universal MD5 family, to prevent attackers generating many colliding objects, SHA which usually results in poor performance. We describe a number 12 SHA256 of attacks allowing us to identify which hash function from a family is being used by observing a relatively small number of 10 collisions. This knowledge can then be used to generate a large number of colliding inputs. In particular we detail attacks against (us) 8 CPU Time small families of hashes, Pearson-like hash functions and linear 6 hashes, such as the Toeplitz hash used in Microsoft’s Receive Side Scaling. 4 I. INTRODUCTION 2 Hash functions are often used to spread load across several 0 resources. For example, in the common case of a hash table, a Geode Core 2 Duo Athlon 64 Xeon Atom 500MHz 2.66GHz 2.6GHz 3GHz 1.6GHz hash function is used to give a consistent assignment of objects to linked lists. In modern networking, similar techniques are used by high-end network cards to assign packets to CPUs [1], Fig. 1. The average cost of hashing an IPv6 flow record with different algorithms on a selection of CPUs.
    [Show full text]
  • Sketch of Lecture 34 Mon, 4/16/2018
    Sketch of Lecture 34 Mon, 4/16/2018 Passwords Let's say you design a system that users access using personal passwords. Somehow, you need to store the password information. The worst thing you can do is to actually store the passwords m. This is an absolutely atrocious choice, even if you take severe measures to protect (e.g. encrypt) the collection of passwords. Comment. Sadly, there is still systems out there doing that. An indication of this happening is systems that require you to update passwords and then complain that your new password is too close to the original one. Any reasonably designed system should never learn about your actual password in the rst place! Better, but still terrible, is to instead store hashes H(m) of the passwords m. Good. An attacker getting hold of the password le, only learns about the hash of a user's password. Assuming the hash function is one-way, it is infeasible for the attacker to determine the corresponding password (if the password was random!!). Still bad. However, passwords are (usually) not random. Hence, an attacker can go through a list of common passwords (dictionary attack), compute the hashes and compare with the hashes of users (similarly, a brute-force attack can simply go through all possible passwords). Even worse, it is immediately obvious if two users are using the same password (or, if the same user is using the same password for dierent services using the same hash function). Comment. So, storing password hashes is not OK unless all passwords are completely random.
    [Show full text]