Geek Answers Handbook

Which procedure is more secure for encryption using password and seeds

I am developing a procedure and file format for an encryption application. I came to the conclusion that I need to make a decision regarding the encryption method / workflow. I can not decide on the pros and cons of using one approach over another.

The following is an overview of the format structure:

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

At first I use SHA-256 for the Hash function and AES-256 for the encryption algorithm, but later it will be configured as the format offers.

Suggested procedure for creating an encrypted container:

  • Hash (Password) => Key-Pass
  • Generate random seed
  • Key-Pass XOR Seed => Key-Seeded
  • Encrypt Seed with Key-Pass and Store Encrypted Seed
  • Encrypt data with Key-Seeded and store encrypted data
  • Key-Seeded CRC Encryption and Saving Encrypted CRC

Questions

A. Do I get anything from storing encrypted seeds and CRC? Would it be safer if I did not store them in encrypted form?

B. Is this more or less a difference in the security of using [Hash (Password + Seed)] for generating keys, and not for the profile [Hash (Password) XOR Seed] for the final key

C. The final question of the two questions above. It would be better or worse to use an alternative procedure to create an encrypted container:

  • Hash (Password + Seed) => Key
  • Store unencrypted seeds
  • Encrypt data with a key and store encrypted data
  • Store unencrypted CRC (or encrypted)

I think I would need to store an unencrypted seed in order to recover the key when reading encrypted content. CRC can be either encrypted or unencrypted.

+4
source share
2 answers

If you are H (password) XOR with a seed, you need to save the encrypted seed, otherwise you will give the hash. If you refuse the hash, people can easily overcome it. This is why salt and several iterations are used on most protocols (e.g. PBKDF2).

You should never keep the CRC unencrypted, since the CRC provides information about the data in an encrypted container. Same as hash, as Ewacker suggested. You are better off using a MAC (also generated by a key generator, for example).

When you asked specific answers, I will answer your questions below:

A: it’s better to keep it encrypted B: H (password | seed) is more secure C: it’s hard to say that XOR is wrong and simple CRC too, but I’ll go to the second anyway

And for the unoccupied:

D: enjoy sugar from above, use the well-known password-based encryption algorithm and use a cryptographically secure way to verify integrity.

0
source

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

Key Generation Instead of starting your own key generation procedure, use PBKDF2 (PKCS # 5 v2.0, RFC 2898 ) to create your keys. This will require you to save the salt (what you call the seed) in an unencrypted format.

CRC Storage If you are already using cryptography, do not use CRC to verify integrity. You are already planning to use SHA256 elsewhere, use it to verify integrity. (I recommend that you hash the unencrypted data and store the hash unencrypted, although you can encrypt it if you want.)

+3
source

More articles:


All Articles