Skip to content
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 for symmetric key files #46

Closed
Paragis opened this issue Dec 28, 2019 · 3 comments
Closed

Feature request: Support for symmetric key files #46

Paragis opened this issue Dec 28, 2019 · 3 comments

Comments

@Paragis
Copy link

Paragis commented Dec 28, 2019

I would like to consider the age format for some future applications, however a common requirement is the use of key files instead of passwords, especially where no user interaction is given.
The key files in these scenarios are used as symmetric keys and optionally protected by a master password. One of the application ideas is similar to a rachet with pre shared symmetric keys, where the user enters a password to access an app and decrypt the keyfiles for the session.

Currently supported in age:

  • asymmetric keys
  • passwords (interactive only)

Wanted feature:

  • symmetric keys
@kousu
Copy link

kousu commented Jul 23, 2020

This is implemented now: https://github.com/FiloSottile/age#passphrases

EDIT no it's not my reading comprehension is bad.

But you can turn it into what you wanted with

cat symmetric.key | age -p file.bin > file.bin.age
cat symmetric.key | age -d file.bin.age

@str4d
Copy link

str4d commented Jul 23, 2020

Age's "one joint" is the identity/recipient format, which is designed for arbitrary extensibility, and we are working on a plugin system that will enable this extensibility to be implemented easily by third parties. It is definitely possible for someone to define an identity/recipient format that uses keyfiles for symmetric wrapping of the file key. The keyfiles themselves could also be encrypted with age in passphrase mode, as indicated above 🙂

@FiloSottile
Copy link
Owner

This is now supported, in the sense that you can encrypt to an X25519 identity file as of 732f3e8.

The motivation for it ended up being symmetric plugins, that don't have a meaningful identity vs recipient distinction. It makes sense to use an identity file for those for both encryption and decryption. If it's supported for plugins, why not for everything.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants