DOCSLIB.ORG

Distributed Symmetric-Key Encryption∗

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Distributed Symmetric-Key Encryption∗ DiSE: Distributed Symmetric-key Encryption∗ Shashank Agrawal Payman Mohassel Pratyay Mukherjee Peter Rindal shaagraw,pmohasse,pratmukh,[email protected] Visa Research ABSTRACT asymmetric-key setting, namely public-key encryption and signa- Threshold cryptography provides a mechanism for protecting se- ture schemes [15, 22, 24, 25, 29, 33, 34, 36, 48, 49, 69] where the cret keys by sharing them among multiple parties, who then jointly signing/decryption key and algorithms are distributed among mul- perform cryptographic operations. An attacker who corrupts upto tiple parties. This is despite the fact that a large fraction of applica- a threshold number of parties cannot recover the secrets or vio- tions that can benefit from stronger secret-key protection primarily late security. Prior works in this space have mostly focused on use symmetric-key cryptographic primitives wherein secret keys definitions and constructions for public-key cryptography and dig- persist for a long time. We review three such examples below: ital signatures, and thus do not capture the security concerns and Secret Management Systems. An increasing number of tools and efficiency challenges of symmetric-key based applications which popular open source software such as Keywhiz, Knox, and Hashicorp commonly use long-term (centralized) master keys to protect data Vault (e.g. see [4]) are designed to automate the management and at rest, authenticate clients on enterprise networks, and secure data protection of secrets such as sensitive data and credentials in cloud- and payments on IoT devices. based settings by encrypting data at rest and managing keys and We put forth the first formal treatment for distributed symmetric- authentication. These tools provide a wide range of features such as key encryption, proposing new notions of correctness, privacy and interoperability between clouds and audit/compliance support. By authenticity in presence of malicious attackers. We provide strong far, the most commonly adopted primitive for encrypting secrets in and intuitive game-based definitions that are easy to understand the storage backend is authenticated encryption with a master data and yield efficient constructions. encryption key that encrypts a large number of records. Some of We propose a generic construction of threshold authenticated en- these systems use secret sharing to provide limited key protection cryption based on any distributed pseudorandom function (DPRF). in an initialization stage but once keys are reconstructed in memory When instantiated with the two different DPRF constructions pro- they remain unencrypted until the system is rebooted. Consider posed by Naor, Pinkas and Reingold (Eurocrypt 1999) and our en- the following statement from Hashicorp Vault’s architecture docu- hanced versions, we obtain several efficient constructions meeting mentation [12]: different security definitions. We implement these variants and “Once started, the Vault is in a sealed state ::: When the Vault is initialized provide extensive performance comparisons. Our most efficient it generates an encryption key which is used to protect all the data. That key is instantiation uses only symmetric-key primitives and achieves a protected by a master key. By default, Vault uses a technique known as Shamir’s secret throughput of upto 1 million encryptions/decryptions per seconds, sharing algorithm to split the master key into 5 shares, any 3 of which are required to or alternatively a sub-millisecond latency with upto 18 participating reconstruct the master key ::: Once Vault retrieves the encryption key, it is able to parties. decrypt the data in the storage backend, and enters the unsealed state." 1 INTRODUCTION Enterprise Network Authentication. Network authentication pro- A central advantage of using cryptographic primitives such as tocols such as Kerberos [6] are widely used to provide a single-sign- symmetric-key encryption is that the safety of a large amount of on experience to users by enabling them to authenticate periodically sensitive data can be reduced to the safety of a very small key. To (e.g. once a day) to a ticket-granting service using their credentials, get any real benefit from this approach, however, the key mustbe to obtain a ticket-granting ticket (TGT) that they use to get access protected securely. One could encrypt the key with another key, to various services such as mail, printers and internal web. The protect it using secure hardware (e.g. HSM, SGX or SE), or split recommended approach for generating the TGT is authenticated en- it across multiple parties. Clearly, the first approach only shifts cryption (e.g. see [5]) using a master secret key in order to provide the problem to protecting another key. On the other hand secure both confidentiality and integrity for the information contained in hardware, co-processors and the like provide reasonable security the ticket. This renders the master secret key an important attack but are not always available, are expensive or not scalable, lack target, as it remains unprotected in memory over a long period. programmability and are prone to side-channel attacks. Splitting the key among multiple parties, i.e. threshold cryp- Multi-device IoT Authentication. The proliferation of a wide range tography, is an effective general-purpose solution, that has re- of Internet of Things (IoT) has provided users with new and conve- cently emerged in practice as an alternative software-only solu- nient ways to interact with the world around them. Such devices tion [2, 10, 11]. Surprisingly, prior to our work, there was no for- are increasingly used to store secrets that are used to authenti- mal treatment of distributed symmetric-key encryption. Prior for- cate users or enable secure payments. Many IoT devices are not mal treatments of threshold cryptography typically focus on the equipped with proper environments to store secret keys, and even when they are, provide developers with little programmability for ∗ An extended abstract [16] of this work appeared in ACM Conference on Computer their applications. It is therefore desirable to leverage the fact that and Communications Security, 2018. The full version [17] can be found at https: //eprint.iacr.org/2018/727.pdf many users own multiple devices (smart phone, smart watch, smart TV, etc.) to distribute the key material among them (instead of proposed definitions. See the overview in Section 2 for amore keeping it entirely on any single device) to enable multi-device detailed discussion. cryptographic functionalities without making strong assumptions Performance Challenges. In addition to not meeting our security about a device’s security features. Given the limited computation notions, existing threshold public-key constructions are too expen- and communication power of many such IoT devices, such dis- sive for symmetric-key use cases, as they are dominated by more tributed primitives should require minimal interaction and limited expensive public-key operations and/or require extensive interac- cryptographic capabilities (e.g. only block-ciphers). tion and communication between the parties. Applications that use symmetric-key cryptography often have stringent latency or throughput requirements. Ideally, one would like the distributed 1.1 Technical Challenges encryption/decryption protocols to not be significantly more ex- Modeling security. As discussed earlier, existing threshold cryp- pensive than their non-distributed counterparts. In particular, the tographic definitions and constructions are primarily focused on protocols should have low computation and bandwidth cost, and public-key primitives such as digital signatures and public-key en- require minimal interaction. cryption. In fact, to the best of our knowledge, there is no standard General-purpose multi-party computation protocols can also be symmetric-key security notions in the distributed setting. used to solve the same problems by computing standard symmetric- Note that threshold authenticated encryption (TAE) is the ap- key encryption schemes inside an MPC (e.g. see [2, 65]). While this propriate and natural notion here as it would simultaneously solve approach has the benefit of preserving the original non-interactive the confidentiality and the authenticity problem, such that a cipher- algorithm, the resulting protocols would be prohibitively interac- text generated by the TAE scheme could be both an authentica- tive, bandwidth-intensive, and would become increasingly expen- tion token and an encrypted message. Unfortunately, while defini- sive for larger number of parties. In this paper, we aim for two-round tions for threshold public-key encryption are well-understood (e.g. protocols where one server sends a message to other servers and see [22, 25, 29, 35, 68]), as we elaborate next, they fail to capture receives a response, while other servers need not exchange any important subtleties that only arise in the symmetric-key setting messages. This minimal interaction model minimizes coordination when considering standard AE notions of message privacy and between the servers and is ideal for low-latency applications. ciphertext integrity. We review the MPC-based solutions and other related work on What truly separates TAE from threshold public-key encryption protecting cryptographic secrets through splitting them among is that in TAE a corrupted party should not be able to encrypt or multiple parties (i.e. secret sharing, threshold PKE and threshold decrypt messages on her own or even
Load more

Recommended publications
  • Public-Key Cryptography
    Public Key Cryptography EJ Jung Basic Public Key Cryptography public key public key ? private key Alice Bob Given: Everybody knows Bob’s public key - How is this achieved in practice? Only Bob knows the corresponding private key Goals: 1. Alice wants to send a secret message to Bob 2. Bob wants to authenticate himself Requirements for Public-Key Crypto ! Key generation: computationally easy to generate a pair (public key PK, private key SK) • Computationally infeasible to determine private key PK given only public key PK ! Encryption: given plaintext M and public key PK, easy to compute ciphertext C=EPK(M) ! Decryption: given ciphertext C=EPK(M) and private key SK, easy to compute plaintext M • Infeasible to compute M from C without SK • Decrypt(SK,Encrypt(PK,M))=M Requirements for Public-Key Cryptography 1. Computationally easy for a party B to generate a pair (public key KUb, private key KRb) 2. Easy for sender to generate ciphertext: C = EKUb (M ) 3. Easy for the receiver to decrypt ciphertect using private key: M = DKRb (C) = DKRb[EKUb (M )] Henric Johnson 4 Requirements for Public-Key Cryptography 4. Computationally infeasible to determine private key (KRb) knowing public key (KUb) 5. Computationally infeasible to recover message M, knowing KUb and ciphertext C 6. Either of the two keys can be used for encryption, with the other used for decryption: M = DKRb[EKUb (M )] = DKUb[EKRb (M )] Henric Johnson 5 Public-Key Cryptographic Algorithms ! RSA and Diffie-Hellman ! RSA - Ron Rives, Adi Shamir and Len Adleman at MIT, in 1977. • RSA
    [Show full text]
  • Public Key Cryptography And
    PublicPublic KeyKey CryptographyCryptography andand RSARSA 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 9-1 OverviewOverview 1. Public Key Encryption 2. Symmetric vs. Public-Key 3. RSA Public Key Encryption 4. RSA Key Construction 5. Optimizing Private Key Operations 6. RSA Security 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 9-2 PublicPublic KeyKey EncryptionEncryption Invented in 1975 by Diffie and Hellman at Stanford Encrypted_Message = Encrypt(Key1, Message) Message = Decrypt(Key2, Encrypted_Message) Key1 Key2 Text Ciphertext Text Keys are interchangeable: Key2 Key1 Text Ciphertext Text One key is made public while the other is kept private Sender knows only public key of the receiver Asymmetric Washington University in St. Louis CSE571S ©2011 Raj Jain 9-3 PublicPublic KeyKey EncryptionEncryption ExampleExample Rivest, Shamir, and Adleman at MIT RSA: Encrypted_Message = m3 mod 187 Message = Encrypted_Message107 mod 187 Key1 = <3,187>, Key2 = <107,187> Message = 5 Encrypted Message = 53 = 125 Message = 125107 mod 187 = 5 = 125(64+32+8+2+1) mod 187 = {(12564 mod 187)(12532 mod 187)... (1252 mod 187)(125 mod 187)} mod 187 Washington University in
    [Show full text]
  • CS 255: Intro to Cryptography 1 Introduction 2 End-To-End
    Programming Assignment 2 Winter 2021 CS 255: Intro to Cryptography Prof. Dan Boneh Due Monday, March 1st, 11:59pm 1 Introduction In this assignment, you are tasked with implementing a secure and efficient end-to-end encrypted chat client using the Double Ratchet Algorithm, a popular session setup protocol that powers real- world chat systems such as Signal and WhatsApp. As an additional challenge, assume you live in a country with government surveillance. Thereby, all messages sent are required to include the session key encrypted with a fixed public key issued by the government. In your implementation, you will make use of various cryptographic primitives we have discussed in class—notably, key exchange, public key encryption, digital signatures, and authenticated encryption. Because it is ill-advised to implement your own primitives in cryptography, you should use an established library: in this case, the Stanford Javascript Crypto Library (SJCL). We will provide starter code that contains a basic template, which you will be able to fill in to satisfy the functionality and security properties described below. 2 End-to-end Encrypted Chat Client 2.1 Implementation Details Your chat client will use the Double Ratchet Algorithm to provide end-to-end encrypted commu- nications with other clients. To evaluate your messaging client, we will check that two or more instances of your implementation it can communicate with each other properly. We feel that it is best to understand the Double Ratchet Algorithm straight from the source, so we ask that you read Sections 1, 2, and 3 of Signal’s published specification here: https://signal.
    [Show full text]
  • Choosing Key Sizes for Cryptography
    information security technical report 15 (2010) 21e27 available at www.sciencedirect.com www.compseconline.com/publications/prodinf.htm Choosing key sizes for cryptography Alexander W. Dent Information Security Group, University Of London, Royal Holloway, UK abstract After making the decision to use public-key cryptography, an organisation still has to make many important decisions before a practical system can be implemented. One of the more difficult challenges is to decide the length of the keys which are to be used within the system: longer keys provide more security but mean that the cryptographic operation will take more time to complete. The most common solution is to take advice from information security standards. This article will investigate the methodology that is used produce these standards and their meaning for an organisation who wishes to implement public-key cryptography. ª 2010 Elsevier Ltd. All rights reserved. 1. Introduction being compromised by an attacker). It also typically means a slower scheme. Most symmetric cryptographic schemes do The power of public-key cryptography is undeniable. It is not allow the use of keys of different lengths. If a designer astounding in its simplicity and its ability to provide solutions wishes to offer a symmetric scheme which provides different to many seemingly insurmountable organisational problems. security levels depending on the key size, then the designer However, the use of public-key cryptography in practice is has to construct distinct variants of a central design which rarely as simple as the concept first appears. First one has to make use of different pre-specified key lengths.
    [Show full text]
  • TS 102 176-1 V2.1.1 (2011-07) Technical Specification
    ETSI TS 102 176-1 V2.1.1 (2011-07) Technical Specification Electronic Signatures and Infrastructures (ESI); Algorithms and Parameters for Secure Electronic Signatures; Part 1: Hash functions and asymmetric algorithms 2 ETSI TS 102 176-1 V2.1.1 (2011-07) Reference RTS/ESI-000080-1 Keywords e-commerce, electronic signature, security ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N° 348 623 562 00017 - NAF 742 C Association à but non lucratif enregistrée à la Sous-Préfecture de Grasse (06) N° 7803/88 Important notice Individual copies of the present document can be downloaded from: http://www.etsi.org The present document may be made available in more than one electronic version or in print. In any case of existing or perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive within ETSI Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at http://portal.etsi.org/tb/status/status.asp If you find errors in the present document, please send your comment to one of the following services: http://portal.etsi.org/chaircor/ETSI_support.asp Copyright Notification No part may be reproduced except as authorized by written permission.
    [Show full text]
  • Basics of Digital Signatures &
    > DOCUMENT SIGNING > eID VALIDATION > SIGNATURE VERIFICATION > TIMESTAMPING & ARCHIVING > APPROVAL WORKFLOW Basics of Digital Signatures & PKI This document provides a quick background to PKI-based digital signatures and an overview of how the signature creation and verification processes work. It also describes how the cryptographic keys used for creating and verifying digital signatures are managed. 1. Background to Digital Signatures Digital signatures are essentially “enciphered data” created using cryptographic algorithms. The algorithms define how the enciphered data is created for a particular document or message. Standard digital signature algorithms exist so that no one needs to create these from scratch. Digital signature algorithms were first invented in the 1970’s and are based on a type of cryptography referred to as “Public Key Cryptography”. By far the most common digital signature algorithm is RSA (named after the inventors Rivest, Shamir and Adelman in 1978), by our estimates it is used in over 80% of the digital signatures being used around the world. This algorithm has been standardised (ISO, ANSI, IETF etc.) and been extensively analysed by the cryptographic research community and you can say with confidence that it has withstood the test of time, i.e. no one has been able to find an efficient way of cracking the RSA algorithm. Another more recent algorithm is ECDSA (Elliptic Curve Digital Signature Algorithm), which is likely to become popular over time. Digital signatures are used everywhere even when we are not actually aware, example uses include: Retail payment systems like MasterCard/Visa chip and pin, High-value interbank payment systems (CHAPS, BACS, SWIFT etc), e-Passports and e-ID cards, Logging on to SSL-enabled websites or connecting with corporate VPNs.
    [Show full text]
  • Chapter 2 the Data Encryption Standard (DES)
    Chapter 2 The Data Encryption Standard (DES) As mentioned earlier there are two main types of cryptography in use today - symmet- ric or secret key cryptography and asymmetric or public key cryptography. Symmet- ric key cryptography is the oldest type whereas asymmetric cryptography is only being used publicly since the late 1970’s1. Asymmetric cryptography was a major milestone in the search for a perfect encryption scheme. Secret key cryptography goes back to at least Egyptian times and is of concern here. It involves the use of only one key which is used for both encryption and decryption (hence the use of the term symmetric). Figure 2.1 depicts this idea. It is necessary for security purposes that the secret key never be revealed. Secret Key (K) Secret Key (K) ? ? - - - - Plaintext (P ) E{P,K} Ciphertext (C) D{C,K} Plaintext (P ) Figure 2.1: Secret key encryption. To accomplish encryption, most secret key algorithms use two main techniques known as substitution and permutation. Substitution is simply a mapping of one value to another whereas permutation is a reordering of the bit positions for each of the inputs. These techniques are used a number of times in iterations called rounds. Generally, the more rounds there are, the more secure the algorithm. A non-linearity is also introduced into the encryption so that decryption will be computationally infeasible2 without the secret key. This is achieved with the use of S-boxes which are basically non-linear substitution tables where either the output is smaller than the input or vice versa. 1It is claimed by some that government agencies knew about asymmetric cryptography before this.
    [Show full text]
  • The Hitchhiker's Guide to the SHA-3 Competition
    History First Second Third The Hitchhiker’s Guide to the SHA-3 Competition Orr Dunkelman Computer Science Department 20 June, 2012 Orr Dunkelman The Hitchhiker’s Guide to the SHA-3 Competition 1/ 33 History First Second Third Outline 1 History of Hash Functions A(n Extremely) Short History of Hash Functions The Sad News about the MD/SHA Family 2 The First Phase of the SHA-3 Competition Timeline The SHA-3 First Round Candidates 3 The Second Round The Second Round Candidates The Second Round Process 4 The Third Round The Finalists Current Performance Estimates The Outcome of SHA-3 Orr Dunkelman The Hitchhiker’s Guide to the SHA-3 Competition 2/ 33 History First Second Third History Sad Outline 1 History of Hash Functions A(n Extremely) Short History of Hash Functions The Sad News about the MD/SHA Family 2 The First Phase of the SHA-3 Competition Timeline The SHA-3 First Round Candidates 3 The Second Round The Second Round Candidates The Second Round Process 4 The Third Round The Finalists Current Performance Estimates The Outcome of SHA-3 Orr Dunkelman The Hitchhiker’s Guide to the SHA-3 Competition 3/ 33 History First Second Third History Sad A(n Extremely) Short History of Hash Functions 1976 Diffie and Hellman suggest to use hash functions to make digital signatures shorter. 1979 Salted passwords for UNIX (Morris and Thompson). 1983/4 Davies/Meyer introduce Davies-Meyer. 1986 Fiat and Shamir use random oracles. 1989 Merkle and Damg˚ard present the Merkle-Damg˚ard hash function.
    [Show full text]
  • Cryptography Knowledge Area (Draft for Comment)
    CRYPTOGRAPHY KNOWLEDGE AREA (DRAFT FOR COMMENT) AUTHOR: Nigel Smart – KU Leuven EDITOR: George Danezis – University College London REVIEWERS: Dan Bogdanov - Cybernetica Kenny Patterson – Royal Holloway, University of London Liqun Chen – University of Surrey Cryptography Nigel P. Smart April 2018 INTRODUCTION The purpose of this chapter is to explain the various aspects of cryptography which we feel should be known to an expert in cyber-security. The presentation is at a level needed for an instructor in a module in cryptography; so they can select the depth needed in each topic. Whilst not all experts in cyber-security need be aware of all the technical aspects mentioned below, we feel they should be aware of all the overall topics and have an intuitive grasp as to what they mean, and what services they can provide. Our focus is mainly on primitives, schemes and protocols which are widely used, or which are suitably well studied that they could be used (or are currently being used) in specific application domains. Cryptography by its very nature is one of the more mathematical aspects of cyber-security; thus this chapter contains a lot more mathematics than one has in some of the other chapters. The overall presentation assumes a basic knowledge of either first-year undergraduate mathematics, or that found in a discrete mathematics course of an undergraduate Computer Science degree. The chapter is structured as follows: After a quick recap on some basic mathematical notation (Sec- tion 1), we then give an introduction to how security is defined in modern cryptography. This section (Section 2) forms the basis of our discussions in the other sections.
    [Show full text]
  • Selecting Cryptographic Key Sizes
    J. Cryptology (2001) 14: 255–293 DOI: 10.1007/s00145-001-0009-4 © 2001 International Association for Cryptologic Research Selecting Cryptographic Key Sizes Arjen K. Lenstra Citibank, N.A., 1 North Gate Road, Mendham, NJ 07945-3104, U.S.A. [email protected] and Technische Universiteit Eindhoven Eric R. Verheul PricewaterhouseCoopers, GRMS Crypto Group, Goudsbloemstraat 14, 5644 KE Eindhoven, The Netherlands eric.verheul@[nl.pwcglobal.com, pobox.com] Communicated by Andrew Odlyzko Received September 1999 and revised February 2001 Online publication 14 August 2001 Abstract. In this article we offer guidelines for the determination of key sizes for symmetric cryptosystems, RSA, and discrete logarithm-based cryptosystems both over finite fields and over groups of elliptic curves over prime fields. Our recommendations are based on a set of explicitly formulated parameter settings, combined with existing data points about the cryptosystems. Key words. Symmetric key length, Public key length, RSA, ElGamal, Elliptic curve cryptography, Moore’s law. 1. Introduction 1.1. The Purpose of This Paper Cryptography is one of the most important tools that enable e-commerce because cryp- tography makes it possible to protect electronic information. The effectiveness of this protection depends on a variety of mostly unrelated issues such as cryptographic key size, protocol design, and password selection. Each of these issues is equally important: if a key is too small, or if a protocol is badly designed or incorrectly used, or if a pass- word is poorly selected or protected, then the protection fails and improper access can be gained. In this article we give some guidelines for the determination of cryptographic key sizes.
    [Show full text]
  • Signal E2E-Crypto Why Can’T I Hold All These Ratchets
    Signal E2E-Crypto Why Can’t I Hold All These Ratchets oxzi 23.03.2021 In the next 30 minutes there will be I a rough introduction in end-to-end encrypted instant messaging, I an overview of how Signal handles those E2E encryption, I and finally a demo based on a WeeChat plugin. Historical Background I Signal has not reinvented the wheel - and this is a good thing! I Goes back to Off-the-Record Communication (OTR)1. OTR Features I Perfect forward secrecy I Deniable authentication 1Borisov, Goldberg, and Brewer. “Off-the-record communication, or, why not to use PGP”, 2004 Influence and Evolution I OTR influenced the Signal Protocol, Double Ratchet. I Double Ratchet influence OMEMO; supports many-to-many communication. I Also influenced Olm, E2E encryption of the Matrix protocol. I OTR itself was influenced by this, version four was introduced in 2018. Double Ratchet The Double Ratchet algorithm is used by two parties to exchange encrypted messages based on a shared secret key. The Double Ratchet algorithm2 is essential in Signal’s E2E crypto. But first, some basics. 2Perrin, and Marlinspike. “The Double Ratchet Algorithm”, 2016 Cryptographic Ratchet A ratchet is a cryptographic function that only moves forward. In other words, one cannot easily reverse its output. Triple Ratchet, I guess.3 3By Salvatore Capalbi, https://www.flickr.com/photos/sheldonpax/411551322/, CC BY-SA 2.5 Symmetric-Key Ratchet Symmetric-Key Ratchet In everyday life, Keyed-Hash Message Authentication Code (HMAC) or HMAC-based KDFs (HKDF) are used. func ratchet(ckIn[]byte)(ckOut, mk[]byte){ kdf := hmac.New(sha256.New, ckIn) kdf.Write(c) // publicly known constant c out := kdf.Sum(nil) return out[:32], out[32:] } ck0 :=[]byte{0x23, 0x42, ...} // some initial shared secret ck1, mk1 := ratchet(ck0) ck2, mk2 := ratchet(ck1) Diffie-Hellman Key Exchange Diffie-Hellman Key Exchange Diffie-Hellman Key Exchange Originally, DH uses primitive residue classes modulo n.
    [Show full text]
  • NISTIR 7620 Status Report on the First Round of the SHA-3
    NISTIR 7620 Status Report on the First Round of the SHA-3 Cryptographic Hash Algorithm Competition Andrew Regenscheid Ray Perlner Shu-jen Chang John Kelsey Mridul Nandi Souradyuti Paul NISTIR 7620 Status Report on the First Round of the SHA-3 Cryptographic Hash Algorithm Competition Andrew Regenscheid Ray Perlner Shu-jen Chang John Kelsey Mridul Nandi Souradyuti Paul Information Technology Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899-8930 September 2009 U.S. Department of Commerce Gary Locke, Secretary National Institute of Standards and Technology Patrick D. Gallagher, Deputy Director NISTIR 7620: Status Report on the First Round of the SHA-3 Cryptographic Hash Algorithm Competition Abstract The National Institute of Standards and Technology is in the process of selecting a new cryptographic hash algorithm through a public competition. The new hash algorithm will be referred to as “SHA-3” and will complement the SHA-2 hash algorithms currently specified in FIPS 180-3, Secure Hash Standard. In October, 2008, 64 candidate algorithms were submitted to NIST for consideration. Among these, 51 met the minimum acceptance criteria and were accepted as First-Round Candidates on Dec. 10, 2008, marking the beginning of the First Round of the SHA-3 cryptographic hash algorithm competition. This report describes the evaluation criteria and selection process, based on public feedback and internal review of the first-round candidates, and summarizes the 14 candidate algorithms announced on July 24, 2009 for moving forward to the second round of the competition. The 14 Second-Round Candidates are BLAKE, BLUE MIDNIGHT WISH, CubeHash, ECHO, Fugue, Grøstl, Hamsi, JH, Keccak, Luffa, Shabal, SHAvite-3, SIMD, and Skein.
    [Show full text]