3 ms·
The same guy that brought us https://github.com/FiloSottile/age https://github.com/FiloSottile/age I really like this tool.
by vbezhenar 3y ago
The same guy that brought us https://github.com/FiloSottile/age https://github.com/FiloSottile/age
I really like this tool.
- candiddevmike 3y agoAge is nice but seems to have stagnated--last release is from 2022, and it's not using a more modern PBKDF like argon. If you're looking for something designed for secret storage/sharing, checkout rot: https://github.com/candiddev/rot https://github.com/candiddev/rot
- tptacek 3y agoNot changing since 2022 is a feature, not a bug. It's an exchange format, so it was never going to switch KDFs just for funsies, and scrypt is fine.
- dpatterbee 3y agoI wouldn't describe age as having stagnated, it's simply stable. It has a well defined spec which it fully implements (seemingly correctly), so there isn't any need for more recent releases. Also I think it's a bit sly to not mention that you're the creator of the alternative you suggest.
- FiloSottile 3y agoage is intentionally stable as a format and as a core tool. There is a lot of activity in the integration and plugin ecosystem, which I am very happy about. https://github.com/FiloSottile/awesome-age https://github.com/FiloSottile/awesome-age I have a wishlist for v2 changes, and I am considering slowly and carefully making such a release this year, but the difference in security between scrypt and Argon2 doesn't really justify making a change there.
- varispeed 3y agoShame it doesn't have plausible deniability built in. That is you could encrypt at least two files and decrypt one of them based on which key you provide. This seems to be a security flaw of most of these kind of tools. That is there is only one possible key, so someone with a hammer can make you disclose it. But if the number of keys is unknown, you can give up some keys and hope attacker will leave you alone, without revealing the actual protected file.
- woodruffw 3y agoI don’t understand the threat model for plausible deniability in a file encryption tool: any adversary that would physically compel you to provide one key would also know that you’re potentially being dishonest about that key. In other words: plausible deniability on decryption doesn’t satisfy the adversary; they’re just going to torture you until you hand over the real key. (Maybe there are scenarios, like airport security, where the adversary probably won’t torture you but needs the appearance of decryption? But I don’t think the adversary in those scenarios is thinking about file encryption tools; they’re thinking about your phone’s PIN or biometric lock.)
- eviks 3y agoYou seem to understand it with your own example of airport security types of situations. There are also other similar law enforcement actions where the people wouldn't have enough info to have a high enough degree of certainty that you possess something to be able to get suspect enough to cause additional harm on not finding it when the keys are disclosed
- varispeed 3y ago> In other words: plausible deniability on decryption doesn’t satisfy the adversary; If there is only one key that decrypts the file, then they will have validation whether you provided the right one. For instance if you have encrypted your crypto wallet info. You would have to give up the real key that will decrypt the file. With plausible deniability scenario, you could have encrypted two wallets, one that you afford to lose. You can give it up and it's possible the attacker will be satisfied and you can keep the wallet that you care about. The attacker will also never know if there are more keys. Mind you, they can always shoot you either way, but with the plausible deniability you might have a chance to leave the wallet you care about to your dependents.
- woodruffw 3y ago> With plausible deniability scenario, you could have encrypted two wallets, one that you afford to lose. You can give it up and it's possible the attacker will be satisfied and you can keep the wallet that you care about. The observation here is that there's a _very_ narrow slice of adversaries that satisfy the following constraints: 1. Are willing to force you to hand over private key material; 2. Are ignorant to the underlying thing they're looking for; 3. Are ignorant to the fact that your choice of encryption scheme allows for plausible deniability. This model assumes all 3, when in reality almost any adversary that satisfies (1) is not going to satisfy (2) or (3) -- they almost always have a sense of what they're looking for (i.e., they know the wallet isn't empty or they wouldn't waste their time on you) and, given that, they aren't going to be fooled by a scheme that explicitly supports plausible deniability. We can always contrive exceptions, of course. But part of secure design and threat modeling is having a reasonable conception of your adversary.
- deleted 3y ago[deleted]
- vaylian 3y agoI want to like this tool, but it lacks a manual or a tutorial that describes typical usage. I don't mean how to use the command line. That is well-documented. But I want to know how I should manage and distribute my keys and what I need to look out for. The entire social layer on top of the technology is unclear to me. Some stories featuring Alice and Bob would be great.