Using different algorithms to slow down GPU password cracking [duplicate]

Question

I have some job related files I have already compressed with 7Z.

I have protected each with good 10 character passwords consisting of upper, and lower cases, numbers and special characters.

And I have enabled header encryption of the filenames.

I am not yet concerned about the physical security of my system or side channel attacks, but I have heard that GPUs are getting faster at bruteforcing even complex passwords.

Another lesser concern is that the implementation of AES in 7Z might be vulnerable.

But what if I encrypt the files with another symmetric cipher?

My theory is that such a setup keeps me secure even if an adversary succeeds in bruteforcing the outer envelope or exploits a weakness in 7Z's implementation of AES.

What's your take on the following method:

7za a -p -mhe myarchive.7z myfiles

gpg --output myarchive.pgp --symmetric myarchive.7z

I have read about meet in the middle attacks, but so far I understand the risk, it's only an issue if the adversary is able to reduce the key space by trying to decrypt key1 and key2 simultaneously.

But will this be an issue if the outer envelope doesn't give any clues as to how the next layer is encrypted?

Answer 1

Using a second layer of symmetric encryption prevents the secret data from being revealed if only a single layer is broken.

However, I don't think this is the smartest way to counter potential massive GPU brute-forcing attacks - what actually helps against them are three things:

1. use an encryption scheme that incorporates a key derivation function

2. the encryption should use a salt along the password. Chosing a salt value from a good PRNF with enough entropy or directly from a good hardware RNG is paramount.

3. ensure the password is recursivle hashed multiple times, as often as possible to not make the encryption scheme impossible. This considerably slows down brute force attacks.

   PBKDF2 provides all of the above features, but scrypt (which I would recommend over the other if you are that concerned over the security of your data) adds the additional one:

4. the hash function used to derive the keys should be relatively efficient to execute on a general purpose computer, but difficult to execute on specialized hardware (ASIC) by using a serial, non-parallelizable hash function that needs a lot of RAM to work.

So, I would look out for a good (read: used by others already with good reviews) open/free source implementation of an encryption program using scrypt. AFAIR GnuPG only supports PBKDF2, which is pretty good, but not as good as scrypt, which is its main deficiency.

Answer 2

The use of a secondary encryption layer would, in my opinion, mitigate the risk of the information being decrypted if there were some issues with AES implementation resulting vulnerabilities in 7z.

But I think a more valuable and easier way for you to mitigate the risk of a brute force attack cracking your password would be to use a much longer password (pass phrase). Depending on the usability factor, I'd go for a 32 or even 64 character pass phrase. Yes, length is not everything when it comes to passwords but using 64 characters with the same key space moves the possibility of cracking your password from unlikely to practically impossible during our lifetime even with the increased processing power of GPU's.