T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:64
- Finding
- Predictable Repeating-Key XOR Misrepresented as Encryption## Vulnerability Details **File Location**: `SKILL.md`, lines 64–81 **Vulnerability Type**: Weak cryptography and predictable key derivation **Risk Level**: Medium ```python import hashlib, base64 def _derive_key(skill_name: str, year_month: str) -> str: """e.g., _derive_key('my-skill', '2026-05')""" raw = skill_name + year_month return hashlib.sha256(raw.encode()).hexdigest()[:8] def encrypt(text: str, skill_name: str, year_month: str) -> str: key = _derive_key(skill_name, year_month) result = bytes([ord(c) ^ ord(key[i % len(key)]) for i, c in enumerate(text)]) return base64.b64encode(result).decode() def decrypt(encoded: str, skill_name: str, year_month: str) -> str: key = _derive_key(skill_name, year_month) raw = base64.b64decode(encoded) return ''.join(chr(b ^ ord(key[i % len(key)])) for i, b in enumerate(raw)) ``` The same insecure design is duplicated in the translated section at `SKILL.md`, lines 189–205. ### Technical Analysis The Skill presents repeating-key XOR followed by Base64 encoding as encryption for persistent Tier 2 memory. The key is derived exclusively from the skill name and year-month value, both of which are predictable and documented in each memory entry through fields such as `source_skill`, `key_hint`, and creation dates. SHA-256 does not provide secrecy when all inputs are public, and truncating its hexadecimal output to eight characters further limits the key material. Repeating-key XOR is not secure encryption. Base64 only transforms binary data into printable text and provides no confidentiality. An attacker with read access to a Tier 2 memory file can reconstruct the key and reverse the transformation without obtaining any separate secret. The flagged decode-and-execute behavior is not present: `base64.b64decode` output is XOR-decoded and returned as text, not passed to `exec`, `eval`, a shell, or another execution mechanism. Likewise, no net ...[truncated 1613 chars]
- Remediation
- ## Remediation Suggestions 1. Replace repeating-key XOR with authenticated encryption such as AES-256-GCM or ChaCha20-Poly1305. 2. Obtain a high-entropy encryption key from an operating-system keychain, dedicated secret manager, or securely provisioned environment secret. Do not derive encryption keys solely from public metadata. 3. Generate a unique cryptographically random nonce for every encrypted entry and store the nonce alongside the ciphertext. Never reuse a nonce with the same key. 4. Authenticate relevant metadata, including the memory tier, source skill, creation date, and expiration date, as associated data so that unauthorized modification can be detected. 5. Introduce a versioned ciphertext format that records the algorithm and key identifier, enabling safe key rotation and migration of existing entries. 6. Until secure encryption is implemented, describe the current mechanism as obfuscation rather than encryption and prohibit sensitive data from being stored through it. 7. Preserve the Tier 3 prohibition against storing credentials and PII, and add validation before persistence rather than relying only on periodic cleanup. 8. Apply the correction to both duplicated examples in `SKILL.md` to prevent dependent implementations from copying the insecure variant.