DOCSLIB.ORG

PKCS (Public-Key Cryptography Standards)

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
PKCS (Public-Key Cryptography Standards) PKCS (Public-key cryptography standards) Códigos y Criptografía Francisco Rodríguez Henríquez Network Access Security Model Códigos y Criptografía Francisco Rodríguez Henríquez Security Levels • Confidentiality – Protection from disclosure to unauthorized persons • Integrity – Maintaining data consistency • Authentication – Assurance of identity of person or originator of data • Non-repudiation – Originator of communications can't deny it later • Authorization – Identity combined with an access policy grants the rights to perform some action Códigos y Criptografía Francisco Rodríguez Henríquez Security Building Blocks • Encryption provides – confidentiality, can provide authentication and integrity protection • Checksums/hash algorithms provide – integrity protection, can provide authentication • Digital signatures provide – authentication, integrity protection, and non- repudiation Códigos y Criptografía Francisco Rodríguez Henríquez Keys • Symetric Keys – Both parties share the same secret key – A major problem is securely distributing the key – DES - 56 bit key considered unsafe for financial purposes since 1998 – 3 DES uses three DES keys Códigos y Criptografía Francisco Rodríguez Henríquez Keys • Public/Private keys – One key is the mathematical inverse of the other – Private keys are known only to the owner – Public key are stored in public servers, usually in a X.509 certificate. – RSA (patent expires Sept 2000), Diffie- Hellman, DSA Códigos y Criptografía Francisco Rodríguez Henríquez A Simplified Model of Conventional Encryption Códigos y Criptografía Francisco Rodríguez Henríquez Public-Key Cryptography Códigos y Criptografía Francisco Rodríguez Henríquez Public-Key Cryptography Códigos y Criptografía Francisco Rodríguez Henríquez Message Digest • A message digest, also known as a one-way hash function, is a fixed length computionally unique identifier corresponding to a set of data. That is, each unit of data (a file, a buffer, etc.) will map to a particular short block, called a message digest. It is not random: digesting the same unit of data with the same digest algorithm will always produce the same short block. • A good message digest algorithm possesses the following qualities – The algorithm accepts any input data length. – The algorithm produces a fixed length output for any input data. – The digest does not reveal anything about the input that was used to generate it. – It is computationally infeasible to produce data that has a specific digest. – It is computationally infeasible to produce two different unit of data that produce the same digest. Códigos y Criptografía Francisco Rodríguez Henríquez Hash Algorithms • Reduce variable-length input to fixed- length (128 or 160bit) output • Requirements – Can't deduce input from output – Can't generate a given output – Can't find two inputs which produce the same output Códigos y Criptografía Francisco Rodríguez Henríquez Hash Algorithms • Used to – Produce fixed-length fingerprint of arbitrary- length data – Produce data checksums to enable detection of modifications – Distil passwords down to fixed-length encryption keys • Also called message digests or fingerprints Códigos y Criptografía Francisco Rodríguez Henríquez Message Authentication Code MAC • Hash algorithm + key to make hash value dependant on the key • Most common form is HMAC (hash MAC) – hash( key, hash( key, data )) • Key affects both start and end of hashing process • Naming: hash + key = HMAC-hash – MD5 1 HMAC-MD5 – SHA-1 1 HMAC-SHA (recommended) Códigos y Criptografía Francisco Rodríguez Henríquez RSA: An Example Códigos y Criptografía Francisco Rodríguez Henríquez Digital Signatures • Combines a hash with a digital signature algorithm • To sign – hash the data – encrypt the hash with the sender's private key – send data signer’s name and signature • To verify – hash the data – decrypt the signature with the sender's public key – the result of which should match the hash Códigos y Criptografía Francisco Rodríguez Henríquez Digital Signatures • A data string associating a message with an originating entity – Signature generation algorithm – Signature verification algorithm – Signature scheme • Used for authentication, integrity, and nonrepudiation • Public key certification is one of the most significant applications Códigos y Criptografía Francisco Rodríguez Henríquez Digital Signature/Verification Schemes Códigos y Criptografía Francisco Rodríguez Henríquez Digital Signature/Verification Schemes Códigos y Criptografía Francisco Rodríguez Henríquez Digital Signature/Verification Schemes Códigos y Criptografía Francisco Rodríguez Henríquez Diffie-Hellman protocol Códigos y Criptografía Francisco Rodríguez Henríquez Diffie-Hellman protocol Códigos y Criptografía Francisco Rodríguez Henríquez Diffie-Hellman protocol Códigos y Criptografía Francisco Rodríguez Henríquez Key exchange: Diffie-Hellman protocol 1. Picks a ∈ GF(p) at random 1. Picks b ∈ GF(p) at random a b 2. Computes TA = g mod p 2. Computes TB = g mod p 3. Sends TA 3. Receives TA 4. Receives TB 4. Sends TB a b 5. Computes KA = TB mod p 5. Computes KB = TA mod p Machine A Machine B Where K = KA = KB, Because: a b a ba ab a b b TB = (g ) = g = g = (g ) = TA mod p Códigos y Criptografía Francisco Rodríguez Henríquez Mensaje para Anita en La Jornada Querida Anita de mi corazón: Quisiera pedirte que nuestro número primo sea 128903289023 y nuestra g 23489. Te quiere Betito. Códigos y Criptografía Francisco Rodríguez Henríquez Middle-person attack. • Consider the following scenario: Anita Middleperson Betito ga = 8389 gx = 5876 gb = 9267 8389 5876 5876 9267 Shared key KAX: Shared key KBX 5876a = 8389x 9267x = 5876b • After this exchange, the middle-person attacker simply decrypts any messages sent out by A or B, and then reads any possibly modifies them before re-encrypting with the appropriate key and transmitting them to the correct party. • Middle-person attack is possible due to the fact that DHC does not authenticate the participants. Possible solutions are digital signatures and other protocol variants. Códigos y Criptografía Francisco Rodríguez Henríquez Solution: Mutual authentication I am A, R1 R2, KAB {R1} A B KAB{R2} Códigos y Criptografía Francisco Rodríguez Henríquez Reflection attack I am A, R T 1 B R2, KAB{R1} I am A, R2 T B R3, KAB{R2} Códigos y Criptografía Francisco Rodríguez Henríquez Encryption across a packet-switching network Códigos y Criptografía Francisco Rodríguez Henríquez Elements of PKI • Certificate Authorities (CA) – OpenSSL, Netscape, Verisign, Entrust, RSA Keon • Public/Private Key Pairs - Key management • x.509 Identity Certificates - Certificate management • LDAP servers Códigos y Criptografía Francisco Rodríguez Henríquez PKCS • Public-key cryptography standards (PKCS) • Owned by RSA and motivated to promote RSA • Created in early 1990’s • Numbered from PKCS1 to PKCS15 • Some along the way have – lost interest – folded into other PKCS – taken over by other standards bodies • Continue to evolve Códigos y Criptografía Francisco Rodríguez Henríquez RSA cryptosystem by layers Protocols and Applications: SSL, TLS, WTLS, WAP, etc. PKCS User Functions:PKCS1_OAEP_Encrypt, PKCS1_OAEP_Decrypt, PKCS1_v15_Sign, PKCS Primitives: PKCS1_OAEP_Encode, PKCS1_OAEP_Decode, etc RSA primitive Operations: Encryption: C = Me mod n, Decryption M = Cd mod n. FP finite field operations : Addition, Squaring, multiplication, inversion and exponentiation Códigos y Criptografía Francisco Rodríguez Henríquez PKCS 1 • RSA Cryptography Standard Version 2.0 onwards (1998) RSA Encryption Standard Version 1.5 (1993) Códigos y Criptografía Francisco Rodríguez Henríquez PKCS 1 • Specifies how to use the RSA algorithm securely for encryption and signature • Why do we need this? – Padding for encryption – Different schemes for signature Códigos y Criptografía Francisco Rodríguez Henríquez PKCS 1 • Chosen ciphertext attack based on multiplicative property of RSA • Attacker wishes to decrypt c Choose r, compute c’ = c⋅ re mod n Get victim to decrypt c’ giving cd ⋅ r mod n cd ⋅ r ⋅ r-1 mod n = cd mod n • Padding destroys multiplicative property Códigos y Criptografía Francisco Rodríguez Henríquez RSA: Key Generation Códigos y Criptografía Francisco Rodríguez Henríquez RSA: Encryption, Decryption Códigos y Criptografía Francisco Rodríguez Henríquez RSA: An Example Códigos y Criptografía Francisco Rodríguez Henríquez RSA encryption is deterministic We can check whether M is the message of C by C=Me mod n. Attack example: C = (PIN)e mod n, where PIN is 4-digit number. We can find M by a brute force attack within several 10 seconds. => We need a semantically secure cryptosystem! 2 Semantically secure: For two messages M0, M1, and C = Mb mod n, attackers can not guess whether C is encryption of Mb (b=0,1). An easy way is to pad M with random integer R like M||R, but no security proof! Códigos y Criptografía Francisco Rodríguez Henríquez Chosen Ciphertext Attack (CCA) Decryption oracle ciphertext C d Information based on C,d An attack example: (0) We assume the decryption oracle computes Ad mod n for a request. (1) Attacker computes A = ReC mod n for a random R in Zn, and sends A to the decryption oracle. (2) Decryption oracle computes B = Ad mod n and send B back to the attacker. (3) The attacker computes B/R = M mod n and get the message M. There are several models, which are secure against the chosen ciphertext attack Códigos y Criptografía Francisco Rodríguez Henríquez Side Channel Attacks Algorithm Binary exponentiation Input: a in G, exponent
Load more

Recommended publications
  • On the NIST Lightweight Cryptography Standardization
    On the NIST Lightweight Cryptography Standardization Meltem S¨onmez Turan NIST Lightweight Cryptography Team ECC 2019: 23rd Workshop on Elliptic Curve Cryptography December 2, 2019 Outline • NIST's Cryptography Standards • Overview - Lightweight Cryptography • NIST Lightweight Cryptography Standardization Process • Announcements 1 NIST's Cryptography Standards National Institute of Standards and Technology • Non-regulatory federal agency within U.S. Department of Commerce. • Founded in 1901, known as the National Bureau of Standards (NBS) prior to 1988. • Headquarters in Gaithersburg, Maryland, and laboratories in Boulder, Colorado. • Employs around 6,000 employees and associates. NIST's Mission to promote U.S. innovation and industrial competitiveness by advancing measurement science, standards, and technology in ways that enhance economic security and improve our quality of life. 2 NIST Organization Chart Laboratory Programs Computer Security Division • Center for Nanoscale Science and • Cryptographic Technology Technology • Secure Systems and Applications • Communications Technology Lab. • Security Outreach and Integration • Engineering Lab. • Security Components and Mechanisms • Information Technology Lab. • Security Test, Validation and • Material Measurement Lab. Measurements • NIST Center for Neutron Research • Physical Measurement Lab. Information Technology Lab. • Advanced Network Technologies • Applied and Computational Mathematics • Applied Cybersecurity • Computer Security • Information Access • Software and Systems • Statistical
    [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]
  • Key Derivation Functions and Their GPU Implementation
    MASARYK UNIVERSITY FACULTY}w¡¢£¤¥¦§¨ OF I !"#$%&'()+,-./012345<yA|NFORMATICS Key derivation functions and their GPU implementation BACHELOR’S THESIS Ondrej Mosnáˇcek Brno, Spring 2015 This work is licensed under a Creative Commons Attribution- NonCommercial-ShareAlike 4.0 International License. https://creativecommons.org/licenses/by-nc-sa/4.0/ cbna ii Declaration Hereby I declare, that this paper is my original authorial work, which I have worked out by my own. All sources, references and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source. Ondrej Mosnáˇcek Advisor: Ing. Milan Brož iii Acknowledgement I would like to thank my supervisor for his guidance and support, and also for his extensive contributions to the Cryptsetup open- source project. Next, I would like to thank my family for their support and pa- tience and also to my friends who were falling behind schedule just like me and thus helped me not to panic. Last but not least, access to computing and storage facilities owned by parties and projects contributing to the National Grid In- frastructure MetaCentrum, provided under the programme “Projects of Large Infrastructure for Research, Development, and Innovations” (LM2010005), is also greatly appreciated. v Abstract Key derivation functions are a key element of many cryptographic applications. Password-based key derivation functions are designed specifically to derive cryptographic keys from low-entropy sources (such as passwords or passphrases) and to counter brute-force and dictionary attacks. However, the most widely adopted standard for password-based key derivation, PBKDF2, as implemented in most applications, is highly susceptible to attacks using Graphics Process- ing Units (GPUs).
    [Show full text]
  • Guidelines on Cryptographic Algorithms Usage and Key Management
    EPC342-08 Version 7.0 4 November 2017 [X] Public – [ ] Internal Use – [ ] Confidential – [ ] Strictest Confidence Distribution: Publicly available GUIDELINES ON CRYPTOGRAPHIC ALGORITHMS USAGE AND KEY MANAGEMENT Abstract This document defines guidelines on cryptographic algorithms usage and key management. Document Reference EPC342-08 Issue Version 7.0 Date of Issue 22 November 2017 Reason for Issue Maintenance of document Produced by EPC Authorised by EPC Document History This document was first produced by ECBS as TR 406, with its latest ECBS version published in September 2005. The document has been handed over to the EPC which is responsible for its yearly maintenance. DISCLAIMER: Whilst the European Payments Council (EPC) has used its best endeavours to make sure that all the information, data, documentation (including references) and other material in the present document are accurate and complete, it does not accept liability for any errors or omissions. EPC will not be liable for any claims or losses of any nature arising directly or indirectly from use of the information, data, documentation or other material in the present document. Conseil Européen des Paiements AISBL– Cours Saint-Michel 30A – B 1040 Brussels Tel: +32 2 733 35 33 – Fax: +32 2 736 49 88 Enterprise N° 0873.268.927 – www.epc-cep.eu – [email protected] © 2016 Copyright European Payments Council (EPC) AISBL: Reproduction for non-commercial purposes is authorised, with acknowledgement of the source Table of Content MANAGEMENT SUMMARY ............................................................. 5 1 INTRODUCTION .................................................................... 7 1.1 Scope of the document ...................................................... 7 1.2 Document structure .......................................................... 7 1.3 Recommendations ............................................................ 8 1.4 Implementation best practices .........................................
    [Show full text]
  • Public Key Cryptography Public Key Cryptography
    Public Key Cryptography Public Key Cryptography • Symmetric Key: – Same key used for encryption and decrypiton – Same key used for message integrity and validation • Public-Key Cryptography – Use one key to encrypt or sign messages – Use another key to decrypt or validate messages • Keys – Public key known to the world and used to send you a message – Only your private key can decrypt the message Public Key Private Key Plaintext Ciphertext Plaintext Encryption Decryption ENTS 689i | Network Immunity | Fall 2008 Lecture 2 Public Key Cryptography • Motivations – In symmetric key cryptography, a key was needed between every pair of users wishing to securely communicate • O(n2) keys – Problem of establishing a key with remote person with whom you wish to communicate • Advantages to Public Key Cryptography – Key distribution much easier: everyone can known your public key as long as your private key remains secret – Fewer keys needed • O(n) keys • Disadvantages – Slow, often up to 1000x slower than symmetric-key cryptography ENTS 689i | Network Immunity | Fall 2008 Lecture 2 Cryptography and Complexity • Three classes of complexity: – P: solvable in polynomial time, O(nc) – NP: nondeterministic solutions in polynomial time, deterministic solutions in exponential time – EXP: exponential solutions, O(cn) • Cryptographic problems should be: increasing P – Encryption should be P difficult – Decryption should be P with key NP – Decryption should be NP for attacker EXP • Need problems where complexity of solution depends on knowledge of a key ENTS
    [Show full text]
  • BIP Note 18 Binding Implementation Practice (BIP) Note
    Superannuation Transaction Network BIP Note 18 Binding Implementation Practice (BIP) Note Title: TLS Configuration and Cryptography Date: 10 Nov 201 5 Standards Version: 1.0 Scope [ x ] transport layer Status: [ ] Draft [ ] message payload [x ] Ratified [ x ] security Live Date: 25 February 2016 On this date this BIP note will be binding on all participants 1. Change This document sets requirements for SSL/TLS configuration within the STN. 2. Reason for Change Secure message exchange within the STN is fully dependent on HTTPS protocol (HTTP over TLS). SSL 3.0 has existed for at least 15 years. It was superseded by TLS 1.0 which was in turn replaced by TLS 1.1 and TLS 1.2. Cryptography standards used in SSL and early versions of TLS are now deprecated and do not provide sufficient level of security. Clause 6.6(a) of Superannuation Data and Gateway Services Standards for Gateway Operators transaction within the Superannuation Transaction Network document requires STN gateways to use “a minimum level of protection of Transport Layer Security (TLS) of version 1.1 or above”. Majority of the STN gateways supports TLS versions 1.0 through 1.2 at the server side (some gateways still support SSL 3.0). However, only a few gateways support modern TLS versions at the client side resulting majority of transactions within the STN being sent through TLS 1.0 channel. In order to eliminate vulnerabilities of the obsolete SSL/TLS protocols, SSL 3.0 and TLS 1.0 must be completely disabled. Mozilla Foundation recommends not to include TLS 1.0 into “Modern” configuration set for web- servers and limits its usage only for backward-compatibility purposes (given that STN is P2P network with a limited number of participants, backward-compatibility issue is not relevant).
    [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]
  • The Double Ratchet Algorithm
    The Double Ratchet Algorithm Trevor Perrin (editor) Moxie Marlinspike Revision 1, 2016-11-20 Contents 1. Introduction 3 2. Overview 3 2.1. KDF chains . 3 2.2. Symmetric-key ratchet . 5 2.3. Diffie-Hellman ratchet . 6 2.4. Double Ratchet . 13 2.6. Out-of-order messages . 17 3. Double Ratchet 18 3.1. External functions . 18 3.2. State variables . 19 3.3. Initialization . 19 3.4. Encrypting messages . 20 3.5. Decrypting messages . 20 4. Double Ratchet with header encryption 22 4.1. Overview . 22 4.2. External functions . 26 4.3. State variables . 26 4.4. Initialization . 26 4.5. Encrypting messages . 27 4.6. Decrypting messages . 28 5. Implementation considerations 29 5.1. Integration with X3DH . 29 5.2. Recommended cryptographic algorithms . 30 6. Security considerations 31 6.1. Secure deletion . 31 6.2. Recovery from compromise . 31 6.3. Cryptanalysis and ratchet public keys . 31 1 6.4. Deletion of skipped message keys . 32 6.5. Deferring new ratchet key generation . 32 6.6. Truncating authentication tags . 32 6.7. Implementation fingerprinting . 32 7. IPR 33 8. Acknowledgements 33 9. References 33 2 1. Introduction The Double Ratchet algorithm is used by two parties to exchange encrypted messages based on a shared secret key. Typically the parties will use some key agreement protocol (such as X3DH [1]) to agree on the shared secret key. Following this, the parties will use the Double Ratchet to send and receive encrypted messages. The parties derive new keys for every Double Ratchet message so that earlier keys cannot be calculated from later ones.
    [Show full text]
  • Study on the Use of Cryptographic Techniques in Europe
    Study on the use of cryptographic techniques in Europe [Deliverable – 2011-12-19] Updated on 2012-04-20 II Study on the use of cryptographic techniques in Europe Contributors to this report Authors: Edward Hamilton and Mischa Kriens of Analysys Mason Ltd Rodica Tirtea of ENISA Supervisor of the project: Rodica Tirtea of ENISA ENISA staff involved in the project: Demosthenes Ikonomou, Stefan Schiffner Agreements or Acknowledgements ENISA would like to thank the contributors and reviewers of this study. Study on the use of cryptographic techniques in Europe III About ENISA The European Network and Information Security Agency (ENISA) is a centre of network and information security expertise for the EU, its member states, the private sector and Europe’s citizens. ENISA works with these groups to develop advice and recommendations on good practice in information security. It assists EU member states in implementing relevant EU leg- islation and works to improve the resilience of Europe’s critical information infrastructure and networks. ENISA seeks to enhance existing expertise in EU member states by supporting the development of cross-border communities committed to improving network and information security throughout the EU. More information about ENISA and its work can be found at www.enisa.europa.eu. Contact details For contacting ENISA or for general enquiries on cryptography, please use the following de- tails: E-mail: [email protected] Internet: http://www.enisa.europa.eu Legal notice Notice must be taken that this publication represents the views and interpretations of the au- thors and editors, unless stated otherwise. This publication should not be construed to be a legal action of ENISA or the ENISA bodies unless adopted pursuant to the ENISA Regulation (EC) No 460/2004 as lastly amended by Regulation (EU) No 580/2011.
    [Show full text]
  • On the Security of the PKCS#1 V1.5 Signature Scheme
    On the Security of the PKCS#1 v1.5 Signature Scheme Tibor Jager1 Saqib A. Kakvi1 Alexander May2 September 10, 2018 1Department of Computer Science, Universitat¨ Paderborn ftibor.jager,[email protected] 2Hortz Gortz¨ Institute, Ruhr Universitat¨ Bochum [email protected] Abstract The RSA PKCS#1 v1.5 signature algorithm is the most widely used digital signature scheme in practice. Its two main strengths are its extreme simplicity, which makes it very easy to implement, and that verification of signatures is significantly faster than for DSA or ECDSA. Despite the huge practical importance of RSA PKCS#1 v1.5 signatures, providing formal evidence for their security based on plausible cryptographic hardness assumptions has turned out to be very difficult. Therefore the most recent version of PKCS#1 (RFC 8017) even recommends a replacement the more complex and less efficient scheme RSA-PSS, as it is provably secure and therefore considered more robust. The main obstacle is that RSA PKCS#1 v1.5 signatures use a deterministic padding scheme, which makes standard proof techniques not applicable. We introduce a new technique that enables the first security proof for RSA-PKCS#1 v1.5 signatures. We prove full existential unforgeability against adaptive chosen-message attacks (EUF-CMA) under the standard RSA assumption. Furthermore, we give a tight proof under the Phi-Hiding assumption. These proofs are in the random oracle model and the parameters deviate slightly from the standard use, because we require a larger output length of the hash function. However, we also show how RSA-PKCS#1 v1.5 signatures can be instantiated in practice such that our security proofs apply.
    [Show full text]
  • SMPTE Standards Transition Issues for NIST/FIPS Requirements V1.1
    SMPTE Standards Transition Issues for NIST/FIPS Requirements v1.1 2010.8.23 DRM inside, Taehyun Kim ETRI, Kisoon Yoon Contents 1 Introduction NIST (National Institute of Standards and Technology) published second draft special document 1 (SP 800-131, Recommendation for the Transitioning of Cryptographic Algorithms and Key Length) [28] in June, 2010. It includes transition recommendations through 9 items associated with the use of cryptography, whose purpose is to keep the security level being still higher as the more powerful computing techniques are available. The 9 items described in the SP 800-131 are: • Encryption (Sec. 2) • Digital Signature (Sec. 3) • Random Number Generation (Sec. 4) • Key Agreement Using Diffie-Hellman and MQV (Sec. 5) • Key Agreement and Key Transport Using RSA (Sec. 6) • Key Wrapping (Sec. 7) • GDIO Protocol (Sec 8.) • Deriving Additional Keys (Sec. 8) • Hash Function (Sec. 9) • Message Authentication Codes (Sec. 10) Currently, SMPTE documents2 refer to the FIPS (Federal Information Processing Standard) to use its cryptographic algorithms which are Secure Hash Standard (FIPS 180-1, 180-2) [1][2], Digital Signature Standard (FIPS 186-2, Jan. 2000) [4], Random Number Generation (FIPS 186-2, Jan. 2000), Advanced Encryption Standard (FIPS 197, Nov. 2001) [6] and Keyed-Hash Message Authentication Code (FIPS 198-1, Apr. 2002) [7]. As upgrade version of the FIPSs and new recommendation are published from the NIST, we need to consider impacts on the SMPTE standard documents. This report summarizes SMPTE documents in cryptographic point of view and new NIST requirements related to the cryptographic algorithm and strength to which SMPTE standards are referring.
    [Show full text]
  • Nist Sp 800-77 Rev. 1 Guide to Ipsec Vpns
    NIST Special Publication 800-77 Revision 1 Guide to IPsec VPNs Elaine Barker Quynh Dang Sheila Frankel Karen Scarfone Paul Wouters This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-77r1 C O M P U T E R S E C U R I T Y NIST Special Publication 800-77 Revision 1 Guide to IPsec VPNs Elaine Barker Quynh Dang Sheila Frankel* Computer Security Division Information Technology Laboratory Karen Scarfone Scarfone Cybersecurity Clifton, VA Paul Wouters Red Hat Toronto, ON, Canada *Former employee; all work for this publication was done while at NIST This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-77r1 June 2020 U.S. Department of Commerce Wilbur L. Ross, Jr., Secretary National Institute of Standards and Technology Walter Copan, NIST Director and Under Secretary of Commerce for Standards and Technology Authority This publication has been developed by NIST in accordance with its statutory responsibilities under the Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3551 et seq., Public Law (P.L.) 113-283. NIST is responsible for developing information security standards and guidelines, including minimum requirements for federal information systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130. Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding on federal agencies by the Secretary of Commerce under statutory authority.
    [Show full text]