What does HackerNews think of 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

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.

Yes, this is incredibly easy to use: 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

> 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

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

Yes, with https://github.com/FiloSottile/age

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

https://github.com/FiloSottile/age

Meh, I would rather use age[0]

0: 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...

You may wish to look at age: https://github.com/FiloSottile/age

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 demonstrably better: https://github.com/FiloSottile/age

Also, an informed analysis of PGP: https://latacora.micro.blog/2019/07/16/the-pgp-problem.html

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.

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.