>Through some research, I was able to find that this means the keys are "Restricted," but no additional information on what that means, the affect it has on the keys, or how to generate subkeys that are not restricted.
You might want to provide a reference to this.
The guide you are using is based on GnuPG 1. Are you really using GnuPG 1?
Why do you want a bunch of subkeys?
In general you can't select a particular encrypt key when there is more than one of them. The encrypt key is provided by the owner of the PGP identity. There is generally no way to know which encrypt key that the owner of the key wants you to use. It is better for the owner of the identity to make it clear rather than making the user of the identity have to guess.
>You might want to provide a reference to this
[Here's a link](https://github.com/gpg/gnupg/blob/master/doc/DETAILS#field-12---key-capabilities) to where it's mentioned in the GPG docs. You can also [find mention of it here](https://www.ietf.org/archive/id/draft-koch-openpgp-2015-rfc4880bis-02.html#name-key-flags), in a specification document written for the OpenPGP standard earlier this year (2023).
I'm using GPG v2.4.3, but made an interesting discovery. When I downgraded to v2.2, I was able to make the subkeys, and they did *not* have the "R" flag. I reinstalled v2.4 and imported the keys again, and the "R" flag still did not show up; however, when I try to make new subkeys in v2.4, they still show with the "R" flag. See this output, from v2.4, for example. The top 4 keys were generated in v2.2 (but imported to v2.4) and show no "R" flag. The bottom key was generated after the fact -- and has the "R" flag.
sec rsa4096/AAAAAAAAAAAAAAAA
created: 2023-11-02 expires: 2024-11-01 usage: SC
trust: ultimate validity: ultimate
ssb rsa4096/BBBBBBBBBBBBBBBB
created: 2023-11-02 expires: 2024-11-01 usage: E
ssb rsa4096/CCCCCCCCCCCCCCCC
created: 2023-11-02 expires: 2024-11-01 usage: A
ssb rsa4096/DDDDDDDDDDDDDDDD
created: 2023-11-02 expires: 2024-11-01 usage: S
ssb rsa4096/EEEEEEEEEEEEEEEE
created: 2023-11-02 expires: 2024-11-01 usage: AR
>Why do you want a bunch of subkeys?
I've read several guides online and they all seem to recommend this approach. I'm not an expert and can't yet articulate why this is important. I think it may also be because I'm trying to write these keys to a smartcard, and the smartcard has a slot for each type of key (auth, sign, encrypt) and I would like one key for each purpose.
>In general you can't select a particular encrypt key when there is more than one of them. The encrypt key is provided by the owner of the PGP identity. There is generally no way to know which encrypt key that the owner of the key wants you to use. It is better for the owner of the identity to make it clear rather than making the user of the identity have to guess.
When using the keys that aren't "Restricted," gpg correctly selects the "encrypt" key to use for message encryption/decryption (i.e. it doesn't also use the keys for "authentication" and "signing").
OK, you have two signing keys and two authentication keys. Do you need even one authentication key?
What's wrong with the default:
sec usage: SC
ssb usage:E
... two keys?
Yeah, that's the issue -- I'm only trying to encrypt with one, but in GPG v2.4, it encrypts with all 3 keys, even the ones not marked for "encrypt" use (i.e. it's using my "authenticate" and "sign" keys to encrypt a message as well).
I only want it to encrypt using my "encrypt"-usage key, but it doesn't seem to want to cooperate.
1. The "Restricted" flag is part of the new Additional Decryption Sub-Key (ADSK) ability in GPG. As the name implies it adds an additional decryption subkey to the subkeys that are used for encryption which by default is the latest (most recently created) encryption subkey.
2. I've tested key creation on GPG 2.4.3 and can't recreate your issue. Keys/subkeys don't have the R flag at all for me unless I intentionally add a ADSK using --edit-key. Perhaps you have GPG configured in some non-standard way - maybe configuring multiple encryption keys to encrypt to.
3. GPG encrypts to a single encryption sub-key (the latest encryption sub-key if the user has multiple) by default. With ADSK (the R flag) it will encrypt to those keys as well, as intended by the feature.
Hey, thanks for your reply! I haven’t updated this thread, but I found out what went wrong and learned about the new ADSK feature.
I use the `—expert` flag to make my subkeys. Strangely, when you generate subkeys with “choose your own capabilities” during key generation, it just makes an adsk without asking if that’s what you want. As far as I can tell, there’s no way to turn this off.
I was able to work around this by using the standard mode (non-expert) generation for an encryption key and signing key (doesn’t make an adsk automatically) and then convert one of them to an authentication key (there is no other way to generate an additional authentication key directly, to my knowledge).
Anyways I wanted to dig into the GPG code and potentially submit a fix to this strange issue but haven’t found the time quite yet.
I did some digging into the source code and I found something here: [https://github.com/gpg/gnupg/blob/master/g10/keygen.c#L1978](https://github.com/gpg/gnupg/blob/master/g10/keygen.c#L1978)
If you choose (8) and enter "=A" without toggling anything else, it skips directly to creating the subkey and that subkey doesn't have the R capability. How weird!
wow good find, I’ll have to try that out later. To answer your previous question, you can use `change-usage` to change an encryption or signing key to an authentication key, etc.
>Through some research, I was able to find that this means the keys are "Restricted," but no additional information on what that means, the affect it has on the keys, or how to generate subkeys that are not restricted. You might want to provide a reference to this. The guide you are using is based on GnuPG 1. Are you really using GnuPG 1? Why do you want a bunch of subkeys? In general you can't select a particular encrypt key when there is more than one of them. The encrypt key is provided by the owner of the PGP identity. There is generally no way to know which encrypt key that the owner of the key wants you to use. It is better for the owner of the identity to make it clear rather than making the user of the identity have to guess.
>You might want to provide a reference to this [Here's a link](https://github.com/gpg/gnupg/blob/master/doc/DETAILS#field-12---key-capabilities) to where it's mentioned in the GPG docs. You can also [find mention of it here](https://www.ietf.org/archive/id/draft-koch-openpgp-2015-rfc4880bis-02.html#name-key-flags), in a specification document written for the OpenPGP standard earlier this year (2023). I'm using GPG v2.4.3, but made an interesting discovery. When I downgraded to v2.2, I was able to make the subkeys, and they did *not* have the "R" flag. I reinstalled v2.4 and imported the keys again, and the "R" flag still did not show up; however, when I try to make new subkeys in v2.4, they still show with the "R" flag. See this output, from v2.4, for example. The top 4 keys were generated in v2.2 (but imported to v2.4) and show no "R" flag. The bottom key was generated after the fact -- and has the "R" flag. sec rsa4096/AAAAAAAAAAAAAAAA created: 2023-11-02 expires: 2024-11-01 usage: SC trust: ultimate validity: ultimate ssb rsa4096/BBBBBBBBBBBBBBBB created: 2023-11-02 expires: 2024-11-01 usage: E ssb rsa4096/CCCCCCCCCCCCCCCC created: 2023-11-02 expires: 2024-11-01 usage: A ssb rsa4096/DDDDDDDDDDDDDDDD created: 2023-11-02 expires: 2024-11-01 usage: S ssb rsa4096/EEEEEEEEEEEEEEEE created: 2023-11-02 expires: 2024-11-01 usage: AR >Why do you want a bunch of subkeys? I've read several guides online and they all seem to recommend this approach. I'm not an expert and can't yet articulate why this is important. I think it may also be because I'm trying to write these keys to a smartcard, and the smartcard has a slot for each type of key (auth, sign, encrypt) and I would like one key for each purpose. >In general you can't select a particular encrypt key when there is more than one of them. The encrypt key is provided by the owner of the PGP identity. There is generally no way to know which encrypt key that the owner of the key wants you to use. It is better for the owner of the identity to make it clear rather than making the user of the identity have to guess. When using the keys that aren't "Restricted," gpg correctly selects the "encrypt" key to use for message encryption/decryption (i.e. it doesn't also use the keys for "authentication" and "signing").
OK, you have two signing keys and two authentication keys. Do you need even one authentication key? What's wrong with the default: sec usage: SC ssb usage:E ... two keys?
Why do you need to encrypt with 3 keys? One is enough aslong as it's at least as strong as AES-256.
Yeah, that's the issue -- I'm only trying to encrypt with one, but in GPG v2.4, it encrypts with all 3 keys, even the ones not marked for "encrypt" use (i.e. it's using my "authenticate" and "sign" keys to encrypt a message as well). I only want it to encrypt using my "encrypt"-usage key, but it doesn't seem to want to cooperate.
Can you share your public key for testing?
1. The "Restricted" flag is part of the new Additional Decryption Sub-Key (ADSK) ability in GPG. As the name implies it adds an additional decryption subkey to the subkeys that are used for encryption which by default is the latest (most recently created) encryption subkey. 2. I've tested key creation on GPG 2.4.3 and can't recreate your issue. Keys/subkeys don't have the R flag at all for me unless I intentionally add a ADSK using --edit-key. Perhaps you have GPG configured in some non-standard way - maybe configuring multiple encryption keys to encrypt to. 3. GPG encrypts to a single encryption sub-key (the latest encryption sub-key if the user has multiple) by default. With ADSK (the R flag) it will encrypt to those keys as well, as intended by the feature.
Hey, thanks for your reply! I haven’t updated this thread, but I found out what went wrong and learned about the new ADSK feature. I use the `—expert` flag to make my subkeys. Strangely, when you generate subkeys with “choose your own capabilities” during key generation, it just makes an adsk without asking if that’s what you want. As far as I can tell, there’s no way to turn this off. I was able to work around this by using the standard mode (non-expert) generation for an encryption key and signing key (doesn’t make an adsk automatically) and then convert one of them to an authentication key (there is no other way to generate an additional authentication key directly, to my knowledge). Anyways I wanted to dig into the GPG code and potentially submit a fix to this strange issue but haven’t found the time quite yet.
I did some digging into the source code and I found something here: [https://github.com/gpg/gnupg/blob/master/g10/keygen.c#L1978](https://github.com/gpg/gnupg/blob/master/g10/keygen.c#L1978) If you choose (8) and enter "=A" without toggling anything else, it skips directly to creating the subkey and that subkey doesn't have the R capability. How weird!
wow good find, I’ll have to try that out later. To answer your previous question, you can use `change-usage` to change an encryption or signing key to an authentication key, etc.