[HN Gopher] Age is a simple, modern and secure file encryption t...
___________________________________________________________________
Age is a simple, modern and secure file encryption tool, format,
and Go library
Author : gjvc
Score : 254 points
Date : 2024-08-04 22:42 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| ashconnor wrote:
| Rust version: https://github.com/str4d/rage
| rcarmo wrote:
| Such an appropriate name.
| e3bc54b2 wrote:
| Age (and its rust implementation Rage) combined with agenix[0]
| and age.el[1] has made my self-hosted deployment and management
| so, so easy without compromising security. That, when combined
| with general NixOS conveniences is why I'm able to self-host at
| all. If not for these, just the anxiety of having to setup new
| server in case of whatever loss and the associated
| time/opportunity loss kept me from dong the same for years.
|
| Anyway, just want to say that Age is great!
|
| P.S. The author also did an analysis of Restic the backup tool
| [2] which also prompted me to setup nice backup solution for my
| machines. Pretty cool.
|
| [0]: https://github.com/ryantm/agenix
|
| [1]: https://github.com/anticomputer/age.el
|
| [2]: https://words.filippo.io/restic-cryptography/
| ggpsv wrote:
| Can you elaborate on how age (and the downstream packages) has
| made a difference in your workflows?
| sharperguy wrote:
| With agenix, you can encrypt your secrets, such as API keys,
| and have them stored in your git repo alongside the system
| configuration (which in nixos is just a bunch of text files).
| Then you only need to provision the server with the ed25519
| private key corresponding to the pubkey the files were
| encrypted with, and agenix will automatically decrypt the
| files on boot and place them in /run/agenix, with the
| specified access permissions.
| SOLAR_FIELDS wrote:
| So like SOPS, but specific to nix somehow? What is the
| advantage of the nixy integration here vs the universality
| of SOPS? Better native integration with NixOS?
| e3bc54b2 wrote:
| Similar to sops in a sense that both allow
| encryption/decryption with SSH keys.
|
| In terms of NixOS integration, both are on equal footing.
|
| I'm just unfond of yaml is all.
| fmbb wrote:
| So you still need a secret when provisioning, and you need
| to handle change management for that, and storing it
| securely outside of the git repo. And agenix did not change
| that workflow, or did it?
| e3bc54b2 wrote:
| Yes and no.
|
| I only need to care about my SSH key(s). Which I had to
| anyway. But now the secrets for all the services (except
| SSH) lie right besides their config. Any change in one or
| other is directly visible in git log.
|
| In short, age cut down on the number and types of secrets
| that I have to manage out of band. Which is very good.
| It's always easier to be able to remember 2 things
| (config + SSH keys) than 2+n things (config + SSH keys +
| whatever secret mechanism any service uses, times number
| of services).
| Foxboron wrote:
| You could also include SSH keys as public secrets.
|
| https://github.com/Foxboron/ssh-tpm-agent
| zelphirkalt wrote:
| Server deployment/management tools like Ansible have their own
| file encryption and string encryption tools builtin.
| max-privatevoid wrote:
| But then you'd have to use YAML
| zelphirkalt wrote:
| I concur, that is an unfortunate side-effect. The only
| thing you can then do is to treat yaml as a thing that is
| constantly out to get you. Make all values strings and use
| things like > or >- to write strings without having to
| escape quotes, don't rely on any referencing, except for
| Ansible's templating itself. Do not code in yaml. Or, if
| you really want to, perhaps you could even write yaml like
| json, since json should be accepted format for yaml files.
| ElectricalUnion wrote:
| If the thing accepts YAML it often also accepts a
| equivalent JSON.
| valczir wrote:
| yaml is a superset of json, so by definition anything
| that accepts yaml _must_ accept json
| turboponyy wrote:
| More notably, then you'd have to use Ansible.
| shlant wrote:
| any suggestions on a better config management tool?
| max-privatevoid wrote:
| NixOS
| worldsayshi wrote:
| Coming from Ansible I can understand the distrust in yaml.
| But I haven't seen half as much yaml weirdness in
| Kubernetes (and i associate age/sops with k8s). At least
| not since I stopped making my own helm charts.
| hardwaresofton wrote:
| I've used git-crypt[0] with great success. It uses git smudge
| so you never commit secrets if you set it up properly the first
| time.
|
| Unfortunately, it doesn't support groups.
|
| For a solution that scales to teams, check out SOPS[1]. You
| have to do a little more work to be sure that secrets are
| ignored in the repo but it works reasonably well and is well
| known.
|
| Transparent support at the editor level (age.el) sounds really
| nice though.
|
| [0] https://github.com/AGWA/git-crypt
|
| [1] https://github.com/getsops/sops
| sidpatil wrote:
| You forgot to include the links.
| mkl wrote:
| These?
|
| [0] https://github.com/AGWA/git-crypt
|
| [1] https://github.com/getsops/sops
| hardwaresofton wrote:
| Yes! Thank you :)
| sharperguy wrote:
| I have been using agenix and it is very helpful. I am also
| looking into writing a system module that makes it easy to
| generate secrets on the fly.
|
| A lot of secrets are just things like, backend and frontend of
| some service need to be configured with matching keys, but are
| both running on the same device. In that case you could have a
| systemd service which just generates a new random key if it
| doesn't already exist, and then ensure that the dependent
| services wait for that service to complete. That way you don't
| have to store anything in git for those at least.
| mattmein wrote:
| Check out agenix-rekey[https://github.com/oddlama/agenix-
| rekey], it has the ability to set up secret generators.
| lifeisstillgood wrote:
| Recommended in here I believe:
|
| https://www.latacora.com/blog/2020/03/12/the-soc-starting/
| fmajid wrote:
| No, it's here (scroll all the way to the bottom):
|
| https://www.latacora.com/blog/2019/07/16/the-pgp-problem/
| aborsy wrote:
| When will there be a post quantum version, or a plugin by the
| same author?
| lf-non wrote:
| There is also an official typescript implementation [1] and sops
| supports it natively [2].
|
| [1] https://github.com/FiloSottile/typage
|
| [2] https://github.com/getsops/sops?tab=readme-ov-
| file#encryptin...
| kitd wrote:
| > _The author pronounces it [age] with a hard g, like GIF_
|
| Lol, or 'git' according to one of my more sensitive colleagues.
| thaumasiotes wrote:
| 'Git' is a preexisting word; it'd be pretty strange to
| pronounce it with a soft G.
|
| https://en.wiktionary.org/wiki/git#Etymology_1
|
| https://en.wiktionary.org/wiki/git#Etymology_2
|
| It'd be like naming your software fukr and then insisting "no
| no no, the R is pronounced 'are', not 'er'."
| ljlolel wrote:
| Or Coq?
| nvy wrote:
| Coq is pronounced exactly how it looks. It's the French
| word for rooster and for the language, comes from part of
| the guy's name.
| kitd wrote:
| _Git ' is a preexisting word; it'd be pretty strange to
| pronounce it with a soft G._
|
| It certainly was when I heard it.
| zokier wrote:
| Age is good at what it does, but note that afaik you probably
| should almost always pair it with something like signify[1],
| because age doesn't have integrity/authenticity verification (by
| design).
|
| [1] https://man.openbsd.org/signify.1
| Sh4pe wrote:
| I always use minisign [1] for this. It is small and self-
| contained.
|
| [1] https://github.com/jedisct1/minisign
| q2dg wrote:
| Or Minisign (https://jedisct1.github.io/minisign)
| makeworld wrote:
| Pretty sure age does have integrity and authenticity due to the
| use of AEAD.
| zokier wrote:
| its complicated: https://words.filippo.io/dispatches/age-
| authentication/
| lrvick wrote:
| For someone that never ever needs signing or authentication,
| including for ones own backups, who never has malware in their
| threat model, and trusts this specless tool will be maintained
| forever, maybe this makes sense?
|
| Even then openssl or sq can solve the problem in the same number
| of commands but with sntabdards.
|
| Most people are best off going with a modern implementation of
| the PGP standard, ideally via a smart card to protect you from
| key exfil via malware.
|
| Tools like Keyfork, Sequoia, and/or openpgp-card-tool are almost
| certainly what you want for most personal signing, encryption,
| and authentication use cases.
|
| You get broad compatibility with many many different tools.
| amluto wrote:
| > Even then openssl or sq can solve the problem in the same
| number of commands but with sntabdards.
|
| Using OpenSSL to properly encrypt a file is next to impossible,
| and if you actually succeed at doing so, you're very unlikely
| to be following a defined standard.
|
| I'm not familiar with sq.
|
| > modern implementation of the PGP standard
|
| The PGP standard is an unmitigated disaster.
| e12e wrote:
| > I'm not familiar with sq.
|
| The reimplantation of PGP as a clean rust implantation with a
| simple cli (sq) is imnho quite exiting:
|
| https://sequoia-pgp.gitlab.io/sq-user-guide/
|
| I do think perhaps it's too little too late - bit in contrast
| with age it does provide for signing and authentication as
| well as simple(-ish) key/certificate management.
| dpatterbee wrote:
| > trusts this specless tool will be maintained forever
|
| As per the third sentence of the readme there indeed is a
| spec[0]. There is also an alternative implementation in the
| form of rage[1], as well as numerous others listed on the
| awesome-age page[2].
|
| [0]: https://github.com/C2SP/C2SP/blob/main/age.md
|
| [1]: https://github.com/str4d/rage
|
| [2]: https://github.com/FiloSottile/awesome-age
| Retr0id wrote:
| Age is not specless.
| woodruffw wrote:
| Age uses standard (and modern) cryptography, and is itself
| standardized[1].
|
| This is in contrast to the PGP ecosystem, which is infamously
| fragmented and insistent on maintaining support for insecure
| and home-baked schemes (e.g. 4880's weird custom CFB mode).
| Sequoia has made some progress on the UX side of things, but
| PGP is a dead horse as far as modern, _even conservative_
| cryptographic software design goes.
|
| [1]: https://github.com/C2SP/C2SP/blob/main/age.md
| FiloSottile wrote:
| _o/ hi all, age author here! age is the one of my projects that
| grew most organically into an ecosystem. It's always great to see
| what people build with it. Happy to answer any questions.
|
| Here are some previous discussions
|
| 132 points on Feb 26, 2023 | 77 comments |
| https://news.ycombinator.com/item?id=34936504
|
| 126 points on Sept 26, 2022 | 54 comments |
| https://news.ycombinator.com/item?id=32980141
|
| 113 points on June 11, 2022 | 33 comments |
| https://news.ycombinator.com/item?id=31705670
|
| 494 points on Sept 6, 2021 | 88 comments |
| https://news.ycombinator.com/item?id=28435613
|
| 466 points on Dec 27, 2019 | 199 comments |
| https://news.ycombinator.com/item?id=21895671
|
| and here some related resources
|
| - a list of age ecosystem projects
| https://github.com/FiloSottile/awesome-age
|
| - the format specification https://c2sp.org/age
|
| - the Go library docs https://pkg.go.dev/filippo.io/age
|
| - the CLI man page https://filippo.io/age/age.1
|
| - the large reusable test suite (which I should write about!)
| https://c2sp.org/CCTV/age
|
| - an interoperable Rust implementation by @str4d
| https://github.com/str4d/rage
|
| - an official TypeScript implementation
| https://github.com/FiloSottile/typage (based on libsodium.js in
| the latest version, and on pure-js Noble libraries on main)
|
| - a YubiKey plugin by @str4d https://github.com/str4d/age-plugin-
| yubikey
|
| - the plugin protocol specification https://c2sp.org/age-plugin
|
| - a Windows GUI by @spieglt https://github.com/spieglt/winage
|
| - a discussion of the authentication properties of age
| https://words.filippo.io/dispatches/age-authentication/
|
| - a discussion of the plugin architecture
| https://words.filippo.io/dispatches/age-plugins/
|
| - a discussion of a potential post-quantum plugin
| https://words.filippo.io/dispatches/post-quantum-age/
|
| - a password-store fork that uses age instead of gpg
| https://github.com/FiloSottile/passage (see also: how I use it
| with a YubiKey https://words.filippo.io/dispatches/passage/)
| nabla9 wrote:
| Maybe I'm dense but I can't figure out howto
| verify/authenticate encrypted files.
|
| Is there something missing in the documentation.
| vaylian wrote:
| Age is designed for a single purpose: Encryption and
| decryption of files. To create digital signatures use another
| specialized tool like minisign instead.
|
| Specialized tools are simpler than one do-it-all tool.
| CGamesPlay wrote:
| Simpler, but not necessarily as capable! From <
| https://words.filippo.io/dispatches/age-authentication/>:
|
| > If you encrypt and then sign, an attacker can strip your
| signature, replace it with their own, and make it look like
| they encrypted the file even if they don't actually know
| the contents.
|
| > If you sign and then encrypt, the recipient can decrypt
| the file, keep your signature, and encrypt it to a
| different recipient, making it look like you intended to
| send the file to them.
| upofadown wrote:
| Both cases assume that the user doesn't understand what a
| signature means. In either case it means that the signer
| certified the thing signed. Are paper signatures getting
| so rare that we are collectively starting to forget this?
| PhilipRoman wrote:
| > make it look like they encrypted the file even if they
| don't actually know the contents.
|
| I might as well encrypt a message "add $10000 to my
| account" with the bank's public key, sign it with my own
| key and send it...
| wuiheerfoj wrote:
| Afaik the x25519 recipient uses chacha20poly1305 which is
| authenticated
| upofadown wrote:
| Only in the case of symmetrical encryption. Then the
| authentication is based on the shared secret key.
| hosteur wrote:
| Hi
|
| Do you have an opinion or comment on this?
| https://news.ycombinator.com/item?id=41159236
| KolmogorovComp wrote:
| For those wondering, they answered
| https://news.ycombinator.com/item?id=41160037
| alexgartrell wrote:
| Age is great. I used the rust crate to write an ftp server that
| encrypts the files before they hit disk (specific use case is
| having a drop box for my network scanner) and I love the
| simplicity and composability it provides.
|
| One feature request: it would be awesome to have paraphrase
| encryption for age private keys.
| FiloSottile wrote:
| Identity files can be passphrase encrypted and cmd/age will
| transparently ask for the passphrase before using them. Is
| that what you meant?
|
| https://github.com/FiloSottile/age?tab=readme-ov-
| file#passph...
| alexgartrell wrote:
| Yeah that's it. Probably just wasn't supported in the rust
| age library when I used it. Will double check.
| qyckudnefDi5 wrote:
| Have you considered writing passage in Go to integrate age and
| age-plugin-yubikey as a single binary to make it more
| convenient to setup and use?
| eterps wrote:
| Age is a much better experience than PGP/GPG, even though it only
| has a subset of GPG's features.
|
| The option and argument handling is intuitive; it makes sense
| instantly. It gives a more grounded understanding of what's
| happening with the encryption process, especially because of the
| short-form recipient format.
|
| Also, setting it up with a Yubikey and Passage (a GNU pass
| alternative for Age) was a breeze.
| Comma2976 wrote:
| >$this is a much better experience than $that, even though it
| only has a subset of $that's features
|
| I concur, and:
|
| sed 's/even though/because'
| ementally wrote:
| https://www.kryptor.co.uk/ is much more secure than age.
|
| From their FAQ [0]:
|
| >Kryptor uses strong, fast, and modern cryptographic algorithms,
| offering post-quantum security. It also addresses security
| limitations of tools like age and Minisign.
|
| >Unlike most tools, Kryptor limits metadata by using an
| indistinguishable from random encrypted file format. Encrypted
| files have no identifiable headers and are randomly padded. File
| names can also be encrypted.
|
| And from their Secure section [1]:
|
| >Private key encryption for protection at rest, unlike age.
|
| [0]: https://www.kryptor.co.uk/faq#why-should-i-use-kryptor-
| over-...
|
| [1]: https://www.kryptor.co.uk/#secure
| jmprspret wrote:
| I'd never heard of this. Looks very very interesting!
|
| I'd be keen to know Filippo's (age creator) opinion on this, if
| he has any.
| aborsy wrote:
| It does not support hardware keys.
|
| An Age key can be in a PIV slot of a Yubikey. With a secret
| manager such as Passage, you will have secure access to
| secrets.
| FiloSottile wrote:
| Thanks for sharing, always happy when my projects inspire
| alternatives addressing different parts of the design space.
| Here are a few quick comments based on skimming the
| documentation, let me know if I misinterpreted anything.
|
| - signing support
|
| This has always been a non-goal for age. It makes the UX
| significantly more complex, but it's good if different tools
| have different goals.
|
| I can't quite make out from
| https://www.kryptor.co.uk/specification if it does proper
| signcryption, sign-then-encrypt (vulnerable to signature
| stripping and re-signing), or encrypt-then-sign (vulnerable to
| decrypt-reencrypt-forward, like OpenPGP). If the latter two,
| it's a missed opportunity to offer more security than
| age+minisign can offer and I encourage the author to look into
| it!
|
| - sender authentication
|
| I wrote about this. tl;dr age _has_ authentication, but I am
| not sure what a non-sharp UX around it would be, so I don 't
| advertise it. https://words.filippo.io/dispatches/age-
| authentication/
|
| - post-quantum security
|
| As https://www.kryptor.co.uk/security-limitations#post-
| quantum-... acknowledges, "the asymmetric algorithms in Kryptor
| aren't post-quantum secure". There is support for adding a pre-
| shared symmetric key, although I did not find the pre-shared
| key in the usage section, but I would argue that is not
| asymmetric encryption.
|
| In this sense, I would actually argue that Kryptor is just as
| post-quantum secure as age: age's symmetric encryption (the
| passphrase mode) is post-quantum (see
| https://words.filippo.io/dispatches/post-quantum-age/). We
| don't support adding a pre-shared symmetric key to asymmetric
| encryption, but if you have a secure channel to establish a
| pre-shared key, you should just use passphrase mode.
|
| age does have a third-party fully post-quantum asymmetric
| encryption plugin (https://github.com/keisentraut/age-plugin-
| sntrup761x25519) and I plan to make an ML-KEM one once the
| standard is out.
|
| - key commitment
|
| This is a pretty wonky topic. age _as a whole_ is key
| committing (you can 't make a file that decrypts with two age
| identities as different plaintexts, some academic researchers
| tried!). Our file key encryption is not (https://github.com/Fil
| oSottile/age/commit/2194f6962c8bb3bca8...) which means that if
| you host an online service that accepts an age file and
| decrypts it with a passphrase and returns an error if it's
| incorrect, an attacker can do a bruteforce two passphrases at a
| time instead of one at a time. Given the online oracle is
| already unusual as a setting, I am not interested in adding
| complexity to solve this one.
|
| - private key encryption
|
| age supports that!
| https://github.com/FiloSottile/age?tab=readme-ov-file#passph...
|
| It's not the default because most threat models don't need it:
| if you have FDE, who's an attacker that can read files from
| your disk but not replace the age binary in $PATH?
|
| - indistinguishability from random
|
| Not an age goal, actually we very intentionally put "age-
| encryption.org/v1" in the header so you can run file(1), and
| specify the type of the recipients to help plugins disambiguate
| files. The default recipient type doesn't leak any other
| metadata (i.e. you can't link age files encrypted to the same
| recipient).
|
| - size padding
|
| This is a good idea and slated for age v2.
| vluft wrote:
| re: https://words.filippo.io/dispatches/age-
| authentication/#on-c...
|
| other than inelegance and the computational overhead, is
| there a reason why sign then encrypt then sign wouldn't work
| for this?
| FiloSottile wrote:
| Assuming that implementation never skip verifying the
| second signature, and compare the signing keys, that should
| be ok.
| colmmacc wrote:
| Massive fan of age and congrats on its success!! On size
| padding, I know you've patiently listened to me before on
| this, but I'll always take a chance to advocate for an
| approach like PURBs ( https://petsymposium.org/2019/files/pap
| ers/issue4/popets-201... ).
|
| Let's say you're in a country that suppresses certain
| material, like copies of the Bible, or the Hacker Manifesto,
| or whatever; if the authorities find an encrypted file that
| closely matches the size of that material; that could do you
| in. But maybe a more realistic case is how the size of maps
| tiles alone is enough to figure out where you are looking on
| a map (https://ioactive.com/ssl-traffic-analysis-on-google-
| maps/), or the size of streaming video segments
| (https://www.cs.cornell.edu/~shmat/shmat_usenix17.pdf) gives
| away what you are watching. Both real-world examples of size
| side-channels. It's not un-imaginable that someone could use
| a tool like age to build bigger systems like that, where the
| leaks creep in.
| FiloSottile wrote:
| My age v2 note for padding says "use Padme, see Colm's
| comments" :)
|
| I'm not really sold on the UR part of PURBs, though: age
| wants to avoid asking for a passphrase if the file is not
| passphrase encrypted, and age-plugin-yubikey wants to avoid
| asking for a PIN if it's for the wrong YubiKey. These are
| tradeoffs and it's not obvious the very end of the spectrum
| (uniform random) is the right spot.
| quectophoton wrote:
| The description claims it's "secure", but nothing pops up in the
| README when I Ctrl+F `audit`.
|
| So maybe take the "secure" claims with a grain of salt.
| klabb3 wrote:
| Meh. The author of age is very experienced and known
| specifically for security, crypto and within the implementation
| language (Go).
|
| Audits are only as good as the competence of the auditors and
| can often turn into checklist rituals. It certainly doesn't
| hurt, but audits are not a panacea.
| quectophoton wrote:
| Agreed, but IMHO claiming that a crypto library is secure
| without providing independent verification, is like claiming
| something is fast without providing benchmarks. (And both are
| the same in the sense that neither is a panacea.)
|
| I'm only bringing up audits because such claim was made, but
| maybe I should have said "independent verification" instead
| since it's more general.
| klabb3 wrote:
| Sure, I think we agree in semantics but the wording is
| difficult. The bar for secure you're referring to is quite
| high, a lot of commercial products that brand themselves
| secure would be much _less_ secure than something like age.
| These days I think it's fair to use "secure" in the sense
| of "made a serious effort to provide certain security
| properties". It's too hard to define, let alone agree, to
| what secure should mean for everyone.
| tantalor wrote:
| Sounds like a false analogy.
|
| "independent verification" is subjective. Who does the
| verification, do you trust them, how do you know they
| didn't screw up.
|
| "benchmarks" are objective. A is faster than B, we know
| because of the way that it is.
| bpicolo wrote:
| The library is out in the world. Audit at will.
|
| Have you seen Filippo's credentials? He's overwhelmingly
| qualified for this. https://github.com/FiloSottile
|
| > Today, I maintain the cryptography packages that ship as
| part of the Go standard library (crypto/... and
| golang.org/x/crypto/...), including the TLS, SSH, and low-
| level implementations, such as elliptic curves, RSA, and
| ciphers. These packages are critical to virtually every Go
| application, securing HTTPS requests, implementing
| authentication, and providing encryption.
| quectophoton wrote:
| I'm no cryptographer so I might be misunderstanding how
| all this works (also why I have to rely on whatever
| signal I can catch instead of just reviewing the code
| myself like with other more mundane dependencies), but it
| was my impression that in cryptography things were to be
| considered with skepticism until at least someone else
| (emphasis on "someone else") with good enough
| credentials/skills had attempted to break it at least
| once.
| eximius wrote:
| Because the vast majority of new works are not done by
| one of the few who would be qualified to check it.
|
| You can think of the cryptography community as similar to
| the math community. If some nobody makes a new proof of a
| big conjecture, it is considered with skepticism until
| some big name comes around to verify it. If Terence Tao
| comes out with a new proof in one of his specialities,
| people are going to assume it's basically correct or will
| have only very minor errors that are easily fixed.
| quectophoton wrote:
| Makes sense, I see where I went wrong now, thanks for
| taking the time to explain.
| samatman wrote:
| The description claims these curves are "safe" but nothing pops
| up when I Ctrl+F `audit`. https://safecurves.cr.yp.to
| quectophoton wrote:
| It's a good observation, but probably a bad example since
| that page is clear on what criteria they consider for
| something to be "safe".
|
| That aside, of course DJB would choose criteria that let him
| label his own curve as "safe".
|
| I'm no cryptographer so ultimately I have no choice but to
| rely on others' expertise, but that does not mean I take at
| face value the words of someone talking about their own
| project. Probably for the same reason HN requires disclosure
| when talking about something you're involved in.
| tptacek wrote:
| This drives me a little nuts. There are something like 4 firms+
| in the world generally recognized as qualified for assessing
| cryptosystems, against dozens well-known and qualified to audit
| software but not cryptography. Cryptography is a rare specialty
| for software security people. How were you going to know
| whether an "audit" for age was meaningful?
|
| + _and, to be fair, dozens of independent practitioners_
| quectophoton wrote:
| Oof, yeah maybe "audit" was the wrong word if it causes a
| reaction this strong.
|
| I just wanted to say it would be nice to know what makes this
| implementation secure other than the creator's own words
| about their own project.
|
| (EDIT: Though I guess you coming out to defend it is good
| enough signal to vouch in favor of it.)
| aboardRat4 wrote:
| Just use gnupg.
| packetlost wrote:
| gnupg is a usability dumpsterfire with tons of footguns
| everywhere. Very very few people should use gnupg in its
| current form.
| micklemeal wrote:
| Wow, what an insightful response. My mind is blown. It never
| would've crossed my mind to just use gnupg. Thank you so much
| for this high quality response which was totally necessary.
| isoprophlex wrote:
| > The author pronounces it [age] with a hard g, like GIF
|
| lol
| jrflowers wrote:
| So it is pronounced kind of like "egg", Aygg
| jjice wrote:
| It would be fantastic if Age (or at least something similar)
| could become standard on Unix machines. I'd love a more Unix-
| philosophy following tool than GPG/PGP to be around for
| encryption. That said, I don't think new standard tools for Unix
| machines are very common. The closest thing I can think of in the
| last while is `jq`, but it's not "preinstalled on your machine"
| kind of standard, just "my script might just use it and expect
| you to have it" kind of standard.
| ReptileMan wrote:
| >just "my script might just use it and expect you to have it"
|
| That is one path to standardizing something - using it.
| 0cf8612b2e1e wrote:
| Chicken and egg problem. People use sh/bash because it is
| everywhere and standard. Requires energy to justify using an
| objectively superior tool if it is not default installed.
|
| I would love if I could count on Just, fish, ripgrep, or any
| other multitude of tools that improve upon these CLI apis
| that were invented ad hoc and ossified in the 70s. Paved a
| lot of cow paths.
| packetlost wrote:
| Isn't POSIX userspace mostly standardized? We _should_ be
| pretty conservative with what goes into such a standard, but
| something like age and jq IMO meet that level of utility to
| justify it.
| jjice wrote:
| Yeah POSIX standardizes a bunch of tools, mostly the ones
| you'd expect (cut, cat, file, etc). I agree with the
| conservative standardization for the most part, but I
| selfishly would love these more niche tools to be available
| on a fresh box. Good point though, I just want to be a little
| lazier in my script writing I guess :)
|
| I've always used this site as reference:
| https://pubs.opengroup.org/onlinepubs/9699919799/
| packetlost wrote:
| I guess distros are the next layer over POSIX standard.
| Distributions have the ability to, mostly arbitrarily,
| select the default packages they ship in their releases.
| upofadown wrote:
| Doing one thing and doing it well is all and good, but most
| people are not interested in having to manually mess around
| with up to 4 raw keys in the pursuit of that. That's
| particularly true if you are doing pipes and you don't have any
| good place to put all those keys.
|
| Most of the time you want to go: gpg --sign
| --encrypt file
|
| ... and be done with it.
| tptacek wrote:
| This is a little vacuous. Why are you signing? Why are you
| encrypting? Those are different operations. What are you
| trying to accomplish? The biggest problem with PGP is that
| its most popular use cases tend to be people bodging this old
| clanking command line tool into cryptosystems that (a) PGP
| wasn't designed for and (b) purpose-built cryptosystems are
| _much better at_.
|
| One of the reasons age is so constrained is that the problems
| best served by direct simple file encryption are quite
| narrow.
| qyckudnefDi5 wrote:
| I know there are specialized backup tools like restic or borg,
| but I like to keep things simple.
|
| Is using age like this to encrypt my files before uploading them
| to untrusted cloud storage not ok?
|
| tar > age > cloud
|
| Some comments mention signing with minisign. Should I be doing
| that like this:
|
| tar > age > minisign > cloud
| tptacek wrote:
| Use specialized backup tools! There are cryptographic
| constructions designed specifically for backup. You will get
| better backup _and_ better encryption.
| qyckudnefDi5 wrote:
| "Better backup" aside, as I understand that I'd miss out on
| deduplication and all the other things backup software can do
| like keeping track of what it has backed up etc.
|
| "Better encryption": Can you explain why age's encryption
| isn't sufficient if it's recommended for encrypting files?
| Really want to understand how it's recommended for encrypting
| and sharing a file over an untrusted channel like email, but
| not recommended to encrypt a file and upload it to an
| untrusted server.
| WhyNotHugo wrote:
| If you make a second backup tomorrow, you'll end up with a new
| (huge) encrypted tar. restic handles deltas when creating a
| second backup, and writes new files so that tools like rsync or
| rclone have to do less work to upload the new data.
|
| That said, I don't see anything strictly _wrong_ with your
| approach.
| qyckudnefDi5 wrote:
| No deduplication is a tradeoff I'm willing to make for
| simplicity and less things that can go wrong :)
| aborsy wrote:
| It's obviously not practical except for small data, for many
| obvious reasons.
|
| You may expect tools such as restic or Borg or rclone should
| use Age. But they don't, because they need their own file
| formats.
|
| Restic is excellent. I can't recommend it enough.
___________________________________________________________________
(page generated 2024-08-05 23:01 UTC)