UX: Missing option for noninteractive use of passwords

[x97x53x81]

What were you trying to do

Writing an application that uses age as a backend for encryption using passwords

The application uses passwords for various things and I would like the use age to encrypt data by using the preexisting passwords. Using public keys is not an option in this scenario.

What happened

Age only allows the use of passwords interactively, making it hard to use if (preexisting) passwords need to be used.

For age to become a global standard for encryption, it should consider use cases like this and allow to use of passwords without being used interactively.

[cyb3rz3us]

Can you explain a bit more about how you are trying to use the PW w/ age and your app? I use age as is right now for encrypting a credentials file and while I do use public keys, I don't see much of a hurdle is using a password as well. However, how big that hurdle is will depend on what you are doing and the apps you employ.

As an aside, I know the dev is working to expose an age API library (#63) so perhaps that will provide what you need...

[Fastidious]

@cyb3rz3us OP is trying to pass passwords as an argument (or having age to read it from file, or similar), so it seems. Right now age does passwords only interactively.

[cyb3rz3us]

Thanks @Fastidious --- I'm aware of what age can do but having the PW acquired interactively is not that big a deal depending on what is being done. It's somewhat trivial to have an app peek into an existing file or take a CLI argument and then provide that to age when appropriate. This is why I asked for more details as to what is being done...

[Fastidious]

@cyb3rz3us that will require a third party tool, like expect or similar. I really don't see the need for what the OP asks. If I were it, I would use public key to encrypt instead. 🤷🏻‍♂️

[cyb3rz3us]

"...would use public key to encrypt instead..." --- Indeed. Hence my query...

[x97x53x81]

The scenario in which I am opting to use age does not allow to store something like keyfiles for each user. Additionally there is one requirement where new users need to get access to previously encrypted files, which is easy when using a shared password.

In an additional use case, data is encrypted for long term storage (decades) and one of the requirements that were set for this is symmetric crypto, as it is deemed more reliable in the long run.

At the moment the implementation for all of this is planned with a custom encryption file format, but I would like to prefer age if possible to make it easier to access the data in the future and to help age become a standard. Also I do not see much reason to design and implement yet another format if age is already available for this.

If #63 provides an API that allows this use case, that is exactly what I am looking for.

[cyb3rz3us]

Thanks @x97x53x81 --- So just considering this at a high-level, I can say it is definitely possible to use something simple like a Tcl\Expect script to collect the requisite password information and then pass it to age which would then hand over decrypted data to another app whatever it may be.

If the API ends up working for you, then of course all the better. But if you need something in the interim, then technically speaking, I don't really see an issue making this work with age as it is right now.