Comment by usrbinbash
6 hours ago
Why does my text-editor need to do "encryption at rest"? If I want data encrypted, I store it in an encrypted drive with a transparent en/decryption layer.
6 hours ago
Why does my text-editor need to do "encryption at rest"? If I want data encrypted, I store it in an encrypted drive with a transparent en/decryption layer.
That is completely valid for personal threat models, I rely on LUKS/BitLocker for my daily driver too.
The specific gap this fills is 'Defense in Depth' + compliance. OS-level encryption (like FDE) is transparent once you log in. If you walk away from an unlocked machine, FDE does nothing.
App-level encryption, however, ensures the specific sensitive notes remain encrypted on disk even while the OS is running and the user is authenticated.
It's also portable as it allows the encrypted blob to be moved across untrusted transports (email, USB, cloud) without needing to set up an encrypted container/volume on the destination.
For FIPS/NIST workflows, relying solely on the OS often isn't enough for the auditor; having the application control the keys explicitly satisfies the 'data protection' control regardless of the underlying storage medium.
> If you walk away from an unlocked machine
...then I might as well ask what happens when I walk away from the encrypting edior while a file is still open. User Error can happen with any encryption or security schema. Pointing out a trueism is not an argument.
> It's also portable
So is encrypting files using a specialized tool. I don't need my editor to do this. The entire point of my criticism, and indeed the entire point of this thread, is that software that should focus on a narrow task, tries to do way too much, leading to problems.
For what it's worth I understood the argument and think it is valid. It's one thing for the file you're working on to be vulnerable if you walk away leaving the editor open; it's another for all of your other files to be vulnerable too. It's O(1) vs. O(n). The difference is clearly not zero.