Differences

This shows you the differences between two versions of the page.

--- pgpfan:gpgburn [2021/12/06 02:20] – missed b.walzer
+++ pgpfan:gpgburn [2021/12/06 12:10] (current) – Typo. b.walzer
@@ Line 31: / Line 31: @@
 </code>
-Then use the ''key'' command to select the encryption subkey (''ssb*'', ''usage: E'') which is this case is the first subkey:
+Then use the ''key'' command to select the encryption subkey (''ssb*'', ''usage: E'') which in this case is the first subkey:
 <code text [highlight_lines_extra="6,7"]>
@@ Line 147: / Line 147: @@
 Now export your updated public key (OpenPGP identity) and send it to your correspondents and any appropriate key servers (not shown). At this point you are in the preburning transition phase. You will still be able to decrypt your old messages and any messages from people that have not yet updated your public key in their keyring. You will also be able to decrypt any messages from people that have updated your public key to the new one. If you are not in any hurry there is no reason that this phase can't last months or even years. Messages generated in the transition phase will not be burnt. This would be a good time to look through your old messages for anything that you want to save before burning them. You can probably do this by remailing them to yourself.
-OK, sufficient time has passed, all your correspondents have your new key installed in their keyrings. Thus starts the actual burning. For the demonstration you are going to do a secure delete of the file containing your old encryption subkey. Find the file name using the gpg ''--with-keygrip'' option to the ''--list-keys'' command looking for the older subkey that has no usage ''[]'':
+OK, sufficient time has passed, all your correspondents have your new key installed in their keyrings. Thus starts the actual burning. For the demonstration you are going to do a secure delete of the file containing your old encryption subkey. Find the file name using the gpg ''%%--with-keygrip%%'' option to the ''%%--list-keys%%'' command looking for the older subkey that has no usage ''[]'':
 <code text [highlight_lines_extra="6,7"]>
@@ Line 244: / Line 244: @@
 Removing the encryption designation from your old encryption subkey might not be strictly necessary. GnuPG will automatically select the newest encryption subkey. This behaviour is not part of any standard so the removal of the encryption designation is intended as a form of insurance to cover the case where other OpenPGP implementations have different behaviour.
-There is no point in redistributing your new cleaned up key produced at the end of the demonstration. Importing that key will not result in a change to your current correspondents keyrings or your key already stored on a key server. That is because the OpenPGP practice is to merge subkeys on an import. That eliminates the complexity of a mechanism exclusively under the control of the key owner to delete subkeys.
+There is no point in redistributing your new cleaned up key produced at the end of the demonstration. Importing that key will not result in a change to your current correspondents keyrings or your key already stored on a key server. Your old encryption key will remain. That is because the OpenPGP practice is to merge subkeys on an import. That eliminates the complexity of a mechanism exclusively under the control of the key owner to delete subkeys.
 Deleting the private key, even with an overwrite as shown here might not be reliable. See [[em:burn#the_trouble_with_media|The Trouble With Media]] for the details. For some sort of extreme security requirement a backup followed by media destruction followed by a restore might be in order.
 This process is very manual. There are no GnuPG ''%%--preburn%%'' and ''%%--burn%%'' commands to automate this. This suggests that this is not something that is commonly done. Most people don't fear the exposure of their keys enough to make this worthwhile for this sort of system.
+[[pgpfan:index|PGP FAN index]]
+[[em:index|Encrypted Messaging index]]