I need help with two PGP / GPG issues:
- Ensuring that my thinking is correct (i.e., I really do need another GPG subkey for my scenario)
- Ensuring that I create the subkey correctly without compromising my current keys (bonus to any extra constructive criticism / suggestions from the data exposed).
GPG SUBKEY SCENARIO
I use my GPG key for:
- Encrypting and/or signing some email conversations
- Signing my Git commits
There has been something that has bugged me for a while now regarding using the same key for both.
As pointed out in the Alan Turing movie, "The Imitation Game" (2014), the Enigma encoded messages were cracked only after the namespace was cut down dramatically. The machine Turing built couldn't try enough combinations before the ciphers were changed. However, by cutting the namespace down dramatically, they were able to decipher the messages.
The way the namespace was cut down was by finding a phrase known to be in every coded message. Again, referring to the Turing movie, if I remember correctly, this phrase was "Heil Hitler" signed at the bottom of every German message.
Encrypting an email message does not concern me as the typical email headers are not part of the message that is being encrypted. However, if one looks at the internal structure of a Git commit, it always contains "tree", "author" and "committer." And, except for one commit, it also always includes "parent".
Additionally, we can assume the "author" and "committer" will often be the same. In the example below "Glen Jarvis ". Here is an example of a signed commit message that I have recently made (unsigned commit messages had the same structure as signed commit messages — the are only missing the "gpgsig" key and its following multiline value):
tree 29d37a46658eaeb764b587a105be5eabc2d6a641 parent 45646279562c74461e7237104e9f335ac3054635 author Glen Jarvis <email@example.com> 1500272497 -0700 committer Glen Jarvis <firstname.lastname@example.org> 1500272497 -0700 gpgsig -----BEGIN PGP SIGNATURE----- iQIcBAABAgAGBQJZbFd3AAoJEJF24vsEed5ckiEP/26n9kfkwx2i0z+hhlDTytYP qlFvHRgv4djOQCZkbDiRU5PS3G5dS9LQpVJ/bHrXLKfUPhB/pux64XEv+mTRqrk3 ncgGt0sEWoIaZhHhY5Cyc+2MCoNgDCIxSexP7X5bvxRwO1cGeuJ4AfmcL/Fp+xRz vFaPINSZJMvXqJBFnnNFltFFSe4HRA+wloTLyk9zpJ7LnOKMHNbkPCxmf2dqBjmL ZEi9VFM9r0EYmXmZSF1KThCXy2dZDMPhRhe8VwPXQ8jXMSChhwSD+wFT79+xF/Fg hq2vpD9vkqcYUfucobNzz7T17Fr7ICuZvhGXxOwYk079p9SyPpN9U3VuqayEyV6O B49J8tcblu1XfrGh151Lhp6Fjr2TbKecnB2q/XgaH7MsaR99xt1UFaKVlMtbTn95 vqTSieyG3IPSjp+17oXev83IHXMvIKCetx5r3D9vUrKd4HVPAzzjfDjSO99Smz2J 2UKHep7da0SOpN/bn/x13CzYW9MCtN0FFAYogIuDu61HnlhOik+WqMm+uCvgmtzm 0BdSEPAn9udvpAkHRcEd3a2JYABvheEjgDhqWLy9iL1Z+wKP9Sz5Mh9xYVI6AA8V Cs6vyYJqoS5GRGh0UNR26hafpCcIbXZLjXVkxWVzZGYqHpf+adBOiOmrtRF87Fz4 3hgDVlhzTagHBw3HEmWD =juvL -----END PGP SIGNATURE----- Switch to Wheel format
My concern is that, by using the same GPG key to sign these commit messages and encrypt/sign email messages, I am weakening my key so that my email messages may be more easily decrypted. My Git commits are publicly available in GitHub. Is my thinking sound?
Assuming my thinking above is correct and this is a concern, I need help making the correct subkey. I can encrypt my email messages with
F27C. And, I can sign my commit messages with a subkey if I can create it correctly. I already understand how to configure Git to choose which subkey to use in signing.
Here is a list of my public keys (some are clearly expired, have been rotated over time, and are here only for reference):
$ gpg --list-keys email@example.com pub rsa2048 2012-05-28 [SCEA] F27CA351FD010F450D2B1431DBCBDF2F36703FB2 uid [ unknown] Glen Jarvis (glenjarvis.com) <firstname.lastname@example.org> uid [ unknown] [jpeg image of size 7125] sub rsa4096 2016-06-05 [S] [expires: 2021-06-04] pub rsa2048 2012-05-07 [SCEA] B560A0D698E1E0267AA81F7DACD3887417F3CCD7 pub dsa1024 2008-05-25 [SCA] 8D6D27687BA839C9C88F4FE50B00116142CE11B6 pub dsa1024 2010-04-03 [SC] 63A1BBC8DCC51CA5E7CA1A4889B35CEFA08FF5FD uid [ unknown] Glen Jarvis <email@example.com> sub elg1024 2010-04-03 [E]
Also available on Keybase
Any unsolicited advice (from data exposed in this question) is also welcome.