Posted on 2018-11-12 23:52 technical
A month ago my key has expired again, so I spent some time exploring subkey behavior in gnupg. This is an experimental procedure for converting a typical primary/sub key pair into a pair of independent keys. I don't have practical experience with all the different implications of the switch, so proceed at your own risk.
First and most important point is that contrary to my previous assumption pgp can work with a single, primary key.
Default key generator though forces you into a particular set of ancient assumptions, that also gave us keychain databases, trust levels, signing parties and other such rituals, that seem to have been designed in vacuum, and failed to gain standing in the real world. A key can be used for Signing and Encryption, but also Certification, that is the signing of subkeys in a keychain. What the key is allowed to do is stored in the key's usage flags, and is enforced by gnupg. The usage is split between primary key and any number of subkeys. By default the primary key is allowed to Sign and Certify, the subkey in turn can only Encrypt. Gnupg gives preference to subkeys, so if e.g. a subkey has a Sign flag, it will be used for signing instead of the primary key.
Here's an example of a typical primary/sub pair, that you get with gen-key:
% gpg --homedir keys --edit-key 60D55B29
Secret key is available.
pub 2048R/60D55B29 created: 2018-10-12 expires: never usage: SC
trust: ultimate validity: ultimate
sub 2048R/4FC43EBB created: 2018-10-12 expires: never usage: E
[ultimate] (1). test key
The goal is to remove the subkey, and allow the primary key to also encrypt. You can delete the subkey using edit-key interface, but the procedure for editing usage flags is more elaborate. Unfortunately I haven't found a way to edit key's usage flags after the key has been generated, but there's a way to surgically split the keys and give them whatever options you need. Frankly I'm surprised there isn't an easier way!1
A pgp key consists of a series of packets,
% gpg --homedir keys --export-secret-key | pgpdump |grep Packet Old: Secret Key Packet(tag 5)(920 bytes) Old: User ID Packet(tag 13)(16 bytes) Old: Signature Packet(tag 2)(312 bytes) Old: Secret Subkey Packet(tag 7)(920 bytes) Old: Signature Packet(tag 2)(287 bytes)
Secret key/subkey packets contain the necessary values to do RSA computation and nothing else. The only difference between a key and a subkey is the packet tag.
Old: Secret Key Packet(tag 5)(920 bytes)
Ver 4 - new
Public key creation time - Fri Oct 12 00:29:24 EDT 2018
Pub alg - RSA Encrypt or Sign(pub 1)
RSA n(2048 bits) - ...
RSA e(17 bits) - ...
RSA d(2044 bits) - ...
RSA p(1024 bits) - ...
RSA q(1024 bits) - ...
RSA u(1023 bits) - ...
Checksum - 3f b4
A user id packet is a string value that's assembled out of the relevant gen-key questions,
Old: User ID Packet(tag 13)(16 bytes)
User ID - test key
A signature packet is the bucket full of Everything Else,
Old: Signature Packet(tag 2)(312 bytes)
Ver 4 - new
Sig type - Positive certification of a User ID and Public Key packet(0x13).
Pub alg - RSA Encrypt or Sign(pub 1)
Hash alg - SHA1(hash 2)
Hashed Sub: signature creation time(sub 2)(4 bytes)
Time - Fri Oct 12 00:29:24 EDT 2018
Hashed Sub: key flags(sub 27)(1 bytes)
Flag - This key may be used to certify other keys
Flag - This key may be used to sign data
Hashed Sub: preferred symmetric algorithms(sub 11)(5 bytes)
Sym alg - AES with 256-bit key(sym 9)
Sym alg - AES with 192-bit key(sym 8)
Sym alg - AES with 128-bit key(sym 7)
Sym alg - CAST5(sym 3)
Sym alg - Triple-DES(sym 2)
Hashed Sub: preferred hash algorithms(sub 21)(5 bytes)
Hash alg - SHA256(hash 8)
Hash alg - SHA1(hash 2)
Hash alg - SHA384(hash 9)
Hash alg - SHA512(hash 10)
Hash alg - SHA224(hash 11)
Hashed Sub: preferred compression algorithms(sub 22)(3 bytes)
Comp alg - ZLIB (comp 2)
Comp alg - BZip2(comp 3)
Comp alg - ZIP (comp 1)
Hashed Sub: features(sub 30)(1 bytes)
Flag - Modification detection (packets 18 and 19)
Hashed Sub: key server preferences(sub 23)(1 bytes)
Flag - No-modify
Sub: issuer key ID(sub 16)(8 bytes)
Key ID - 0xC1E46ED560D55B29
Hash left 2 bytes - 1f 27
RSA m^d mod n(2048 bits) - ...
-> PKCS-1
It contains and signs various dates, flags, and preferences. Of interest are the "key flags". Now one could write a pgp packet editor, that will patch the relevant bits in, and I suspect that's something that asciilifeform might have on his workbench already, but there exists a somewhat odd way of breaking the keys apart and then reassembling them from bits.
We will need a signature with the right key flags enabled. I said that gnupg gives you a primary/sub key pair by default, but with an --expert flag you can make it produce whatever key configuration you want, and that should really be the recommended way of making new keys in the republic.
% mkdir tmp % gpg --homedir tmp --gen-key --expert Please select what kind of key you want: (1) RSA and RSA (default) (2) DSA and Elgamal (3) DSA (sign only) (4) RSA (sign only) (7) DSA (set your own capabilities) (8) RSA (set your own capabilities) Your selection? 8 Possible actions for a RSA key: Sign Certify Encrypt Authenticate Current allowed actions: Sign Certify Encrypt (S) Toggle the sign capability (E) Toggle the encrypt capability (A) Toggle the authenticate capability (Q) Finished Your selection? q RSA keys may be between 1024 and 4096 bits long. What keysize do you want? (2048) 1024 [...]
Now we split the two key sets we have with a gpgsplit utility that's part of gnupg,
% gpg --homedir keys --export-secret-key | gpgsplit -p k % gpg --homedir tmp --export-secret-key | gpgsplit -p tmp % ls k000001-005.secret_key k000005-002.sig tmp000002-013.user_id k000002-013.user_id keys tmp000003-002.sig k000003-002.sig tmp k000004-007.secret_subkey tmp000001-005.secret_key
which gives us all the packets in separate files. The ones prefixed with k- are the original keys (there's 5 files that correspond to 5 packets from pgpdump above), the tmp- ones are the temp key we just generated.
An arbitrary key combination can now be assembled out of the individual packets, but we use original primary key, original user id and the signature from the temp key.
% cat k000001-005.secret_key k000002-013.user_id tmp000003-002.sig > key
A straight import of the resulting key will fail, because of the invalid signature, but passing an --allow-non-selfsigned-uid will bypass the signature verification, while still applying whatever preferences are stored in signature packet,
% gpg --homedir tmp1 --allow-non-selfsigned-uid --import key gpg: WARNING: unsafe permissions on homedir `tmp1' gpg: keyring `tmp1/secring.gpg' created gpg: keyring `tmp1/pubring.gpg' created gpg: key 60D55B29: secret key imported gpg: key 60D55B29: accepted non self-signed user ID "test key" gpg: tmp1/trustdb.gpg: trustdb created gpg: key 60D55B29: public key "test key" imported gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1) gpg: secret keys read: 1 gpg: secret keys imported: 1 gpg: no ultimately trusted keys found
Finally in order to fix the key's internal consistency we need to delete the bogus signature and re-sign the identity,
% gpg --homedir tmp1 --allow-non-selfsigned-uid --edit-key 60D55B29
Secret key is available.
pub 2048R/60D55B29 created: 2018-10-12 expires: never usage: SCEA
trust: unknown validity: unknown
[ unknown] (1). test key
gpg> uid 1
pub 2048R/60D55B29 created: 2018-10-12 expires: never usage: SCEA
trust: unknown validity: unknown
[ unknown] (1)* test key
gpg> delsig
uid test key
sig?3 4FEE77E7 2018-11-13
Delete this unknown signature? (y/N/q)y
Deleted 1 signature.
gpg> sign
pub 2048R/60D55B29 created: 2018-10-12 expires: never usage: SCEA
trust: unknown validity: unknown
Primary key fingerprint: 454C 1EFC A29D 02A0 E6CE 3A47 C1E4 6ED5 60D5 5B29
royal astronomer
Are you sure that you want to sign this key with your
key "test key" (60D55B29)
This will be a self-signature.
Really sign? (y/N) y
gpg> save
The entire ungodly procedure gives us the original primary key 60D55B29 with all the usage flags enabled. The procedure can be repeated with the subkey, and is left as an exercise for the reader. It requires first patching k000004-007.secret_subkey subkey's first byte to 149 to switch it from Secret Subkey Packet(tag 7) to Secret Key Packet(tag 5).2
Now one can distribute the primary key as the canonical key, and keep the newly elevated subkey around to decrypt messages from the correspondents who are using an old pubkey.
with Ada.Direct_IO; with Ada.Command_Line; use Ada.Command_Line; procedure P is type Byte is mod 2**8; package Io is new Ada.Direct_IO(Byte); use Io; F: Io.File_Type; B: Byte; Position: Positive_Count; Wrong_File: exception; begin Open( F, Inout_File, Argument(1) ); Position := Positive_Count'Value( Argument(2) ); B := Byte'Value( Argument(3) ); Write( F, B, Position ); Close( F ); end;
which can be used thus,
% gprbuild p.adb
[...]
% ./p 000004-007.secret_subkey 1 149
% pgpdump 000004-007.secret_subkey | grep Packet
Old: Secret Key Packet(tag 5)(920 bytes [↩]
Post a comment
Dear Phf,
Are you still alive? What have you been up to these days?
Any chance of updates to the patches www, or of publishing the src?
Yours,
-S
Posted 2020-01-2214:00 by Stanislav Datskovskiy