Use chacha20 without poly for more speed? Aka AEAD?

[iger]

According to the specification https://age-encryption.org/v1, signing is out of scope, thus authentication is out of scope, thus AEAD is a misfeature slowing decryption and bloating the file size, and worse, implies nonexistent authentication to an unattentive reader.

The specification misquotes an authenticated streaming encryption endorsement https://www.imperialviolet.org/2014/06/27/streamingencryption.html, as it doesn't actually provide any authentication in the recommended usage scheme.

Is there actually a reasonable case for encryption without authentication? Is it not a bad idea to release an encryption tool without authentication, as masses will forget to sign when they should?

On a more serious note, if we were to take recommendation from the quoted document:
https://www.imperialviolet.org/2014/06/27/streamingencryption.html, age would provide a semblance of nacl's crypto_box, with streaming, on a command line. It seems reasonable to support encryption to either a symmetric or asymmetric key and verify authenticity via a symmetric or asymmetric key. No web of trust, key distribution etc.

It might be nice if it were interoperable with signify, meaning it could use the same key, at least for signing. It might even be possible to reuse the format to sign the header and that might be sufficient.

[FiloSottile]

Authenticated encryption is about defending the plaintext from oracle attacks, not about sender identity. Closing as a duplicate of #51.

[iger]

After careful reading, I concede that age does not claim to provide authentication. To reiterate, currently age only provides unauthenticated streaming encryption. Internally it uses AEAD as an implementation detail to defend against a swath of attacks such as cyphertext malleability and oracle attacks, which does seem like a good thing.

An unauthenticated encryption still gives an attacker the opportunity to generate a valid encrypted stream of his choosing or replace it with another cyphertext and have you decrypt it.

Note however that I am not necessarily proposing sender identity verification or sender authentication. I am proposing data authentication, i.e. a tool that provides a reasonable authenticated streaming encryption. A means to reasonably bind an encrypted stream to something, to verify it is what it should be and not something else.

After rereading the referenced Streaming Encryption post, I have not identified a place where the author would be ok with unauthenticated streaming AEAD, preventing malleability etc. yet not stream replacement. On the other hand, in many cases it is very clear having an authenticated encrypted stream is actually the point.