Don't decrypt unless it's a ramdisk about age

[Macil]

There's a lot of use-cases where using a ramdisk isn't what you want. If age is just being used to protect files while they're in transit (like hosting encrypted data on a possibly-public cloud host or transporting it on a flash drive), then you probably intend to actually decrypt the file once it's at its destination. It might be that protection is only intended while the file is in vulnerable transit, or the destination might have its own protection like full disk encryption.

The use-cases where you would want to be strict about requiring a ramdisk seem like they would be better addressed by using full disk encryption or by using a system that lets you transparently mount an encrypted directory.

[alerque]

The risk of things being written to disk needs to be solved at the hardware architecture and operating system levels, not the userspace tool level. A tool at the level of age would never be able to reliably measure this anyway, and I would argue that less than perfect detection might be worse than none at all since it would give a false sense of security.

I for one use this an systems with fill disk encryption, inside of VMs, and inside containers, sandboxes, and jails where it would not be able to reliably determine what the risk level was or was not. As such any such restriction would need to come with an override switch anyway, which most people would end up using all the time.

GPG has too much machinery, agents and clients and keyrings and such. This suggestion is to add a bunch of machinery that will work differently on different platforms, will never work completely correctly, etc. I don't think it's the right place to work on this problem.

[Macil]

I think it's valid and within age's scope for it to do things to guide users to use it safely, but I think the specific choice of forcing a user to decrypt to a ramdisk is a very bad one. That limit would be an unnecessary obstacle for all of the use-cases I can see myself using age for, and I would have to instruct everyone I used age with to disable this safety feature, which would cut into age's simplicity and normalize toggling dangerous-looking safety settings. I don't see a situation where I use age (and not some other tool) and actually want age to decrypt to a ramdisk. I'm even worried that the suggestion to use a ramdisk could be dangerous to someone with a privacy-critical use-case and give them false confidence.

The main use-cases I'm picturing for myself with age are where I'm sending a file to someone (and for some reason magic-wormhole isn't usable: maybe we can't both be online at the same time, the file is too big for our network connections, the recipient is myself in the future, or the recipient is a yet-to-be-determined person who eventually happens to solve a puzzle box and find a password I hid) and I need to use a storage medium for this transfer that is more public than I would like, such as a public cloud host or a CD or USB stick that's going to be shipped internationally and may be inspected. The content isn't particularly secret -- I don't care what the recipient does with it once they get it (maybe even the contents originally belong to the recipient and I'm just sending it to their current machine; I'm not trying to assert at all to the recipient that they themselves must continue to keep the contents private from the world) -- but in the same way that I put my letters in envelopes when I send mail and don't put my documents folder on a cloud host in a publicly-accessible configuration, I'd rather keep that same kind of privacy despite making use of a public transfer medium. In this case, the suggestion to use a ramdisk is useless. It might actively confuse the recipient. I would probably instruct the recipient to use a fork of age which doesn't mention anything about ramdisks just so they don't misunderstand the suggestion and think whatever stuff I sent them is dangerous. Age recommending people use a ramdisk is like an envelope that instructs the recipient to burn the contents after reading or store it in a safe.

If someone is very paranoid about keeping the decrypted plaintext completely private, then using a ramdisk isn't enough of a precaution and may even be unnecessary given other precautions, and the suggestion itself could give them false confidence. Most operating systems can page out memory from RAM to disk at any time, and additionally, many programs that people may use to view the decrypted content may keep a cache on disk. Full disk encryption or a live disk-based OS with a temporary file-system would be proper. And if you're using full disk encryption, the reason to use a ramdisk mostly disappears.

[kierenj]

It's a composable unix-style tool: I think being concerned with the output device seems a little out of scope?

[alerque]

Users should not have to know about secret side conditions like AES cipher modes, RSA padding, or the fact that hard drives can't delete data safely.

One of these things is not like the others. I'm not saying it's not an important point — it is — it's just the wrong context.

"Drivers should not have to know about the timing between cylinders of internal combustion engines, cycle depths on lead acid batteries, or the fact that driving under intoxication is dangerous to themselves and others."

The last point is life or death critical to know for safe usage of any user piloted automobile.

A case can certainly be made for self driving cars being safer, and computers that are more secure from top to bottom — but you can't solve DUIs by making cars that pull the emergency brake when they detect a gravel surface! That's what your suggestion is trying to do. It would not make a more useful car, it would just be an obnoxious thing to work around. I'm all for better security models but you kind of need to work with the whole picture (build a whole car) not force one odd-ball feature onto existing platforms.

[cyb3rz3us]

The OP's suggestion violates (or just wholly ignores) part of the reason why 'age' was developed --- to be a simple to use file encryption\decryption utility that employs reliable and trusted cryptographic primitives. As such, forcing decryption to a only a ramdisk doesn't make much sense.

Devs are responsible for writing good code and building good software --- not user actions or behavior. How a given tool is employed is up to the user.

@est31: If you want something like 'age' that only decrypts to a ramdisk, then the best course of action is to fork the code and build the tool you want without forcing other 'age' users into the box you suggest.

[divmgl]

Do you really expect all use cases of decrypting files using age to write to a ramdisk?

[est31]

@Macil if you get data on a flash drive, it's likely that most non-suspecting users will decrypt it to the flash drive as well. On linux, GUI tools will even do it as default! That default is highly unsecure as it's very likely you'll use the USB stick for data transfer in the future. The secure default is to drop support for non-ramdisk locations.

[est31]

For the use cases where you really must put the decrypted file onto a non-ramdisk you can simply copy over the file. It should rather be an opt-out than an opt-in. Usability will always be in conflict with security but for security related software, security should come first.

[philband]

IMHO requiring ramdisk as a default for age would not be sensitive to all of the use cases aswell.
As of the current design it provides a reasonably secure interface, that is usable for lots of people. Requring a ramdisk would IMO significantly decrease the userbase and therefore the usefullness of this project. I would assume, that users that are security minded as @est31 (and me) would always take the neccesary precautions to ensure full-disk-encryption and limiting system access in a sensitve way. Apart from that it should be up to the user to decide on those methods. Maybe a hint in the README would be a good idea.

[est31]

@kierenj

It's a composable unix-style tool: I think being concerned with the output device seems a little out of scope?

Actually my proposal is to only deploy the check if the filename is passed via CLI param. You can still write to stdout and pipe the result to the hard drive if you want.

unix was made with user separation based security in mind. Avoiding to write stuff to hard drives for security reasons wasn't considered. age's ambition seems to be to improve upon the prior GPG generation. GPG has this very flaw that it allows writing to hard disk. It's time to fix it.

[divmgl]

Owner or maintainers should close this issue

[est31]

WTF ramdisks are already a compromise. Ideally, the decrypted data shouldn't get to the file system at all and instead be only available in the RAM of the process that is used to edit/view the data. That's a key flaw of pass: every program running as the user can just read the file containing the password, e.g. html files loaded by the file:// protocol.

Maybe it would be best to remove the option to decrypt to fs for age altogether and just rely on piping. People could still pipe to hard disk if that's what they really want.

[alerque]

Or better yet, write a wrapper project that uses age as the backend primitive but limits the usage to safe environments....

[est31]

How a given tool is employed is up to the user.

Users should not have to know about secret side conditions like AES cipher modes, RSA padding, or the fact that hard drives can't delete data safely. I prefer an error as a failure mode to a possible exposure of private information many times. And no, forking or wrapping age won't help as the unsuspecting users won't use the fork but will likely use age or insecure GUI wrappers (see my comment above about GUI wrappers).

[cyb3rz3us]

Users should not have to know about secret side conditions...the fact that hard drives can't delete data safely

Of course they should...the user's data is their responsibility....full stop. Furthermore, hard drives can and do delete data safely as there are more than several tools which do the job quite nicely.

And of course we have the fact that users should be using some type of whole disk or volume encryption which obviates (or at least significantly mitigates) the concerns stated herein. For example:

1. User decrypts some cypher text to their hard drive which happens to be encrypted using whole disk encryption.
2. User's machine is stolen by certain nefarious entities who's identity is unknown.
3. Said nefarious entities try to recover previously decrypted data but alas...the original user being somewhat security conscious (as evidenced by the fact that they use encryption in the first place) had decent password generation techniques and the HDD withstood all attempted attacks.

[est31]

not force one odd-ball feature onto existing platforms.

Note that most security features started out as odd-ball until global deployment. In the 2000s, SSL was an odd-ball feature. If you wanted encryption, you had to use encrypted.google.com. Now Google is transit-encrypted per default and it's unthinkable that Google would ever switch back, and many other services are https-encrypted as well. Tons of people were mad about the introduction!

Similarly, in the 2000s, you could find many unencrypted WiFis in your neighbourhood and nowadays most of them are encrypted.

We live in an age where we are entrusting computers with more and more private and sensitive data. This development has led to threats becoming ever more sophisticated. Security is following suit, and thus the features considered odd-ball currently may very well become standard in the future. While I'm still convinced that this feature is a good idea, the unpopularity in this thread tells me that maybe it's too early for it.

hard drives can and do delete data safely as there are more than several tools which do the job quite nicely.

When I used the term "hard drive", I meant the meaning that includes both HDDs as well as SSDs. It's possible to safely delete files from HDDs but with SSDs it's not possible due to their complicated (and untrustable) wear levelling layer.

And while full disk encryption is generally a good idea, it's still no protection for the USB stick scenario I outlined above.

[cyb3rz3us]

I don't think anybody is arguing against the merit of saving a decrypt to a ramdisk...I think what most (or at least me) are arguing against is forcing a ramdisk to be the sole decryption destination. Said differently, using a ramdisk as a destination is not unpopular...forcing one to only use a ramdisk is what is unpopular. That said, let me reiterate that the security of one's data is 100% their responsibility --- not the tool devs. So if people opt to not understand and properly use tools that empower them to be secure, then that's on them.

As to SSL being an "odd-ball feature", I would humbly suggest to check the history. SSL predates Google by at least 3-4 years as the first public release of SSL was in 1996 shortly after Andreessen et al spun out Navigator v1.0.

Last, and just musing here...but after decrypting to ramdisk, what's to prevent the user from then copying the contents of the ramdisk to a non-volatile device? Should 'age' also disable copy from ramdisk after decryption has taken place?

[colmmacc]

is a Ramdisk really secure enough? We know that in some cases, particularly with consumer grade RAM, that contents can be inferred by other processes using rowhammer and similar attacks. RAM contents have been recovered in sophisticated theft attacks too (e.g. freezing with LN), and can be read with physical side-channels like micro-antennae. Why not have age be the agent that renders the material to be read by a human to the screen buffer directly? And even then, it should use HDCP.

O.k., only kidding ... but we could always take this line of reasoning further and further. Personally as long as age doesn't /prevent/ me from using a Ramdisk, I'm happy and I think that's a cool suggestion to make to users and an ephemeral bin for decryption is something that OSes should think about supporting; because SSD risks are real and a bit more practical than what I outlined.

[cyb3rz3us]

Change the term from "make" to "compel" or "encourage" and then we can talk...but "making" users do anything should be forbidden...