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.
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 :)
Encrypt: `age -p secrets.txt > secrets.txt.age`
Decrypt: `age -d secrets.txt.age > secrets.txt`
It asks for a password in both operations.
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.
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
From former head of Go security team at Google.
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/
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
[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
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.
If you're paranoid you can use GPG + a smart card like a yubikey, but its all about convenience trade off..
(For everything you think you should use PGP for please use Age - https://github.com/FiloSottile/age)
- 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.
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...
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
[0] https://github.com/FiloSottile/age
[1] https://github.com/FiloSottile/age#encrypting-to-a-github-us...
https://latacora.micro.blog/2019/07/16/the-pgp-problem.html
For file encryption age is recommended. A frontend for it would be welcomed.
Why not use something more modern?
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...
Symmetric encryption with an actually comprehensible CLI; thank you!
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...
It's based on ChaCha20-Poly1305 AEAD and the author is well respected in the crypto community.
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.
Also, an informed analysis of PGP: https://latacora.micro.blog/2019/07/16/the-pgp-problem.html
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.
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
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.