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.


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.

  • 7
    I consider this question as too broad. First, it is not clear what you really need to protect (disk, files, email, other communication ...) - all you are taking about is algorithms but not use cases. Then, it is not clear what the capabilities of the attackers are, i.e. do they have physical access or might even use violence. Also, it is sufficient to encrypt the data or is it necessary to deny the existence of any encrypted data too? And note that the harder it needs to get for an attacker the less comfortable it gets probably for you to to access the data. Mar 11, 2019 at 12:49
  • Thanks. I added clarifications to the question. I tried to keep the original question brief, but what I really did is I assumed things and took for granted that people will read my mind. Hopefully the question is better now. Mar 11, 2019 at 15:55
  • Some comments, because event with your clarifications I find your answer too broad: I do not feel that you have a clear idea of what you need to protect and against whom. 1) If they manage to execute code on your device, it's basically game over for you. 2) Also, you should not expect your adversary to be fooled by fake data, because discrepancy are easy to notice and hard to avoid. 3) Do not implement your own crypto, event using libraries. Instead, use something designed to do what you want to achieve, such as LUKS disk encryption or the Tails Linux distribution.
    – A. Hersean
    Mar 11, 2019 at 16:28
  • Re:1) As I wrote, I almost never have the most critical data unencrypted on my main device, so it's not game over even if it's compromised. Expanding on this: I have a separate device to work with critical data and it goes online only when I want to upload new version to cloud. I don't even access web from that device, its firewall rules are very restrictive, and I don't use it for anything else. I don't claim it's unhackable, but I try to minimise opportunities. My main/daily device has access to the storage with encrypted files, so it's a possible attack path to gain access to encrypted data Mar 11, 2019 at 16:55
  • 2
    For point 3, I could give you the answer you seek, but it will not help you reduce the risk you are exposed to. You should do a proper risk assessment and then choose the proper tools to reduce the risks, not the other way around.
    – A. Hersean
    Mar 11, 2019 at 17:08

1 Answer 1


PGP (via the linux gnupg toolset) seems to address your questions, and I've never heard anything bad about its crypto (though I'm expecting someone to post links in comments).

It's well-supported, has good interop with other tools in the PGP world, and for increased security it can use private keys on smartcards or Yubikey-style hardware tokens.

Disclaimer: I did not read your entire question, so forgive me if you've already discounted this for some reason.

Not the answer you're looking for? Browse other questions tagged .