使用 OpenSSL 生成短许可证密钥

Posted 2023-03-29

【中文标题】使用 OpenSSL 生成短许可证密钥

【英文标题】：Generating short license keys with OpenSSL

【发布时间】：2011-02-24 08:54:20

【问题描述】：

我正在为我的软件制定一个基于 OpenSSL 公钥/私钥加密的新许可方案。我过去的方法based on this article 是使用较大的私钥大小并加密一个 SHA1 散列字符串，我将其作为许可证文件发送给客户（base64 编码的散列长度约为一个段落）。我知道有人仍然可以轻松破解我的应用程序，但它阻止了有人制作密钥生成器，我认为从长远来看这会造成更大的伤害。

出于各种原因，我想摆脱许可证文件，而只是通过电子邮件发送一个 16 个字符的 base32 字符串，客户可以在应用程序中键入该字符串。即使使用小的私钥（据我所知，破解起来很简单），也很难得到这么小的加密哈希。使用相同的策略生成加密散列，但仅使用前 16 个字符作为许可证密钥是否有任何好处？如果没有，是否有更好的替代方法可以创建我想要的格式的密钥？

【参考方案1】：

DSA 签名明显短于 RSA 签名。 DSA 签名是Q 参数大小的两倍；如果您使用 OpenSSL 默认值，Q 为 160 位，因此您的签名适合 320 位。

如果您可以切换到 base-64 表示（只需要大小写字母数字、数字和其他两个符号），那么您将需要 53 个符号，您可以使用 11 个 5 个组来完成。不是你想要的 16 个，但仍然在用户可输入的范围内。

---

实际上，我想到您可以将许可证密钥中所需的位数减半。 DSA 签名由两个数字组成，R 和 S，每个数字的大小为 Q。但是，R 值都可以由签名者（您）预先计算 - 唯一的要求是您永远不要重复使用它们。因此，这意味着您可以预先计算一整张 R 值的表——比如其中的 100 万个（占用 20MB）——并将它们作为应用程序的一部分分发。现在，当您创建许可证密钥时，您选择下一个未使用的 R 值，并生成 S 值。许可证密钥本身仅包含 R 值的索引（仅需要 20 位）和完整的 S 值（160 位）。

如果您的应用程序即将售出一百万份 - 这是一个很好的问题 - 只需使用新的 R 表创建一个新版本。

【参考方案2】：

您是否考虑过使用一些现有的保护 + 密钥生成方案？我知道 EXECryptor（我根本不是在宣传它，这只是我记得的一些信息）提供了强大的保护，与同一个人的免费产品一起，StrongKey（如果没有记错的话）提供短密钥和防止破解的保护。犰狳是我想到的另一个产品名称，虽然我不知道他们现在提供什么级别的保护。但他们之前也有快捷键。

一般来说，加密强短密钥基于 ECC（椭圆曲线加密）的某些方面。 ECC 的很大一部分是专利，总体而言 ECC 很难正确实施，因此行业解决方案是首选方式。

当然，如果您不需要强密钥，您可以只使用“密码”（盐）+ 用户名的哈希，并在应用程序中验证它们，但这可以在几分钟内破解。

【讨论】：

ECC +1。也许看看 TinyECC，它是一个最小的方案，用类似 C 的语言，用于进行短密钥公共加密。

我正在编写 Mac 应用程序，而大多数商业解决方案仅适用于 Windows 和/或非常昂贵，所以我还没有真正找到任何令我兴奋的东西。我考虑过一些 Mac 端的开源解决方案，但它们实际上也使用相同的 OpenSSL 策略，所以我最终会遇到相同的问题。不过，我现在正在研究 ECC！虽然乍一看它看起来很复杂，以至于我认为我将只使用 SHA1 哈希路由，尽管那样不安全。

【参考方案3】：

为什么要使用公钥加密？它为您提供了一个优势，即没有人可以对可执行文件进行逆向工程以创建密钥生成器，但与修补可执行文件以跳过检查相比，密钥生成器是一个次要风险，这通常对攻击者来说更容易，即使使用良好 -混淆的可执行文件。

Eugene 建议使用 ECC 是一个很好的建议 - 对于给定的安全级别，ECC 密钥比 RSA 或 DSA 短得多。

但是，以 32 为基数的 16 个字符仍然只有 5*16=80 位，这已经足够低，无论您使用什么算法，对有效密钥的暴力破解都可能是可行的。

【讨论】：

"...5*16=80 位，这已经足够低，有效密钥的暴力破解可能是实用的..."。哇，你一定有一些很棒的电脑！

@GregS：虽然暴力破解 80 位对称密钥不切实际，但在非对称算法中暴力破解 80 位签名更可行（实际上并不需要尝试所有 2** 80 个可能的数字）。

@caf：我知道，我只是在开玩笑。

您也不是在寻找一个有效的密钥，而是寻找大量潜在的有效密钥中的任何一个。