【问题标题】:Generate reasonable length license key with asymmetric encryption?使用非对称加密生成合理长度的许可证密钥?
【发布时间】:2011-02-13 03:25:43
【问题描述】:

我整天都在看这个。我可能应该在几个小时前离开它;在这一点上,我可能遗漏了一些明显的东西。

短版:有没有办法生成非对称加密哈希并将其归结为合理数量的明确、人类可读的字符?

长版:

我想为我的软件生成许可证密钥。我希望这些键具有合理的长度(25-36 个字符),并且易于被人类阅读和输入(因此请避免使用数字 0 和大写字母 O 之类的模棱两可的字符)。

最后——这似乎是关键——我真的很想使用非对称加密来增加生成新密钥的难度。

我有一个通用的方法:将我的信息(用户名、产品版本、盐)连接成一个字符串并从中生成一个 SHA1() 哈希,然后用我的私钥加密该哈希。在客户端上,使用相同的信息构建 SHA1() 哈希,然后使用公钥解密许可证并查看是否匹配。

由于这是一个 Mac 应用程序,我查看了 AquaticPrime,但它生成的许可证文件相对较大,而不是字符串。如果必须,我可以使用它,但作为用户,我真的很喜欢我可以阅读和打印的许可证密钥的便利性。

我还查看了生成密钥的 CocoaFob,但它太长了,我还是想将它作为文件传递。

fooled around with OpenSSL 了一段时间,但想不出任何合理的长度。

所以...我在这里遗漏了一些明显的东西吗?有没有办法生成非对称加密的哈希并将其归结为合理数量的明确、人类可读的字符?

我愿意购买解决方案。但是我在许多不同的平台上工作,所以我想要一些便携的东西。到目前为止,我看到的所有内容都是特定于平台的。

非常感谢您的解决方案!

PS - 是的,我知道它仍然会被破解。我正在尝试提出一些合理的东西,作为用户,我仍然会觉得很友好。

【问题讨论】:

  • 答案似乎是:不,你不能。如果有人能证明我错了,我会留下这个问题,但据我所知,加密哈希只需要那么多字节,就是这样。我最终使用了 CocoaFob,到目前为止,没有人抱怨过(荒谬的)长许可证密钥。
  • 作为一个兴趣点:我的应用程序,尽管它是晦涩难懂的,但在不到 24 小时内就被破解了。但它需要对可执行文件进行修补(他们用他们自己的一个交换我的公钥),然后他们的密钥生成器才能工作。我可以轻松破解每个新版本的补丁(只需随机播放密钥),这样我就可以忍受它了。
  • Base58 编码消除了不明确的字符。

标签: license-key


【解决方案1】:

很遗憾,没有。如果将其缩短,则会丢失信息并且无法重新创建原始哈希。

不过,您可以尝试以下几点:

  • 使用 base32。将其映射到字母表中所有没有歧义的可用字母。 (0vsO 等)
  • 使用 DSA,它往往比 RSA 更紧凑。
  • 使输入更短(例如,截断 sha1 哈希,或改用 md5)也可能使输出更短。

【讨论】:

  • 截断散列,然后使用更少的位进行加密,听起来是个不错的建议。
【解决方案2】:

将每个 SHA1 字符视为十六进制,可能删除任何不必要的格式(破折号或方括号),使用一些数组映射以某种随机顺序将 0-9A-F 转换为 AP,将其用作“人类”输入的文本. MD5 将为您提供 32 个字符或更多用于 SHA1 的字符。将字符解映射回您的 SHA1/MD5 字符串/字节,然后从那里继续。

【讨论】:

  • 好的,但问题是“有没有办法...简化非对称加密哈希。
  • 我认为你如何到达字节/字符串并不重要,不对称与否。哈希输出被“设计”为“占用”位空间,即:128 位、160 位等。您可以按原样处理它,也可以对其进行后处理:截断它或将其煮沸选择,但您将失去散列的唯一性或/和散列的加密强度。一个简单的截断应该可以工作并且“足够好”,在与截断部分进行比较之前,您可以在内部计算完整的哈希值。
  • 分发非对称密钥的哈希是没有意义的;您必须在客户端中包含私钥以验证哈希!我正在计算一个哈希值,然后对其进行加密,that 是我的(长)许可证密钥。
【解决方案3】:

加密部分我不会回答,但是我已经开始做注册界面的事情是在界面被提升时检查剪贴板中的文本。如果剪贴板上有文本,请扫描它以查看用户是否从某处(电子邮件、网页等)复制了他们的注册信息,以及您是否找到可能的信息strong> 成为您的注册信息/密钥,使用它预先填充注册界面。

在界面上显示一个小警报也是一个好主意,指示信息已成功从剪贴板中抓取(或没有!),以便用户知道发生了什么或没有发生什么。

【讨论】:

    【解决方案4】:

    目前创建短许可证密钥的最佳基于签名的方法似乎是the Boneh–Lynn–Shacham signature scheme,尽管它是相当新的(评论不多)并且没有在常见的加密工具中实现。

    这是一种使用通用 openssl 和 bash 的方法:

    openssl ecparam -genkey -name sect113r1 -out private.key # generate the private key (store it on your server)
    openssl ec hist-in private.key -pubout -out public.key # generate a public key (store it in the client software)
    # generate a random one time activation userID or a hardware-based one here (CLIENT SIDE)
    user_id="unique_on_the_fly_generated_user_ID" # send the user ID to the server for license generation
    signature=""
    return_value=0
    while [[ $return_value == 0 ]]
    do
        signature=$(echo "$user_id" | openssl dgst -sign private.key | base64 > signature.txt) # generate a user licence
        echo "$signature" | egrep -q 'O|l|/|\+|=' # check for ambiguous chars
        return_value=$?
    done
    echo "$signature" | base64 -d > signature.txt # send the signature/license to the client
    openssl dgst -verify public.key -signature signature.txt # verify signature (CLIENT SIDE)
    

    请注意,您仍然会获得一个 48 个字符长的签名/许可证密钥(加上一个通用的“M”标头字符,您可以避免发送)。据我所知,您目前无法使用 openssl 生成更短的签名。

    【讨论】:

      【解决方案5】:

      我会考虑 MD5 算法。它被广泛实施,无论输入大小如何,都会生成一个 32 个字符的字母数字字符串。将算法应用于您的 SHA1 哈希,它可能就是您正在寻找的。​​p>

      【讨论】:

      • MD5 只会比 SHA1 节省四个字节,而且不管它不是加密,只是一个哈希。任何计算出输入数据的人都可以生成自己的许可证密钥。通过添加私钥/公钥对,他们将无法在没有私钥的情况下创建新许可证。 (他们仍然可以破解二进制文件,但这是一个不同的问题)
      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2011-04-20
      • 2010-10-30
      • 2011-02-24
      • 1970-01-01
      • 2011-09-23
      • 2012-02-29
      • 2023-03-13
      相关资源
      最近更新 更多