DOCSLIB.ORG

8: Password-Hashing Basics

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

8: Password-Hashing Basics I Passwords, Passphrases, “Personal Identification Numbers” (PINs) are needed all the time user name: Max passwort: ******** I Can be part of a “two-factor-authentication” (e.g., chipcard + PIN) I Adversaries trying to “guess” them: I How probable is a pwd? I How to attack unknwon pwd by making X attempts to “guess” them I Which passwords are the X most probable ones? I How to choose pwd to thwart such attacks? I . while still being able to remember pwd? Our goal: Make the usage of passwords as secure as possible. –226– Stefan Lucks Hash Fun. & PW (S 2014) 8: Passw.-Hash Preliminaries . speaking words of wisdom, let it be, let it be, . (The Beatles) I QUESTION: Which of the following passwords is OK? “53cur3 pa55w0rd”, “ci90n38!P0??3ah9vhv” or “123456”? user name: Max passwort: ******** I ANSWER: None! (Not after being shown on my slides . ) I Passwords must be unpredictable ... I BUT this is actually a property of password-generation and password-handling (random choices, not published on slides, . ) I information-theory: a “password-source” must have high entropy! k−1 I very informally: k-bit of entropy ≥ 2 “guesses” for the attacker –227– Stefan Lucks Hash Fun. & PW (S 2014) 8: Passw.-Hash Wisdom # 1: Choose “high-entropy” passwords! . this is harder than it looks –228– Stefan Lucks Hash Fun. & PW (S 2014) 8: Passw.-Hash Wisdom # 2: Do not allow Offline Attacks! . whenever you can avoid them user name: Max passwort: ******** Online: Offline: I access to server I function F I adversary sends pwd-”guess” I adversary can compute F I server accepts or rejects without the server’s aid pwd-”guess” I F(pwd) = 1 , pwd accepted X: as large as the server allows X: as large as the adversary can and can handle afford –229– Stefan Lucks Hash Fun. & PW (S 2014) 8: Passw.-Hash Wisdom #3: Passwords in the Clear are bad! . worse than leaving the key to your flat under the door-mat name pwd Anakin skywalker Dagobert moneymoneymoney Donald enwo34qindk!d Luke sykwalker Tick mysecretpassword Trick mysecretpassword Track mysecretpassword –230– Stefan Lucks Hash Fun. & PW (S 2014) 8: Passw.-Hash Wisdom # 4: Hashing Passwords helps . but is not good enough name H(pwd) Anakin viqwbnqwtomwm Dagobert wer4mnrt4rnrm Donald r034jionksioe Luke viqwbnqwtomwm Tick sdjklasdle9nr Trick sdjklasdle9nr Track sdjklasdle9nr best attack: I assume “dictionary” with N “common” passwords I compute another dictionary with N hashed passwords I attacking each account in time O(1), if password is “common” –231– Stefan Lucks Hash Fun. & PW (S 2014) 8: Passw.-Hash Wisdom # 5: Salt and Hash Passwords name salt H(salt, pwd) Anakin 34892 4unuiio8nuue7 Dagobert 29495 ksni9m8k89kiu Donald 09858 cdk5jkambydyu Luke 45888 xumun6muzyqjo Tick 19495 cnjk9mk3msdfk Track 27849 dekcexcidklc7 Trick 90479 yei7kmdkx2dcx best attack: I assume “dictionary” with N “common” passwords I attacking each account in time O(N), if password is “common” (if the salt never repeats) –232– Stefan Lucks Hash Fun. & PW (S 2014) 8: Passw.-Hash 8.1: Key Stretching Wisdom # 6: Perform “Key Stretching” I stretching by k bit k I attacks slow down 2 times I “virtual” entropy goes from β to β + k k I unfortunately, the defenders’ operations may also slow down by 2 times I so the idea is to I choose k as large as possible I without annoying the defender –233– Stefan Lucks Hash Fun. & PW (S 2014) 8: Passw.-Hash 8.1: Key Stretching Generate Password Hashes with Stretching iteration: stretch by log (N) bit 2 pepper: stretch by p bit input: pwd, salt, N input: pwd, salt, p X H(salt; pwd) choose random R < 2p for I 1 to N do X H(salt; R; pwd) X H(salt; X) return X end for return X –234– Stefan Lucks Hash Fun. & PW (S 2014) 8: Passw.-Hash 8.1: Key Stretching Verify Password Hashes verify iteration verify pepper input: pwd, salt, N; X 0 input: pwd, salt, p, X 0 X H(salt; pwd) choose random R0 < 2p for I 1 to N do for I 0 to 2p − 1 do X H(salt; X) R00 (R0 + I) mod 2p end for X 0 H(salt; R00; X) accept if X = X 0 else reject accept if X = X 0 end for reject Advantages and disadvantages: +iteration generation and verification are the same +pepper fast generation +pepper parallelizable (why is this an advantage for the defender, and not a disadvantage?) -pepper R must be random – and even secret (why?) –235– Stefan Lucks Hash Fun. & PW (S 2014) 8: Passw.-Hash 8.1: Key Stretching Iteration – Without Knowing the Count just let the user decide for herself unknown iteration verify unknown iteration input: pwd, salt, N input: pwd, salt, N, X X H(salt; pwd) X 0 H(salt; pwd) while true do while X 6= X 0 do X H(salt; X) X 0 H(salt; X) end while end while when exception: {user: ctrl-c} accept return X when exception: {user: ctrl-c} reject –236– Stefan Lucks Hash Fun. & PW (S 2014) 8: Passw.-Hash 8.1: Key Stretching Usage Scenarios for Password Scramblers I user authentication I key derivation I proof of work I ... These uses imply different attack models / security requirements! –237– Stefan Lucks Hash Fun. & PW (S 2014) 8: Passw.-Hash 8.1: Key Stretching History until 2010 1960s: Wilkes: plain passwords are bad ! store hash and compare 1978: unix crypt I 25 iterations of DES-like operation I 12 bit salt to hinder dictionary attacks 1980s: shadow passwords I store (user; salt; dummy) in File A I store H(pwd; salt) in File B 1995: Abadi, Lomas, Needham: pepper 1997: Kelsey, Schneier, Hall, Wagner: analyzed iteration 2007: Boyen: unknown iteration count 2010: Turan, Barker, Burr, Chen: First standard for KDFs (PBKDF1/2 – Password-Based Key Derivation Function) –238– Stefan Lucks Hash Fun. & PW (S 2014) 8: Passw.-Hash 8.1: Key Stretching Practical Password Scramblers and KDFs until 2010 1978: crypt: in UNIX-based systems based on DES (25 iterations), 12-bit salt 1995: md5crypt by Poul-Henning Kamp 64-bit salt, 1000 iterations of MD5 1995: bcrypt by Provos and Mazières based on Blowfish (Schneier, 1993) needs a significant (but constant) amount of memory: S-boxes (4 × 1024 Bytes) + subkey (72 Bytes)) 2010: PBKDF2 by NIST first standard for KDFs, can use hash function or block cipher –239– Stefan Lucks Hash Fun. & PW (S 2014) 8: Passw.-Hash 8.1: Key Stretching PBKDF2 Password-Based Key Derivation Function Two F(pwd, salt, N, i) I F is the core function I PRF(Key, Input) is modelled U PRF(pwd; salt jj i32) X U as a “pseudorandom for I 1 to N do function” U PRF(pwd; U)(∗) I Why is pwd used in every X X ⊕ U round? Isn’t that dangerous? end for I Should we replace line (∗) return X by U PRF(U)? I PRF could be instantiated by I a block cipher E: PRF(K ; U) = EK (U) I a MAC M: PRF(K ; U) = MK (U) I a hash function H: PRF(K ; U) = H(K jj U) I the HMAC-construction, using H in a nested way: PRF(K ; U) = H(K ⊕ const2 jj (H(K ⊕ const1 jj U)) –240– Stefan Lucks Hash Fun. & PW (S 2014) 8: Passw.-Hash 8.1: Key Stretching PBKDF2 can Generate Large Outputs relevant for key derivation I For a required number of output bits, PBKDF2 concatenates F(pwd; salt; N; 1) jj F(pwd; salt; N; 2) jj ::: truncating the final call to F(pwd; salt; N; i) to the required number of bits I Example WPA2: I PBKDF2 with PRF = HMAC-SHA-1 and N = 4096 iterations I output 256 bits, but HMAC-SHA-1 provides 160 bits I thus, call F twice I use all the 160 bits from F(pwd, salt, N; 1) I and the first 96 bits from F(pwd, salt, N; 2) –241– Stefan Lucks Hash Fun. & PW (S 2014) 8: Passw.-Hash 8.1: Key Stretching 8.2: scrypt(Percival, 2009) The Advance of Massively Parallel Commodity Hardware http://www.nvidia.com/object/what-is-gpu-computing.html I commodity hardware with an abundance of parallel cores I attacker can try out any number of password in parallel I defender is hashing a single password I also, defender does not always have so many cores –242– Stefan Lucks Hash Fun. & PW (S 2014) 8: Passw.-Hash 8.2: scrypt Wisdom # 7: Storage is Expensive . use this, to make the adversary’s life harder CPU (Multiple Cores) GPU (Hundreds of Cores) Core 1 Core 2 Core 3 Core 4 Cache Cache similar cache and memory sizes RAM RAM Adversaries with cheap of-the-shelf parallelizable hardware (GPUs, FPGAs, ASICs, . ) do not have much memory – especially fast cache-memory. –243– Stefan Lucks Hash Fun. & PW (S 2014) 8: Passw.-Hash 8.2: scrypt Memory-Hard Functions I let f be a function which can be computed in time T using space S I consider a machine with S=k units of memory, instead of S I a function f is memory-hard if the time grows from T to kT , at least Definition 10 A function f is memory-hard if computing f (x) with an input of size n needs S(n) space and T 0(n) units of operations, where S(n) ∗ T 0(n) 2 Ω T 0(n)2− for > 0. –244– Stefan Lucks Hash Fun. & PW (S 2014) 8: Passw.-Hash 8.2: scrypt Sequentially Memory-Hard Functions 0 I note that the “time” T in the definition of memory-hardness only denotes the number of operations I this does not rule out a c-times speed-up when computing f (x) on a machine with c parallel cores I we would like to stick with an actual time T =k, given any number of parallel cores Definition 11 A function f is sequentially memory-hard if (1) it is memory-hard and (2) it cannot be computed on a machine with S(n) processors and S(n) space in expected time T (n), where S(n) ∗ T (n) = O T (n)2− for any > 0.
Recommended publications
  • GPU-Based Password Cracking on the Security of Password Hashing Schemes Regarding Advances in Graphics Processing Units

    GPU-Based Password Cracking on the Security of Password Hashing Schemes Regarding Advances in Graphics Processing Units

    Radboud University Nijmegen Faculty of Science Kerckhoffs Institute Master of Science Thesis GPU-based Password Cracking On the Security of Password Hashing Schemes regarding Advances in Graphics Processing Units by Martijn Sprengers [email protected] Supervisors: Dr. L. Batina (Radboud University Nijmegen) Ir. S. Hegt (KPMG IT Advisory) Ir. P. Ceelen (KPMG IT Advisory) Thesis number: 646 Final Version Abstract Since users rely on passwords to authenticate themselves to computer systems, ad- versaries attempt to recover those passwords. To prevent such a recovery, various password hashing schemes can be used to store passwords securely. However, recent advances in the graphics processing unit (GPU) hardware challenge the way we have to look at secure password storage. GPU's have proven to be suitable for crypto- graphic operations and provide a significant speedup in performance compared to traditional central processing units (CPU's). This research focuses on the security requirements and properties of prevalent pass- word hashing schemes. Moreover, we present a proof of concept that launches an exhaustive search attack on the MD5-crypt password hashing scheme using modern GPU's. We show that it is possible to achieve a performance of 880 000 hashes per second, using different optimization techniques. Therefore our implementation, executed on a typical GPU, is more than 30 times faster than equally priced CPU hardware. With this performance increase, `complex' passwords with a length of 8 characters are now becoming feasible to crack. In addition, we show that between 50% and 80% of the passwords in a leaked database could be recovered within 2 months of computation time on one Nvidia GeForce 295 GTX.
  • Argon and Argon2

    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 .
  • CASH: a Cost Asymmetric Secure Hash Algorithm for Optimal Password Protection

    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.
  • Security + Encryption Standards

    Security + Encryption Standards

    Security + Encryption Standards Author: Joseph Lee Email: joseph@ ripplesoftware.ca Mobile: 778-725-3206 General Concepts Forward secrecy / perfect forward secrecy • Using a key exchange to provide a new key for each session provides improved forward secrecy because if keys are found out by an attacker, past data cannot be compromised with the keys Confusion • Cipher-text is significantly different than the original plaintext data • The property of confusion hides the relationship between the cipher-text and the key Diffusion • Is the principle that small changes in message plaintext results in large changes in the cipher-text • The idea of diffusion is to hide the relationship between the cipher-text and the plaintext Secret-algorithm • A proprietary algorithm that is not publicly disclosed • This is discouraged because it cannot be reviewed Weak / depreciated algorithms • An algorithm that can be easily "cracked" or defeated by an attacker High-resiliency • Refers to the strength of the encryption key if an attacker discovers part of the key Data-in-transit • Data sent over a network Data-at-rest • Data stored on a medium Data-in-use • Data being used by an application / computer system Out-of-band KEX • Using a medium / channel for key-exchange other than the medium the data transfer is taking place (phone, email, snail mail) In-band KEX • Using the same medium / channel for key-exchange that the data transfer is taking place Integrity • Ability to determine the message has not been altered • Hashing algorithms manage Authenticity
  • Implementation and Performance Analysis of PBKDF2, Bcrypt, Scrypt Algorithms

    Implementation and Performance Analysis of PBKDF2, Bcrypt, Scrypt Algorithms

    Implementation and Performance Analysis of PBKDF2, Bcrypt, Scrypt Algorithms Levent Ertaul, Manpreet Kaur, Venkata Arun Kumar R Gudise CSU East Bay, Hayward, CA, USA. [email protected], [email protected], [email protected] Abstract- With the increase in mobile wireless or data lookup. Whereas, Cryptographic hash functions are technologies, security breaches are also increasing. It has used for building blocks for HMACs which provides become critical to safeguard our sensitive information message authentication. They ensure integrity of the data from the wrongdoers. So, having strong password is that is transmitted. Collision free hash function is the one pivotal. As almost every website needs you to login and which can never have same hashes of different output. If a create a password, it’s tempting to use same password and b are inputs such that H (a) =H (b), and a ≠ b. for numerous websites like banks, shopping and social User chosen passwords shall not be used directly as networking websites. This way we are making our cryptographic keys as they have low entropy and information easily accessible to hackers. Hence, we need randomness properties [2].Password is the secret value from a strong application for password security and which the cryptographic key can be generated. Figure 1 management. In this paper, we are going to compare the shows the statics of increasing cybercrime every year. Hence performance of 3 key derivation algorithms, namely, there is a need for strong key generation algorithms which PBKDF2 (Password Based Key Derivation Function), can generate the keys which are nearly impossible for the Bcrypt and Scrypt.
  • Speeding up Linux Disk Encryption Ignat Korchagin @Ignatkn $ Whoami

    Speeding up Linux Disk Encryption Ignat Korchagin @Ignatkn $ Whoami

    Speeding Up Linux Disk Encryption Ignat Korchagin @ignatkn $ whoami ● Performance and security at Cloudflare ● Passionate about security and crypto ● Enjoy low level programming @ignatkn Encrypting data at rest The storage stack applications @ignatkn The storage stack applications filesystems @ignatkn The storage stack applications filesystems block subsystem @ignatkn The storage stack applications filesystems block subsystem storage hardware @ignatkn Encryption at rest layers applications filesystems block subsystem SED, OPAL storage hardware @ignatkn Encryption at rest layers applications filesystems LUKS/dm-crypt, BitLocker, FileVault block subsystem SED, OPAL storage hardware @ignatkn Encryption at rest layers applications ecryptfs, ext4 encryption or fscrypt filesystems LUKS/dm-crypt, BitLocker, FileVault block subsystem SED, OPAL storage hardware @ignatkn Encryption at rest layers DBMS, PGP, OpenSSL, Themis applications ecryptfs, ext4 encryption or fscrypt filesystems LUKS/dm-crypt, BitLocker, FileVault block subsystem SED, OPAL storage hardware @ignatkn Storage hardware encryption Pros: ● it’s there ● little configuration needed ● fully transparent to applications ● usually faster than other layers @ignatkn Storage hardware encryption Pros: ● it’s there ● little configuration needed ● fully transparent to applications ● usually faster than other layers Cons: ● no visibility into the implementation ● no auditability ● sometimes poor security https://support.microsoft.com/en-us/help/4516071/windows-10-update-kb4516071 @ignatkn Block
  • Optimizing a Password Hashing Function with Hardware-Accelerated Symmetric Encryption

    Optimizing a Password Hashing Function with Hardware-Accelerated Symmetric Encryption

    S S symmetry Article Optimizing a Password Hashing Function with Hardware-Accelerated Symmetric Encryption Rafael Álvarez 1,* , Alicia Andrade 2 and Antonio Zamora 3 1 Departamento de Ciencia de la Computación e Inteligencia Artificial (DCCIA), Universidad de Alicante, 03690 Alicante, Spain 2 Fac. Ingeniería, Ciencias Físicas y Matemática, Universidad Central, Quito 170129, Ecuador; [email protected] 3 Departamento de Ciencia de la Computación e Inteligencia Artificial (DCCIA), Universidad de Alicante, 03690 Alicante, Spain; [email protected] * Correspondence: [email protected] Received: 2 November 2018; Accepted: 22 November 2018; Published: 3 December 2018 Abstract: Password-based key derivation functions (PBKDFs) are commonly used to transform user passwords into keys for symmetric encryption, as well as for user authentication, password hashing, and preventing attacks based on custom hardware. We propose two optimized alternatives that enhance the performance of a previously published PBKDF. This design is based on (1) employing a symmetric cipher, the Advanced Encryption Standard (AES), as a pseudo-random generator and (2) taking advantage of the support for the hardware acceleration for AES that is available on many common platforms in order to mitigate common attacks to password-based user authentication systems. We also analyze their security characteristics, establishing that they are equivalent to the security of the core primitive (AES), and we compare their performance with well-known PBKDF algorithms, such as Scrypt and Argon2, with favorable results. Keywords: symmetric; encryption; password; hash; cryptography; PBKDF 1. Introduction Key derivation functions are employed to obtain one or more keys from a master secret. This is especially useful in the case of user passwords, which can be of arbitrary length and are unsuitable to be used directly as fixed-size cipher keys, so, there must be a process for converting passwords into secret keys.
  • A New Approach in Expanding the Hash Size of MD5

    A New Approach in Expanding the Hash Size of MD5

    374 International Journal of Communication Networks and Information Security (IJCNIS) Vol. 10, No. 2, August 2018 A New Approach in Expanding the Hash Size of MD5 Esmael V. Maliberan, Ariel M. Sison, Ruji P. Medina Graduate Programs, Technological Institute of the Philippines, Quezon City, Philippines Abstract: The enhanced MD5 algorithm has been developed by variants and RIPEMD-160. These hash algorithms are used expanding its hash value up to 1280 bits from the original size of widely in cryptographic protocols and internet 128 bit using XOR and AND operators. Findings revealed that the communication in general. Among several hashing hash value of the modified algorithm was not cracked or hacked algorithms mentioned above, MD5 still surpasses the other during the experiment and testing using powerful bruteforce, since it is still widely used in the domain authentication dictionary, cracking tools and rainbow table such as security owing to its feature of irreversible [41]. This only CrackingStation, Hash Cracker, Cain and Abel and Rainbow Crack which are available online thus improved its security level means that the confirmation does not need to demand the compared to the original MD5. Furthermore, the proposed method original data but only need to have an effective digest to could output a hash value with 1280 bits with only 10.9 ms confirm the identity of the client. The MD5 message digest additional execution time from MD5. algorithm was developed by Ronald Rivest sometime in 1991 to change a previous hash function MD4, and it is commonly Keywords: MD5 algorithm, hashing, client-server used in securing data in various applications [27,23,22].
  • Security Policy: Informacast Java Crypto Library

    Security Policy: Informacast Java Crypto Library

    FIPS 140-2 Non-Proprietary Security Policy: InformaCast Java Crypto Library FIPS 140-2 Non-Proprietary Security Policy InformaCast Java Crypto Library Software Version 3.0 Document Version 1.2 June 26, 2017 Prepared For: Prepared By: Singlewire Software SafeLogic Inc. 1002 Deming Way 530 Lytton Ave, Suite 200 Madison, WI 53717 Palo Alto, CA 94301 www.singlewire.com www.safelogic.com Document Version 1.2 © Singlewire Software Page 1 of 35 FIPS 140-2 Non-Proprietary Security Policy: InformaCast Java Crypto Library Abstract This document provides a non-proprietary FIPS 140-2 Security Policy for InformaCast Java Crypto Library. Document Version 1.2 © Singlewire Software Page 2 of 35 FIPS 140-2 Non-Proprietary Security Policy: InformaCast Java Crypto Library Table of Contents 1 Introduction .................................................................................................................................................. 5 1.1 About FIPS 140 ............................................................................................................................................. 5 1.2 About this Document.................................................................................................................................... 5 1.3 External Resources ....................................................................................................................................... 5 1.4 Notices .........................................................................................................................................................
  • Rifflescrambler – a Memory-Hard Password Storing Function ⋆

    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.
  • Hash Functions

    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.
  • Cs 255 (Introduction to Cryptography)

    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.