Cryptographic Analysis & Assessment

Cryptographic Analysis & Assessment

Purpose

Enable Claude to assist with cryptographic security assessments including SSL/TLS configuration auditing, cipher suite analysis and recommendation, hash algorithm identification, encryption implementation code review, key management evaluation, and detection of cryptographic vulnerabilities. Claude directly analyzes provided configurations and code.

Activation Triggers

This skill activates when the user asks about:

• Auditing SSL/TLS configuration of a server or service
• Evaluating cipher suites for security strength
• Identifying hash algorithms from hash values or code
• Reviewing code for cryptographic implementation flaws
• Assessing key lengths, key management, or rotation policies
• Detecting hardcoded keys, weak IVs, or ECB mode usage
• Generating TLS configuration recommendations (Mozilla profile)
• Certificate analysis (expiration, chain, transparency)
• Post-quantum cryptography guidance
• Password hashing implementation review (bcrypt, Argon2, PBKDF2)

Prerequisites

pip install cryptography requests pyOpenSSL

Recommended tools:

• sslyze — Python TLS scanner
• testssl.sh — Comprehensive TLS testing
• openssl — Command-line TLS operations
• Wireshark — TLS traffic analysis
• certbot — Certificate management

Core Capabilities

1. SSL/TLS Configuration Auditing

When the user asks to audit TLS for a server or paste a TLS configuration:

Command-line audit approach:

# Quick TLS check using openssl
openssl s_client -connect example.com:443 -tls1_2 2>/dev/null | grep -E "Protocol|Cipher"
openssl s_client -connect example.com:443 -tls1 2>/dev/null | grep -E "handshake|error"

# Check certificate details
openssl s_client -connect example.com:443 </dev/null 2>/dev/null | openssl x509 -noout -dates -subject -issuer

# Comprehensive scan with sslyze
sslyze --regular example.com --json_out result.json

# Or testssl.sh (most comprehensive)
./testssl.sh --severity HIGH --quiet example.com

# Use the skill's script
python scripts/tls_auditor.py --host example.com --port 443 --output report.json
python scripts/tls_auditor.py --host mail.example.com --port 993 --grade

TLS Version Support Ratings:

| Protocol | Status | Action |

|----------|--------|--------|

| SSLv2 | Critically broken | Block immediately |

| SSLv3 | Broken (POODLE) | Block immediately |

| TLS 1.0 | Deprecated (PCI-DSS violation) | Disable — BEAST, POODLE |

| TLS 1.1 | Deprecated | Disable |

| TLS 1.2 | Acceptable (with strong ciphers) | Keep with restrictions |

| TLS 1.3 | Current standard | Enable and prefer |

TLS Vulnerability Checklist:

[ ] Heartbleed (CVE-2014-0160): openssl s_client + heartbleed test
[ ] POODLE: SSLv3 enabled?
[ ] BEAST: TLS 1.0 + CBC cipher?
[ ] ROBOT: RSA key exchange supported?
[ ] DROWN: SSLv2 on any port of same server?
[ ] Logjam/FREAK: DHE < 2048-bit or EXPORT ciphers?
[ ] CRIME/BREACH: TLS compression enabled?
[ ] Sweet32: 3DES (64-bit block cipher) supported?
[ ] Weak certificate: RSA < 2048-bit, SHA-1 signed?
[ ] Certificate validity: Not expired, chain complete, not self-signed for prod?
[ ] HSTS: Strict-Transport-Security header present?
[ ] CT: Certificate in public transparency logs?

2. Cipher Suite Strength Evaluation

When the user asks about cipher suite security:

TLS 1.3 Cipher Suites (All Secure — Use These):

| Cipher Suite | Key Exchange | Auth | Encryption | MAC | Rating |

|-------------|-------------|------|------------|-----|--------|

| TLS_AES_256_GCM_SHA384 | ECDHE | RSA/ECDSA | AES-256-GCM | SHA-384 | A+ |

| TLS_CHACHA20_POLY1305_SHA256 | ECDHE | RSA/ECDSA | ChaCha20 | Poly1305 | A+ |

| TLS_AES_128_GCM_SHA256 | ECDHE | RSA/ECDSA | AES-128-GCM | SHA-256 | A |

TLS 1.2 Cipher Suite Ratings:

| Cipher Suite | Rating | Notes |

|-------------|--------|-------|

| ECDHE-ECDSA-AES256-GCM-SHA384 | A+ | Perfect — AEAD, PFS |

| ECDHE-RSA-AES256-GCM-SHA384 | A+ | Perfect — AEAD, PFS |

| ECDHE-RSA-AES128-GCM-SHA256 | A | Good — AEAD, PFS |

| DHE-RSA-AES256-GCM-SHA384 | A | Good — if DHE ≥ 2048-bit |

| AES256-GCM-SHA384 | B | No forward secrecy |

| ECDHE-RSA-AES256-SHA384 | B | CBC mode (timing attacks) |

| RC4-SHA | F | RC4 broken — never use |

| DES-CBC3-SHA | F | 3DES vulnerable (Sweet32) |

| NULL-SHA | F | No encryption |

| EXPORT-RC4-MD5 | F | FREAK vulnerable |

Recommended nginx TLS Configuration (Mozilla Modern Profile):

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;  # TLS 1.3 ignores this; client order for TLS 1.2

# For TLS 1.2 compatibility
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;

# DH parameters for DHE cipher suites
ssl_dhparam /etc/nginx/dhparam.pem;  # Generate: openssl dhparam -out dhparam.pem 4096

# Session management
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;  # Disabling improves forward secrecy

# HSTS
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

# OCSP Stapling
ssl_stapling on;
ssl_stapling_verify on;
resolver 1.1.1.1 8.8.8.8 valid=300s;

Generate DH parameters:

# 4096-bit DH parameters (do this once, takes a few minutes)
openssl dhparam -out /etc/nginx/dhparam.pem 4096

3. Hash Algorithm Identification & Assessment

When the user provides a hash value or asks to identify hash algorithms:

Hash Identification by Format:

| Hash Format / Length | Algorithm | Security Status |

|----------------------|-----------|----------------|

| 32 hex chars | MD5 | Broken — collision attacks exist |

| 40 hex chars | SHA-1 | Deprecated — SHAttered collision |

| 56 hex chars | SHA-224 | Acceptable (limited use) |

| 64 hex chars | SHA-256 | Current standard |

| 96 hex chars | SHA-384 | Strong |

| 128 hex chars | SHA-512 | Strong |

| $apr1$... | MD5-APR (Apache) | Weak — only 1000 iterations |

| $1$... | MD5-crypt | Broken |

| $5$... | SHA-256-crypt | Acceptable |

| $6$... | SHA-512-crypt | Good |

| $2b$12$... | bcrypt (cost 12) | Good for passwords |

| $argon2id$... | Argon2id | Best for passwords |

| sha256:... | Django SHA-256 | Good |

| pbkdf2_sha256$... | PBKDF2-SHA256 | Good if iterations ≥ 260,000 |

Password Hash Security Assessment:

bcrypt:
  $2b$10$... → cost factor 10 → ~100ms/hash → ACCEPTABLE
  $2b$12$... → cost factor 12 → ~400ms/hash → GOOD
  $2b$14$... → cost factor 14 → ~1.6s/hash  → STRONG

Argon2id (OWASP recommended):
  Minimum: m=19456 (19MB), t=2 iterations, p=1 parallelism
  Strong:  m=65536 (64MB), t=3 iterations, p=4 parallelism

PBKDF2:
  SHA-1: 1,300,000 iterations minimum (NIST 2023)
  SHA-256: 600,000 iterations minimum (NIST 2023)
  SHA-512: 210,000 iterations minimum (NIST 2023)

Avoid:
  Plain MD5/SHA-1 → instantly cracked
  bcrypt cost < 10 → too fast for modern hardware
  No salt → rainbow table attack
  SHA-256 without KDF → GPU-crackable

4. Encryption Implementation Code Review

When the user asks to review code for cryptographic flaws:

Claude reads the code directly and flags these patterns:

Python Crypto Anti-Patterns:

# INSECURE: Hardcoded encryption key
key = b"mysecretkey12345"  # ← NEVER hardcode keys
cipher = AES.new(key, AES.MODE_ECB)  # ← ECB mode is insecure

# INSECURE: ECB mode (produces identical ciphertext for identical blocks)
from Crypto.Cipher import AES
cipher = AES.new(key, AES.MODE_ECB)  # ← Pattern detection attacks possible

# INSECURE: Static/reused IV
iv = b"\x00" * 16  # ← Static IV allows pattern detection
cipher = AES.new(key, AES.MODE_CBC, iv)  # ← Reusing IV with same key = CRITICAL

# INSECURE: Weak hash for passwords
import hashlib
password_hash = hashlib.md5(password.encode()).hexdigest()  # ← GPU-crackable

# INSECURE: Trusting certificate errors
import ssl
ssl._create_default_https_context = ssl._create_unverified_context  # ← MitM possible
requests.get(url, verify=False)  # ← Never do this in production

Secure Python Crypto Patterns:

from cryptography.hazmat.primitives.ciphers.aead import AESGCM
from cryptography.hazmat.primitives.kdf.pbkdf2 import PBKDF2HMAC
from cryptography.hazmat.primitives import hashes
import os, secrets

# SECURE: Derive key from password using PBKDF2
def derive_key(password: bytes, salt: bytes = None) -> tuple[bytes, bytes]:
    if salt is None:
        salt = secrets.token_bytes(32)  # 256-bit random salt
    kdf = PBKDF2HMAC(
        algorithm=hashes.SHA256(),
        length=32,  # 256-bit key
        salt=salt,
        iterations=600_000  # NIST 2023 minimum for PBKDF2-SHA256
    )
    key = kdf.derive(password)
    return key, salt

# SECURE: AES-GCM (authenticated encryption)
def encrypt(data: bytes, key: bytes) -> bytes:
    aesgcm = AESGCM(key)
    nonce = secrets.token_bytes(12)  # 96-bit random nonce (NEVER reuse!)
    ciphertext = aesgcm.encrypt(nonce, data, associated_data=None)
    return nonce + ciphertext  # Prepend nonce for decryption

def decrypt(ciphertext: bytes, key: bytes) -> bytes:
    aesgcm = AESGCM(key)
    nonce = ciphertext[:12]
    return aesgcm.decrypt(nonce, ciphertext[12:], associated_data=None)

# SECURE: Argon2id for password hashing
from argon2 import PasswordHasher
ph = PasswordHasher(time_cost=3, memory_cost=65536, parallelism=4)
hashed = ph.hash(password)  # Automatic random salt
ph.verify(hashed, password)  # Verify with timing-safe comparison

Code Review Checklist:

Encryption:
[ ] No hardcoded keys (check for key = b"...", SECRET_KEY = "...", etc.)
[ ] No ECB mode (MODE_ECB, "AES/ECB/PKCS5Padding")
[ ] IV/Nonce is random and unique per encryption operation
[ ] Authenticated encryption used (AES-GCM, ChaCha20-Poly1305)
[ ] Key properly derived from password (PBKDF2, bcrypt, Argon2)
[ ] No custom/homebrew crypto algorithms

Certificate Handling:
[ ] Certificate validation is NOT disabled (verify=True)
[ ] Certificate pinning for mobile/critical apps
[ ] No ssl._create_unverified_context

Randomness:
[ ] Cryptographic operations use secrets module or os.urandom()
[ ] Not using random.random() or random.randint() for security
[ ] Tokens and OTPs have sufficient entropy (≥128 bits)

5. Key Management Assessment

When the user asks about key management:

Key Length Recommendations (2025):

| Algorithm | Minimum | Recommended | Notes |

|-----------|---------|-------------|-------|

| RSA | 2048-bit | 3072-bit | NIST recommends 3072+ post-2030 |

| ECC (ECDSA) | P-256 | P-384 | P-256 OK through 2030 |

| AES | 128-bit | 256-bit | 128-bit adequate; use 256 for high-value |

| ECDH (key exchange) | P-256 | P-384 | |

| DH (classic) | 2048-bit | 3072-bit | Avoid, prefer ECDH |

| SHA (hashing) | SHA-256 | SHA-256/384/512 | SHA-1 deprecated |

Post-Quantum Cryptography Transition:

NIST finalized PQC standards in 2024:

• ML-KEM (CRYSTALS-Kyber) — Key encapsulation mechanism (replaces RSA/ECDH for key exchange)
• ML-DSA (CRYSTALS-Dilithium) — Digital signature (replaces RSA/ECDSA)
• SLH-DSA (SPHINCS+) — Stateless hash-based signature (conservative fallback)

For systems expected to protect data beyond 2030, begin PQC migration planning.

Key Rotation Schedule:

| Key Type | Recommended Rotation |

|----------|---------------------|

| TLS certificates | Annual (or use 90-day Let's Encrypt) |

| Signing keys (JWT/API) | 90 days |

| Encryption keys (data at rest) | Annual |

| API keys / service tokens | 90 days or per-service |

| Employee SSH keys | Annual + on role change |

| Password hashes | On password change |

Script Reference

tls_auditor.py

python scripts/tls_auditor.py --host example.com --port 443 --output report.json
python scripts/tls_auditor.py --host mail.example.com --port 993 --grade

Skill Integration

| Condition | Adjacent Skill |

|-----------|---------------|

| TLS audit for web application | ← Skill 09 (Web Security) |

| Cloud service encryption assessment | ← Skill 10 (Cloud Security) |

| Weak crypto findings → hardening recommendations | → Skill 15 (Blue Team Defense) |

| Crypto flaws → vulnerability report | → Skill 02 (Vulnerability Scanner) |

References

• Mozilla SSL Configuration Generator
• NIST SP 800-52 Rev. 2 — TLS Guidelines
• SSL Labs Grading Criteria
• NIST Post-Quantum Cryptography Standards
• OWASP Cryptographic Failures
• OWASP Cryptographic Storage Cheat Sheet
• NIST Password Storage Guidelines

v3.0 Enhancements (2026 Update)

Post-quantum migration is now operational:

• Finalized PQC standards — FIPS 203 (ML-KEM, key encapsulation), FIPS 204 (ML-DSA, signatures), and FIPS 205 (SLH-DSA, hash-based signatures) are published. Recommend these for new designs; FIPS 206 (FN-DSA/Falcon) is forthcoming.
• Hybrid key exchange — for TLS, recommend hybrid groups (e.g., X25519+ML-KEM-768 / X25519MLKEM768) so confidentiality survives both classical and quantum attacks during transition.
• Harvest-now-decrypt-later — prioritize PQC for long-lived secrets and data with multi-year confidentiality requirements; this is a present risk, not a future one.
• Crypto-agility — flag hardcoded algorithms/key sizes; recommend abstraction so primitives can be swapped. Inventory cryptography (a CBOM) as the first migration step.
• Hard deprecations — TLS 1.3 preferred / TLS 1.0-1.1 disallowed; SHA-1 and RSA/DH < 2048 flagged as failing; RSA-2048 acceptable now but on the PQC migration clock.

Precision rule: every finding states the primitive, key size/curve, protocol version, and the concrete upgrade (classical-now and PQC-target).