CTF 密码学出题大师

常见的出题事故

CTF 密码学题目的事故往往不在「写出来那一刻」，而在选手开打之后：求解链路在某一步断了，只有作者知道某个常量从哪来；flag 明文躺在源码注释里，随机种子可预测导致私钥可重放；模数太小被直接分解，格维数过小被暴力枚举。这些事故的共同点是先写生成器、后想解法——题目的可解性没有被验证过。

Crypto 题目的分发形态是「方案源码 + 公开挑战数据」（加密脚本、输出密文、公钥、协议交互记录），选手拿到的是一个数学还原任务。出题人必须在分发前证明：只凭这些公开材料，就能走通从分析到 flag 的完整链路。

八阶段门禁式出题流程

这个技能把出题拆成八个顺序阶段，每阶段结束后必须向用户展示交付物并等待确认，才能进入下一阶段：

• Phase 1 需求采集：对齐方向（RSA 族 / ECC / DLP / 对称 / 格 / 哈希 / 签名 / 古典 / PRNG / 组合多阶段）、难度、知识点、flag 编码方式与部署形态。
• Phase 2 求解拓扑设计：先画出从公开数据到 flag 的攻击拓扑，再排查非预期解（源码泄漏 flag、种子可预测、模数可分解等），列出处置策略。
• Phase 3 方案规划：确定生成器结构、flag 落在哪个数学对象（明文、密钥、nonce 派生、签名消息、格解）、部署形态与目录产物。
• Phase 4 方案二次确认：汇总前三个阶段为单页摘要，动手写代码前做最后一次总确认。
• Phase 5 内容制作：运行脚手架生成工程骨架，在 challenge/src/encrypt.py 中实现方案生成器，产出公开挑战数据与合并版 README、writeup。
• Phase 6 黑盒自测：派发独立求解子代理，只给选手公开包（README + 方案源码 + 公开挑战数据），禁止接触秘密与题解，验证题目可解且求解链路中没有凭空出现的步骤或常量。
• Phase 7 PoC 打洞验证：把验证过的预期解落成 poc/solve.py，真正运行它证明从公开数据一步到位打印 flag；脚本内不得写死 flag 明文或等效答案。
• Phase 8 成果审阅：汇总全部交付物（含自测报告与 PoC）交用户终审。

贯穿全流程的底层纪律是从解法倒推：先锚定一条在自己机器上能脚本化跑通的数学攻击，再把题目当「包裹」套上去，而不是先写加密再祈祷有人能破。

适用边界与注意点

• 这套流程严格分阶段，每阶段有门禁；如果你希望快速迭代、一口气出多题，它会增加确认轮次。
• 技能的核心价值不是「直接写出加密代码」，而是先想清楚选手要怎么攻破，再动手做；它不替代你对密码学攻击手法的理解。
• 知识点库覆盖 RSA 家族脆弱点、离散对数、ECC、对称模式、哈希、签名、PRNG、格攻击与多阶段协议链；范围之外的高阶题目需要你自己补充材料。
• 是否需要在线校验服务取决于是否要防选手搜到 flag 或交互式动态生成；纯静态数据的题目可省略。
• 本地环境需要 Python（常见）与 SageMath（格题），生成的公开数据必须能由生成器稳定复现。