如何创建序列密钥以保护应用程序
我有一个创建串行密钥的应用程序，如下所示：
Take customername Sign customername using privatekey and sha/dsa algorithm 然后可以通过使用公钥解码并检查cuastomername匹配来检查许可证
除了生成的序列相当长之外，这没关系。 因此，客户输入序列密钥并不是真正实用，而是必须在文件中提供序列，这与薄雾应用程序和工作方式有很大不同，并且令人困惑。
许多其他应用程序仅在用户进行购买时向其提供Guid
即5bd1060b-8608-4817-93ca-207f7c828e2f
并且用户必须输入他们的电子邮件地址和guid来许可他们的申请。
这对于用户来说看起来更简洁，但我不明白这样的应用程序如何validation来自无效guid的有效guid，除非它通过检查数据库上的emailaddress / guid对在线完成。 但我真的希望在不需要在线检查的情况下进行某种validation：
a>如果互联网连接/我的服务器关闭或b>他们可以通过禁用互联网访问来绕过检查，应用程序将无法运行
编辑：
我的理解解决方案如下面的答案所示：
用户购买
拿emailaddress + salt
使用SHA1加密可提供160位散列
转换为hex表示法给出20个hex值，即40个字符
最后8个字符的Lop给了一个Guid
电子邮件用户Gui和他们输入程序的电子邮件地址程序通过获取电子邮件地址，添加盐，加密ectera和检查生成有效的guid来validation此配对。
我的主要问题是我需要将盐存储在程序中的某个地方，因此如果黑客找到了盐并找出了我正在做的事情，他们可以为任何电子邮件地址创建有效的许可证密钥生成器。
我目前另一个程序的方法：
我已经生成了一个公钥/私钥对
用户购买
我通过签署电子邮件地址来生成许可证
BaseEncode生成的许可证
将许可证发送给用户
程序通过basedecoding和使用公钥解密来validation许可证
我的问题是，当我签署电子邮件地址太长时，我最终把它放在一个文件而不是用户将其输入到字段中，但问题可能是我是base64encoding而不是转换为Hex。
签名输出可以持续多长时间，取决于输入的长度还是始终相同？
因为我使用公钥解密密钥，我可以删除许可密钥的一些字符，但如果生成密钥只有40个字符，我想这是可以的
我认为这种方法的优点是，即使黑客知道我在做什么，他们也无法创建许可证生成器，因为他们没有，并且无法获取私钥，因为它只存储在我的服务器上。 他们只能在创建新的私钥/公钥配对时生成许可证，然后如果我的应用程序有自己编码的公钥，则应用程序可以拒绝许可证。
当然，他们可以破解应用程序，但如果应用程序定期更新，这将成为很多努力。
总而言之：我是否正确理解了这一点，哪种方法最好，以及为第二种方法生成了多少数据。
我认为签名方法目前是最佳实践。 顺便说一句。 有许多免费的libs涵盖了这个主题。
许可证密钥的长度至少由签名密钥长度确定 – 1024位密钥产生128字节许可证（如果没有添加其他有效负载）。
许可证文件通常包含有关许可使用本身的更多信息，例如有效期，许可子模块，吞吐量…… – 签名本身嵌入在此结构中。 通过这种方式，您可以获得灵活性，我强烈建议您使用此解决方案，即使许可证变得更大。
要在应用程序中导入许可证，您可以采用混合方式（就像我们一样）。 一方面，您可以提供经典的“导入许可证文件”解决方案。 另一方面，我们生成一个随机的短ID（如您的GUID）并将其与许可证数据相关联。 注册后，用户输入短ID，应用程序通过HTTP查找完整的许可证。 您必须只在线一次，仍然可以提供复杂的许可证，用户只需要一个简短的ID。
编辑
- 签名的长度是密钥的长度。 例如1024位（或128字节）
- 如果您的应用程序知道签名的数据（例如邮件），您可以单独使用此签名
- 您可以签署一个“许可证文档”，其中包含的内容不仅仅是邮件。 在这种情况下，许可证包含属性和签名（因此，仅比签名更长）
- 您不需要在线连接进行许可证检查。 只需随应用程序导入许可证，并随时检查。
- 除了许可证文件导入之外，您还可以使用短ID作为密钥在线下载许可证文件。 许可证已下载并脱机。 所以你拥有两全其美。
您可以只哈希用“秘密”盐连接的用户信息，然后截断哈希值。
黑客 – 只要他们对您的程序感兴趣 – 将通过对源代码进行逆向工程来破解它们：他们将找到哈希算法和秘密盐。
但这也会发生在您的签名和validation解决方案中：他们可以绕过检查，使其返回true。
因此，签名和validation解决方案更复杂但不安全。