我有一个创建串行密钥的应用程序,如下所示：

Take customername
Sign customername using privatekey and sha/dsa algorithm

然后可以通过使用公钥解码并检查cuastomername匹配来检查许可证

除了生成的序列相当长之外,这没关系.因此,客户键入串行密钥并不是真正实用,而是必须在文件中提供串行,这与薄雾应用程序和工作方式有很大不同,并且令人困惑.

许多其他应用程序仅在用户进行购买时向其提供Guid

即5bd1060b-8608-4817-93ca-207f7c828e2f

并且用户必须输入他们的电子邮件地址和guid来许可他们的申请.

这看起来像是一个更简洁的用户解决方案,但我不明白这样的应用程序如何从无效的guid验证有效的guid,除非它通过检查数据库上的emailaddress / guid对在线完成.但我真的希望在不需要在线检查的情况下进行某种验证：

a>如果互联网连接/我的服务器关闭,应用程序将无法运行
要么
b>他们可以通过禁用互联网访问来规避检查

编辑：

我的理解解决方案如下面的答案所示：

用户购买
拿emailaddress盐
使用SHA1加密可提供160位哈希值
转换为十六进制表示法给出20个十六进制值,即40个字符
最后8个字符的Lop给了一个Guid
电子邮件用户Gui和他们输入程序的电子邮件地址
程序通过获取电子邮件地址,添加盐,加密ectera来验证此配对
并检查生成有效的guid.

我的主要问题是我需要在某个地方将盐存储在程序中,因此如果黑客找到了盐并找出了我正在做的事情,他们可以为任何电子邮件地址创建有效的许可证密钥生成器.

我目前另一个程序的方法：

我已经生成了一个公钥/私钥对
用户购买
我通过签署电子邮件地址来生成许可证
BaseEncode生成的许可证
将许可证发送给用户
程序通过basedecoding和使用公钥解密来验证许可证

我的问题是,当我签署电子邮件地址太长时,所以我最终把它放在一个文件而不是用户将其输入到字段中,但可能问题是我是base64encoding而不是转换为Hex.

签名输出能持续多长时间,取决于输入的长度还是始终相同？

因为我使用公钥解密密钥,我可以删除许可密钥的一些字符,但如果生成密钥只有40个字符,我想这是可以的

我认为这种方法的优点是,即使黑客知道我在做什么,他们也无法创建许可证生成器,因为他们没有,并且无法获取私钥,因为它只存储在我的服务器上.如果他们创建新的私钥/公钥配对,他们只能生成许可证,然后如果我的应用程序有自己编码的公钥,则应用程序可以拒绝许可证.

当然,他们可以破解应用程序,但如果应用程序定期更新,这将成为很多努力.

总结如下：
我是否正确理解了这种方法,哪种方法最好,以及为第二种方法生成了多少数据.

解决方法:

我认为签名方法目前是最佳实践.顺便说一句.有很多免费的libs涵盖了这个主题.

许可证密钥的长度至少由签名密钥长度确定 – 1024位密钥产生128字节许可证(如果没有添加其他有效负载).

许可证文件通常包含有关许可使用本身的更多信息,例如有效期,许可子模块,吞吐量…… – 签名本身嵌入在此结构中.通过这种方式,您可以获得灵活性,我强烈建议您使用此解决方案,即使许可证变得更大.

要在应用程序中导入许可证,您可以采用混合方式(就像我们一样).一方面,您可以提供经典的“导入许可证文件”解决方案.另一方面,我们生成一个随机的短ID(如您的GUID)并将其与许可证数据相关联.注册后,用户输入短ID,应用程序通过HTTP查找完整许可证.您必须只在线一次,仍然可以提供复杂的许可证,用户只需要一个简短的ID.

编辑

>签名的长度是密钥的长度.例如. 1024位(或128字节)
>如果您的应用程序知道签名的数据(例如邮件),您可以单独使用此签名
>您可以签署一个“许可证文档”,其中包含的内容不仅仅是邮件.在这种情况下,许可证包含属性和签名(因此,只比签名更长)
>您不需要在线连接进行许可证检查.只需随应用程序导入许可证,然后随时查看.
>除了许可证文件导入之外,您还可以使用短ID作为密钥在线下载许可证文件.许可证已下载并脱机.所以你拥有两全其美.