Acceptable Encryption Policy

Version1.0.2 Last Updated2023-11-29 APPROVED

1. Overview

The purpose of this policy is to provide guidance on the acceptable use of encryption technologies within AccuCode AI, Inc. to ensure the protection of sensitive data, compliance with Federal regulations, and adherence to industry best practices.

2. Purpose

The purpose of this policy is to limit the use of encryption to algorithms that have undergone substantial public review and have been proven to work effectively.

3. Scope

This policy applies to all employees of AccuCode AI, Inc.

4. Policy

4.1 Algorithm Requirements

  • 4.1.1 Ciphers in use must meet or exceed the set defined as “AES-compatible” or “partially AES-compatible” according to the IETF/IRTF Cipher Catalog, or the set defined for use in the United States National Institute of Standards and Technology (NIST) publication FIPS 140-3, or any superseding documents according to the date of implementation. The use of the Advanced Encryption Standard (AES) with a minimum key size of 256 bits (AES256) is required for symmetric encryption.

  • 4.1.2 Algorithms in use must meet the standards defined for use in NIST publication FIPS 140-3 or any superseding document, according to the date of implementation. The use of the RSA and Elliptic Curve Cryptography (ECC) algorithms is strongly recommended for asymmetric encryption.

  • 4.1.3 Signature Algorithms:

    • ECDSA: P-256
    • RSA: 2048 bits minimum (Must use a secure padding scheme, such as PKCS#7)
    • LDWM: SHA256

4.2 Hash Function Requirements

AccuCode AI, Inc. adheres to the NIST Policy on Hash Functions.

4.3 Key Agreement and Authentication

  • 4.3.1 Key exchanges must use one of the following cryptographic protocols: Diffie-Hellman, IKE, or Elliptic curve Diffie-Hellman (ECDH).

  • 4.3.2 End points must be authenticated prior to the exchange or derivation of session keys.

  • 4.3.3 Public keys used to establish trust must be authenticated prior to use. Examples of authentication include transmission via cryptographically signed message or manual verification of the public key hash.

  • 4.3.4 All servers used for authentication (for example, RADIUS or TACACS) must have installed a valid certificate signed by a known trusted provider.

  • 4.3.5 All servers and applications using SSL or TLS must have the certificates signed by a known, trusted provider.

4.4 Key Generation

  • 4.4.1 Cryptographic keys must be generated using hardware-based random number generators (RNGs) and stored securely in key vaults to prevent loss, theft, or compromise.

  • 4.4.2 Key generation must be seeded from an industry-standard random number generator (RNG) that complies with NIST Annex C: Approved Random Number Generators for FIPS PUB 140-3.

  • 4.4.3 Key rotation must be performed regularly, with the frequency determined by the sensitivity of the data and the criticality of the system.

5. Policy Compliance

5.1 Compliance Measurement

The InfoSec team will verify compliance to this policy through various methods, including but not limited to, business tool reports, internal and external audits, and feedback to the policy owner.

5.2 Exceptions

Any exception to the policy must be approved by the InfoSec team in advance.

5.3 Non-Compliance

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

  • National Institute of Standards and Technology (NIST) publication FIPS 140-3
  • NIST Policy on Hash Functions