Skip to content

Acceptable Encryption Policy

Authorized By: Chief Information Security Officer (CISO)

The purpose of this policy is to provide clear guidance on the use of encryption to protect Safire’s data. It ensures that all cryptographic mechanisms are selected from algorithms that have undergone extensive public review and demonstrated proven effectiveness. Additionally, this policy ensures compliance with federal regulations, regarding the protection of Controlled Unclassified Information (CUI).

This policy applies to all Safire employees, contractors, and third parties utilizing company assets. It applies to all encryption used for  Data at Rest  (stored on disk) and  Data in Transit (transmitted over networks).

Algorithm and Module Requirements Approved Algorithms

Section titled “Algorithm and Module Requirements Approved Algorithms”

Ciphers and algorithms used by Safire must be selected from those approved by the U.S. National Institute of Standards and Technology (NIST), as specified in current NIST and related FIPS publications (e.g., FIPS 140 -2 / FIPS 140 -3 and associated SP 800 -series guidance), according to the date of implementation.

Symmetric Encryption: The use of the Advanced Encryption Standard (AES) is strongly recommended for symmetric encryption. AES with 128 -bit keys or higher must be used for new implementations, unless a stronger configuration is justified.

Asymmetric Encryption: The use of RSA and Elliptic Curve Cryptography (ECC) algorithms is strongly recommended for asymmetric encryption, with key sizes meeting or exceeding current NIST minimums.

Cryptographic Modules (CMMC 3.13.11): Where required by contract, regulation, or risk assessment (specifically for the protection of CUI), cryptographic functions must be performed in FIPS 140 -2 or FIPS 140 -3 validated modules.

The following are the minimum acceptable standards for digital signature algorithms used for Safire business purposes (e.g., code signing, authentication, document signing):

Algorithm Minimum Key / Curve Additiona l Comment
ECDSA P - 256 Use NIST - appr oved curves (e.g., P - 256, P - 384).
RSA 2048 bits Must use a secure padding scheme (e.g., RSA - PSS or PKCS#1 v1.5) with appropriat e hashing.

The organization adheres to the NIST Policy on Hash Functions.

Allowed: SHA-256 or higher is required for all new implementations.

Prohibited: Usage of MD5 and SHA-1 is strictly prohibited for security purposes (digital signatures, password hashing).

Key Agreement and Authentication (Data in Transit)

Section titled “Key Agreement and Authentication (Data in Transit)”

Protocols: Key exchanges must use secure cryptographic protocols: Diffie-Hellman, IKE, or Elliptic Curve Diffie-Hellman (ECDH).

TLS Requirement: All external-facing servers and applications must use TLS 1.2 or higher . SSL and TLS 1.0/1.1 are prohibited.

Certificates: All external-facing servers using TLS must have certificates signed by a known, trusted public Certificate Authority (CA).

Generation: Cryptographic keys must be generated using an industry-standard Random Number Generator (RNG) approved by NIST (e.g., SP 800-90A).

Storage: Cryptographic keys must be stored in a secure manner that prevents loss, theft, or compromise. Private keys must never be stored in plain text code or scripts.

The policy owner will verify compliance to this policy through various methods, including but not limited to, business tool reports, internal and external audits, with oversight by CISO, IT, and Compliance, though they do not hold final authority.

Any exceptions must be approved by the Policy Owner in advance.

An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.

Referenced Terms

CUI
Information that requires safeguarding or dissemination controls pursuant to and consistent with applicable law, regulations, and government-wide policies.

Revision History

2026-08-20 — Darren Rush
Merge pull request #2 from safire-dev/dev (16cb681)
Edit this Page