I read several guides and Stackexchange answers, but the more I know, the more I realise how much I don't know. What I learnt is that details of implementation matter and that most popular tools do something wrong.
I can reasonably expect to be individually targeted because of the nature and publicity of my work. I actually were targeted before (unsuccessfully) and I feel that I need to be ready, sooner or later, for more knowledgeable and crypto-sophisticated adversaries (but non-governments). I'm a freelancer, so I don't have any big company behind me which resources I could use for security protocols.
I've been using aes-256-cbc via openssl enc (with default parameters) my entire life, but as my work is getting more publicity and the likelihood of me being targeted increases, I decided to upgrade to a "golden standard".
Cryptographic Right Answers (Latacora, Ptacek) agree to recommend using "NaCl/libsodium’s default", but these are libraries and, as far as I know, don't provide executables. I'm fairly technical and I can program, but I'm not familiar with C language. There are 3rd party libsodium bindings for other languages, so I guess I could cook something up, but I would prefer not to reinvent the wheel and I look for the least error-prone way.
I already know several reasons to don't use openssl cli. I'm not sure if it can be trusted with its implementation of Latacora/Ptacek's 2nd preference ChaCha20-Poly1305 (and if yes, what additional parameters should be specified, if any). It doesn't support their 3rd preference at all (AES-GCM). I also read that gpg has weak key stretching. This exhausts my knowledge of popular linux encryption tools.
Questions:
Is there actually any tool which does encryption "right" out of the box and provides linux shell interface?
If not, is there any tool which does it "right" when configured properly and can you provide the "right" set of parameters?
Or maybe it's best to take node.js or Python bindings for libsodium, make a tiny wrapper and use defaults?
Side question: are there any special considerations to take when encrypting very short pieces of data? Some things which I encrypt are encryption keys or passphrases which are just dozens of bytes long (I know that my currently used AES-CBC is a block cipher, so there's some padding which can be tricky, etc).
Am I being too paranoid wanting to switch from openssl enc aes-256-cbc (considering I can expect to be individually targeted)?
Thank you!
Edit to clarify:
I want to encrypt files at rest.
Adversaries won't be opportunistic and I expect them to spend resources on cracking encryption. They will specifically target what I do and they will know that the data exists somewhere. I might sound a bit paranoid and I admit that I have a paranoid-ish attitude to security, but I think it's the right attitude to this matter and it actually saved my data at least once in the past.
I'm aware of rubber-hose cryptanalysis and I try to include it in my planning to some degree. If you could help planning for this as well, I would be grateful. Right now my plan is to retrieve previously prepared fake data (encrypted using a different key than the real data), hope that it will be realistic enough to satisfy attackers and that they won't be so thorough to demand me to decrypt virtually everything what they find despite already having what they came for.
So, what I was meaning when writing this question was specifically situation in which attackers try to decrypt my encrypted files using technology (non-wrench based). E.g:
- They gained access to encrypted data by compromising my device or by social engineering of 3rd parties (I store copies of some encrypted data online at cloud storages and offline at 3rd parties), but either don't have physical access to me or are not ready to escalate this way. For the most critical data, I don't access it often and even compromising my device most likely wouldn't give access to encryption key (e.g. by seeing it at decryption).
- They gained physical access to me and were fooled by my fake data, but later discovered it's fake so they try to decrypt any other data which they gained access to "in bulk" when they had access to me (or before that).
Deniability for existence of encrypted data might help to protect the real data in situations with physical access to me. Especially if attackers also gained access to offline copy stored at 3rd party, so they know that the data is exactly there (and they gained this access independently, so I cannot retrieve fake data from a different 3rd party). Deniability would allow keeping both files at the same place and decrypt only the fake one without anyone recognising existence of another one. But I consider this last scenario (gaining access to me and to data independently) the least likely, so I guess deniability is not at the top of my requirements.
As for comfortable access to data: the data I'm the most concerned with is not data I access frequently. I can handle a complex and not very comfortable process if it benefits security. However I would like decryption to be a process which average person (not very technical, but also not stupid) is able to perform when given very detailed written instructions. I need and have procedures to access the data and encryption keys by specific people after my death (don't misunderstand me: I'm not that paranoid that I think someone wants to kill me. I just know that of all possible disaster scenarios death is actually the most probable - meaning, I will die at some point in the future - and I need other people to access some of the data then).
Edited to provide more overall assessment of my situation:
Because of what I do (which I would like to not disclose), people/groups might get an idea to breach my secrets for their profit. It happened in the past. I was specifically targeted and someone tried to get access to several of my critical digital assets (access to email, hijack domains, other) using targeted phishing (i.e. not looking like a part of a broad/universal campaign) and social engineering towards 3rd parties. None of this was successful and I did not detect who it was (it stopped some time ago and I think/hope they moved on to focus on easier targets). But because my work is getting more and more publicity, I can reasonably expect more attacks in the future, as they're common and somehow expected in my field. I am not trying to protect against any specific adversary which I know of today, and I don't know who my future adversary might be tomorrow, but I'm in a high-risk group of people likely to be targeted.
I take a lot of measures to protect my data. The first line of defence is "trying to don't get hacked". The second one is to try to minimise damage in case of a breach (and here is where my concerns over encryption belong).
Huge part of my strategy in this area is based on compartmentalization. E.g. my most sensitive data is almost never decrypted on my main computer. I have a separate computer to work on the most sensitive stuff and I try to isolate it as good as I can:
- It usually stays offline and connects only to upload or backup encrypted data (or more rarely: download encrypted data to work on). All these connections are only to my storage.
- I don't do any communication from it and don't even have configured any communication methods. If I need to send data to someone else or upload somewhere else than my standard storage, I encrypt it for someone and upload to storage, then download it on my main computer and send away without being able to decrypt it on main computer.
- I don't do any browsing from it (even accidentally, as it's blocked on firewall). If I need to research something for work, I do it on the main computer.
- I don't plug it anywhere other than electric outlet and don't connect to any peers (even when I want to transfer encrypted results to my main computer, I do it through intermediary storage).
- It's stored in a safe when I'm not working on it. Besides the safe, I don't leave it unattended ever (never leave it in a car trunk or gym locker, etc). I don't travel with it. Of course it uses full disk encryption, but it could be rendered useless if someone tampered with the computer physically.
- (To think of it, I am hardly ever seen with this computer in public as it almost never leaves my office. I sometimes (rarely) take it home (where I have another safe). I don't think I ever worked on it in a public place. I don't think anyone other than my family even seen this computer. This is not some idea for a master-strategy for security through obscurity, just a conclusion that if I will be physically targeted, an adversary will most likely not even know about this device and target my main computer which I often carry with me).
It might look complicated and uncomfortable, but it sounds worse than it is. It's just a basic hygiene and not being sluggish. Also, it's only 10% of my work, the rest of which I am comfortable doing using my main computer (which I also take care to secure as good as I can).
I wrote that the most sensitive data is almost never decrypted on the main computer and someone answered that if I'm targeted, they will attack when the content is unencrypted. The "never decrypt" rule is one that I take seriously. It happened only few times during several years, when faced with emergency-kind need for access the data and only small subset of data were involved (and the same subset each time). Compartmentalization also means separating sets of data and encrypting them using different keys. I did not have any indication I was being actively targeted at that time or that I could be hacked and I took a calculated risk (which I wouldn't even take if it would involve more than this subset of data). Also, I redesigned my processes to minimise risk of such situations in the future.
The point of all this is: while I try to don't get hacked as much as I can, if this ever happened (either directly me or via access to a 3rd party responsible for storage), an attacker would only gain access to encrypted data, as I don't usually decrypt sensitive data on my main computer. Of course they would also gain access to a lot of other data on my main computer, but I'm most concerned about data which I don't access from it. This is a scenario which I want your help to protect from and I think it covers most online / non-physical threats.
I could really use some strictly technical help with how to encrypt data in rest for this scenario using some "golden standards" of modern cryptography.
As for https://xkcd.com/538/ - I really don't know how to prepare for this other than providing bogus or partial data. I can't try total deniability, because attacker will know what they came for. Not very specifically "what-what" or "how much of what", but they will have a general idea of the "kind of what". I can try "partial deniability", which is to feed them with bogus data, or even a moderately valuable subset of real data (which don't really look like a subset or incomplete data; nobody outside knows on how many different projects I work and I'm publicly associated to only smart part of them; so by "subset of data" I usually mean "data for some projects, but not all"). I have several separate subsets of data, encrypted with several keys, some of which I don't need to access anymore on a regular basis. It's believable (and also true) that I'm not able to decrypt everything without visiting some physical locations where I keep old encryption keys. Also in this scenario hard to break encryption will help, as attackers will most likely make a copy of everything, including data which I'm not able to decrypt without accessing offsite keys, and might try to decrypt it later. If anyone has other suggestions for this kind of threats (physical), I'm very curious to read about it too.
This is the best of what I can think in terms of risk assessment. I don't know if it's a "proper risk assessment" according to your standards, but I hope you can use it to help me with my questions.
