# Strongest file encryption available

I know nothing about cryptography. How does one encrypt a file in the strongest possible way, such that it can be accessed some years later? I prefer that it should be fairly resistant from brute force and other possible ways attacks.

I need some direction only.

• This could be better answered on the Cryptography SE site. Commented Jun 19, 2020 at 8:28
• Also recommend moving to Cryptography SE. I feel OP also needs to further explain his threat model. If he just does AES-GCM with a single key the contents of files can swapped with eachother without it being detectable... and without such a model from OP, it's impossible to actually answer this question Commented Jun 19, 2020 at 16:34
• The strongest encryption is to have the fastest computer you can find continuing to encrypt the data until about half the time before you require the data has elapsed. You would then use the same computer and begin decryption - if it took six months of computer time to encrypt, it will then take six months to decrypt - even with the key. Clearly this is foolish, so the answer is that, whatever your threat model is, the "strongest" achievable encryption is not going to be either sensible or practical. You need to first define your threat model and then design the encryption strategy to match.
– J...
Commented Jun 19, 2020 at 18:17
• @J... Clearly you're joking, but I'll take you seriously just to say: Remember that if the lights go off while your super-fast computer is encrypting the only copy of your data... you had better have a recovery plan. Commented Jun 19, 2020 at 20:17
• Technically a "one time pad" is unbeatable (and that's the strongest you're going to get!), but if OP can store a key as long as the file securely, then why not store the file there instead? As has been said before, we need a threat model to answer the question. Commented Jun 19, 2020 at 20:27

The strongest possible way to encrypt data is to start with a threat model. What sort of adversary are you trying to protect your data from? What are they willing to do to get it? All reasonable approaches to cryptography start with one. If you start with one, you stand a chance of finding "the strongest" for your particular situation.

I recommend this approach because, as you start thinking about threat models and researching them, you'll start to realize that security is far more about the human element. Then you can worry about things like how you will secure your key.

source: https://xkcd.com/538/

Once you have decided whether you are trying to outwit a state actor while committing treason, or just merely trying to protect your diary from the prying eyes of your little sister, you can decide what the best algorithm is.

Failing that, go with the flow. Rather than finding out what is the "strongest" encryption, look for what is "recommend" by the security experts for someone who knows nothing of cryptography. Currently AES comes highly recommended. We're quite confident that nobody short of a state actor can break it, and we are reasonably confident that no state actor can break it either.

But better yet, don't look for encryption algortihms, look for tried and true packages which are recommended. The application of an algorithm is as important as the algorithm itself. Highly reputable implementations are worth their weight in gold.

• Is there an SI-Standard for weight of code? Maybe source-code printed on standard paper in font-size 10 ? Commented Jun 22, 2020 at 10:57
• @Falco SLoC. Here are some more characters such that I can post this comment. Commented Jun 22, 2020 at 12:13

If you want the strongest, I’d suggest a one-time pad to encrypt the file.

If you want realistic, I suggest you rather expand on what your threat model is and take advice as to the actual level of encryption that you need is.

• And then put the one-time-pad in a tiny titanium capsule and embed it subcutaneously in your hip. 🤪 Commented Jun 19, 2020 at 20:20
• That could easily be detected and extracted. Keep the entire thing in your head. Commented Jun 20, 2020 at 13:31
• @bytepusher you could be tricked into revealing it. Burn it. Commented Jun 20, 2020 at 14:54
• Or they might extract it with a wrench. Commented Jun 20, 2020 at 16:25
• If you already have the data, then the utility of a one time pad becomes negative: you now have to secure twice the amount of data. OTPs are only useful when you know you will need some secure channel in the future and have access to a secure channel that you will not have access to later (hence their history in espionage). Commented Jun 21, 2020 at 9:56

I know nothing about cryptography. How do we encrypt a file in strongest (emphasis added) possible way such that we can access them some years later. I prefer that it should be fairly resistant from brute force and other possible ways attacks. I need some direction only.

Use AES-256 in GCM mode.

• This. Yes, the many other comments are right, about threat models and OTPs, but this simple answer will cover at least 99.99% of cases quite well.
– Tom
Commented Jun 21, 2020 at 20:06

This isn't a problem with an obvious solution. You need to plan in advance how you are going to handle and safely store your key material as well as your encrypted material. The strength and type of encryption is also part of that plan. If you lose your key, you can't decrypt your data. If someone grabs a copy of your key, they can decrypt the data. If you lose the encrypted data, you can't recover it. And so on...

I suggest you take a look at GnuPG which implements a hybrid encryption scheme, whereby data is encrypted with a one-time session key (symmetric crypto) protected by the recipient's public keys. There are userland tools ready to be used to generate and handle key pairs and to encrypt/decrypt using this mechanism.

I'm not aware of the top of my head of which tools can do symmetric encryption using AES-256/GCM, although it is likely that openssl and libressl can. You need to be careful with generating properly random encryption keys, since at this level you may not have the support of a userland tool to ensure your keys have enough entropy.

• The Windows API will do AES/GCM for you
– hft
Commented Jun 19, 2020 at 20:51
• I doubt any tool encrypts files with asymmetric cipher directly; that's too computationally expensive. Instead they just encrypt a random key and encrypt the actual data with a symmetric cipher. It is also possible to create the symmetric key using a key derivation function (pbkdf2) from a passphrase. Openssl (1.1.1g) does not support GCM in enc though. Commented Jun 19, 2020 at 21:48
• What would be the advantage of using asymmetric encryption in this scenario, where we have just a single user? Commented Jun 20, 2020 at 8:42
• @janHudec gnuog does exactly that, asymmetric cryptography. Being computationally expensive is not necessarily a problem if the solution does not need to scale. Commented Jun 20, 2020 at 22:37
• @Pedro GnuPG uses symmetric encryption for it's data just like all other tools do. The public key encryption just encrypts the key for the symmetric encryption. It's not just computationally expensive to use public key cryptography, it mathematically doesn't work. Public key encryption can't encrypt arbitrarily-sized data on it's own, only something smaller than the key size. Commented Jun 22, 2020 at 0:12

There are issues on the stored data, it may be corrupted and altered. That can be detected with integrity and authentication and solved with data protection methods.

Another issue is how one stores a cryptographic key. This can be solved with a good password to remember with high entropy and Key Derivation Functions.

1. Choose a good password with diceware so that it has an entropy equal with the desired key size like 128,192,256, etc.
2. Use password-based key derivation function like PBKDF2, Scrypt, or Argon2id to derive a cryptographic key, for example, 128-bit for AES128 or 256 bits for AES256. In the case of multiple files, additional data can be used to derive different keys for each file.
3. Encrypt the file with AES-GCM or ChaCha20-Poly1305 both are Authenticated Encryption that provides confidentiality, integrity, and authentication.

Notes:

1. You may need to keep multiple copies of the file since integrity only detects errors. It is not an error correction code.
2. The key size up to you. If you fear the multiple target attacks and possible quantum computers use a key size 256.
3. The IV of GCM or ChaCHa20 should not be repeated. A counter combined with random is advised.

I'd say to use 4096 bit encryption. I use this when generating ssh keys. I've read that even quantum computers are a good 30 years away from cracking current encryption techniques and I don't think that the NSA can crack it because the articles I've read from such sources as the ACLU blog indicate that the government is using malware to spy because they can't crack current encryption standards although sha1 was recently cracked. Congress has been trying to rush through legislation to require back doors in encryption but I believe this is ill advised. The mathematical formulas behind the encryption algorithms used today are ubiquitous and they cannot be wiped from the public domain. They tried outlawing the exportation of encryption in the 90s when pgp was developed and it proved unenforceable because the internet is global.

• Your expression "4096 bit encryption" is meaningless in this context. It only describes the size of the key. It is the encryption technique or algorithm that matters. A crude encryption with a 4096 bit key could be cracked with a pencil and paper in a few hours. Commented Jun 19, 2020 at 17:00
• Note that because far from any number is a valid RSA key, a 3072-bit RSA key is only about as good as a 256-bit key of a suitable elliptic-curve DSA. Commented Jun 19, 2020 at 21:59
• @JanHudec Is that really the reason? (I thought the reason is good factoring algorithms) As far as google answers, there are around $\frac{n \log \log n}{\log n}$ semiprimes (and I don't think so many of them are invalid), and also with that logic generating valid RSA keys should be 2^2816 times as hard as generating keys for other algorithms, but all programs somehow do that quickly. Commented Jun 20, 2020 at 14:04