使用非对称加密生成合理长度的许可证密钥?

发布于 2024-08-30 16:59:35 字数 922 浏览 6 评论 0原文

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

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

长版本:

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

最后——这似乎是最重要的——我真的很想使用非对称加密来使生成新密钥变得更加困难。

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

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

我还查看了 CocoaFob,它确实生成了一个密钥,但它太长了,我无论如何都想将它作为文件提供。

用OpenSSL玩了一段时间但无法想出任何合理长度的内容。

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

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

非常非常感谢您提供解决方案!

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

I've been looking at this all day. I probably should have walked away from it hours ago; I might be missing something obvious at this point.

Short version: Is there a way to generate and boil down an asymmetrically encrypted hash to a reasonable number of unambiguous, human readable characters?

Long version:

I want to generate license keys for my software. I would like these keys to be of a reasonable length (25-36 characters) and easily read and entered by a human (so avoid ambiguous characters like the number 0 and the capital letter O).

Finally--and this seems to be the kicker--I'd really like to use asymmetric encryption to make it more difficult to generate new keys.

I've got the general approach: concatenate my information (user name, product version, a salt) into a string and generate a SHA1() hash from that, then encrypt the hash with my private key. On the client, build the SHA1() hash from the same information, then decrypt the license with the public key and see if I've got a match.

Since this is a Mac app, I looked at AquaticPrime, but that generates a relatively large license file rather than a string. I can work with that if I must, but as a user I really like the convenience of a license key that I can read and print.

I also looked at CocoaFob which does generate a key, but it is so long that I'd want to deliver it as a file anyway.

I fooled around with OpenSSL for a while but couldn't come up with anything of a reasonable length.

So...am I missing something obvious here? Is there a way to generate and boil down an asymmetrically encrypted hash to a reasonable number of unambiguous, human readable characters?

I'm open to buying a solution. But I work on a number of different of platforms, so I'd want something portable. Everything I've looked at so far has been platform specific.

Many, many thanks for a solution!

PS - Yes, I know it will still be cracked. I'm trying to come up with something reasonable that, as a user, I would still find friendly.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

檐上三寸雪 2024-09-06 16:59:36

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

不过,您可以尝试以下几项操作:

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

Unfortunately, no. If you make it shorter, you lose information and won't be able to recreate the original hash.

However, here's a couple things you may try:

  • Use base32. Map it to all the available letters in the alphabet that aren't ambiguous. (0vsO, etc.)
  • Use DSA, it tends to be more compact than RSA.
  • Making your input shorter (truncating the sha1 hash, or using md5 instead, for example) might make the output shorter, too.
感情旳空白 2024-09-06 16:59:36

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

Treat each SHA1 character as hex, perhaps drop any unnecessary formatting, (dashes or brackets), use some array mapping to convert 0-9A-F as say A-P in some random order, use that as your 'human' entered text. MD5 will give you your 32 chars or a few more for SHA1. Unmap the chars back to your SHA1/MD5 string/bytes and proceed from there.

你丑哭了我 2024-09-06 16:59:36

我不会回答加密部分,但我开始做注册界面的事情是在界面启动时检查剪贴板中的文本。如果剪贴板上存在文本,请对其进行扫描以查看用户是否从某处(电子邮件、网页等)复制了其注册信息,以及您是否找到可以的信息是您的注册信息/密钥,用它预先填充注册界面。

在界面上显示一个小警报也是一个好主意,表明信息已成功从剪贴板中抓取(或未抓取!),以便用户知道发生或未发生的情况。

I will not answer on the encryption part, but the thing I have started to do registration interfaces is to check the clipboard for text when the interface is raised. If text is present on the clipboard, scan it to see if the user has copied their registration information from somewhere (email, web page, etc.) and if you find information that could be your registration info/keys, pre-populate the registration interface with it.

It is also a good idea to show a small alert on the interface indicating that the info was successfully scraped from the clipboard (or not!) just so the user knows what did or did not happen.

留蓝 2024-09-06 16:59:36

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

这是使用通用 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 生成较短的签名。

The best signature based method to create short license keys currently seems to be the Boneh–Lynn–Shacham signature scheme, though it is rather recent (not so many reviews) and not implemented in common crypto tools.

Here is a way to do it with generic openssl and 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)

Note that you still get a 48 characters long signature/licence key (plus a generic "M" header char you can avoid sending). As far as I know you can't generate shorter signatures with openssl at the moment.

缱倦旧时光 2024-09-06 16:59:36

我会考虑MD5算法。它得到了广泛的应用,无论输入大小如何,都会生成 32 个字符的字母数字字符串。将该算法应用于您的 SHA1 哈希值,它可能就是您正在寻找的。

I would consider the MD5 algorithm. It's widely implemented and will generate a 32 character alphanumeric string regardless of the input size. Apply the algorithm to your SHA1 hash and it may be what you're looking for.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文