加密：如何将8个字符串变成128位密钥、256位密钥等？
我试图对此进行研究，但仍有一些问题没有得到解答。我正在研究如何将 8 个字符的密码转换为高位加密密钥。在我的研究过程中，我发现了一些谈论盐值的文章。
假设您可以使用全部 256 个字符，那么 8 个字符的密码将是 64 位长。所以，剩下的 64 位只是一个盐值。并且，如果我错了，请纠正我，但这样做是为了如果有人要尝试所有可能的值（强力），他们就必须尝试所有 128 位，因为甚至盐也是未知的。
我的问题确实与这个“盐”值有关：
- 当有人制作应用程序时，盐值是否硬编码到其中？如果是的话，难道不能通过对可执行文件进行逆向工程来获得它吗？
- 如果盐是随机生成的，那么我认为它一定有某种方法来复制它。那么，返回随机盐的函数是否可以进行逆向工程以强制其复制自身以获得盐值？
- 这可能超出了范围，但是如果在服务器端（客户端/服务器关系）生成盐值，那么是否必须与客户端共享它，以便它们可以解密服务器发送的数据？而且，如果它被发送到客户端，它不会被拦截而变得毫无用处吗？
- 除了这个“盐”值之外，是否还有其他方法可以将 8 个字符的字符串转换为强加密密钥？
I tried to research this, but there were still some questions left unanswered. I was looking into figuring out how an 8 character password gets turned into a high-bit encryption key. During my research I found articles that would talk about the salt value.
Assume you could get all 256 characters to play with, then an 8-character password would be 64-bits long. So, the remaining 64 bits is simply a salt value. And, correct me if I'm wrong, but this is done so that if someone was going to try to try ALL the possible values (brute force) they'd have to try all 128-bits since even the salt is unknown.
My questions really relate to this 'salt' value:
- When someone makes an application, is the salt value hard-coded into it? And if so, can't it be obtained through reverse engineering the executable?
- If the salt is generated at random, then I assume it must have some way to duplicate it. So, isn't that function that returns a random salt able to be reverse engineered to force it to duplicate itself to get the salt value?
- This might be out of the scope, but if a salt value is generated on a server side (of a client/server relation), then wouldn't it have to be shared with the client so they can decrypt data sent by the server? And, if it's being sent over to the client, can't it be intercepted which makes it useless?
- Is there some other method that is used besides this 'salt' value that can turn an 8-character string into a strong encryption key?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
与通常的安全相关问题一样，这个答案会很长。
首先，简单回答。
问：如何将 8 个字符的字符串转换为 128 位密钥？
答：有一个没有。
这是一个真实的答案。现在，一个更适合您所要求的：
答：创建一个随机 64 位值，并将其与密码一起存储在数据库中。现在，密码是密钥的一半，随机值是另一半。
这是一个谎言。这就是你实际做的事情：
答：使用生成 128 位或更长输出的方法对密码和随机盐进行哈希处理。使用其中的 128 位作为密钥。储存盐。
现在解答大家关于盐的问题。首先，盐的目的并不是为了延长加密密钥。它是为了防止人们构建彩虹表 - 从散列形式到非散列形式的映射。要查看您的加密是否更强，只需想象攻击者知道您的密钥扩展算法。现在，他不再猜测 128 位密钥，而是猜测您的 64 位密码，然后使用相同的算法。瞧。如果攻击者不知道盐，是的，你已经获得了一些，但他们必须已经拥有你的密文才能攻击他们，并且盐必须与密文一起存储在明文中。所以这是一个不太可能发生的情况。
/dev/random的用途 - 系统熵池非常好。如果你担心的话，就买一个更好的硬件 RNG。As usual with security-related questions, this answer's going to be a long one.
First, the simple answer.
Q: How does one turn an 8-character string into a 128-bit key?
A: One doesn't.
This is a truthful answer. Now, one that's more appropriate to what you're asking:
A: Create a random 64-bit value, and store it with the password in the database. Now, the password is half the key, and the random value is the other half.
This one is a lie. Here's what you actually do:
A: Hash the password along with a random salt using a method producing 128-bit or longer output. Use 128 bits of that as the key. Store the salt.
Now to address your questions on salt. First off, the purpose of salt is not really to lengthen encryption keys. It is to prevent people building rainbow tables - mappings from hashed to unhashed forms. To see that your encryption is no stronger, just imagine the attacker knows your key-extending algorithm. Now, instead of guessing 128-bit keys, he just guesses your 64-bit password and then uses the same algorithm. Voila. If the salt is unknown to the attacker, yes, you've gained a bit, but they must already have your ciphertexts to attack them, and the salt must be stored in the plain along with the ciphertext. So this is an unlikely scenario.
/dev/randomis for - the system entropy pool is very good. Get a better hardware RNG if you're worried.将密码或密码短语转换为加密密钥的函数称为密钥派生函数（这可能有助于您搜索有关该主题的更多信息）。此类函数采用密码和随机生成的盐，并通过故意计算密集的过程生成密钥。要复制该密钥，您必须同时拥有密码和盐 - 所以您是正确的，盐必须与加密数据一起存储或传输。
密钥导出函数使用盐的原因是增加攻击者的工作量。如果不使用盐，则给定的密码将仅产生一个密钥。这意味着攻击者可以轻松创建一个键字典 - 字典中的每个单词一个键。另一方面，如果使用 64 位盐，则每个密码可以生成 ~2**64 个不同的可能密钥，这会以相同的倍数扩展字典的大小。这本质上使得提前生成这样一本字典变得不可能。相反，攻击者必须等到看到盐值，然后开始生成密钥进行测试。由于密钥导出函数的计算量很大，因此速度很慢，并且他无法在合理的时间内查完字典。
The function that turns a password or passphrase into a cryptographic key is called a Key Derivation Function (this might help you searching for more information on the topic). Such functions take a password and a randomly generated salt, and produce a key through a process that is deliberately computationally intensive. To reproduce that key, you must have both the password and the salt - so you are correct, the salt must be stored or transmitted along with the encrypted data.
The reason that Key Derivation Functions use a salt is to increase the work factor for any attacker. If a salt was not used, then a given password will only ever produce one single key. This means that an attacker can easily create a dictionary of keys - one key for each word in his dictionary. If, on the other hand, a 64 bit salt is used then each password can produce ~2**64 different possible keys, which expands the size of the dictionary by the same factor. This essentially makes producing such a dictionary ahead-of-time impossible. Instead, the attacker has to wait until he's seen the salt value, and then start generating keys to test. Since the key derivation function is computationally expensive, this is slow, and he won't be able to get far through his dictionary in a reasonable timeframe.
1）每个密码的加盐方式不同，盐值与哈希值一起存储。
2）已存储。
3）不，客户端永远不会解密任何内容。它发送密码，服务器对密码进行加盐、散列和比较。
4）是的，我会添加一些链接。
1) Each password is salted differently, and the salt is stored with the hash.
2) It's stored.
3) No, the client never decrypts anything. It sends the password, which the server salts, hashes and compares.
4) Yes, I'll add a few links.
盐通常不是硬编码的，而是随机生成的，通常是服务器端的，并且从不传达给用户。
盐通常不是硬编码的，而是随机生成的
盐将存储在数据库中，与密码分开。这个想法是，即使密码哈希数据库被盗，如果没有盐，也很难获得实际密码（您必须尝试很多组合）。这些盐会随机生成，并且对于每个用户来说都是不同的，因此即使您找到了其中一个，您仍然需要找到所有其他盐。
盐永远不会发送，因为客户端永远不会解密任何内容。客户端将密码发送到服务器，服务器添加盐（盐是为每个用户随机生成和存储的，用户永远不知道）。
基本上就是这样。
注册时：
登录时：
在。
Salts are generally not hardcoded, but they are generated at random, usually server-side, and never communicated to the user.
The salt would be stored in a database, separate from the passwords. The idea is that even if the password hash database is stolen, it would be very difficult to get the actual passwords (you'd have to try a lot of combinations), without having the salts as well. The salts would be generated at random, and different for each user, so even if you found it out for one, you'd still need to find all the others.
The salt is never sent, because the client never decrypts anything. The client sends the password to the server, the server adds the salt (which is randomly generated and stored for each user, and the user never know it).
So basically on this is what happens.
On registration:
On login:
in.
...除了这个“盐”值之外，是否还有其他方法可以将 8 个字符的字符串变成强加密密钥？
是的，但是...
您可以计算该 8 字符字符串的哈希值：
例如，如果您需要 256 位密钥：
key-256bit = hash(8-character string) //use SHA-256 - 非常安全
key-128bit = hash(8-character string) //使用MD5不再被认为安全
“变成一个强加密密钥？”关于强......取决于你需要它有多强，因为如果你只使用8个字符的字符串，这意味着你只能创建2^8=256个不同的哈希值，这是一个简单的暴力破解任务！
结论：盐非常有价值！
欢呼
丹尼尔
...Is there some other method that is used besides this 'salt' value that can turn an 8-character string into a strong encryption key?
YES but...
You can compute the hash of that 8-character string:
For example if you need a 256 bit key:
key-256bit = hash(8-character string) //use SHA-256 - very secure
key-128bit = hash(8-character string) //use MD5 no more considered secure
"into a strong encryption key?" about strong.... depend how strong you need it because if you use only a 8-character string it mean that you could only create 2^8=256 different hash values and that's an easy task to brute force!!
conclusion: a salt would be of great value!
cheers
Daniel