docs: add cryptographic implementation audit

This commit adds a cryptographic audit report in AUDIT-CRYPTO.md.

The audit was conducted to review the cryptographic implementations in the codebase. The findings indicate that there are no custom or third-party cryptographic implementations present. The use of `math/rand` is confined to non-security-critical test code, and references to `TLSA` in DNS-related files are purely descriptive.

Co-authored-by: Snider <631881+Snider@users.noreply.github.com>

AUDIT-CRYPTO.md

@@ -0,0 +1,50 @@
+# Cryptographic Implementation Audit: Poindexter
+
+**Date:** 2024-07-25
+
+## 1. Executive Summary
+
+A thorough audit of the Poindexter codebase was conducted to review its cryptographic implementations. The audit found **no instances of custom or third-party cryptographic code**. The project, in its current state, does not handle sensitive data requiring encryption, hashing, or secure random number generation.
+
+Based on this analysis, the codebase is considered **out of scope** for a detailed cryptographic security review.
+
+## 2. Audit Scope
+
+The audit focused on the following areas as per the initial request:
+
+- **Constant-time operations:** Searching for code where timing side-channels could leak sensitive information.
+- **Key material handling:** Looking for storage, transmission, or use of cryptographic keys.
+- **Random number generation:** Identifying the use of cryptographically secure (CSPRNG) vs. insecure random number generators.
+- **Algorithm implementation correctness:** Verifying the implementation details of any cryptographic algorithms found.
+- **Side-channel resistance:** General review for potential information leaks.
+
+## 3. Findings
+
+Our review of the entire Go codebase yielded the following observations:
+
+### 3.1. No Cryptographic Implementations Found
+
+The primary finding is that the Poindexter library does not contain any cryptographic functions. Its purpose is to provide sorting utilities and a k-d tree implementation, which do not inherently require cryptography.
+
+### 3.2. Use of `math/rand`
+
+The codebase makes use of the `math/rand` package in several test files:
+
+- `kdtree_backend_parity_test.go`
+- `fuzz_kdtree_test.go`
+- `bench_kdtree_dual_test.go`
+
+This usage is confined to generating random data for testing and benchmarking purposes (e.g., creating random points for the k-d tree). Since this data is not security-sensitive, the use of a non-cryptographically secure random number generator like `math/rand` is appropriate and poses no security risk.
+
+### 3.3. DNS-related Mentions (`TLSA`)
+
+The file `dns_tools.go` and its corresponding test file contain references to `TLSA` (TLS Authentication) DNS records. These references are limited to type definitions and descriptive strings. The codebase **does not implement** any part of the DANE protocol or the underlying cryptographic operations associated with TLSA records.
+
+## 4. Recommendations
+
+- **Continue Using Standard Libraries:** If cryptographic functionality is required in the future (e.g., for securing communications or data), it is strongly recommended to use Go's standard `crypto` library or other well-vetted, community-trusted cryptographic libraries.
+- **Avoid Custom Implementations:** Do not implement custom cryptographic algorithms, as this is notoriously error-prone and can lead to severe security vulnerabilities.
+
+## 5. Conclusion
+
+The Poindexter library currently has no exposure to cryptographic implementation risks because it does not implement any cryptographic features. The existing code follows good practices by using non-secure random number generation only for non-security-critical applications. No corrective actions are required at this time.