使用OpenSSL生成短许可证密钥

Question

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

出于各种原因，我想远离许可证文件，只需通过电子邮件发送16个字符的base32字符串，客户就可以输入应用程序。即使使用小型私钥（我理解这一点很容易破解），也很难将加密的哈希变得很小。使用相同的策略生成加密哈希会有什么好处，但只使用前16个字符作为许可证密钥？如果没有，是否有更好的选择，将以我想要的格式创建密钥？

Answer 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表创建一个新版本。

Answer 2

您是否考虑使用一些现有的保护+密钥生成方案？我知道EXECryptor（我根本就没有广告，这只是我记得的一些信息）提供了强大的保护，同时还有同一个人的赞美产品，StrongKey（如果内存服务）提供短按键和防止破解。犰狳是我想到的另一个产品名称，虽然我不知道他们现在提供什么样的保护。但他们之前也有短按键。

通常，密码强的短密钥基于ECC（椭圆曲线密码术）的某些方面。 ECC的很大一部分已获得专利，并且整体ECC难以正确实施，因此行业解决方案是首选方式。

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

Answer 3

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

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

但是，基数32中的16个字符仍然只有5 * 16 = 80位，这足够低，无论您使用何种算法，强制键的强制执行都可能是实用的。