Entering password (-p) in scripts

[olastor]

When encrypting via jose jwe enc -I msg.txt -k key.jwk -o - -p, it expects the user to type and confirm a password, but how can the password be provided when it is in a variable in a bash script? Or alternatively, how can a user generated string be used as a symmetric encryption key? Thanks.

[sarroutbi]

At a first glance, I don't see code is ready to provide a password via "-p -" or similar. I tried with here documents but it doesn't work.

It depends on your scenario but, If I was to do this, I would try "expect", which allows to automatically wait for a string in a script and, once received, send the output. The string to expect would be "Please enter an encryption password: ", and the one to send the one in your bash script variable. Otherwise, code in jose should be modified to allow the specification of a password on a non-interactive way.

[olastor]

It depends on your scenario but, If I was to do this, I would try "expect", which allows to automatically wait for a string in a script and, once received, send the output. The string to expect would be "Please enter an encryption password: ", and the one to send the one in your bash script variable. Otherwise, code in jose should be modified to allow the specification of a password on a non-interactive way.

@sarroutbi Thank you for that suggestion. I was also considering something like this, but would like to avoid something like that if possible.

May it be that I can use one of the key wrapping algorithms and set the "k" field to my custom (hashed) password?

When I do jose jwk gen -i '{"alg":"PBES2-HS512+A256KW"}' -o -, it seems to generate a random key in "k". For example:

{"alg":"PBES2-HS512+A256KW","k":"Imd2NKkh9b3bmkbT4IimH1x2jeiiaWjzeGmiOKjjsno","key_ops":["wrapKey","unwrapKey"],"kty":"oct"}

Entering some test values into "k" often fails with "Wrapping failed!" in the jose jwe enc, but if I enter a hash of my password, e.g. sha256 or sha512, then it works. I assume it has to do with the "oct" format and interestingly the jwk works with different lengths of "k". Probably I need to read more of the specs to find out why. Also noticed that the README shows for the PBES* algorithms no "oct", but "N/A". Wondering why that is.

[olastor]

So, citing from RFC7518:

An ideal password is one that is as large as (or larger than) the derived key length. However, passwords larger than a certain algorithm-specific size are first hashed, which reduces an attacker's effective search space to the length of the hash algorithm. It is RECOMMENDED that a password used for "PBES2-HS256+A128KW" be no shorter than 16 octets and no longer than 128 octets and a password used for "PBES2-HS512+A256KW" be no shorter than 32 octets and no longer than 128 octets long.

I assume that the "k" parameter in the case above is the password, which can have a variable octet lenght.

[olastor]

I think this solves the problem. In this library there is also a method to simply base64url encode a password and put it into the "k" field and set "kty": "oct". I guess this would then be the preferable way.