Reference Guide

ManualsBrandsDell ManualsBSAFEBSAFE Crypto-C Micro Edition

Security Policy

03.07.19

RSA BSAFE

Crypto-C Micro Edition 4.1.4

Security Policy Level 1

This document is a non-proprietary Security Policy for the RSA BSAFE Crypto-C

Micro Edition 4.1.4 (Crypto-C ME) cryptographic module from RSA Security LLC

(RSA), a Dell Technologies company.

This document may be freely reproduced and distributed whole and intact including

the Copyright Notice.

Contents:

Preface ............................................................................................................ 2

References .............................................................................................. 2

Document Organization ......................................................................... 2

Terminology ............................................................................................. 2

1 Crypto-C ME Cryptographic Toolkit ........................................................... 3

1.1 Cryptographic Module ....................................................................... 4

1.2 Crypto-C ME Interfaces .................................................................. 14

1.3 Roles, Services and Authentication .............................................. 16

1.4 Cryptographic Key Management ................................................... 17

1.5 Cryptographic Algorithms ...............................................................21

1.6 Self Tests .......................................................................................... 27

2 Secure Operation of Crypto-C ME .......................................................... 30

2.1 Crypto User Guidance .................................................................... 30

2.2 Roles ................................................................................................. 40

2.3 Modes of Operation ......................................................................... 41

2.4 Operating Crypto-C ME .................................................................. 42

2.5 Startup Self-tests ............................................................................. 42

2.6 Deterministic Random Number Generator ................................... 43

3 Services ...................................................................................................... 44

4 Acronyms and Definitions ......................................................................... 50

Summary of content (56 pages)

PAGE 1
Security Policy 03.07.19 RSA BSAFE® Crypto-C Micro Edition 4.1.4 Security Policy Level 1 This document is a non-proprietary Security Policy for the RSA BSAFE Crypto-C Micro Edition 4.1.4 (Crypto-C ME) cryptographic module from RSA Security LLC (RSA), a Dell Technologies company. This document may be freely reproduced and distributed whole and intact including the Copyright Notice. Contents: Preface ...........................................................................................................
PAGE 2
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 Preface This security policy describes how Crypto-C ME meets the relevant Level 1 and Level 3 security requirements of FIPS 140-2, and how to securely operate Crypto-C ME in a FIPS 140-2-compliant manner. Federal Information Processing Standards Publication 140-2 - Security Requirements for Cryptographic Modules (FIPS 140-2) details the United States Government requirements for cryptographic modules.
PAGE 3
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 1 Crypto-C ME Cryptographic Toolkit Crypto-C ME is designed for different processors, and includes various optimizations. Assembly-level optimizations on key processors mean Crypto-C ME algorithms can be used at increased speeds on many platforms. The Crypto-C ME software development toolkit is designed to enable developers to incorporate cryptographic technologies into applications.
PAGE 4
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 1.1 Cryptographic Module Crypto-C ME is classified as a multi-chip standalone cryptographic module for the purposes of FIPS 140-2. As such, Crypto-C ME must be tested on a specific operating system and computer platform. The cryptographic boundary includes Crypto-C ME running on selected platforms running selected operating systems while configured in “single user” mode.
PAGE 5
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 1.1.1 Laboratory Validated Operating Environments For FIPS 140-2 validation, Crypto-C ME is tested by an accredited FIPS 140-2 testing laboratory on the following operating environments: • • Apple®: – iOS® 11.0 on ARM®v8 (64-bit), built with Xcode® 9 – iOS 10.0 on ARMv7 (32-bit), built with Xcode 9 – macOS® 10.13 on x86_64 (64-bit), built with Xcode 7.3 – macOS 10.12 on x86 (32-bit), built with Xcode 7.3.
PAGE 6
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 • Micro Focus®: – SUSE® Linux Enterprise Server 15 on x86_64 (64-bit), built with LSB 4.0 and gcc 4.4 – SUSE Linux Enterprise Server 12 SP3 on: – • • ARMv8 (64-bit) built with gcc 4.8 • PowerPC (64-bit), built with gcc 4.8 • x86_64 (64-bit), built with LSB 4.0 and gcc 4.4 • x86 (32-bit), built with LSB 4.0 and gcc 4.4. SUSE Linux Enterprise Server 11 SP4 on: • PowerPC (64-bit), built with gcc 3.
PAGE 7
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 – Windows Server 2008 Enterprise SP2 on: • • Oracle®: – – Solaris® 11.4 on • SPARC® v9-T4 (64-bit), built with Sun C 5.13 • SPARC v8+ (32-bit), built with Sun C 5.13 • SPARC v8 (32-bit), built with Sun C 5.8 • x86_64 (64-bit), built with Sun C 5.13. Solaris 10 Update 11 on: • • Itanium (64-bit), built with Visual Studio 2010 (/MT). x86 (32-bit), built with Sun C 5.13. Red Hat®: – Enterprise Linux 5.
PAGE 8
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 – – – – • – • 8 • x86_64 (64-bit), built with Xcode 7.3 • x86 (32-bit), built with Xcode 7.3. OS X 10.10 on: • x86_64 (64-bit), built with Xcode 7.3 • x86 (32-bit), built with Xcode 7.3. OS X 10.9 on: • x86_64 (64-bit), built with Xcode 7.3 • x86 (32-bit), built with Xcode 7.3. OS X 10.8 on: • x86_64 (64-bit), built with Xcode 7.3 • x86 (32-bit), built with Xcode 7.3. Canonical: – • OS X 10.11 on: Ubuntu 16.
PAGE 9
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 • IBM: – • • PowerPC 64-bit, built with XLC v11.1 • PowerPC 32-bit, built with XLC v11.1. Micro Focus®: – – – • AIX v7.1 on: SUSE® Linux Enterprise Server 15 on: • x86 (32-bit), built with LSB 4.0 and gcc 4.4 • PowerPC 64-bit, built with and gcc 4.8. SUSE Linux Enterprise Server 12 SP4 on: • ARMv8 (64-bit) built with gcc 4.8 • PowerPC (64-bit), built with gcc 4.8 • x86_64 (64-bit), built with LSB 4.0 and gcc 4.
PAGE 10
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 • – Windows Server 2016 on: • – – – – • x86_64 (64-bit), built with Visual Studio 2017 (/MD) • x86_64 (64-bit), built with Visual Studio 2013 (/MT • x86_64 (64-bit), built with Visual Studio 2010 (/MT). Windows Server 2012 Standard on: • x86_64 (64-bit), built with Visual Studio 2017 (/MD) or (/MT) • x86_64 (64-bit), built with Visual Studio2013 (/MD) or (/MT) • x86_64 (64-bit), built with Visual Studio 2010 (/MD) or (/MT).
PAGE 11
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 • • Oracle: – Solaris 11.4 on SPARC v9-T2 (64-bit), built with Sun C 5.13 – Solaris 10 Update 11 on: • SPARC v9-T4 (64-bit), built with Sun C 5.13 • SPARC v9-T2 (64-bit), built with Sun C 5.13 • SPARC v8+ (32-bit), built with Sun C 5.13 • SPARC v8 (32-bit), built with Sun C 5.8 • x86_64 (64-bit) built with Sun C 5.13. Red Hat: – Enterprise Linux 7.6 on: • PowerPC 64-bit, built with and gcc 4.
PAGE 12
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 Multi-user Operating Systems For the following supported multi-user operating systems, the operating system and hardware enforce a single operator mode of operation by enforcing process isolation and CPU scheduling: • Apple OS X and macOS • Canonical Ubuntu • CentOS Project CentOS • FreeBSD Foundation FreeBSD • HPE HP-UX • IBM AIX • Micro Focus SUSE • Microsoft Windows • Oracle Solaris • Red Hat Enterprise Linux.
PAGE 13
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 Privileged user accounts are able to use tracing and debugging utilities to target a process with a different user id to the controlling process. An operator using this privilege to inspect or manipulate a process operating on behalf of another operator contravenes the single operator mode of operation.
PAGE 14
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 1.2 Crypto-C ME Interfaces Crypto-C ME is validated as a multi-chip standalone cryptographic module. The physical cryptographic boundary of the module is the case of the general-purpose computer or mobile device, which encloses the hardware running the module. The physical interfaces for Crypto-C ME consist of the keyboard, mouse, monitor, CD-ROM drive, floppy drive, serial ports, USB ports, COM ports, and network adapter(s).
PAGE 15
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 The underlying logical interface to Crypto-C ME is the API, documented in the RSA BSAFE Crypto-C Micro Edition Developers Guide. Crypto-C ME provides for Control Input through the API calls. Data Input and Output are provided in the variables passed with the API calls, and Status Output is provided through the returns and error codes documented for each call. This is illustrated in the following diagram.
PAGE 16
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 1.3 Roles, Services and Authentication Crypto-C ME meets all FIPS 140-2 Level 1 requirements for roles services and authentication, implementing both a Crypto User role and Crypto Officer role. As allowed by FIPS 140-2, Crypto-C ME does not support user identification or authentication for these roles. Only one role can be active at a time and Crypto-C ME does not allow concurrent operators.
PAGE 17
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 1.4 Cryptographic Key Management Cryptographic key management is concerned with generating keys, key assurance, storing keys, managing access to keys, protecting keys during use, and zeroizing keys when they are no longer required. 1.4.1 Key Generation Crypto-C ME supports the generation of DSA, RSA, Diffie-Hellman (DH) and Elliptic Curve Cryptography (ECC) public and private keys.
PAGE 18
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 Table 2 Key Storage (continued) Key or CSP Generation/Input/Output Storage DH public/private keys • Entered in plaintext through the API or generated by an explicit API call • Output in plaintext through the API. Volatile memory only (plaintext) ECC public/private keys • Entered in plaintext through the API or generated by an explicit API call • Output in plaintext through the API.
PAGE 19
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 1.4.4 Key Access An authorized operator of the module has access to all key data created during Crypto-C ME operation. Note: The Crypto User and Crypto Officer roles have equal and complete access to all keys. The following table lists the different services provided by the toolkit with the type of access to keys or CSPs.
PAGE 20
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 1.4.5 Key Protection/Zeroization All key data resides in internally allocated data structures and can be output only using the Crypto-C ME API. The operating system protects memory and process space from unauthorized access. The operator should follow the steps outlined in the RSA BSAFE Crypto-C Micro Edition Developers Guide to ensure sensitive data is protected by zeroizing the data from memory when it is no longer needed. 1.4.
PAGE 21
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 1.5 Cryptographic Algorithms To achieve compliance with the FIPS 140-2 standard, only FIPS 140-2-approved or allowed algorithms can be used in an approved mode of operation. Note: Crypto User Guidance on Algorithms provides algorithm-specific guidance on the use of the algorithms listed in this section. 1.5.
PAGE 22
RSA BSAFE Crypto-C Micro Edition 4.1.
PAGE 23
RSA BSAFE Crypto-C Micro Edition 4.1.
PAGE 24
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 Table 4 Crypto-C ME FIPS 140-2-approved Algorithms (continued) Algorithm Type Algorithm and approved parameter/modulus/key sizes Symmetric Cipher AES • CBC, CFB 128-bit, ECB, OFB 128-bit, and CTR modes with 128, 192, and 256-bit key sizes • CCM modes with 128, 192, and 256-bit key sizes • GCM mode with automatic internally generated IV with 128, 192, and 256-bit key sizes • XTS mode with 128 and 256-bit key sizes.
PAGE 25
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 1.5.2 FIPS 140-2-allowed Algorithms The following table lists the Crypto-C ME FIPS 140-2-allowed algorithms, with appropriate standards.
PAGE 26
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 1.5.3 Non-FIPS 140-2-approved Algorithms The following table lists the algorithms that are not FIPS 140-2-approved. Table 6 Crypto-C ME non-FIPS 140-2-approved Algorithms Algorithm Type Algorithm Asymmetric Key ECAES, ECIES Key Derivation Function SCrypt PBKDF1 Shamir's Secret Share Message Digest MD2, MD4 Message Authentication Code HMAC-MD5 Random Number Non-approved RNG (FIPS 186-2) Non-approved RNG (OTP).
PAGE 27
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 1.6 Self Tests Crypto-C ME performs a number of power-up and conditional self-tests to ensure proper operation. If a power-up self-test fails for one of the resource libraries, all cryptographic services for the library are disabled. Services for a disabled library can only be re-enabled by reloading the FIPS 140-2 module. If a conditional self-test fails, the operation fails but no services are disabled.
PAGE 28
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 1.6.2 Conditional Self-tests Crypto-C ME performs two conditional self-tests: • A pair-wise consistency test each time Crypto-C ME generates a DH, DSA, RSA, or ECC public/private key pair. • A Continuous Random Number Generation (CRNG) test each time the toolkit produces random data, as per the FIPS 140-2 standard.
PAGE 29
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 Constant time padding operation: RSA PKCS#1 v1.5 encryption padding operations are implemented in constant time in order to make the operation immune to timing attacks. For more information, see Chosen Ciphertext Attacks Against Protocols Based on the RSA Encryption Standard PKCS #1.
PAGE 30
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 2 Secure Operation of Crypto-C ME This section provides an overview of how to securely operate Crypto-C ME in compliance with the FIPS 140-2 standards. Note: The module operates as a Validated Cryptographic Module only when the rules for secure operation are followed. 2.1 Crypto User Guidance This section provides guidance to the module user to ensure that the module is used in a FIPS 140-2 compliant way. Section 2.1.
PAGE 31
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 • – The key establishment methodology provides: • between 112 bits and 256 bits of encryption strength when using approved domain parameter size sets, as listed in Table 4. • between 112 and 256 bits of encryption strength when curves that are allowed. • less than 112 bits of encryption strength when using curves that are not allowed.
PAGE 32
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 • • 112 or 128 bits of encryption strength when using approved modulus sizes, as listed in Table 4. • between 112 and 256 bits of encryption strength when using allowed modulus sizes. • less than 112 bits 256 bits of encryption strength when using modulus sizes that are not allowed. Digital Signatures. – An approved DRBG must be used for digital signature generation.
PAGE 33
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 • KDFs: – – For HKDF: • A FIPS 140-2 approved HMAC must be used. • A particular key-derivation key must only be used for a single key-expansion step. For more information see SP 800-56C Rev. 1 • The derived key must be used only as a secret key. • The derived key shall not be used as a key stream for a stream cipher.
PAGE 34
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 • The KDF is performed in the context of the TLS protocol • HMAC is as specified in FIPS 198-1 • P_HASH uses either SHA-256, SHA-384 or SHA-512. For more information, see SP 800-135 Rev. 1. The TLS protocols have not been tested by the CAVP and CMVP. • • MAC: – The key length for an HMAC generation or verification must be equal to or greater than 112 bits.
PAGE 35
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 RFC 5288, are generated deterministically by the module using an 64-bit global counter within the module. The module uses the current system time to initialize the counter when it is first used. The module user must ensure the system time is valid to prevent repetition of IVs. – In case the power to the module is lost and then restored, a new key must be used for AES GCM encryption/decryption.
PAGE 36
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 2.1.2 Crypto User Guidance on Obtaining Assurances for Digital Signature Applications The module provides support for the FIPS 186-4 standard for digital signatures. The following gives an overview of the assurances required by FIPS 186-4. SP 800-89 provides the methods to obtain these assurances. The tables below describe the FIPS 186-4 requirements for signatories and verifiers and the corresponding module capabilities and recommendations.
PAGE 37
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 Table 9 Verifier Requirements (continued) FIPS 186-4 Requirement Module Capabilities and Recommendations Outside the scope of the module. Obtain assurance that the claimed signatory actually possessed the private key that was used to generate the digital signature at the time that the signature was generated. 2.1.
PAGE 38
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 2.1.4 Crypto User Guidance on Obtaining Assurances for Key Transport Applications The module provides support for the recommendations for key transport in SP 800-56B, which provides the methods to obtain these assurances. The table below describes the SP 800-56B recommendations for key transport.
PAGE 39
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 The following table provides examples for a password used by PBKDF2: S = 4.32 x 1020 Character Set N L Case sensitive (a-z, A-Z) 52 13 Case sensitive alpha numeric 62 12 All ASCII printable characters except space 94 11 2.1.6 General Crypto User Guidance Crypto-C ME users should take care to zeroize CSPs when they are no longer needed. For more information on clearing sensitive data, see section 1.4.
PAGE 40
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 2.2 Roles If a user of Crypto-C ME needs to operate the toolkit in different roles, then the user must ensure all instantiated cryptographic objects are destroyed before changing from the Crypto User role to the Crypto Officer role, or unexpected results could occur. The following table lists the roles in which a user can operate: Table 12 Services Authorized for Roles Role Authorized Services Crypto Officer All services.
PAGE 41
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 2.3 Modes of Operation The following table lists the available mode filters to determine the mode Crypto-C ME operates in and the algorithms allowed. Table 13 Crypto-C ME Mode Filters Mode Description R_MODE_FILTER_FIPS140 FIPS 140-2-approved. Implements FIPS 140-2 mode and provides the cryptographic algorithms listed in Table 4. The default pseudo-random number generator (PRNG) is CTR DRBG.
PAGE 42
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 2.4 Operating Crypto-C ME Crypto-C ME operates in an unrestricted mode on startup, providing access to all cryptographic algorithms available from the FIPS 140-2 provider set against the library context. To restrict the module to a specific set of algorithms, call R_LIB_CTX_set_mode() with one of the mode filters listed in listed in Table 13.
PAGE 43
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 2.6 Deterministic Random Number Generator In all modes of operation, Crypto-C ME provides the CTR DRBG as the default deterministic random number generator (DRNG). Users can choose to use an approved DRNG other than the default, including the HMAC DRBG implementations, when creating a cryptographic object and setting this object against the operation requiring random number generation (for example, key generation).
PAGE 44
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 3 Services The following is the list of services provided by Crypto-C ME. For more information about individual functions, see the RSA BSAFE Crypto-C Micro Edition Developers Guide.
PAGE 45
RSA BSAFE Crypto-C Micro Edition 4.1.
PAGE 46
RSA BSAFE Crypto-C Micro Edition 4.1.
PAGE 47
RSA BSAFE Crypto-C Micro Edition 4.1.
PAGE 48
RSA BSAFE Crypto-C Micro Edition 4.1.
PAGE 49
RSA BSAFE Crypto-C Micro Edition 4.1.
PAGE 50
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 4 Acronyms and Definitions The following table lists and describes the acronyms and definitions used throughout this document. Table 14 Acronyms and Definitions 50 Term Definition AES Advanced Encryption Standard. A fast symmetric key algorithm with a 128-bit block, and keys of lengths 128, 192, and 256 bits. Replaces DES as the US symmetric encryption standard. API Application Programming Interface. BPS Brier, Peyrin and Stern.
PAGE 51
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 Table 14 Acronyms and Definitions (continued) Term Definition CTR DRBG Counter mode Deterministic Random Bit Generator. CTS Cipher text stealing mode of encryption, which enables block ciphers to be used to process data not evenly divisible into blocks, without the length of the ciphertext increasing. DES Data Encryption Standard. A symmetric encryption algorithm with a 56-bit key with eight parity bits. See also Triple-DES.
PAGE 52
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 Table 14 Acronyms and Definitions (continued) 52 Term Definition FFC Finite Field Cryptography (FFC): the public-key cryptographic methods using operations in a multiplicative group of a finite field. FFC keys are use in algorithms including DSA and Diffie-Hellman. FIPS Federal Information Processing Standards. FIPS 180-4 Federal Information Processing Standards Publication: Secure Hash Standard (SHS).
PAGE 53
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 Table 14 Acronyms and Definitions (continued) Term Definition Key A string of bits used by cryptographic algorithms. There are a variety of cryptographic key types. These keys might be used for operations such as encryption or decryption, cryptographic signing or verification, or key agreement. Some types of keys are intended to be kept secret, and other keys are intended to be public.
PAGE 54
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 Table 14 Acronyms and Definitions (continued) 54 Term Definition PRF PseudoRandom Function Private Key The secret key in public key cryptography. Primarily used for decryption but also used for encryption with digital signatures. PRNG Pseudo-random Number Generator. Public Key TBA RC2 Block cipher developed by Ron Rivest as an alternative to the DES. It has a block size of 64 bits and a variable key size.
PAGE 55
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 Table 14 Acronyms and Definitions (continued) Term Definition SHA-2 The NIST-mandated successor to SHA-1, to complement the Advanced Encryption Standard. It is a family of hash algorithms (SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and SHA-512/256), which produce digests of 224, 256, 384, 512, 224, and 256 bits respectively. SHA-3 SHA-3 is a family of hash algorithms which include SHA-3-224, SHA-3-256, SHA-3-384 and SHA-3-512 bits.
PAGE 56
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 Table 14 Acronyms and Definitions (continued) 56 Term Definition SP 800-131A NIST Special Publication 800-131A Revision 1 Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths SP 800-132 NIST Special Publication 800-132: Recommendation for Password-Based Key Derivation SP 800-133 NIST Special Publication 800-133: Recommendation for Cryptographic Key Generation. SP 800-135 Rev.