Project Talk:Infrastructure/Generating GLEP 63 based OpenPGP keys
Before creating a discussion or leaving a comment, please read about using talk pages. To create a new discussion, click here. Comments on an existing discussion should be signed using
~~~~:
A comment [[User:Larry|Larry]] 13:52, 13 May 2024 (UTC) : A reply [[User:Sally|Sally]] 12:45, 5 November 2024 (UTC) :: Your reply ~~~~
How to use Talk
I don't know how to quote in this Mediawiki installation. I hope my reply will be readable: --Michal Górny
- No problem, I wikified it for you. --Jonas Stein (talk) 13:15, 24 May 2020 (UTC)
utf8-strings
utf8-strings: why? If you're using UTF-8 locale, it's implicit. If you're not, then wtf? --Michal Górny (talk) 14:54, 29 August 2018 (UTC)
- -----
- This is to ensure that any key property is stored as UTF8-encoded string regardless of user's locale or other settings. --Whissi (talk) 09:10, 4 September 2018 (UTC)
keyid-format 0xlong
- keyid-format 0xlong is worse than the default keyid-format none. The former encourages users to use 'long ids' while the latter gives them full fingerprint. --Michal Górny (talk) 14:54, 29 August 2018 (UTC)
- -----
- This is wrong and I disagree: This option doesn't remove fingerprints. It only adds long ids in addition. Of course, people should use fingerprint whenever they deal with non-local keys. But once you are working with your local keyring, the risk is very limited:
-
- If you followed best practice, your keyring contains only these keys, you manually added using fingerprints.
- Even if you use applications that perform auto-key-fetching: If you haven't signed a key locally, the unsigned key doesn't expose any risk.
- Instead, long id will help you because it is displayed everywhere:
-
- GitHub
- Our own git hook will use long ids in error messages because this is the only reliable way to identify subkeys
- So my point is, displaying long id in addition does not hurt anyone but can help you debugging problems and make you understand key usage.
- No objections in removing the other GPG2 default values. --Whissi (talk) 09:10, 4 September 2018 (UTC)
4096-bit RSA vs 2048-bit
Secondly, your primary key is hardly 'perfect' as you claim it to be. You're using 4096-bit RSA while 2048-bit is recommended (but that's a minor issue) --Michal Górny (talk) 14:54, 29 August 2018 (UTC)
- -----
- There's not one opinion regarding key size. I guess you aren't calling Snowden or Bruce Schneier a dumb person, are you? Both picked a 4096-bit key.
- But that's not my point: Please recognize that this guide will show you how to create a master key setup with subkeys. The idea is that this master key will last for next 10 years. However, for day-to-day usage, it is OK to decide to use a 2048-bit RSA key. But it all depends:
- Please don't try to defend current hardware token like YubiKey, some Nitrokeys or other keycards which just don't support 4096-bit keysize or only offer very low speed when using a 4096-bit key by saying, "Well, if you thought doubling RSA keysize would double the difficulty of brute forcing the key, then I have bad news for you: That's not how it works. The increase in bits of security is only 18, a mere 16%". I guess we all agree that this isn't very much. But if you don't care because you will never use a hardware token or even use a CPU which offers RSA hardware acceleration then it doesn't matter and even 16% of an improvement still is an improvement.
- My point is: Once this guide is completed and you follow every step you should end up with a 4096-bit RSA master key stored on an air-gapped system and keep your keys you use for daily work (like signing commits, decryption or authentication) on a secure hardware token, then you should have a perfect key which should last for next 10 years.
- We don't know what will happen in 2, 4 or 5 years. Maybe 2048-bit keys are no longer considered to offer adequate security. In this case you would have to re-create a complete new key and you will lose all received signatures. With a 4096-bit RSA master key you have at least 16% higher chances. If you want to, you could even go for a 8192-bit master key. The large keysize wouldn't affect anyone's daily work because they use smaller subkeys. --Whissi (talk) 09:10, 4 September 2018 (UTC)
You're also using the maximum key expiration which is definitely not recommended. The recommendation also suggests using fixed day of year (such as January 1st). You are blatantly ignoring recommendations, so there is nothing 'perfect' about that key. --Michal Górny (talk) 14:54, 29 August 2018 (UTC)
- -----
- No. I just wasn't aware that GnuPG will accept dates in YYYY-MM-DD or YYYYMMDDThhmmss format in "expire" command.
- I'll update documentation for subkeys but at the moment I want to keep recommending using maximum expiration time for master key, given that the idea is to have that key stored on an air-gapped system which you should only access when needed. However, when you already have to access that system at least once a year to update expiration date of subkeys... one can argue that you could update master key expiration date at the same time. Will think about it. --Whissi (talk) 09:10, 4 September 2018 (UTC)
CLI output
Thirdly, the CLI output is completely unreadable since there is no distinction between lots of GnuPG output and your input. Pasting them like that makes no sense as the user would have to put more effort figuring out where he is than if he wasn't given any guide at all. --Michal Górny (talk) 14:54, 29 August 2018 (UTC)
- -----
- Most feedback I received yet liked that style and verbosity. I avoided 100% copy&paste-ready commands because I want that readers have to understand how it works. But if you have any idea how we could improve the documentation, please share! --Whissi (talk) 09:10, 4 September 2018 (UTC)
set your own capabilities
Fourthly, why are you going through set your own capabilities instead of using sign only and encrypt only? --Michal Górny (talk) 14:54, 29 August 2018 (UTC)
- -----
- Mh, have to think about it. Of course, this would save some steps for subkey creation. Thanks for the hint! --Whissi (talk) 09:10, 4 September 2018 (UTC)
switching from RSA to EdDSA
Fifthly, you are suddenly switching from RSA to EdDSA for authentication without any explanation. This is at least confusing. --Michal Górny (talk) 14:54, 29 August 2018 (UTC)
- -----
- The idea was to show readers that you can mix a RSA key with ECC subkey. I'll add an explanation. --Whissi (talk) 09:10, 4 September 2018 (UTC)
Debian & Subkeys
The debian project has a good manual about their key policy, perhaps we can copy or learn from them. https://wiki.debian.org/Subkeys --Jonas Stein (talk) 18:13, 2 September 2018 (UTC)
Drop [A] subkey for pubkey export
The [A] subkey for authentication isn't needed by 3rd parties and shouldn't be shared. I personally have export-filter "drop-subkey=usage=a" set in my "~/.gnupg/gpg.conf". Of course, you can use gpg --export-filter "drop-subkey=usage=a" --export etc., too. --Duxsco (talk) 01:38, 29 October 2022 (UTC)
Use --export-options no-export-attributes,export-clean
Photo IDs just bloat things up and it doesn't make sense to export unusable stuff. Thus, gpg --export-options no-export-attributes,export-clean --export EFA6F1BD36FA9FDE3C0432975C6A132050668578 | ssh dev.gentoo.org /usr/local/bin/openpgp-key-upload should be used. --Duxsco (talk) 02:05, 29 October 2022 (UTC)