Hacker News Reader

Comment by jph | Hacker News Reader

Great work, thank you for sharing. I especially appreciate your link to your "Goals" section-- I'm listed them below because they are important and helpful IMHO.

+ An extremely simple CLI that composes well with UNIX pipes, and that works well as a backend for other programs

+ Small copy-pasteable keys, with optional textual keyrings Support for public/private key pairs and passwords, with multiple recipients

+ The option to encrypt to SSH keys, with built-in GitHub .keys support

+ “Have one joint and keep it well oiled”, no configuration or (much) algorithm agility

+ A good seekable streaming encryption scheme based on modern chunked AEADs, reusable as a general encryption format

View on HN

"An extremely simple CLI that composes well with UNIX pipes"

Just for fun, I occasionally experiment with proposed "post-quantum" encryption solutions and one in particular called Classic McEliece, from the same author (more or less) as the encryption used in age. Its small and compiles quickly. The interface is elegant and seems impossible to screw up. I have rarely seen anyone outside of the author and his followers use file descriptors in compiled programs in this way. I like it.

Three programs, each only does one thing

     usage: cmkeypair 5>publickey 9>secretkey

     usage: cmencrypt <message 4<publickey >ciphertext

     usage: cmdecrypt <ciphertext 8<secretkey >message

To be fair, I should probably add that McEliece arguably fails the "small, copy-pasteable keys" criteria. :)

In theory I like the idea of making better use of file descriptors other than stdin and stderr. It seems like a powerful feature of *nix that never really caught on, except with that one sysadmin at work who writes insane one-liners with fifteen pipes.

In practice, I find the syntax needlessly obtuse, and numbered file descriptors are rare enough in the real world that most casual observers will have no idea what's going on.

I’m seeing this for the first time and don’t quite get the usefulness of this interface, can you help me? I mean, file descriptor numbers instead of ordinary options provide some i/o semantics, but I have to remember the descriptor numbers? Is there some mnemonic/logic behind the ids?

Fair question. Im not the author so can only make a guess (other readers of HN surely know far more than I about these subjects). However I suspect the rationale is related to whats been called "Bernstein chaining".

https://cr.yp.to/proto/ucspi.txt

http://www.catb.org/~esr/writings/taoup/html/ch06s06.html

https://skarnet.org/software/execline/grammar.html

https://www.oilshell.org/blog/2017/01/13.html

Hmmm, now I don’t get how Bernstein chaining relates to file descriptor interface. I’m curious about specifically the `4<infile` you seem to be admiring, you just observed its unusualness or do you see how its more powerful than the more common `-input infile`?

Nice. TIL...

> The option to encrypt to SSH keys, with built-in GitHub .keys support

It’s not built in, just composable in. And to the version in the readme I prefer using command substitution personally: it’s clearer when there are multiple recipients, and the infile tends to be much larger than the keys.

The biggest issues wrt github are that it rejects age files (so you have to rename them) and there is no /keys at the repo level whivh would give you the keys of all maintainers, so you have to hunt them by hand.

How do you do AEAD with seeking? Tags (MACs) every few kilobytes?

https://web.cs.ucdavis.edu/~rogaway/papers/oae.pdf (Section 7)

Previously: https://news.ycombinator.com/item?id=21897192

STREAM is a well-studied construction for online authenticated encryption. It doesn't just involve an auth tag every few kilobytes (or megabytes, or gigabytes). There's also a byte flag (called a "tag" in some implementations) to indicate whether or not there should be additional blocks or not.

You don't happen to know of a slightly more approachable specification?

A search for anything like "stream cipher construction" only lands me on the traditional "stream vs block" discussions.

A Poly1305 tag every few 64 kilobytes. An encrypted chunk in age is thus 64 KiB + 16 bytes.

Reply on news.ycombinator.com