Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: Support public key authenticated encryption #59

Closed
NeilMadden opened this issue Dec 30, 2019 · 5 comments
Closed

Feature request: Support public key authenticated encryption #59

NeilMadden opened this issue Dec 30, 2019 · 5 comments

Comments

@NeilMadden
Copy link

Currently age encryption with X25519 or ssh keys is unauthenticated. While the use of an AEAD for encryption of the file contents prevents tampering with the ciphertext, an attacker who is in a position to do such tampering can instead just replace the entire file with their own encrypted contents.

Although this doesn’t impact the confidentiality of age-encrypted files, it has practical impacts on the security of streaming use-cases for which an online AE mode was (I think) selected. For example, in agl’s blog post linked from the spec he talks about cases such as:

gpg -d your_archive.tgz.gpg | tar xz

This is insecure if an attacker could replace the archive with one of their choosing. Such an attack is possible in most situations a chosen ciphertext attack is.

While you could argue that origin authentication can be done by another tool like minisign or signify, use of those tools implies giving up on streaming as a signature over the entire archive would need to be verified before any output can be processed.

Public key authenticated encryption could be achieved by making the encryptor supply a X25519 private key and using crypto_box (or equivalent) to encrypt the file key in the header rather than the current ECIES-like scheme.

(NB where there are multiple recipients then each recipient can use the decrypted file key to create new encrypted file contents with the same header and make it look as if the original user produced the new ciphertext, so the threat model would need to be worked out in detail - perhaps only supporting a single recipient when using this mode).

I wrote a bit more about this here: https://neilmadden.blog/2019/12/30/a-few-comments-on-age/

@tqbf
Copy link

tqbf commented Dec 30, 2019

Unlike a full-on signing feature, a decryption feature that takes a durable sender public key seems straightforwardly an improvement?

@xorhash
Copy link

xorhash commented Dec 31, 2019

It's probably worth noting that the response to this has apparently moved to the mailing list: https://groups.google.com/d/msg/age-dev/r-gwwcN3L-0/EhEvUbG5AwAJ

@ovalseven8
Copy link

I wonder about the use-cases for age without any public key sender authentication or signing capabilities?

The "I want to decrypt this message and verify it's from XY" is a very common use-case. And combining age with e.g. Minisign looks unhandy because you have to maintain two different key pairs.

@tqbf
Copy link

tqbf commented Dec 31, 2019

In what application is "I want to decrypt this message and verify it's from XY" very common? age isn't a general-purpose building block the way pgp is.

@ovalseven8
Copy link

When age is used primarily as small library for other, bigger systems, I can understand that it's only focused on encryption/decryption (confidentiality).

But since age seems to be a CLI tool as well, I do not understand the lack of optional sender authentication - and even with sender authentication it's far from being the all-in-one solution that GnuPG is.

Repository owner locked and limited conversation to collaborators Apr 19, 2021

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants