-
-
Notifications
You must be signed in to change notification settings - Fork 517
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
Comments
Unlike a full-on signing feature, a decryption feature that takes a durable sender public key seems straightforwardly an improvement? |
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 |
I wonder about the use-cases for The "I want to decrypt this message and verify it's from XY" is a very common use-case. And combining |
In what application is "I want to decrypt this message and verify it's from XY" very common? |
When But since |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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:
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/
The text was updated successfully, but these errors were encountered: