An Additional Decryption SubKey may be used for archival purposes, to encrypt for stand-ins, as well as to split subkeys to different devices. It is the remote counterpart of --encrypt-to. This feature makes use of a new OpenPGP key flag:
The "restricted encryption key" (2nd,0x04) does not take part in any automatic selection of encryption keys. It is only found on a subkey signature (type 0x18), one that refers to the key the flag applies to.
| rGPGMEPP Gpgme plus plus | |||
| rGPGMEPPbd97412bd89a core,cpp: Add new key flags to gpgme_subkey_t | |||
| rG GnuPG | |||
| rG45ae027ce404 gpg: New command --quick-add-adsk | |||
| rG9f27e448bf1f gpg: New command --quick-add-adsk | |||
| rGe4f61df8509e gpg: Implement encryption to ADSKs. | |||
| rGef5a48dd5178 gpg: Actually encrypt to ADSKs. | |||
| rG3a18378a92af gpg: Allow adding of Additional Decryption Subkeys. | |||
| rM GPGME | |||
| rM6d21256c9220 core,cpp: Add new key flags to gpgme_subkey_t | |||
Encryption to the ADSK seems to work but I'm not sure if everything is displayed as expected.
I've used the Ted Testkey with Bertas Key added as ADSK.
On encryption Bertas name is not shown, only " Ted Tester <Ted.Tester@demo.gnupg.com> [ADSK]"
On decryption "[User-ID nicht gefunden]" is shown for Bertas encryption key. (And I do even have her key in the testkeyring.)
But as I understand it, Teds UID should be given here, too (like in the verbose output of encryption), as the ADSK belongs to his UID?
Or is this as designed and desired? Please explain.
C:\Users\g10code.WIN-TEST3\Documents>gpg -v -r Ted -e test2.txt
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: enabled debug flags: memstat
gpg: enabled compatibility flags:
gpg: verwende Vertrauensmodell pgp
gpg: Schlüssel 458612006D8E6F0D: Als vertrauenswürdiger Schlüssel akzeptiert
gpg: Schlüssel C5D6C919005F36A4: Als vertrauenswürdiger Schlüssel akzeptiert
gpg: Schlüssel 08F8682320DEDDB9: Als vertrauenswürdiger Schlüssel akzeptiert
gpg: der Unterschlüssel CD573B2B0736643A wird anstelle des Hauptschlüssels C5D6C919005F36A4 verwendet
gpg: Dieser Schlüssel gehört uns (da wir nämlich den geheimen Schlüssel dazu haben)
gpg: Lesen von 'test2.txt'
gpg: Schreiben nach 'test2.txt.gpg'
gpg: ECDH/AES256.CFB verschlüsselt für:"FFA2FCCB2EC589F8 Ted Tester <Ted.Tester@demo.gnupg.com> [ADSK]
gpg: RSA/AES256.CFB verschlüsselt für:"CD573B2B0736643A Ted Tester <Ted.Tester@demo.gnupg.com>
gpg: keydb: handles=2 locks=0 parse=2 get=2
gpg: build=0 update=0 insert=0 delete=0
gpg: reset=0 found=2 not=0 cache=0 not=0
gpg: kid_not_found_cache: count=0 peak=0 flushes=0
gpg: sig_cache: total=6 cached=6 good=6 bad=0
gpg: random usage: poolsize=600 mixed=272 polls=0/10 added=243/158358
outmix=5 getlvl1=4/442 getlvl2=0/0
gpg: rndjent stat: collector=0x02840098 calls=4 bytes=128
gpg: secmem usage: 3488/32768 bytes in 4 blocksC:\Users\g10code.WIN-TEST3\Documents>gpg --list-pack test2.txt.gpg
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: enabled debug flags: memstat
gpg: enabled compatibility flags:
gpg: Öffentlicher Schlüssel ist FFA2FCCB2EC589F8
gpg: der Unterschlüssel FFA2FCCB2EC589F8 wird anstelle des Hauptschlüssels 458612006D8E6F0D verwendet
gpg: Öffentlicher Schlüssel ist CD573B2B0736643A
gpg: der Unterschlüssel CD573B2B0736643A wird anstelle des Hauptschlüssels C5D6C919005F36A4 verwendet
gpg: verschlüsselt mit 3072-Bit RSA Schlüssel, ID CD573B2B0736643A, erzeugt 2023-03-08
gpg: der Unterschlüssel CD573B2B0736643A wird anstelle des Hauptschlüssels C5D6C919005F36A4 verwendet
"[User-ID nicht gefunden]"
gpg: der Unterschlüssel FFA2FCCB2EC589F8 wird anstelle des Hauptschlüssels 458612006D8E6F0D verwendet
gpg: verschlüsselt mit 384-Bit ECDH Schlüssel, ID FFA2FCCB2EC589F8, erzeugt 2023-03-08
"Berta Boss <Berta.Boss@demo.gnupg.com>"
gpg: AES256 verschlüsselte Daten
gpg: keydb: handles=6 locks=0 parse=6 get=6
gpg: build=0 update=0 insert=0 delete=0
gpg: reset=0 found=6 not=0 cache=0 not=0
gpg: kid_not_found_cache: count=0 peak=0 flushes=0
gpg: sig_cache: total=12 cached=12 good=12 bad=0
gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0
outmix=0 getlvl1=0/0 getlvl2=0/0
gpg: rndjent stat: collector=0x00000000 calls=0 bytes=0
gpg: secmem usage: 0/32768 bytes in 0 blocks
# off=0 ctb=84 tag=1 hlen=2 plen=158
:pubkey enc packet: version 3, algo 18, keyid FFA2FCCB2EC589F8
data: 0453F921EE3F53F8F2A051FFC821FCFCF2CF44A166FC9A9D4D7E8C12166E54040578E9D86A4657EF0FA8FC644BDCF7AB0681606E225FFB186A41BCC4AAED5B6B199EB41EC62D23108E9A6FF7442A15889BE84EFEDE470AA367EA546A1238BDA361
data: 30B80D2FDA78C29FEA52C4D94A2EA8C1E3B2EEA20335501CA9A8DF594A99DE96207A89995E8CD4A159D244DB92EA96CAF3
# off=160 ctb=85 tag=1 hlen=3 plen=396
:pubkey enc packet: version 3, algo 1, keyid CD573B2B0736643A
data: 66E5F82444B102FEBDE20D7F1DE5AD956C1D3501C7A8C31D8F52282EDFB63119691788392069CB63314E33E12EAA09F4BC6E5B172F05791DE2F1460EAA95FDE5A84388538CDD13B983161B8B7E825A2BF91B1283BE4946E7CCF748263D42D90414513B49F3BAF283F1F66A497CCCAB2F90C65F9805692A09E5357CFDD1EBB962C662D354766BAF31950910D999EE58846F9453CAFDCCB82B9BB8EAE7AA8780BF4C356DF7CDFE90D1D03414095B2C3D760CCE20010F76FCF1174BE43ED3E7C8ED2F6A100C7E6C573C85A41F34627C40DB3E80924A792B5AB1C960401E7C727967BD31DFC2D2BEF0D069F623686FC2DE58614F5F3D0CB1A48EF746AE44A9411C64DE8917159D6D19B37DCAC61863D131B52F8691F698C4356A5237E063A00D20B31A24B5F52CC28C186FFC06757AE534EEE86B14E90294BC00A6BA82AD5BA8993D7CF6D82AF52C35BB0DEDD6446176EFC446A723D57F8771BB48FDE43523E9D40997AB641F6695750B273C9BE4DC3B040ECD98F028E8629C0090D2B613DBA291AA
# off=559 ctb=d2 tag=18 hlen=2 plen=94 new-ctb
:encrypted data packet:
length: 94
mdc_method: 2
# off=580 ctb=a3 tag=8 hlen=1 plen=0 indeterminate
:compressed packet: algo=2
# off=582 ctb=ac tag=11 hlen=2 plen=42
:literal data packet:
mode b (62), created 1695390990, name="test2.txt",
raw data: 27 bytesWhile trying to replicate your findings I might have found a but in the import code which rejected one of the keys (using gnupg 2.2). I'll take care of this.
Further investigation showed that this was due to a bogus key creating during I wrote the code.