使用密码和种子进行加密时哪种过程更安全

发布于 2024-11-09 03:05:00 字数 1343 浏览 0 评论 0原文

我正在为加密应用程序设计一个程序和文件格式。当我需要就加密的方法/工作流程做出决定时,我遇到了这样的情况。我无法决定使用一种方法相对于另一种方法的利弊。

下面是格式结构的概述:

------------------------------------------
| File signature || fixed    | plain     |
|----------------||----------|-----------|
| Algorithm info || fixed    | plain     |
|----------------||----------|-----------|
| Seed           || fixed    | encrypted |
|----------------||----------|-----------|
| Data           || variable | encrypted |
|----------------||----------|-----------|
| CRC            || fixed    | encrypted |
------------------------------------------

最初,我将使用 SHA-256 作为哈希函数,使用 AES-256 作为加密算法,但稍后它将使用正如格式所示,是可配置的。

建议的创建加密容器的过程:

  1. Hash(Password) =>密钥传递
  2. 生成随机种子
  3. 密钥传递 XOR 种子 =>密钥种子
  4. 使用密钥传递加密种子并存储加密种子
  5. 使用密钥种子加密数据并存储加密数据
  6. 使用密钥种子加密 CRC 并存储加密 CRC

问题

A. 我从存储加密中获得什么吗种子和 CRC?如果我不加密存储它们,安全性会降低吗?

B. 使用 [ Hash(Password + Seed) ] 进行密钥生成与使用 [ Hash(Password) XOR Seed ] 作为最终密钥相比,在安全性上是否存在或多或少或没有差异?

C. 上述两个问题的结论性问题。使用替代过程来创建加密容器是好是坏:

  1. Hash(Password + Seed) =>密钥
  2. 存储未加密的种子
  3. 使用密钥加密数据并存储加密的数据
  4. 存储未加密的 CRC(或加密)

我想我必须存储未加密的种子才能在读回加密内容时重新生成密钥。 CRC 可以是加密的,也可以是未加密的。

I am designing a procedure and file format for the encryption application. I came to a point when I need to make a decision regarding the method/workflow of the encryption. I can't make up my mind on pros vs cons of using one approach over another.

Below is an overview of the format structure:

------------------------------------------
| File signature || fixed    | plain     |
|----------------||----------|-----------|
| Algorithm info || fixed    | plain     |
|----------------||----------|-----------|
| Seed           || fixed    | encrypted |
|----------------||----------|-----------|
| Data           || variable | encrypted |
|----------------||----------|-----------|
| CRC            || fixed    | encrypted |
------------------------------------------

Initially, I am going to use SHA-256 for a Hash function and AES-256 for an Encryption algorithm, but later it will be configurable, as the format suggests.

Proposed procedure for creating encrypted container:

  1. Hash(Password) => Key-Pass
  2. Generate random Seed
  3. Key-Pass XOR Seed => Key-Seeded
  4. Encrypt Seed with Key-Pass and store encrypted Seed
  5. Encrypt Data with Key-Seeded and store encrypted Data
  6. Encrypt CRC with Key-Seeded and store encrypted CRC

Questions

A. Do I gain anything from storing encrypted Seed and CRC? Would it be less secure if I store them not encrypted?

B. Is it more or less or no difference in security of using [ Hash(Password + Seed) ] for key generation rather than prosed [ Hash(Password) XOR Seed ] for the final key?

C. A concluding question from two questions above. Would it be better or worse to use the alternative procedure for creating encrypted container:

  1. Hash(Password + Seed) => Key
  2. Store unencrypted Seed
  3. Encrypt Data with Key and store encrypted Data
  4. Store unencrypted CRC (or encrypted)

I guess I would have to store unencrypted Seed in order to regenerate Key on reading back the encrypted content. CRC can be either encrypted or unencrypted.

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

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

发布评论

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

评论(2

手心的海 2024-11-16 03:05:00

构建自己的加密文件格式总是很困难(而且有风险)。

密钥生成
请使用 PBKDF2 (PKCS #5 v2.0, RFC 2898)来生成您的密钥。这将要求您以未加密的格式存储盐(您称之为种子)。

CRC存储
如果您已经达到使用加密的水平,请不要使用 CRC 进行完整性检查。您已经计划在其他地方使用 SHA256,也可以将其用于完整性检查。 (我建议对未加密的数据进行哈希处理并以未加密的方式存储哈希值,尽管您可以根据需要对其进行加密。)

Building your own cryptographic file formats is always tough (and risky).

Key generation
Instead of rolling your own key generation routine, please use PBKDF2 (PKCS #5 v2.0, RFC 2898) to generate your keys. This will require you to store the salt (what you are calling a seed) in an unencrypted format.

CRC Storage
If you're already at the level of using crypto, don't use CRC for integrity checks. You're already planning on using SHA256 elsewhere, use it for your integrity check as well. (I recommend hashing the unencrypted data and storing the hash unencrypted, though you could encrypt it to if you want.)

我不是你的备胎 2024-11-16 03:05:00

如果您将 H(密码)与种子异或,则需要加密存储种子,否则您将泄露哈希值。如果你泄露了哈希值,人们就可以轻松地暴力破解它。这就是大多数协议(如 PBKDF2)使用盐和多次迭代的原因。

您永远不应该保存未加密的 CRC,因为 CRC 提供有关加密容器内数据的信息。与 Eacwacer 建议的哈希相同。您最好使用 MAC(例如也使用密钥生成器生成)。

当您询问特定答案时,我将在下面回答您的问题:

A:最好加密存储
B:H(密码|种子)更安全
C:很难说,XOR 是错误的,纯 CRC 也是错误的,但我仍然会选择第二个

对于未询问的一个:

D:请在上面加上糖,使用众所周知的基于密码的加密算法使用加密安全的完整性检查方式

If you H(password) XOR with the seed, you need to store the seed encrypted, otherwise you will give away the hash. If you give away the hash, people can easily brute force it. That is why salt and a number of iterations is used on most protocols (like PBKDF2).

You should never save the CRC unencrypted since a CRC gives information about the data within the encrypted container. Same as with a hash as Eacwacer suggested. You are better off using a MAC (also generated with the key generator for instance).

As you asked for particular answers, I'll answer your questions below:

A: better store it encrypted
B: H(password | seed) is more secure
C: difficult to say, the XOR is wrong and the plain CRC too, but I would still go for the second one

And for the unasked one:

D: pretty please with sugar on top, use a well known password based encryption algorithm instead and use a cryptographically secure way of integrity checking

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