密码学攻击的痛点：工具太散，套路太多

做密码学攻防的人都有过这样的经历：拿到一个密文场景，需要临时找工具、查参数、拼脚本。Factordb用来分解大整数，SageMath做LLL格基约减，gmssl处理国密算法，hashcat跑哈希碰撞——每种攻击对应不同的工具，参数各不相同。遇到新的场景时，往往要花费大量时间”从哪下手”而不是真正在解题。

一位来自山西的安全研究者解决了这个问题。他用本地大模型Ollama配合Qwen3-8B，构建了一套面向密码学攻击的Agent工具链：46个MCP协议封装的攻击工具，加上自动化的审题、检索和脚本生成流程。输入一个密文场景，系统可以自动生成可执行的攻击脚本。

这不是一个玩具项目。它解决的问题是真实的：攻击面广、工具杂、知识散。

整体架构：三步走

整个系统分为三个核心模块：审题引擎、解题Agent和MCP工具链。

**审题引擎（solver）**负责理解输入。它先做正则快路由——对明显的特征（哈希、小n RSA、LCG、凯撒密码等）直接命中，零延迟分类。然后调用LLM做结构化分类，输出category（攻击类别）、attack_type（攻击类型）、tools（推荐工具列表）和reasoning（判断依据）。

这一步的关键是HyDE检索。不是直接拿原始场景去检索知识库，而是让LLM先”脑补”一段假设的攻击日志，再向量化后与131条攻击知识库做余弦相似度匹配。这种方法比直接检索原始场景的命中率高得多。

**解题Agent（bridge）**用ReAct范式工作。每轮输出一个JSON：要么调用工具，要么给出最终答案。限制最多20轮循环，工具报错时会回传给LLM让它换参数或换工具。

MCP工具链是系统的核心，共46个工具，分为三类：

Go MCP（25个）：RSA分解/GCD攻击、AES加密解密、国密SM2/SM3/SM4、LCG随机数破解、哈希长度扩展、ECB字节攻击oracle、LSB隐写、各种编码解码。

Python attack（8个）：SM2恶意曲线、SM4数字信封、WOTS+签名伪造、SM3长度扩展、CBC-MAC伪造等。

SageMath（13个）：LLL格基约减、Coppersmith攻击、ECC离散对数、Gröbner基求解等数学工具。

真实局限：小模型的边界

作者很诚实地列出了系统的局限性，这些局限恰好反映了当前本地小模型的能力边界。

分类错误导致检索失败。8B模型处理长hex字符串时，结构化JSON分类经常失败——输出”JSON格式错误”，类别退化为”解析失败”，检索就匹配到无关知识。”分类错→检索错”是整个链路的软肋，根本解法是换更强的模型。

工具调用不稳定。8B模型在做结构化工具调用时，频繁返回空响应或JSON格式错误。这是小模型结构化输出能力不足的表现，解法是加更强的JSON约束、降低num_ctx或换强模型。

死循环问题。Agent在工具报错时会反复重试同一失败工具，需要加”连续失败换策略”的约束来缓解。

这些局限不是项目的缺陷，而是当前技术条件的真实反映。用一个开源的8B模型做到这个程度，已经值得尊重。

工程踩坑实录

这个项目最值得参考的是作者的工程经验总结：

f-string吃正则量词。生成脚本里的{32}被外层f-string当成占位符解析，需要转义成{{32}}。这种细节问题在自动化脚本生成中很常见。

小模型复制长hex会”偷懒”。本地8B模型在处理长十六进制字符串时会自动缩写成...，需要在喂给LLM之前预提取命名变量。

Windows GBK编码。PYTHONUTF8=1解决编码问题，这是国内开发环境的老朋友了。

多次LLM调用超时。前端超时放宽到300秒，因为复杂的密码学攻击可能需要多轮工具调用和数学计算。

这个项目意味着什么

这个项目展示了一个有趣的方向：把专业领域的知识沉淀为可复用的工具链，然后用LLM作为统一入口。对于密码学攻击这样专业性强、工具分散的领域，这种模式特别有意义。

从防御的角度看，这种工具链的价值同样不可忽视。安全研究人员可以用它来快速评估系统的密码学强度，红队可以用它来自动化渗透测试中的密码学环节，开发者可以用它来理解常见密码学陷阱。

当然，这个工具链也可能被恶意使用。这就是为什么负责任的披露和合法使用框架如此重要。

核心要点：46个MCP密码学攻击工具覆盖RSA/国密/LCG/哈希攻击，LLM Agent实现从密文场景到自动化攻击脚本的端到端生成。核心局限：8B小模型的结构化输出不稳定，分类错误会导致检索失败。管理建议：安全团队可以参考此架构构建内部密码学分析工具，同时关注小模型结构化输出的改进方向。