The Call of the Open Sidewalk

From a place slightly to the side of the more popular path

User Tools

Site Tools


pgpfan:gpgburn

This is an old revision of the document!


A Demonstration of Message Burning Through Encryption using GnuPG

This can be taken as a practical example for Message Burning in Encrypted Messaging. It also serves as a standalone example of how forward secrecy could work in an OpenPGP context.

You might consider doing something like this if you have encrypted messages you would like to burn where they:

  • Can no longer be found to be deleted, or
  • Can not be reliably burned, or
  • Might of been archived without your knowledge or consent.

The following procedure completely destroys access to any encrypted messages sent to your OpenPGP identity in the past1). The advantage over just deleting your identity and making a new one is that the work that your correspondents did to verify that they have your correct identity is preserved. In other words; they do not have to reestablish any trust in your identity.

First use the GnuPG key editor on your own key and confirm you are editing the correct one (“Jane Noakes” for the purposes of this demonstration):

jnoakes:~$ gpg --edit-key jane
gpg (GnuPG) 2.2.30; Copyright (C) 2021 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
 
Secret key is available.
 
sec  rsa2048/B4ED075812FFF97C
     created: 2019-12-04  expires: 2025-12-13  usage: SC  
     trust: ultimate      validity: ultimate
ssb  rsa2048/6A165CD100AA1CFE
     created: 2019-12-04  expires: 2025-12-13  usage: E   
[ultimate] (1). Jane Noakes <jnoakes@example.org>
 
gpg>

Then use the key command to select the encryption subkey (ssb*, usage: E) which is this case is the first subkey:

gpg> key 1
 
sec  rsa2048/B4ED075812FFF97C
     created: 2019-12-04  expires: 2025-12-13  usage: SC  
     trust: ultimate      validity: ultimate
ssb* rsa2048/6A165CD100AA1CFE
     created: 2019-12-04  expires: 2025-12-13  usage: E   
[ultimate] (1). Jane Noakes <jnoakes@example.org>
 
gpg>

Use the change-usage command to remove the encryption usage (e, q) leaving your current encryption key with no permitted usage at all (usage: ):

gpg> change-usage
Changing usage of a subkey.
 
Possible actions for a RSA key: Sign Encrypt Authenticate 
Current allowed actions: Encrypt 
 
   (S) Toggle the sign capability
   (E) Toggle the encrypt capability
   (A) Toggle the authenticate capability
   (Q) Finished
 
Your selection? e
 
Possible actions for a RSA key: Sign Encrypt Authenticate 
Current allowed actions: 
 
   (S) Toggle the sign capability
   (E) Toggle the encrypt capability
   (A) Toggle the authenticate capability
   (Q) Finished
 
Your selection? q
 
sec  rsa2048/B4ED075812FFF97C
     created: 2019-12-04  expires: 2025-12-13  usage: SC  
     trust: ultimate      validity: ultimate
ssb* rsa2048/6A165CD100AA1CFE
     created: 2019-12-04  expires: 2025-12-13  usage:     
[ultimate] (1). Jane Noakes <jnoakes@example.org>
 
gpg>

Use the “addkey” command to create a new encryption key (6, 2048, 4y, y, y):

gpg> addkey
Please select what kind of key you want:
   (3) DSA (sign only)
   (4) RSA (sign only)
   (5) Elgamal (encrypt only)
   (6) RSA (encrypt only)
  (14) Existing key from card
Your selection? 6
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (3072) 2048
Requested keysize is 2048 bits
Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0) 4y
Key expires at Wed Dec  3 14:24:16 2025 CST
Is this correct? (y/N) y
Really create? (y/N) y

You will be asked for the passphrase to unlock your OpenPGP identity here and possibly later:

┌───────────────────────────────────────────────────────────────┐
│ Please enter the passphrase to unlock the OpenPGP secret key: │
│ "Jane Noakes <jnoakes@example.org>"                           │
│ 2048-bit RSA key, ID B4ED075812FFF97C,                        │
│ created 2021-12-04.                                           │
│                                                               │
│                                                               │
│ Passphrase: *************************________________________ │
│                                                               │
│         <OK>                                   <Cancel>       │
└───────────────────────────────────────────────────────────────┘

Check that you have two subkeys, the old one with usage: and the new one with usage: E. Use the save command to make this real and end the key edit session:

We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
 
sec  rsa2048/B4ED075812FFF97C
     created: 2019-12-04  expires: 2025-12-13  usage: SC  
     trust: ultimate      validity: ultimate
ssb  rsa2048/6A165CD100AA1CFE
     created: 2019-12-04  expires: 2025-12-13  usage:     
ssb  rsa2048/52AEB4B0CFE61BE4
     created: 2021-12-04  expires: 2025-12-03  usage: E   
[ultimate] (1). Jane Noakes <jnoakes@example.org>
 
gpg> save
jnoakes:~$ 

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 []:

jnoakes:~$ gpg --with-keygrip --list-keys jane     
pub   rsa2048 2019-12-04 [SC] [expires: 2025-12-13]
      73C545C937EFA44679338B21B4ED075812FFF97C
      Keygrip = 5F742902AFF9125A26242F270BAA0F9F792A5A53
uid           [ultimate] Jane Noakes <jnoakes@example.org>
sub   rsa2048 2019-12-04 [] [expires: 2025-12-13]
      Keygrip = 70DDFAEB6BA38E8D515CC9AD3BB5D061A7CDB316
sub   rsa2048 2021-12-04 [E] [expires: 2025-12-03]
      Keygrip = CFDF64FA3733B60AFFE52AA70FC7BFD6930AD4BA
 
jnoakes:~$ 

The filename is the keygrip with a .key extension. The file is found in the private-keys-v1.d directory/folder in the GnuPG working directory. The example for securely deleting the private key file on OpenBSD would be:

jnoakes:~$ rm -P -v /home/jnoakes/.gnupg/private-keys-v1.d/70DDFAEB6BA38E8D515CC9AD3BB5D061A7CDB316.key

… and on Linux:

jnoakes:~$ shred --remove --verbose /home/jnoakes/.gnupg/private-keys-v1.d/70DDFAEB6BA38E8D515CC9AD3BB5D061A7CDB316.key

At this point the burn is complete. The old encryption subkey is now useless in practice as well as usage designation and can be removed. Again edit your key and find the old encryption subkey with the usage: designation:

jnoakes:~$ gpg --edit-key jane                                                                       
gpg (GnuPG) 2.2.30; Copyright (C) 2021 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
 
Secret key is available.
 
sec  rsa2048/B4ED075812FFF97C
     created: 2019-12-04  expires: 2025-12-13  usage: SC  
     trust: ultimate      validity: ultimate
sub  rsa2048/6A165CD100AA1CFE
     created: 2019-12-04  expires: 2025-12-13  usage:     
ssb  rsa2048/52AEB4B0CFE61BE4
     created: 2021-12-04  expires: 2025-12-03  usage: E   
[ultimate] (1). Jane Noakes <jnoakes@example.org>
 
gpg>

Select it using the key command. In this case it is the first subkey (sub*, usage: ):

gpg> key 1
 
sec  rsa2048/B4ED075812FFF97C
     created: 2019-12-04  expires: 2025-12-13  usage: SC  
     trust: ultimate      validity: ultimate
sub* rsa2048/6A165CD100AA1CFE
     created: 2019-12-04  expires: 2025-12-13  usage:     
ssb  rsa2048/52AEB4B0CFE61BE4
     created: 2021-12-04  expires: 2025-12-03  usage: E   
[ultimate] (1). Jane Noakes <jnoakes@example.org>
 
gpg>

Delete the key using the delkey command (y). Use the save command to make this real and end the key edit session:

gpg> delkey
Do you really want to delete this key? (y/N) y

sec  rsa2048/B4ED075812FFF97C
     created: 2019-12-04  expires: 2025-12-13  usage: SC  
     trust: ultimate      validity: ultimate
ssb  rsa2048/52AEB4B0CFE61BE4
     created: 2021-12-04  expires: 2025-12-03  usage: E   
[ultimate] (1). Jane Noakes <jnoakes@example.org>

gpg> save
jnoakes:~$ 

This is what we did during this demonstration:

  • Removed the encryption usage designation from your current encryption subkey.
  • Added another encryption subkey.
  • Sent out your public key (OpenPGP identity) to your correspondents and any appropriate key servers.
  • Waited for all the possible changes to take place.
  • Securely deleted the private key for your old encryption subkey.
  • Deleted your old encryption subkey.

Discussion

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.

Deleting the private key, even with an overwrite as shown here might not be reliable. See 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.

1)
Since this is burning through encryption this only works up to the point that the encryption on the messages is broken. The actual messages should be deleted as well if possible.
pgpfan/gpgburn.1638757552.txt.gz · Last modified: 2021/12/06 02:25 by b.walzer