Home GnuPG
Diffusion GnuPG 4e117f206beb

gpg,sm: Error out on compliance mismatch while decrypting.


gpg,sm: Error out on compliance mismatch while decrypting.

* g10/pubkey-enc.c (get_session_key): Bail out if the algo is not
allowed in the current compliance mode.
* sm/decrypt.c (gpgsm_decrypt): Ditto.

The idea here is that the owner of the key created a non-compliant key
and later receives a mail encrypted to that key. The sender should
have checked this key too but we can't guarantee that. By hard
failing here the owner of the key will notice that he had created a
non-compliant key and thus has a chance to generate a new compliant
key. In case the compliant criteria changes and the owner wants to
decrypt an old message he can still switch gpg to another compliant


wernerAuthored on Aug 1 2017, 8:41 AM
rGa21ca77988ce: indent: Wrap overlong lines in argparse.c
T3308: Compliance: Decryption in de-vs with bp256 key fails

Event Timeline

I have not tested this. But I think it does not what we want.
Use case: I have thousands of mails encrypted to my old ELG 1024 key.

Now I switch to an RSA 3072 key and activate de-vs.

I won't be able to decrypt stuff of my old DSA key without disabling compliance mode?

I think a warning together with an omission of the compliance flag when decrypting is what we want. Kleopatra / GpgOL will show "This encryption was not VS-NfD compliant" in this case.

I had a long discussion with Stephan on this and he convinced me that this is the Right Thing to do. Anyway, in the last meeting with the customer we agreed on this behaviour There is a table in the minutes.

I doubt that you want to use de-vs anyway. It is for the spooks^Wgov.

Andre, you are talking about changing compliance requirements and then be able to recover your old data via "legacy" mode. This is a valid argument. But if you need it you will not operate compliant and should disable the compliance mode. That was the agreement during the customer meeting.