T09 · Insecure Skill Coding Practices
- Location
SKILL.md:64- Finding
Predictable Repeating-Key XOR Misrepresented as Encryption
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 64–81
Vulnerability Type: Weak cryptography and predictable key derivation
Risk Level: Mediumpython 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.b64decodeoutput is XOR-decoded and returned as text, not passed toexec,eval, a shell, or another execution mechanism. Likewise, no net ...[truncated 1613 chars]- Remediation
View remediation
Remediation Suggestions
- Replace repeating-key XOR with authenticated encryption such as AES-256-GCM or ChaCha20-Poly1305.
- 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.
- 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.
- Authenticate relevant metadata, including the memory tier, source skill, creation date, and expiration date, as associated data so that unauthorized modification can be detected.
- Introduce a versioned ciphertext format that records the algorithm and key identifier, enabling safe key rotation and migration of existing entries.
- Until secure encryption is implemented, describe the current mechanism as obfuscation rather than encryption and prohibit sensitive data from being stored through it.
- Preserve the Tier 3 prohibition against storing credentials and PII, and add validation before persistence rather than relying only on periodic cleanup.
- Apply the correction to both duplicated examples in
SKILL.mdto prevent dependent implementations from copying the insecure variant.