Return to Question

I am currently working on a file encryption software that works via AES-GCM-256 and I am looking for feedback on the encryption key generation process I intend to implement.

So far, I have come up with the following process:

1. User supplies password or key file.

Then, per file that is to be encrypted:

1. Password/key file from (1 above) is hashed via SHA256 once.
2. The result from SHA256 is base91-encoded and sent through a script (N=2^15, r=8, p=1) with a randomized 16-byte salt to derive a 32-Bit key for AES-GCM.
3. The file is encrypted and authenticated using AES-GCM with the key from (2) using a randomized 96-bit nonce as iv.
4. Script-values (N, r, p, and salt) and the AES-GCM nonce (=iv) get stored (unencrypted) in the file header for decryption.

The program does make sure it doesn't process files larger than 2^39 - 256 Bits (size limit for AES-GCM encryption from NIST 800-38D).

Is this design flawed in any serious way?

I am currently working on a file encryption software that works via AES-GCM-256 and I am looking for feedback on the encryption key generation process I intend to implement.

So far, I have come up with the following process:

1. User supplies password or key file.

Then, per file that is to be encrypted:

1. Password/key file from (1 above) is hashed via SHA256 once.
2. The result from SHA256 is base91-encoded and sent through scrypt (N=2^15, r=8, p=1) with a randomized 16-byte salt to derive a 32-Bit key for AES-GCM.
3. The file is encrypted and authenticated using AES-GCM with the key from (2) using a randomized 96-bit nonce as iv.
4. Scrypt-values (N, r, p, and salt) and the AES-GCM nonce (=iv) get stored (unencrypted) in the file header for decryption.

The program does make sure it doesn't process files larger than 2^39 - 256 Bits (size limit for AES-GCM encryption from NIST 800-38D).

Is this design flawed in any serious way?

I am currently working on a file encryption software that works via AES-GCM-256 and I am looking for feedback on the encryption key generation process I intend to implement.

So far, I have come up with the following process:

1. User supplies password or key file.

Then, per file that is to be encrypted:

1. Password  / key file from (1 above) is hashed via SHA256 once.
2. Result from from SHA256 is base91-encoded and sent through scrypt (N=2^15, r=8, p=1) with a randomized 16-byte salt to derive a 32-Bit key for AES-GCM.
3. File is encrypted and authenticated using AES-GCM with key from (2) using a randomized 96-bit nonce as iv.
4. Scrypt-values (N, r, p and salt) and the AES-GCM nonce (=iv) get stored (unencrypted) in the file header for decryption.

The program does make sure it doesn't process files larger than 2^39 - 256 Bits (size limit for AES-GCM encryption from NIST 800-38D).

Is this design flawed in any serious way?

Thanks!

Joe

I am currently working on a file encryption software that works via AES-GCM-256 and I am looking for feedback on the encryption key generation process I intend to implement.

So far, I have come up with the following process:

1. User supplies password or key file.

Then, per file that is to be encrypted:

1. Password/key file from (1 above) is hashed via SHA256 once.
2. The result from SHA256 is base91-encoded and sent through a script (N=2^15, r=8, p=1) with a randomized 16-byte salt to derive a 32-Bit key for AES-GCM.
3. The file is encrypted and authenticated using AES-GCM with the key from (2) using a randomized 96-bit nonce as iv.
4. Script-values (N, r, p, and salt) and the AES-GCM nonce (=iv) get stored (unencrypted) in the file header for decryption.

The program does make sure it doesn't process files larger than 2^39 - 256 Bits (size limit for AES-GCM encryption from NIST 800-38D).

Is this design flawed in any serious way?