What does HackerNews think of age?

A simple, modern and secure encryption tool (and Go library) with small explicit keys, no config options, and UNIX-style composability.

Language: Go

None of the existing password managers filled my need, so i started to write my own (not the crypto ofcourse). Here it is :)

Why did I do it? I'm totaly dependend on my password managing software, all my passwords are generated by random so non of them are rememberable. During the last years I felt that my expectations and the traits of the password manager I was using grew appart. I dislike subscription based software (especialy if i might need it to extract/recover my secrets out of an old file). I dislike Web-UIs in native Apps. So i was looking around but when I had an incident where a licensed password vault just forgot that it was licenced and denied access I had enough. I wanted something that had a UI but also a data format that enables recovery with very little tools. So thats what I started to create.

A-Pass saves its secrets as json content encrypted by age[1] (so no hasseling with gpg). No information is visible without decrypting the files (no names / no urls). The file structure should be easy to sync, but its not implemented yet.

Looking forward to input & comments :)

[1] https://github.com/FiloSottile/age

I don't know enc, but you can do this with age [0]

Encrypt: `age -p secrets.txt > secrets.txt.age`

Decrypt: `age -d secrets.txt.age > secrets.txt`

It asks for a password in both operations.

[0] https://github.com/FiloSottile/age

age in question, in case you were as confused as I was by what that means: https://github.com/FiloSottile/age
Rather than being frustrated you should consider that you're holding on to something that is an inelegant relic of another age. There are things PGP/GPG do that need replacements, but those replacements need to be very different to PGP.

1. I've fethed around with PGP since Zimmerman published the source code, and I attest that setting it up properly is not simple. Not as difficult as creating an x509 certificate in OpenSSL with SANs, but really not straight forward. But the real difficulty is actually using it. 1.1 Trusting in-browser crypto like mailvelope is bizarre. mailpile was a better approach, but they seem to have lost momentum.

2.1 The only significant use for PGP is signing linux packages and git code signing. But this is terrible as a breach means you could generate whole trees of fake checkins, and it desperately needs something like Signal's ratchet mechanism, or (heaven forbid) a blockchain. 2.2 If you want to send something on a USB stick then encrypting it with a sensible and usable tool (with modern AEAD encryption) like https://github.com/FiloSottile/age will be far more reliable.

3 You have no basis for this speculation. Signal are clear that they don't hold your data, and I really can't see 'compelled speech' like writing a backdoor being possible. Signal is as capable of resisting analysis as anything else that's around, far better than PGP, to the point that your security is essentially as good as you and your correspondents device security.

I'm not convinced that whole-disk encryption is sensible for most threat models, but I use the built-in FileVault on macOS (under the reasoning that, at the very least, it can't really hurt).

On Linux, I use age[1] (specifically, rage[2]) to encrypt sensitive files. I wrote a secret manager that uses the latter as an encryption backend[3], and I use `rage-mount` to mount (read-only) views of encrypted archives.

[1]: https://github.com/FiloSottile/age

[2]: https://github.com/str4d/rage

[3]: https://github.com/woodruffw/kbs2

Single binary alternative, open source: https://github.com/FiloSottile/age

From former head of Go security team at Google.

I’ve had good experiences with age [1]: it’s relatively easy to use and has sane defaults.

[1] https://github.com/FiloSottile/age

> No, we want a way for the client to encrypt data in such a way that the server can't read. Ideally also with MLS capabilities, so we can encrypt data in a way that other people can read, but not any intermediaries. But let's just ignore that for now, because it threatens to inject only more insane chaotic out of control mayhem.

This is 100% a solved problem already, I have no idea why you are having such a hard time with this.

See PGP/GPG and friends, age[1], magic wormhole[2], etc. Not to mention Noise[0], which I've already mentioned many times, as a protocol that does this. Even MS Exchange supports this for email(S/MIME, OME, etc). Webmail could implement PGP or S/MIME or something similar(and some do last I checked).

> MLS capabilities

Look up Macaroons(for the web) and capability based security. This is also a solved problem.

> 100% of my premise is that we should not need to always trust the server we connect to.

Essentially you are trying to achieve the un-achievable, for various definitions of security and trust, it's just not possible. In the modern web, servers can run arbitrary code on your device AND run arbitrary 3rd party programs on your device, with you having little to no say about it. This isn't limited to the Web, it just makes it ridiculously over the top. Web security is mostly an illusion, it's not going to change anytime soon(arguably never).

Anyways, there is basically zero demand for any of this stuff, and no incentive for companies or organizations to care. We know how to make secure operating systems and software, but nobody bothers.

0: https://noiseprotocol.org/ 1: https://github.com/FiloSottile/age 2: https://magic-wormhole.readthedocs.io/en/latest/index.html 3: https://landlock.io/

I recommend age as well. It offers encrypting for recipients for whom you have public keys.

https://github.com/FiloSottile/age

I'm not familiar with NaCl, websites that don't seem to have been updated in 7 years (version states 2016?) make me a little suspicious about the future viability of said projects. Perhaps it's not something that needs to be updated very frequently, but my knee-jerk reaction is that it looks abandoned, especially considering that they have an "upcomming features" section.

What made you choose it? Could PGP/GPG with ed25519 keys not have been sufficient? What makes NaCL "fun to work with"? For me, fun to work with would be Age [1] or Ring [2] with a elegant and well designed API. I'm also aware that the older something is, the more likely it has undergone peer review and security audits, unlike new Rust crypto libraries.

[1]: https://github.com/FiloSottile/age [2]: https://github.com/briansmith/ring

I feel that trying to make SSH keys short-lived is becoming more painful each year because there's an increase of tools that use SSH keys for purposes other than SSH logins. For example, age [1] encrypts files with SSH keys, agenix [2] does secrets management with it, Git can now sign commits with it [3], and even ssh-keygen can now sign arbitrary data [4]. All of these become useless the moment you start using short-lived keys.

[1]: https://github.com/FiloSottile/age

[2]: https://github.com/ryantm/agenix

[3]: https://calebhearth.com/sign-git-with-ssh

[4]: https://www.man7.org/linux/man-pages/man1/ssh-keygen.1.html

> Do C (or something where the mapping to C is known), and lots of languages have FFI libs where wrapping that is fairly trivial

That is an interesting idea, yet still a lot of work, sadly. I was hoping somebody had done the legwork already. I looked at Tink [1] and age [2] based on my co-worker's recommendation, but they all seem to have limited implementations in other languages.

[1] https://github.com/google/tink

[2] https://github.com/FiloSottile/age

You can encrypt them using something like https://github.com/FiloSottile/age and then just store them in git. When you need to access them, just run "age -d .."

If you're paranoid you can use GPG + a smart card like a yubikey, but its all about convenience trade off..

Is PGP a zombie technology that won’t ever die because there are organizations that have nailed their identity to it?

(For everything you think you should use PGP for please use Age - https://github.com/FiloSottile/age)

As yepguy mentioned AGE is simpler. I can also mention few things:

- It works smoothly with SSH keys (generated from ssh-keygen), which are perfectly recognized by possibly any developer.

- No need for external client, such as GpgWin/Kleopatra for Windows.

- Embed-able in Rust[0] and Go[1] (there are libraries), no need to call `gpg --decrypt ...` from the command line.

- Encrypted files by pass and keys are smaller. I guess it is thanks to ecliptic-curve encryption.

[0]: https://github.com/str4d/rage

[1]: https://github.com/FiloSottile/age

There's no consensus because there's no best answer. Here's an example of what you could do.

Generate a new seed phrase on a hardware wallet. Encrypt the seed phrase using https://github.com/FiloSottile/age and print out the encrypted seed. Store the paper in a safety deposit box. Keep the hardware wallet at home in a safe.

Write down the encryption key and the hardware PIN in an envelope to be opened in the event of your death.

All that said, this particular example is vulnerable in that you could be held at gunpoint and lose everything. So next we start talking about cold wallets vs hot wallets...

This whole thread is off-topic (talking about AEAD in a post about signing), but:

You can use age's AEAD encryption with Yubikeys. Yubikeys can do ECDHE in PIV mode.

I wrote https://github.com/tv42/yubage as a subprocess plugin to https://github.com/str4d/rage (and hopefully https://github.com/FiloSottile/age once they think plugins are stable in enough to go in the reference implementation). The rage author also wrote their https://github.com/str4d/age-plugin-yubikey

Slightly related, but I use age[0] for most of my non-automated file encryption tasks; and one of the neat features it has is the ability to encrypt to a GitHub user's pubkey[1].

[0] https://github.com/FiloSottile/age

[1] https://github.com/FiloSottile/age#encrypting-to-a-github-us...

GnuPG should not be used anymore.

https://latacora.micro.blog/2019/07/16/the-pgp-problem.html

For file encryption age is recommended. A frontend for it would be welcomed.

https://github.com/FiloSottile/age

With all the great encryption utilities like age[0], Signal, or Veracrypt, can anyone please tell me what the point is in using pgp anymore? It's old, it's clunky, it requires careful use to be safe.

Why not use something more modern?

0. https://github.com/FiloSottile/age

Thanks! Link to "age", for those who are interested:

https://github.com/FiloSottile/age

Came here to say this. Please don't use PKIX, ASN.1, and Base64-of-DER-without-PEM-headers for Ed25519. Those are all extra complexity from protocols that were misguidedly built with runtime agility, or from a different time in cryptography engineering in which we really felt the need to put dynamic types on everything. [0][1]

An Ed25519 public key is a 32 bytes sequence. An Ed25519 private key (called seed in crypto/ed25519 for unfortunate historical standardization reasons) is a 32 byte sequence. That's it.

Here they are encoded in Base64.

    public key: 5uW7anEGF1nIjGfp5pS2kiN0cn2mGYkuSa+TCBoFIbQ=
    private key: shhKyGTvTeLjXGDCjEQgHRA7ps3LRNNfoO5S714kinU=
age [2] similarly uses Curve25519 keys encoded with Bech32 to make them easier to copy-paste and read aloud. Look how nice they look compared to PKIX blobs!

    $ age-keygen
    # created: 2021-04-23T12:31:14-04:00
    # public key: age1gek0nrawzg9fhkrzcmt4ql7au0n6hwflz7lqqc8wwcvefn2vssgsa4uulp
    AGE-SECRET-KEY-19JFPFAY2DF3HJP5DFGVSY4A4G4YSRHG4ZCJMKNC5MFD9C9ZN5LCSG8VTDL 
I'll think about how to make the crypto/ed25519 godoc point people in the right direction once Go 1.17 enters feature freeze.

[0] https://www.imperialviolet.org/2016/05/16/agility.html

[1] https://buttondown.email/cryptography-dispatches/archive/cry...

[2] https://github.com/FiloSottile/age

> kbs2 uses the rage[1] implementation of age[2].

Symmetric encryption with an actually comprehensible CLI; thank you!

[1]: https://github.com/str4d/rage

[2]: https://github.com/FiloSottile/age

That was a very interesting read, and covers all the issues I had with GPG/PGP broken down on a per-use-case basis, which is really neat. Fairly up-to-date too (aside from maybe WhatsApp mentioned alongside Signal). In any case, thanks for sharing! Nice to see simplified and somewhat modernized tools like (https://github.com/str4d/rage) and (https://github.com/FiloSottile/age)

The article that post mentions in the beginning also had some interesting perspectives, though a bit older.

https://blog.cryptographyengineering.com/2014/08/13/whats-ma...

the projects are not related at all but this and https://github.com/FiloSottile/age have a name conflict.
A promising contender to "replace" GPG in which you might be interested is age: https://github.com/FiloSottile/age

It's based on ChaCha20-Poly1305 AEAD and the author is well respected in the crypto community.

Thanks for the explanation! Glad to hear you've thought out and handled the linking process.

Just out of curiosity: have you seen or considered age[1] for the symmetric pair? I've used it on a few projects where cryptographic flexibility wasn't necessary.

[1]: https://github.com/FiloSottile/age

Age is new to me, I immediately find there's a Go (age) and Rust (rage) implementation - which one is the encryption community at large favoring more? (stability, code quality, etc.)

https://github.com/FiloSottile/age

https://github.com/str4d/rage

Tink (https://github.com/google/tink) and Age (https://github.com/FiloSottile/age) are the obvious examples, although I think to some extent even things like the Signal Protocol apply.

I'd call them both examples of applied cryptography research. I think these projects compare very, very closely to applied ML research:

They come out of industry research labs, are worked on by respected experts, usually involving some academics, ultimately you end up with an artifact beyond just a paper that is useful for something and improves upon the status quo.

I'm admittedly not a total expert, so I don't know how far down to the level of crypto "primitives" this kind of work goes, but I believe there is some effort to pick primitives that are difficult to "mess up" (think "bad primes") and I know tink actively prevents you from making bad choices in the cases where you are forced to make a choice.

Even more broadly, just consider any tptacek (who I should clarify is *not a researcher, lest he correct me) post on pgp/gpg email, or people like Matt Green (http://mattsmith.de/pdfs/DevelopersAreNotTheEnemy.pdf).

Edit: Some poking around also brought up this person: https://yaseminacar.de/, who has some interesting papers on similar subjects.

keybase is unfortunately one of those programs that combine many things into one - somewhat antithetical to the Unix philosophy of doing one thing well.

For kbfs, tahoe-lafs is a nice alternative. I don't know about the fuse interface as I haven't used it, but it has some solid fundamentals behind it, actively being developed and can be self hosted.

GPG still works! GPG also is a swiss army knife, unfortunately. There is OpenBSD signify (or minisign) if you want signatures.

There is also age - https://github.com/FiloSottile/age

Yes. I _love_ Keybase Git for instant, immediate, safe backups of private repos. Keybase Git has been an absolutely killer feature for me since it came out and I'll miss it terribly if Keybase-the-software takes a turn for the worse. Now is the time to ensure I've got everything properly backed up, I guess.

https://github.com/spwhitton/git-remote-gcrypt is probably the best alternative for now, but I'm wailing and gnashing my teeth at the prospect of going back to PGP keys. Maybe there's some way to intersect https://github.com/FiloSottile/age and a git remote.