While using some software that tries to simultaneously encrypt and sign some piece of data, I realized that I am not able to do so.
I can sign
gpg -s -u MYID output.txt
and encrypt.
gpg -e -r MYID output.txt
but not both:
gpg -e -r MYID -s -u MYID output.txt
gpg: signing failed: Conditions of use not satisfied
gpg: output.txt: sign+encrypt failed: Conditions of use not satisfied
I checked by creating a software key that I am able to do that operation without using the Nitrokey Pro 2.
Is this something hardware related? Any workarounds?
I just tried it here with a NK Pro V1 and it worked fine. Normally I would have said -r MYID would not work (instead --encrypt-to MYID should be used if you want to use your own ID as receipt ) , but it worked with both calls.
So you might need to explain what NK you are using. Also do you have forced PIN and a Pin is requested for signing ?
Hi, it seems that -r just sets the recipient, otherwise you will be asked for additional IDs:
gpg -e --encrypt-to MYID -s -u MYID file
You did not specify a user ID. (you may use “-r”)
Current recipients:
rsa4096/XXXXXXXX date ID
Enter the user ID. End with an empty line:
gpg: signing failed: Conditions of use not satisfied
gpg: file: sign+encrypt failed: Conditions of use not satisfied
My hardware is a NK Pro 2:
Version …: 3.3
Manufacturer …: ZeitControl
Signature PIN …: not forced
Key attributes …: nistp384 rsa4096 nistp256
I don’t know this error. In general, the key is not used for encryption, is only the public key is needed, so I do not see what difference it would make to do signing and encrypting at the same time.
What GnuPG of which system are you using? You may need to use gpg2 instead, as many systems use very old gnupg in version 1 if gpg is invoked. Try gpg --version and gpg2 --version.
Good point about encryption not happening in the key, I did not think about that.
My gpg version looks like fairly recent,
gpg 2.2.12-1 amd64
I guess the sensible thing to get a clue is to trace gpg's code to see what is happening when that error is issued. I will do it if I have some time.
For the record: my original intention was to use the gcrypt backend of the archiving tool git-annex. It uses some file as a manifest, which is encrypted and signed simultaneously, thus giving place to that error. As a reference, I think I found a workaround by using a different encrypted backend (directory with hybrid crypto key option).
Hi! My guess is, that the problem is in having different algorithms for encryption and signing. Perhaps you are hitting some code path, which assumes same algorithm is used for sig+enc. Could you make these two the same type, and test?
Hi,
Just for the records:
a) I just tried it with both (NK Pro V1 & V2 ): gpg —card-edit -> admin -> key-attr does not allow to enter a nistp256. So how have you created the keys ? PKCS#11 ? (V1 anyhow only allows RSA’s)
b) I also get this error when I try to do sign+encrypt in one step.
c) When I use only nistp384 keys (EscA) I get the same results for the tests
d) When I use only RSA4096 keys (EscA) … it takes a long time to generate the keys … but then it works
e) Using RSA2048 for Signing& Auth and nistp384 for encrypt ( which looked for me most usable: simple sign, but strong encrypt - I used 2048 for sake of time ) …and it worked ! So this combination with diffrent key types can make it
So, Now I stop working as a Guinea Pig
Oh, one follow-up: use of a different curve than NSA NIST for encryption is not accepted by gpg
Thank you so much for your throughout testing! I really appreciate it!
a) It is a bit foggy how I created my subkeys, since it has been almost a year; if you say that gpg --card-edit does not allow to create nistp256, maybe I created it in the CPU and then uploaded it to the key. That is my ssh authentication key.
c) What do you mean by EscA?
d) That seems like the real culprit is the algorithm combination and not the hardware.
My only constraint is the rsa4096 for encrypting; maybe it is time to re-create my signing subkey if this is going to bother me in the future.
Sorry for the assumption: “EscA” means the key is used for Encryption, Signing , Certificate and Authentication (gpg --list-keys --list-options show-usage ) So for my case c) & d) I use the same type of key for everything.
For case a) I need to mention: I am using a Mac with gpg 2.2.10. / libcrypt 1.8.4 . So maybe under a linux distribution gpg behaves a bit diffrent or you have created the keys with OpenSC. (I understand that you might have uploaded the key, but I would never recommend that - this is IMHO contradicting the use of a HW crypto key )
As I anyhow now had destroyed the keys, I will do another test to understand if gpg accept curve22519 in at least one case - Using NSA NIST for encryption would be a bit strange. I will publish the results asap
[Update]:
a) ok, curve25519 is of course not supported by the NK Pro as of the datasheet. Why Have I even tried it
b) You might have created the nistp384 with --expert mode of gpg. At least there you could choose it.
c) If the signing key is a RSA you could use a NistP256 or brainpool for encryption and use them both together in a combined command. So seems to be a gpg trouble when you use diffrent algorithms for sign and encryption.
I used
gpg (GnuPG) 2.2.17
libgcrypt 1.8.4
on a Mac
Yes, the hardware does all the operations involving the private keys, including signing and encrypting. The public key ones are done by the host PC.
Initial Conditions of use not satisfied error might indeed mean, that the device reports error invalid parameters for the command execution. The mentioned strace log is the communication log between GnuPG and the scdaemon, the process communicating with the device.
The latter’s details could be caught by modifying the configuration file, as in gnupg-docker/scdaemon.conf at master · Nitrokey/gnupg-docker · GitHub (please remove secrets before publishing, or better: change the PIN for the log taking time).
