CRYPTREC Activities and a Revision of the E-Government Recommended Ciphers List

Total Page:16

File Type:pdf, Size:1020Kb

CRYPTREC Activities and a Revision of the E-Government Recommended Ciphers List Title:J2016S-07-03.indd p203 2017/03/15/ 水 09:19:08 7 Security Fundamental Technologies 7-3 CRYPTREC Activities and a Revision of the e-Government Recommended Ciphers List Takashi KUROKAWA, Sachiko KANAMORI, Ryo NOJIMA, Miyako OHKUBO, and Shiho MORIAI In this paper, we show activities of CRYPTREC carried out by the security fundamentals laboratory between fiscal year 2011 and fiscal year 2015. We focus on “CRYPTREC Ciphers List” revised in fiscal year 2012 which has been issued as the “e-Government Recommended Ciphers List” since fiscal year 2002. We also note an outline of the present activities. 1 Introduction nology expected to be used in e-Government. CRYPTREC is an acronym for Cryptography Research Cryptographic Module Committee*2 and Evaluation Committees. This project evaluates and This committee creates security requirements and test- monitors the security of cryptographic technology, and ing requirements for cryptographic modules that comply surveys and studies appropriate implementation methods with the e-Government Recommended Ciphers, and sur- and operation methods for cryptographic technology. The veys and studies evaluations of implementation aspects for work to amend the e-Government Recommended Ciphers amendment of the e-Government Recommended Ciphers List*1 started during the 2nd Medium-term Plan was done List. in both the 2nd and 3rd Medium-term Plan. After the amending of the e-Government Recommended Ciphers Cryptographic Operation Committee*2 List, CRYPTREC’s organization was changed, and the This committee has been set up to create the new e- content of its activities also changed. This paper first -de Government Recommended Ciphers List (hereinafter re- scribes CRYPTEC’s organization in Section 2. Next, ferred to as the CRYPTREC Ciphers List*3), and it conducts Section 3 describes the amendment of the e-Government surveys and studies on the appropriate operation of the Recommended Ciphers List. Section 4 describes the ac- tivities in the 3rd Medium-term Plan. Finally, future issues are discussed. Former CRYPTREC Organization Advisory Board for Cryptographic Technology (Secretariat: MIC, METI) 2 Organization of CRYPTEC Cryptographic Scheme Cryptographic Modules Cryptographic Operation Committee Committee Committee (Secretariat: NICT, IPA) (Secretariat: NICT, IPA) (Secretariat: NICT, IPA) (1) Monitoring e-Government (1) Investigation/Examination of (1) Investigation/examination for an Recommended Ciphers cipher implementation techniques appropriate operation of e- 2.1 Organization from Fiscal 2009 to Fiscal 2012 (2) Investigation/examination to keep the and attacks for cryptographic Government recommended ciphers security and the reliability of the modules from the viewpoint of system e-Government Recommended Ciphers (2) Evaluation of cipher implementation designers and system providers Towards amendment of the e-Government (3) Security Evaluation of ciphers for the techniques for the revision of the revision of the CRYPTREC ciphers list CRYPTREC ciphers list Cryptographic Techniques Side Channel Security Recommended Ciphers List, CRYPTEC was reorganized Study WG WG starting in fiscal 2009, as shown inFig. 1. The activities of the Cryptographic Scheme Committee mainly handled by the Security Fundamentals Laboratory are described below. FFig. 1 Former CRYPTREC organization chart (from fiscal 2009 to fiscal 2012) Cryptographic Scheme Committee *1 CRYPTEC’s activities during the 2nd Medium-term Plan (from fiscal 2006 to This committee monitors the security of cryptographic fiscal 2010) mainly handled by the Security Fundamental Laboratory were de- technology included in the e-Government Recommended scribed in [1][4]–[9]. *2 The Information-technology Promotion Agency, Japan was mainly in charge of Ciphers List, evaluates the security of cryptographic tech- this work. nology for amendment of the e-Government Recommended *3 It had a tentative name until before the fiscal 2012 amendment, but at the time of the fiscal 2012 amendment, it was formally named the “CRYPTREC Ciphers Ciphers List, and surveys and studies cryptographic tech- L i s t .” 203 Title:J2016S-07-03.indd p204 2017/03/15/ 水 09:19:08 7 Security Fundamental Technologies CRYPTREC Ciphers List for use in e-Government systems, tations of cryptographic technology etc., from the viewpoints of IT system designers and op- (2) Surveys new-generation cryptography (lightweight erators. cryptography, post-quantum cryptography, etc.) (3) Surveys secure methods of using cryptographic 2.2 Organization from Fiscal 2013 to Fiscal 2015 technology (maintenance of technical guidelines, After the amendment of the e-Government academic surveys and publications on security, etc.) Recommended Ciphers List, it was reorganized in fiscal 2013 as shown in Fig. 2. The activities of the Cryptographic Technology Evaluation Committee mainly handled by the Security Fundamentals Laboratory are described below. CRYPTREC Organization Advisory Board for Cryptographic technology (Secretariat: MIC, METI) Cryptographic Technology Evaluation Committee Cryptographic Technology Cryptographic Technology This committee was established in fiscal 2013. It took Evaluation Committee Promotion Committee (Secretariat: NICT, IPA) (Secretariat: NICT, IPA) over the activities which were handled by the Cryptographic (1) Monitoring and evaluation of the security and (1) Research on the promotion of cryptographic implementation properties of the cryptographic technologies and the strengthening of IT security technology industries (2) Research on new-generation cryptographic (2) Research on the utilization status of cryptographic Scheme Committee from fiscal 2009 to fiscal 2012, and part technology technologies and research of their promotion strategy (3) Research on secure utilization of cryptographic (3) Research on the strategy of cryptographic policy from of the activities of the Cryptographic Module Committee. technology mid-and-long term viewpoints Cryptanalysis Evaluation WG, Operational Guideline WG, Specifically, it surveys and studies the matters described Lightweight Cryptography WG Standardization Promotion WG below in (1) to (3). FFig. 2 CRYPTREC organization chart (from fiscal 2013 to fiscal (1) Monitors and evaluates the security and implemen- 2015) TTable 1 List of dates for committee meetings held during 3rd Medium- to Long-Term Plan (1) Fiscal 2011 Fiscal 2012 Cryptographic Scheme First August 5, 2011 First June 8, 2012 Committee Second February 24, 2012 Second July 24, 2012 Third (Joint) March 9, 2012 Third October 9, 2012 Fourth March 5, 2013 Fifth (Joint) March 26, 2013 Cryptanalysis Evaluation First November 14, 2011 First August 29, 2012 Working Group (List Guide) Second January 24, 2012 Second December 20, 2012 Third (Joint) March 9, 2012 Third February 25, 2013 Fourth (Joint) March 26, 2013 Cryptanalysis Evaluation First October 6, 2011 First December 21, 2012 Working Group (Computer Second December 21, 2011 Second February 22, 2013 Performance Evaluation) Third (Joint) March 9, 2012 Third (Joint) March 26, 2013 Cryptographic Module First September 12, 2011 First July 5, 2012 Committee Second December 19, 2011 Second September 4, 2012 Third February 13, 2012 Third October 9, 2012 Fourth (Joint) March 9, 2012 Fourth March 14, 2013 Fifth (Joint) March 26, 2013 Side Channel Security Working First December 19, 2011 First July 5, 2012 Group Second February 13, 2012 Second March 14, 2013 Third (Joint) March 9, 2012 Third (Joint) March 26, 2013 Cryptographic Operation First September 21, 2011 First June 8, 2012 Committee Second November 18, 2011 Second July 25, 2012 Third January 27, 2012 Third October 4, 2012 Fourth February 24, 2012 Fourth March 1, 2013 Fifth (Joint) March 9, 2012 Fifth (Joint) March 26, 2013 *Usage Survey September 24, 2012 Report Meeting *Joint Committee (Committee November 15, 2012 Chairs Meeting) 204 Journal of the National Institute of Information and Communications Technology Vol. 63 No. 2 (2016) Title:J2016S-07-03.indd p205 2017/03/15/ 水 09:19:08 7-3 CRYPTREC Activities and a Revision of the e-Government Recommended Ciphers List Cryptographic Technology Promotion Committee 3 Amendment of e-Government This committee was established in fiscal 2013. It took Recommended Ciphers List (in the 3rd over the activities that were done in the Cryptographic Medium- to Long-term Plan) Operation Committee from fiscal 2009 to fiscal 2012, and part of the activities done in the Cryptographic Module During the 2nd Medium term Plan period, CRYPTEC Committee. Specifically, it surveys and studies the matters mainly did the following: described below in (1) to (3) (fiscal 2013 and fiscal 2014). (1) The draft outline for the revision of e-Government (1) Studies to support wider use of cryptography, and Recommended Ciphers List*4 strengthen the competitiveness of the security in- (2) Cryptographic techniques submissions for the revi- dustry sion of e-Government Recommended Ciphers List (2) Surveys the situation of cryptographic technology (fiscal 2009) use, studies necessary countermeasures, etc. (3) First security evaluations (3) Studies initiatives in cryptography policy, from Activities in the 3rd Medium- to Long-term Plan are medium and long term perspectives described below. Also, since fiscal 2015, aiming to contribute to the se- curity of IT systems overall, it started an initiative for 3.1 Second security evaluations surveys and studies for maintenance and creating opera- In the second evaluations, we continued an overall tions management. evaluation of submitted cryptographic
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]
  • A Quantitative Study of Advanced Encryption Standard Performance
    United States Military Academy USMA Digital Commons West Point ETD 12-2018 A Quantitative Study of Advanced Encryption Standard Performance as it Relates to Cryptographic Attack Feasibility Daniel Hawthorne United States Military Academy, [email protected] Follow this and additional works at: https://digitalcommons.usmalibrary.org/faculty_etd Part of the Information Security Commons Recommended Citation Hawthorne, Daniel, "A Quantitative Study of Advanced Encryption Standard Performance as it Relates to Cryptographic Attack Feasibility" (2018). West Point ETD. 9. https://digitalcommons.usmalibrary.org/faculty_etd/9 This Doctoral Dissertation is brought to you for free and open access by USMA Digital Commons. It has been accepted for inclusion in West Point ETD by an authorized administrator of USMA Digital Commons. For more information, please contact [email protected]. A QUANTITATIVE STUDY OF ADVANCED ENCRYPTION STANDARD PERFORMANCE AS IT RELATES TO CRYPTOGRAPHIC ATTACK FEASIBILITY A Dissertation Presented in Partial Fulfillment of the Requirements for the Degree of Doctor of Computer Science By Daniel Stephen Hawthorne Colorado Technical University December, 2018 Committee Dr. Richard Livingood, Ph.D., Chair Dr. Kelly Hughes, DCS, Committee Member Dr. James O. Webb, Ph.D., Committee Member December 17, 2018 © Daniel Stephen Hawthorne, 2018 1 Abstract The advanced encryption standard (AES) is the premier symmetric key cryptosystem in use today. Given its prevalence, the security provided by AES is of utmost importance. Technology is advancing at an incredible rate, in both capability and popularity, much faster than its rate of advancement in the late 1990s when AES was selected as the replacement standard for DES. Although the literature surrounding AES is robust, most studies fall into either theoretical or practical yet infeasible.
    [Show full text]
  • Security Evaluation of Stream Cipher Enocoro-128V2
    Security Evaluation of Stream Cipher Enocoro-128v2 Hell, Martin; Johansson, Thomas 2010 Link to publication Citation for published version (APA): Hell, M., & Johansson, T. (2010). Security Evaluation of Stream Cipher Enocoro-128v2. CRYPTREC Technical Report. Total number of authors: 2 General rights Unless other specific re-use rights are stated the following general rights apply: Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights. • Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain • You may freely distribute the URL identifying the publication in the public portal Read more about Creative commons licenses: https://creativecommons.org/licenses/ Take down policy If you believe that this document breaches copyright please contact us providing details, and we will remove access to the work immediately and investigate your claim. LUND UNIVERSITY PO Box 117 221 00 Lund +46 46-222 00 00 Security Evaluation of Stream Cipher Enocoro-128v2 Martin Hell and Thomas Johansson Abstract. This report presents a security evaluation of the Enocoro- 128v2 stream cipher. Enocoro-128v2 was proposed in 2010 and is a mem- ber of the Enocoro family of stream ciphers. This evaluation examines several different attacks applied to the Enocoro-128v2 design. No attack better than exhaustive key search has been found.
    [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]
  • Reconsidering the Security Bound of AES-GCM-SIV
    Background on AES-GCM-SIV Fixing the Security Bound Improving Key Derivation Final Remarks Reconsidering the Security Bound of AES-GCM-SIV Tetsu Iwata1 and Yannick Seurin2 1Nagoya University, Japan 2ANSSI, France March 7, 2018 — FSE 2018 T. Iwata and Y. Seurin Reconsidering AES-GCM-SIV’s Security FSE 2018 1 / 26 Background on AES-GCM-SIV Fixing the Security Bound Improving Key Derivation Final Remarks Summary of the contribution • we reconsider the security of the AEAD scheme AES-GCM-SIV designed by Gueron, Langley, and Lindell • we identify flaws in the designers’ security analysis and propose a new security proof • our findings leads to significantly reduced security claims, especially for long messages • we propose a simple modification to the scheme (key derivation function) improving security without efficiency loss T. Iwata and Y. Seurin Reconsidering AES-GCM-SIV’s Security FSE 2018 2 / 26 Background on AES-GCM-SIV Fixing the Security Bound Improving Key Derivation Final Remarks Summary of the contribution • we reconsider the security of the AEAD scheme AES-GCM-SIV designed by Gueron, Langley, and Lindell • we identify flaws in the designers’ security analysis and propose a new security proof • our findings leads to significantly reduced security claims, especially for long messages • we propose a simple modification to the scheme (key derivation function) improving security without efficiency loss T. Iwata and Y. Seurin Reconsidering AES-GCM-SIV’s Security FSE 2018 2 / 26 Background on AES-GCM-SIV Fixing the Security Bound Improving Key Derivation Final Remarks Summary of the contribution • we reconsider the security of the AEAD scheme AES-GCM-SIV designed by Gueron, Langley, and Lindell • we identify flaws in the designers’ security analysis and propose a new security proof • our findings leads to significantly reduced security claims, especially for long messages • we propose a simple modification to the scheme (key derivation function) improving security without efficiency loss T.
    [Show full text]
  • Analysis of Selected Block Cipher Modes for Authenticated Encryption
    Analysis of Selected Block Cipher Modes for Authenticated Encryption by Hassan Musallam Ahmed Qahur Al Mahri Bachelor of Engineering (Computer Systems and Networks) (Sultan Qaboos University) – 2007 Thesis submitted in fulfilment of the requirement for the degree of Doctor of Philosophy School of Electrical Engineering and Computer Science Science and Engineering Faculty Queensland University of Technology 2018 Keywords Authenticated encryption, AE, AEAD, ++AE, AEZ, block cipher, CAESAR, confidentiality, COPA, differential fault analysis, differential power analysis, ElmD, fault attack, forgery attack, integrity assurance, leakage resilience, modes of op- eration, OCB, OTR, SHELL, side channel attack, statistical fault analysis, sym- metric encryption, tweakable block cipher, XE, XEX. i ii Abstract Cryptography assures information security through different functionalities, es- pecially confidentiality and integrity assurance. According to Menezes et al. [1], confidentiality means the process of assuring that no one could interpret infor- mation, except authorised parties, while data integrity is an assurance that any unauthorised alterations to a message content will be detected. One possible ap- proach to ensure confidentiality and data integrity is to use two different schemes where one scheme provides confidentiality and the other provides integrity as- surance. A more compact approach is to use schemes, called Authenticated En- cryption (AE) schemes, that simultaneously provide confidentiality and integrity assurance for a message. AE can be constructed using different mechanisms, and the most common construction is to use block cipher modes, which is our focus in this thesis. AE schemes have been used in a wide range of applications, and defined by standardisation organizations. The National Institute of Standards and Technol- ogy (NIST) recommended two AE block cipher modes CCM [2] and GCM [3].
    [Show full text]
  • Constructing Low-Weight Dth-Order Correlation-Immune Boolean Functions Through the Fourier-Hadamard Transform Claude Carlet and Xi Chen*
    1 Constructing low-weight dth-order correlation-immune Boolean functions through the Fourier-Hadamard transform Claude Carlet and Xi Chen* Abstract The correlation immunity of Boolean functions is a property related to cryptography, to error correcting codes, to orthogonal arrays (in combinatorics, which was also a domain of interest of S. Golomb) and in a slightly looser way to sequences. Correlation-immune Boolean functions (in short, CI functions) have the property of keeping the same output distribution when some input variables are fixed. They have been widely used as combiners in stream ciphers to allow resistance to the Siegenthaler correlation attack. Very recently, a new use of CI functions has appeared in the framework of side channel attacks (SCA). To reduce the cost overhead of counter-measures to SCA, CI functions need to have low Hamming weights. This actually poses new challenges since the known constructions which are based on properties of the Walsh-Hadamard transform, do not allow to build unbalanced CI functions. In this paper, we propose constructions of low-weight dth-order CI functions based on the Fourier- Hadamard transform, while the known constructions of resilient functions are based on the Walsh-Hadamard transform. We first prove a simple but powerful result, which makes that one only need to consider the case where d is odd in further research. Then we investigate how constructing low Hamming weight CI functions through the Fourier-Hadamard transform (which behaves well with respect to the multiplication of Boolean functions). We use the characterization of CI functions by the Fourier-Hadamard transform and introduce a related general construction of CI functions by multiplication.
    [Show full text]
  • Fair and Efficient Hardware Benchmarking of Candidates In
    Fair and Efficient Hardware Benchmarking of Candidates in Cryptographic Contests Kris Gaj CERG George Mason University Partially supported by NSF under grant no. 1314540 Designs & results for this talk contributed by “Ice” Homsirikamol Farnoud Farahmand Ahmed Ferozpuri Will Diehl Marcin Rogawski Panasayya Yalla Cryptographic Standard Contests IX.1997 X.2000 AES 15 block ciphers → 1 winner NESSIE I.2000 XII.2002 CRYPTREC XI.2004 IV.2008 34 stream 4 HW winners eSTREAM ciphers → + 4 SW winners X.2007 X.2012 51 hash functions → 1 winner SHA-3 I.2013 TBD 57 authenticated ciphers → multiple winners CAESAR 97 98 99 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 time Evaluation Criteria in Cryptographic Contests Security Software Efficiency Hardware Efficiency µProcessors µControllers FPGAs ASICs Flexibility Simplicity Licensing 4 AES Contest 1997-2000 Final Round Speed in FPGAs Votes at the AES 3 conference GMU results Hardware results matter! 5 Throughput vs. Area Normalized to Results for SHA-256 and Averaged over 11 FPGA Families – 256-bit variants Overall Normalized Throughput Early Leader Overall Normalized Area 6 SHA-3 finalists in high-performance FPGA families 0.25 0.35 0.50 0.79 1.00 1.41 2.00 2.83 4.00 7 FPGA Evaluations – From AES to SHA-3 AES eSTREAM SHA-3 Design Primary optimization Throughput Area Throughput/ target Throughput/ Area Area Multiple architectures No Yes Yes Embedded resources No No Yes Benchmarking Multiple FPGA families No No Yes Specialized tools No No Yes Experimental results No No Yes Reproducibility Availability
    [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]
  • Ohio IT Standard ITS-SEC-01 Data Encryption and Cryptography
    Statewide Standard State of Ohio IT Standard Standard Number: Title: ITS-SEC-01 Data Encryption and Cryptography Effective Date: Issued By: 03/12/2021 Ervan D. Rodgers II, Assistant Director/State Chief Information Officer Office of Information Technology Ohio Department of Administrative Services Version Identifier: Published By: 2.0 Investment and Governance Division Ohio Office of Information Technology 1.0 Purpose This state IT standard defines the minimum requirements for cryptographic algorithms that are cryptographically strong and are used in security services that protect at-risk or sensitive data as defined and required by agency or State policy, standard or rule. This standard does not classify data elements; does not define the security schemes and mechanisms for devices such as tape backup systems, storage systems, mobile computers or removable media; and does not identify or approve secure transmission protocols that may be used to implement security requirements. 2.0 Scope Pursuant to Ohio Administrative Policy IT-01, “Authority of the State Chief Information Officer to Establish Ohio IT Policy,” this state IT standard is applicable to every organized body, office, or agency established by the laws of the state for the exercise of any function of state government except for those specifically exempted. 3.0 Background The National Institute for Science and Technology (NIST) conducts extensive research and development in cryptography techniques. Their publications include technical standards for data encryption, digital signature and message authentication as well as guidelines for implementing information security and managing cryptographic keys. These standards and guidelines have been mandated for use in federal agencies and adopted by state governments and private enterprises.
    [Show full text]
  • FIPS 140-2 Non-Proprietary Security Policy Oracle Linux 7 NSS
    FIPS 140-2 Non-Proprietary Security Policy Oracle Linux 7 NSS Cryptographic Module FIPS 140-2 Level 1 Validation Software Version: R7-4.0.0 Date: January 22nd, 2020 Document Version 2.3 © Oracle Corporation This document may be reproduced whole and intact including the Copyright notice. Title: Oracle Linux 7 NSS Cryptographic Module Security Policy Date: January 22nd, 2020 Author: Oracle Security Evaluations – Global Product Security Contributing Authors: Oracle Linux Engineering Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. Worldwide Inquiries: Phone: +1.650.506.7000 Fax: +1.650.506.7200 oracle.com Copyright © 2020, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only and the contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. Oracle specifically disclaim any liability with respect to this document and no contractual obligations are formed either directly or indirectly by this document. This document may reproduced or distributed whole and intact including this copyright notice. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners. Oracle Linux 7 NSS Cryptographic Module Security Policy i TABLE OF CONTENTS Section Title
    [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]