使用 OpenSSL 生成短许可证密钥
我正在为我的软件制定一个基于 OpenSSL 公钥/私钥加密的新许可方案。我过去的方法基于本文，是使用较大的私钥大小并加密 SHA1 散列字符串，我将其作为许可证文件发送给客户（base64 编码的散列长度约为一段）。我知道有人仍然可以轻松破解我的应用程序，但它阻止了某人制作密钥生成器，我认为从长远来看这会造成更大的伤害。
由于各种原因，我想放弃许可证文件，而只需通过电子邮件发送一个 16 个字符的 base32 字符串，客户可以将其输入到应用程序中。即使使用小的私钥（我知道破解起来很简单），也很难获得这么小的加密哈希。使用相同的策略生成加密散列，但仅使用前 16 个字符作为许可证密钥是否有任何好处？如果没有，是否有更好的替代方案可以以我想要的格式创建密钥？
I'm working on a new licensing scheme for my software, based on OpenSSL public / private key encryption. My past approach, based on this article, was to use a large private key size and encrypt an SHA1 hashed string, which I sent to the customer as a license file (the base64 encoded hash is about a paragraph in length). I know someone could still easily crack my application, but it prevented someone from making a key generator, which I think would hurt more in the long run.
For various reasons I want to move away from license files and simply email a 16 character base32 string the customer can type into the application. Even using small private keys (which I understand are trivial to crack), it's hard to get the encrypted hash this small. Would there be any benefit to using the same strategy to generated an encrypted hash, but simply using the first 16 characters as a license key? If not, is there a better alternative that will create keys in the format I want?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
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表创建一个新版本即可。DSA signatures are signficantly shorter than RSA ones. DSA signatures are the twice the size of the
Qparameter; if you use the OpenSSL defaults, Q is 160 bits, so your signatures fit into 320 bits.If you can switch to a base-64 representation (which only requires upper-and-lower case alphanumerics, the digits and two other symbols) then you will need 53 symbols, which you could do with 11 groups of 5. Not quite the 16 that you wanted, but still within the bounds of being user-enterable.
Actually, it occurs to me that you could halve the number of bits required in the license key. DSA signatures are made up of two numbers,
RandS, each the size ofQ. However, theRvalues can all be pre-computed by the signer (you) - the only requirement is that you never re-use them. So this means that you could precalculate a whole table ofRvalues - say 1 million of them (taking up 20MB) - and distribute these as part of the application. Now when you create a license key, you pick the next un-usedRvalue, and generate theSvalue. The license key itself only contains the index of theRvalue (needing only 20 bits) and the completeSvalue (160 bits).And if you're getting close to selling a million copies of the app - a nice problem to have - just create a new version with a new
Rtable.您是否考虑过使用一些现有的保护+密钥生成方案？我知道 EXECryptor（我根本没有给它做广告，这只是我记得的一些信息）提供了强大的保护，与同一个人的免费产品一起，StrongKey（如果没记错的话）提供了短密钥和防破解保护。犰狳是我想到的另一个产品名称，但我不知道它们现在提供什么级别的保护。但他们更早也有快捷键。
一般来说，加密强度高的短密钥基于 ECC（椭圆曲线加密）的某些方面。 ECC的很大一部分是有专利的，总体来说ECC很难正确实施，因此行业解决方案是首选方法。
当然，如果您不需要强密钥，您可以仅使用“秘密单词”（盐）+用户名的哈希值，并在应用程序中验证它们，但这在几分钟内就可以破解。
Did you consider using some existing protection + key generation scheme? I know that EXECryptor (I am not advertising it at all, this is just some info I remember) offers strong protection whcih together with complimentatary product of the same guys, StrongKey (if memory serves) offers short keys and protection against cracking. Armadillo is another product name that comes to my mind, though I don't know what level of protection they offer now. But they also had short keys earlier.
In general, cryptographically strong short keys are based on some aspects of ECC (elliptic curve cryptography). Large part of ECC is patented, and in overall ECC is hard to implement right and so industry solution is a preferred way to go.
Of course, if you don't need strong keys, you can go with just a hash of "secret word" (salt) + user name, and verify them in the application, but this is crackable in minutes.
为什么使用公钥加密？它为您提供了一个优势，即没有人可以对可执行文件进行逆向工程来创建密钥生成器，但与修补可执行文件以跳过检查相比，密钥生成器在某种程度上是次要风险，这对于攻击者来说通常要容易得多，即使具有良好的混淆的可执行文件。
Eugene 使用 ECC 的建议是一个很好的建议 - 对于给定的安全级别，ECC 密钥比 RSA 或 DSA 短得多。
然而，基数 32 中的 16 个字符仍然只有 5*16=80 位，这个值足够低，无论您使用什么算法，暴力破解有效密钥都可能是可行的。
Why use public key crypto? It gives you the advantage that nobody can reverse-engineer the executable to create a key generator, but key generators are a somewhat secondary risk compared to patching the executable to skip the check, which is generally much easier for an attacker, even with well-obfuscated executables.
Eugene's suggestion of using ECC is a good one - ECC keys are much shorter than RSA or DSA for a given security level.
However, 16 characters in base 32 is still only 5*16=80 bits, which is low enough that brute-forcing for valid keys might be practical, regardless of what algorithm you use.