TLDR: Which algorithm is safest if we exclude AES, Twofish, Serpent and Whirpool?

My threat model is archiving and backing up important and private files.

Files will be stored in many places including clouds, so count them as publicly accessible.

I plan to store them for the next upcoming 100+ years in the future. Of course, nobody can imagine what computers will look and work in 2100 - BUT at least I can try to mitigate security risks.

Super strong and random password is a sure thing.

So I encrypt those files with VeraCrypt using AES-Twofish-Serpent cascade, Whirpool as the hash.

But in case that someday a flaw will be found in any given algorithm or in its implementation (in VeraCrypt itself), I want to add an additional layer of protection - another software and another algorithm.

BCArchive seems like a great opinion. (Do you agree?)

They state:

"Compressed archive with strong encryption

BCArchive utilizes the following encryption algorithms, standards and specifications:

Symmetric algorithms: Rijndael (AES), Blowfish-256, Blowfish-448, IDEA, CAST5, GOST 28147-89, Triple DES
Secure Hash Algorithms: SHA-256, SHA-1, MD5 and RIPEMD-160
Asymmetric (public/secret key pair) algorithms: RSA, ElGamal / Diffie-Hellman
Specifications for public/secret key pair format: PKCS #12, X.509
PKCS #5 recommendations for the implementation of password-based cryptography
RFC 2440 specifications for session keys encrypted by symmetric or public key encryption algorithms"

When I open advanced settings to modify it, I am given these options:


  1. Which algorithm/hash method mentioned above is best if we exclude AES, Twofish, Serpent and Whirpool?
  2. I think that in case of VeraCrypt AES-Twofish-Serpent is better than Serpent-Twofish-AES because the outermost encryption is strongest (AES will be the first layer needed to break - do I understand that correctly?). Do you agree? Please give me your opinions and do not say that it doesn't matter.

(And please, PLEASE, do not say this is overkill.)

  • None of the algorithms have a particular higher security margin, so mixing multiple is the only option in this case. However I don’t think for any you can make reasonable predictions for 100 years (besides it is not likely they will hold) – eckes May 13 at 0:08
  • "I plan to store them for the next upcoming 100+ years in the future. [...] So I encrypt those files with VeraCrypt [...] I want to add an additional layer of protection [...] BCArchive seems like a great opinion" What are the odds that people will be able to access BCArchive or VeraCrypt files in over 100 years? Let's take a different example: about 35 years ago, WordStar was very popular, and it basically dealt with text; nowadays, how easy is it to find tools that can work with WordStar documents? – a CVn May 13 at 12:12
  • @aCVn Just because it's not easy to find tools for these formats, they are not hard to reverse engineer. If you could easily break AES, for example, then you could likely reverse engineer VeraCrypt with significantly less effort. Anyway, I have a CP/M emulator that I believe actually does have WordStar on it... – forest May 13 at 23:01

I won't say that it's overkill, but I will say that I think you need to get a better understanding of cryptography before attempting to secure your data for 100+ years.

Encrypting in a cascade is actually difficult to do correctly. You need each algorithm to be truly cascaded such that it's impossible to determine if one has been successfully broken without breaking all the others. If you use one encryption program and then another one on top of that, an attacker will be able to break each cipher one at a time. A true cascade (as VeraCrypt does) would make it such that an attacker would need to break every cipher at once to know whether or not they have succeeded. Unless you either modify the code of VeraCrypt yourself, or use an alternate utility that allows true cascading, what you're doing is a bad idea.

Let's go over the ciphers you have available. Blowfish, IDEA, CAST5, and 3DES have a 64-bit block size, making them insecure for encrypting large amounts of data. 3DES is further vulnerable to linear and differential cryptanalysis which becomes possible when encrypting very large amounts of data. This leaves only GOST and Camellia. The GOST algorithms have not been extensively analyzed, so I would not trust them for long-term use. This only leaves Camellia, a cipher with a high security margin. I would suggest Camellia.

Now let's go over the hashing algorithms you have. For PBKDF2, an algorithm that iterates a single hash multiple times to slow down brute force attacks, the choice of algorithm doesn't particularly matter. However, let's exclude MD5, SHA-1, and RIPEMD-160 anyway for being old. This leaves us with SHA-256, SHA-512, SHA3-512, and Skein-512. SHA-256 and SHA-512 are both quite secure. The former is, paradoxically, slower than the latter on 64-bit CPUs. They are both good choices. SHA3-512 is based on the Keccak permutation, which has a remarkably high security margin. However, it's designed to be fast in hardware, not software. This means that an attacker with a hardware-accelerated SHA-3 implementation has a significant advantage. Finally, there's Skein-512. It is an ARX hash which is quite fast in software and is a solid choice, though it does not have nearly as much analysis as many of the others. Overall, I would suggest SHA-512.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.