TOTP密钥是否可逆向还原？暴力枚举实验方案优化求教（教育用途）

本内容仅用于教育研究用途，所有技术探讨不得用于非法场景。

先给最直白的结论：当前跑的32位Base32密钥纯随机枚举方案，从数学概率上就没有成功的可能——32位Base32编码对应的密钥总空间是32³²⁼²160，就算把全球所有计算设备凑一块跑，跑到太阳熄灭都碰不到正确密钥，纯无差别暴力枚举的思路从根上就走不通。

当前实现里的明显问题 #

先把这些bug和负优化改了，至少能让现有脚本的效率提升几个量级，但就算改完也碰不到标准32位真随机密钥：

• 第二种带已用密钥记录的生成方案是纯负优化：2^160的空间下，随机生成两个相同密钥的概率远低于电脑运行时被宇宙射线打穿内存的概率，用列表做in查询的时间复杂度是O(n)，跑的时间越久查询越慢，还会白白占满内存，直接删掉这段逻辑就行。
• 第一个随机密钥生成函数有语法错误：函数名get_random_ secret中间多了个空格，运行会直接报语法错误。
• 主循环有致命变量错误：遍历校验样本的时候取的键名是time_interval，传给get_hotp的参数写的是interval，这个变量名不统一的bug不修，脚本跑到硬件报废都出不了正确结果。
• 全排列枚举的思路完全错误：itertools.permutations生成的是字符不重复的排列，但真实TOTP密钥允许字符重复出现，这段代码从一开始就漏掉了几乎所有可能的密钥，根本没有运行的意义。
• 校验顺序可以优化：把时间间隔最早、计算量最靠前的样本放在校验列表第一位，只要第一个样本校验不通过立刻跳过当前密钥，能减少大量无效计算。

贴出来的HOTP算法移植逻辑本身没有大问题，除了上面提到的变量bug之外，能正常跑通计算流程。

仅用于技术研究的效率提升思路 #

以下内容仅做算法原理探讨：

• 放弃无差别全空间枚举：真实场景下很多服务的TOTP密钥根本达不到32位长度，不少老系统用16位甚至8位Base32密钥，部分服务的密钥生成用了弱伪随机数生成器，这种情况下密钥空间会大幅缩小，才有枚举的价值。如果确定是标准32位真随机密钥，直接放弃枚举思路。
• 换底层实现跑核心计算：Python的解释器特性决定了它跑HMAC-SHA1的效率只有原生C实现的1/10不到，更不要提和并行计算设备比。把核心的HMAC计算、校验逻辑用C/CUDA重写，扔到消费级显卡上并行跑，单张显卡每秒能完成数十亿次HMAC计算，比CPU多进程的效率高3~4个数量级。
• 利用算法特性做剪枝：标准TOTP的6位验证码，是取HMAC-SHA1结果最后一个字节的低4位作为偏移量，再从偏移位置取4字节截断取模得到的。可以在计算时先判断偏移值是否匹配，直接过滤掉93.75%的错误密钥，不需要算完整的验证码结果，能再提十多倍效率。
• 换攻击思路：如果目标是拿到自己账号的OTP密钥用于自动化，根本不需要枚举——正规服务的2FA设置页都提供密钥展示、重新生成的入口，身份验证器APP也支持通过迁移二维码导出所有密钥，直接从存储侧拿密钥的成本，比碰撞哈希低无数个数量级。

内容的提问来源于stack exchange，提问作者Cytan