Cryptography & Key Management Policy

1. Purpose

Defines approved cryptographic algorithms, key strengths, and key lifecycle practices.

2. Approved algorithms

Purpose	Algorithm	Minimum strength
Symmetric encryption	AES-256-GCM	256-bit
Asymmetric encryption	X25519 (key agreement) + AES-256-GCM	256-bit
Signing	Ed25519, or ECDSA P-256 / P-384	256-bit
Hashing	SHA-256, SHA-384, SHA-512	256-bit
MAC	HMAC-SHA-256 or greater	256-bit
Password KDF	Argon2id (t=3, m=64 MiB, p=1) / scrypt	OWASP 2023
TLS	TLS 1.2 or TLS 1.3 only	,

Deprecated: MD5, SHA-1, DES, 3DES, RC4, TLS ≤ 1.1, RSA < 2048-bit. Use of a deprecated algorithm is a security incident.

For CUI / CMMC Level 2 scope: cryptographic modules must be FIPS 140-2 or FIPS 140-3 validated. AWS KMS satisfies this. Application- level crypto in that scope must route through KMS or documented compensating controls.

3. Keys in Rex Black

3.1 AWS KMS keys

• alias/rexblack/default: DynamoDB and S3 server-side encryption.
• alias/rexblack/vault: wraps vault data keys (envelope encryption).
• alias/rexblack/secrets: wraps SSM Parameter Store SecureStrings.
• alias/rexblack/break-glass: seals recovery material for the vault.

All are customer-managed keys with automatic annual rotation enabled. Key policies grant least-privileged access to specific IAM roles; no * principals.

3.2 TLS certificates

• Served from AWS Certificate Manager, auto-renewed.
• HSTS is enabled on all Rex Black web properties.

3.3 Application keys

• Envelope-encrypted data keys are generated via kms:GenerateDataKey and used once per payload; never reused across scopes.
• Per-user vault keypairs (X25519) are generated client-side and encrypted by the user's derived master key before being stored.

4. Key lifecycle

1. Generation: in a FIPS-validated module (KMS) or via well-audited primitives (@noble/* libraries).
2. Distribution: never in plaintext over the wire; wrapped by KMS or a peer's public key.
3. Storage: KMS for root keys; envelope-encrypted at rest for data keys; never checked into source.
4. Rotation: annually for KMS root keys; per use for data keys. Manual rotation on suspected compromise.
5. Revocation / destruction: KMS scheduled deletion with a 30-day waiting period; documented approval required.

5. Secret storage

1. No plaintext secret is ever written to DynamoDB, S3 (outside the Vault), source code, container images, or log output.
2. All application secrets live in AWS SSM Parameter Store SecureString under /rexblack/<env>/....
3. Per-user or per-project credentials live in the Rex Black Vault (envelope-encrypted in DynamoDB).

6. Roles & responsibilities

Role	Responsibility
Security Officer	Approves algorithm deprecations; reviews KMS policies.
Engineering	Uses only approved primitives; handles keys correctly.

7. Enforcement & exceptions

Use of deprecated primitives triggers a security incident. Exceptions require Security Officer written approval and are time-boxed with a remediation plan.

8. References

• 011-encryption-standard.md
• 017-vendor-subprocessor-management-policy.md

9. Revision history

Version	Date	Author	Approver	Change
1.0	2026-04-17	S.O.	CEO	Initial policy

Approval

This policy has been reviewed and is hereby approved for the named version and effective date above.

Approved by	Myles Bai
Title	Chief Executive Officer, Rex Black LLC
Email	myles@rexblack.com
Approval date	2026-04-17
Effective date	2026-04-17
Next review due	2027-04-17

Digital signature of record: the CEO's electronic approval is captured in the platform audit log (event kind admin.policy.approved) with hash-chained integrity under the M-C1 control. The hash-chained audit log entry for this document is the canonical signature of record; this printed block exists for print/review convenience.