Assuming that the system is cryptographically strong knowing those keys will do you no good. Now, many such systems are implemented by guys too cheap to buy a real keygen so you might still have a hope.
Just a little back of the envelop estimation says that such a key has 125 (was 800 oops, thanks for catching that) bits of information, if you sampled that space enough you might be able to make some sort of an attack, but you are talking about a huge number of sample points. But hey, what other plans did you have for your spare time?
Even the big guys mess this up, a half dozen years ago there was a mistake in the way MSDN keys were being generated that allowed some sort of brute force attack. You would find guys selling MSDN subscriptions on eBay as part of a corporate licensing bundle. You would submit your info and they would give you a preregistered MSDN account in a couple of days. I am pretty sure they were taking advantage of a bug in the implementation and brute forcing the enrollment until one stuck.
A company I worked for bought one, Microsoft honored it since we were none the wiser when we bought it, but they were interested in the address of the guy who sold it to us.
This is notoriously hard to solve in the general case. However, if
I'm also told it is an industry standard algorithm
if this is the case, you should obtain a list of those "standard algorithms", and analyze them for weaknesses.
My naïve guess is that most key generation is of the form x || hash(x || fixed), where x is a randomly generated value for each key, and fixed is a fixed value. Using this form, keys can be validated quite easily (extract x, calculate hash(x || fixed), see if it matches).
Assuming you knew the exact algorithm used, you'd either have to find a weakness in the algorithm (not likely, unless they are using a hash with known vulnerabilities), brute-force the fixed value, etc.
Given that there are lots of hashes which do not have known vulnerabilities and if you assume that the guys who chose the fixed value where not dumb... this might be a tough cookie unless you have good cryptanalysis skills available.
So the problem is very hard to solve if the guys who designed the algorithm are not dumb. But they might be...
Keys that are validated offline tend to be defined by a set of some properties. Certain subsets of bits have certain values or symmetries. If certain subsets of bytes passed to certain functors return the expected result then the key is deemed valid.
If you researched common algorithms for generating keys you could probably come up with a universe of possible properties. You could then use inductive logic programming to find which of those properties apply to all valid keys, but not invalid keys. (You also need a set of invalid keys, but those are easy to generate). From the results you could theoretically write a keygen. You could also probably write a paper out of it, if you can get it to work. Good luck.
If they're validated online however, they may simple be pseudo-random numbers that are checked against a database. In that case you are SOL.
In general, the answer is, "No, you can't do anything useful."
If the people generating the keys got lazy and failed to use some sort of cryptographic-quality hash off of an index number (with sufficient bit-mixing to thwart any inspection on your part), then you might assume some sort of functional form of random number generation and see if you can back out, for example, a modulus for a linear congruential random number generator, or a series of bit-mixing shifts and adds and such as in the Jenkins hash function or whatever.
There are no algorithms for going from some generic structure that you spot to the algorithm that produces said structure; something akin to this is what you appear to be asking for. (Such algorithms are provably impossible in general; if you want the simplest algorithm that can compute your keys, the problem is isomorphic to the computation of Kolmogorov complexity, which is fiendishly hard ("effectively impossible thus far") to compute.)
The system could generate the keys randomly then have clients check against a central server. That is just as secure as any other DRM algorithm, that is to say not at all. In this case, extrapolation is impossible.
发布评论
评论（5）
假设系统在加密方面很强大，知道这些密钥对您没有任何好处。现在，许多这样的系统是由那些太便宜而无法购买真正的注册机的人实现的，所以你可能仍然有希望。
信封估计的后面一点说这样的密钥有 125 个（是 800 哎呀，谢谢你抓住了）信息位，如果你对这个空间进行了足够的采样，你可能能够进行某种攻击，但你是谈论大量的样本点。但是嘿，你的业余时间还有什么其他计划吗？
即使是大公司也搞砸了，六年前，MSDN 密钥的生成方式存在一个错误，允许某种暴力攻击。您会发现有人在 eBay 上销售 MSDN 订阅，作为企业许可捆绑的一部分。您只需提交您的信息，他们就会在几天内为您提供一个预先注册的 MSDN 帐户。我非常确定他们正在利用实施中的一个错误并强制注册，直到有人卡住为止。
我工作的一家公司买了一个，微软很荣幸，因为我们买它时并不知情，但他们对卖给我们的人的地址感兴趣。
Assuming that the system is cryptographically strong knowing those keys will do you no good. Now, many such systems are implemented by guys too cheap to buy a real keygen so you might still have a hope.
Just a little back of the envelop estimation says that such a key has 125 (was 800 oops, thanks for catching that) bits of information, if you sampled that space enough you might be able to make some sort of an attack, but you are talking about a huge number of sample points. But hey, what other plans did you have for your spare time?
Even the big guys mess this up, a half dozen years ago there was a mistake in the way MSDN keys were being generated that allowed some sort of brute force attack. You would find guys selling MSDN subscriptions on eBay as part of a corporate licensing bundle. You would submit your info and they would give you a preregistered MSDN account in a couple of days. I am pretty sure they were taking advantage of a bug in the implementation and brute forcing the enrollment until one stuck.
A company I worked for bought one, Microsoft honored it since we were none the wiser when we bought it, but they were interested in the address of the guy who sold it to us.
众所周知，这在一般情况下很难解决。然而，如果
如果是这种情况，您应该获取这些“标准算法”的列表，并分析它们的弱点。
我天真的猜测是，大多数密钥生成的形式为 x || hash(x||fixed)，其中x是每个键随机生成的值，fixed是固定值。使用这种形式，可以很容易地验证密钥（提取x，计算散列（x || 固定），看看它是否匹配）。
暴力破解固定值，等等。
假设您知道所使用的确切算法，您要么必须找到算法中的弱点（不太可能，除非他们使用具有已知漏洞的哈希），要么 没有已知漏洞的哈希值，如果你假设选择固定值的人并不愚蠢......这可能是一个很难的饼干，除非你有良好的密码分析技能。
所以如果设计算法的人不傻的话这个问题是很难解决的。但他们可能是...
This is notoriously hard to solve in the general case. However, if
if this is the case, you should obtain a list of those "standard algorithms", and analyze them for weaknesses.
My naïve guess is that most key generation is of the form x || hash(x || fixed), where x is a randomly generated value for each key, and fixed is a fixed value. Using this form, keys can be validated quite easily (extract x, calculate hash(x || fixed), see if it matches).
Assuming you knew the exact algorithm used, you'd either have to find a weakness in the algorithm (not likely, unless they are using a hash with known vulnerabilities), brute-force the fixed value, etc.
Given that there are lots of hashes which do not have known vulnerabilities and if you assume that the guys who chose the fixed value where not dumb... this might be a tough cookie unless you have good cryptanalysis skills available.
So the problem is very hard to solve if the guys who designed the algorithm are not dumb. But they might be...
离线验证的密钥往往由一组属性定义。某些位子集具有某些值或对称性。如果传递给某些函子的某些字节子集返回预期结果，则该键被视为有效。
如果您研究了生成密钥的常见算法，您可能会想出一系列可能的属性。然后，您可以使用归纳逻辑编程来查找哪些属性适用于所有有效键，但不适用于无效键。 （您还需要一组无效密钥，但这些密钥很容易生成）。根据结果，理论上您可以编写一个注册机。如果你能让它发挥作用，你也可以用它写一篇论文。祝你好运。
然而，如果它们是在线验证的，它们可能只是根据数据库检查的伪随机数。在这种情况下，你就是 SOL。
Keys that are validated offline tend to be defined by a set of some properties. Certain subsets of bits have certain values or symmetries. If certain subsets of bytes passed to certain functors return the expected result then the key is deemed valid.
If you researched common algorithms for generating keys you could probably come up with a universe of possible properties. You could then use inductive logic programming to find which of those properties apply to all valid keys, but not invalid keys. (You also need a set of invalid keys, but those are easy to generate). From the results you could theoretically write a keygen. You could also probably write a paper out of it, if you can get it to work. Good luck.
If they're validated online however, they may simple be pseudo-random numbers that are checked against a database. In that case you are SOL.
一般来说，答案是：“不，你不能做任何有用的事情。”
如果生成密钥的人变得懒惰并且未能使用索引号的某种加密质量散列（具有足够的位混合来阻止您的任何检查），那么您可能会假设某种随机函数形式数字生成，看看是否可以退出，例如，线性同余随机数生成器的模数，或一系列位混合移位和加法，例如 Jenkins 哈希函数或其他函数。
没有算法可以从您发现的某些通用结构转换为生成所述结构的算法；您似乎正在要求类似的东西。 （这样的算法通常被证明是不可能的；如果你想要最简单的算法来计算你的密钥，那么这个问题与柯尔莫哥洛夫复杂度的计算是同构的，而柯尔莫哥洛夫复杂度的计算极其困难（“到目前为止实际上不可能”）。）
In general, the answer is, "No, you can't do anything useful."
If the people generating the keys got lazy and failed to use some sort of cryptographic-quality hash off of an index number (with sufficient bit-mixing to thwart any inspection on your part), then you might assume some sort of functional form of random number generation and see if you can back out, for example, a modulus for a linear congruential random number generator, or a series of bit-mixing shifts and adds and such as in the Jenkins hash function or whatever.
There are no algorithms for going from some generic structure that you spot to the algorithm that produces said structure; something akin to this is what you appear to be asking for. (Such algorithms are provably impossible in general; if you want the simplest algorithm that can compute your keys, the problem is isomorphic to the computation of Kolmogorov complexity, which is fiendishly hard ("effectively impossible thus far") to compute.)
系统可以随机生成密钥，然后让客户端根据中央服务器进行检查。这与任何其他 DRM 算法一样安全，也就是说根本不安全。在这种情况下，外推是不可能的。
The system could generate the keys randomly then have clients check against a central server. That is just as secure as any other DRM algorithm, that is to say not at all. In this case, extrapolation is impossible.