[est31]

I'm not a big fan of tools that take encrypted data, and decrypt it by creating a decrypted file on disk. They give you a false sense of security. Files, even if they get deleted, remain on hard disks. On SSDs they are even harder to remove, as there is a complicated layer of indirection. Even if you shred the file before deletion, it's possible that it will keep being stored by the SSD, maybe even permanently if a block containing the decrypted content is being decomissioned.

The classical gpg based tools have this very same problem. The classical response is to suggest ramdisk usage, ideally for the entire OS (like a live system basically) to avoid getting artifacts onto the disk like clipboard history, cached thumbnails, or log files. pass for example uses such ramdisks. I disagree that this is a good solution though. Of course it is more thorough, but it requires additional intervention/setup, and not everyone has the needed expertise. Instead, I think the encryption tool itself should take care to only store the decrypted content in non-paged RAM, and give users read/write access through a GUI or a TUI. It should be a ready downloadable solution, similar to the TOR browser bundle. The TOR browser is also trying to not put anything onto the hard disk.

[nullc]

This tool is heavily setup to work with streams.

However, if your disk is exposed -- lots of other things, including shell history, swap, etc. may give you away.

The problem with stuff like "gives users read/write access" -- is that it presumes a narrow use case. What if you're encrypting digital audio? Source code? etc.

Should it also turn on your mic and try to determine if you're in a room alone? :P Demand you use an anti-tempest font?

There is only so much a tool can do. It's important that the tool does what it can within the context that it'll be used, but beyond that the best it can do is be clear about it's limitations.

[est31]

> However, if your disk is exposed -- lots of other things, including shell history, swap, etc. may give you away.

Good that you point out shell history. You probably mean stuff like secrets being passed to age via CLI params? That's quite dangerous even if you put a space before the command which excludes it from your shell history. Any user on your system has read-access to the CLI arguments of every other process on your system. I've filed an issue upstream about this: https://github.com/FiloSottile/age/issues/37

I've mentioned swap in my comment. It's a problem indeed. On Linux you can prevent memory regions from being swapped out via mlock, but only to a certain limit if you are unprivileged (limit on my machine is 64 MB it seems). Windows seems to have a way as well. It's solvable in general and RAM is cheap. It's OSs that have to catch up. Even with the looming swap danger, your data is still more safe in RAM as it doesn't neccessarily get swapped while if it's on your hdd/ssd, it is almost certain to actually land there as well (instead of living in the RAM's cache).

> The problem with stuff like "gives users read/write access" -- is that it presumes a narrow use case. What if you're encrypting digital audio? Source code? etc.

That's a good point. Due to the point you made above (swap, shell history, etc leaking data to disk), it would be best if specialized tools handled the file, which are vetted to not leak any data onto the disk. You could think of a model where age is a library, the tools manually vetted with that in mind. Or you could think of a model where age is embedded into a runtime and the tools are sandboxed wasm modules without access to anything but RAM. Admittedly this is a huge project and one shouldn't expect age to be such a runtime.

A good stopgap would age enforcing best practices by checking whether the destination of the decrypted content is a ramdisk or not. I've filed an issue about this: https://github.com/FiloSottile/age/issues/36

[FiloSottile]

Thanks for opening reports! I'll get to them soon.

Note that there are no secrets passed on the age CLI, for the reasons you mention. Only public keys, flags and file paths.

Being a file encryption tool, I think decrypting files to disk is core functionality with legitimate use cases, like backups and encrypted cloud storage.

[baby]

What’s the point of decrypting a binary (non-text) file and not putting it on disk? What if I have to open it with photoshop?

[est31]

The functionality should either be built into the OS, or into Photoshop. Photoshop should support decryption of the file on the fly. It should best be paired with a "private" mode where it stores nothing about your activities (most programs store some artifacts of your behaviour e.g. vlc stores last opened files or kate stores which line you last edited or something like that).

[baby]

> be built into the OS, or into Photoshop

You're already setting yourself up for failure here, there's no way every single tool you're using will integrate encryption in them.

I agree that the OS should do better, but unfortunately that is not the world we live in at the moment so user tools are what is needed.

[dmos62]

You can put the decrypted file on a RAM file system, if the size constraints are satisfied.

[eeZah7Ux]

Spot on. We need better primitives to encrypt and decrypt stuff on the fly while accessing the disk.

BTW it's written Tor, not TOR