The idea is to split your GPG identity into a master key you keep offline and subkeys you use day-to-day. If your machine is ever compromised, an attacker gets the subkeys — you revoke them, generate new ones, and your identity is intact.

What GPG is actually for

A GPG key pair has two common uses:

• Signing — attaching a cryptographic signature to something (a commit, a message, a package) so others can verify it came from you
• Encryption — encrypting something so only the holder of a specific private key can read it

Creating the master key pair

With GnuPG installed, start with:

gpg --expert --full-generate-key

You will be asked to choose a key type:

Please select what kind of key you want:
   (1) RSA and RSA
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
   (7) DSA (set your own capabilities)
   (8) RSA (set your own capabilities)
   (9) ECC (sign and encrypt) *default*
  (10) ECC (sign only)
  (11) ECC (set your own capabilities)
  (13) Existing key
  (14) Existing key from card
  (16) ECC and Kyber

Choose ECC (set your own capabilities) (option 11). RSA was the previous default, but ECC provides equivalent security with much smaller key sizes and faster operations. Neither RSA nor ECC is quantum-resistant, but ECC is the better option for classical threat models and is where the ecosystem has moved. Option 16 (ECC and Kyber) is an experimental post-quantum hybrid, but it lacks broad tooling support and is not recommended for general use yet.

Option 11 lets you control exactly which capabilities the master key has. GPG defaults to Sign and Certify, but the master key should only certify — signing data directly from the master key defeats the purpose of having subkeys. Toggle Sign off:

Possible actions for this ECC key: Sign Certify Authenticate
Current allowed actions: Sign Certify

   (S) Toggle the sign capability
   (A) Toggle the authenticate capability
   (Q) Finished

Your selection? S

Possible actions for this ECC key: Sign Certify Authenticate
Current allowed actions: Certify

   (S) Toggle the sign capability
   (A) Toggle the authenticate capability
   (Q) Finished

Your selection? Q

Enter S to remove the Sign capability, then Q to confirm. The master key will carry [C] only.

You will then be asked to choose a curve:

Please select which elliptic curve you want:
   (1) Curve 25519 *default*
   (2) Curve 448
   (3) NIST P-256
   (4) NIST P-384
   (5) NIST P-521
   (6) Brainpool P-256
   (7) Brainpool P-384
   (8) Brainpool P-512

Choose Curve 25519 (option 1). It uses ed25519 for signing — a well-vetted, modern algorithm with strong performance and wide support.

Next, you will be asked for an expiry:

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)

Set an expiry of one to two years. It might seem counterintuitive, but expiry is a safety net, not a limitation. You can extend it any time before it lapses. What you cannot do is un-publish a non-expiring key you have lost access to. An expired key at least communicates that it is no longer active.

After filling in your name, email, and a passphrase, GPG prints the result:

pub   ed25519 2026-03-31 [C] [expires: 2027-03-31]
      E31C074FA2D89B561C4A730F852E1D493BC60A7F
uid                      Adam Brauns <adam@example.com>

You can confirm it appears in your keyring:

gpg --list-secret-keys

sec   ed25519 2026-03-31 [C] [expires: 2027-03-31]
      E31C074FA2D89B561C4A730F852E1D493BC60A7F
uid           [ultimate] Adam Brauns <adam@example.com>

Reading the output

The labels in the output carry meaning worth understanding before you go further.

sec is your secret master key. ssb is a secret subkey. pub and sub are the public counterparts of each. The bracketed letters describe what the key is authorized to do:

The master key carries [C] only: it can certify but not sign data directly. Certify is what lets the master key generate subkeys, and it cannot be delegated. Subkeys can sign and encrypt but cannot spawn their own subkeys.

Adding a signing subkey

Open the key for editing:

gpg --edit-key E31C074FA2D89B561C4A730F852E1D493BC60A7F

At the gpg> prompt, type 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)
  (10) ECC (sign only)
  (12) ECC (encrypt only)
  (14) Existing key from card

Choose option 10 for an ECC signing subkey.

Please select which elliptic curve you want:
   (1) Curve 25519 *default*
   (4) NIST P-384
   (6) Brainpool P-256

Choose option 1 for elliptic curve.

Set the same expiry as your master key so they stay in sync, and enter your passphrase when prompted.

Once done, the key listing inside the editor should show two keys:

sec  ed25519/95BB0086DDD86937
     created: 2026-03-31  expires: 2027-03-31  usage: C
     trust: ultimate      validity: ultimate
ssb  ed25519/14072A8493246577
     created: 2026-03-31  expires: 2027-03-31  usage: S
[ultimate] (1). Adam Brauns <adam@example.com>

If you also want an encryption subkey, run addkey again and choose option 12 (ECC encrypt only). Select Curve 25519 and set the same expiry. The key listing will then show a third entry with usage: E. Note that even though both subkeys use Curve 25519, GPG generates different algorithms under the hood — ed25519 for signing and cv25519 (X25519) for encryption. That is why the final --list-secret-keys output shows different algorithm labels for each subkey.

Type save and press enter. Your keyring now has a master key for certification and two subkeys — one for encryption, one for signing. That is the complete set you need before moving the master key offline.

Exporting and backing up

Before removing anything from your local machine, export all three components. Adjust the filenames and key ID to match your setup:

gpg --output adam.public.gpg --export E31C074FA2D89B561C4A730F852E1D493BC60A7F
gpg --output adam.secret.gpg --export-secret-key E31C074FA2D89B561C4A730F852E1D493BC60A7F
gpg --output adam.secsub.gpg --export-secret-subkeys E31C074FA2D89B561C4A730F852E1D493BC60A7F

The public key export is what you share with the world — paste it into GitHub, upload it to a keyserver, whatever fits your workflow. The secret key export contains everything and goes to offline storage only. The secret subkeys export is what you will re-import onto your local machine after removing the master.

Before transferring these to your offline storage, you might also want to generate a revocation certificate:

gpg --output adam.revoke.asc --gen-revoke E31C074FA2D89B561C4A730F852E1D493BC60A7F

A revocation certificate lets you publicly invalidate the key even if you no longer have access to it. Store it alongside your other exports. If you ever lose both your machine and your backup, this is your last resort.

Copy all the files to a USB drive or external hard drive that you keep somewhere physically secure. These are your only copies of the master secret key once the next step is done, so the backup matters.

Removing the master key from your local machine

This step is what most guides skip. Delete the entire secret key from your local keyring — this removes both the master key and the subkeys:

gpg --delete-secret-keys E31C074FA2D89B561C4A730F852E1D493BC60A7F

GPG will ask you to confirm. Now your local keyring has no private keys at all. Re-import just the subkeys:

gpg --import adam.secsub.gpg

Verify the result:

gpg --list-secret-keys

sec#  ed25519 2026-03-31 [C] [expires: 2027-03-31]
      E31C074FA2D89B561C4A730F852E1D493BC60A7F
uid           [ultimate] Adam Brauns <adam@example.com>
ssb   ed25519 2026-03-31 [S] [expires: 2027-03-31]

The # after sec is the confirmation you are looking for. It means GPG knows about the master key's public component and fingerprint but does not have the private key on this machine. The two ssb entries are fully present and ready to use for signing and encrypting.

Delete the exported files from your local machine. They belong on the offline backup and nowhere else.

Day-to-day use

For most tasks, the subkey setup is invisible. Signing a git commit, encrypting a file, or decrypting a message all work exactly as they would with the master key present.

The one thing you cannot do without re-importing the master key is change the key itself: adding or revoking subkeys, updating expiry dates, or certifying someone else's key. For any of those operations, temporarily import from your backup:

gpg --import /path/to/backup/adam.secret.gpg

Make your changes, then remove the master key again and re-import just the subkeys. Keeping that cycle explicit is the whole point — the master key touches the machine only when it has to.

When your keys approach expiry, connect the backup, re-import, extend the expiry date on both the master and the subkeys, and put it back offline. Setting a reminder a few weeks before expiry is worth doing so you are not scrambling at the last minute.

What you get from this

The setup limits the consequence of a worst-case scenario. If your machine is stolen or your keyring is compromised, an attacker has your subkeys. That means they can sign things as you and decrypt things addressed to you — which is bad, but recoverable. You revoke the subkeys with the master, generate new ones, and your long-term GPG identity is intact.

Without subkeys, the master key being on your laptop means losing the device is equivalent to losing your identity. Every signature you have ever made, every trust relationship in the web of trust — those are all associated with that key. Rebuilding from scratch means losing all of it.

The subkey model is not exotic or complicated once it is set up. It is just keeping the thing that matters most somewhere that is not your everyday machine.

That was my immediate use case, but the pattern is much broader than tower fans. If a device already responds to an infrared remote, it is often a good candidate for this kind of retrofit. TVs, sound bars, air conditioners, fireplaces, LED controllers, and a lot of other "dumb" appliances can be pulled into Home Assistant without replacing them. With the right hardware, some RF-based devices can too.

I used BroadLink because Home Assistant has a straightforward Broadlink integration, but the general idea applies to any IR blaster Home Assistant can control reliably.

Why this approach made sense

The key insight is that many so-called "dumb" devices are not actually dumb at all. They already accept remote commands over IR, and sometimes RF. That means you do not necessarily need new hardware, new motors, or a cloud-connected replacement. You just need a bridge that can replay the same commands from Home Assistant.

An IR or RF blaster is a good middle ground for exactly that kind of problem:

• Keep the hardware you already own
• Avoid the cost of replacing multiple devices
• Add scheduling, scenes, and automations through Home Assistant
• Keep control local once the commands are learned in Home Assistant

For me, that was much more appealing than rebuying working devices just to get app control.

Where this works well

This approach is especially useful for devices that already have simple remotes and do not need rich two-way state reporting. A few common examples:

• TVs, projectors, and sound bars
• Portable AC units and mini-split remotes
• Tower fans and space heaters with IR remotes
• Electric fireplaces or LED light controllers
• Shades, switches, and other RF devices if you choose hardware that supports RF

The less a device depends on reporting its actual state back to you, the better this pattern tends to work.

RM4 mini vs RM4 Pro

BroadLink has a few variations in this family, but the decision most people care about is the difference between the RM4 mini and the RM4 Pro.

I used the RM4 mini because my tower fans were standard IR devices. If I were trying to control a mix of IR devices and RF-controlled shades or switches, I would start with the RM4 Pro instead.

One important caveat with the RM4 Pro: BroadLink positions it for RF devices, but it does not support rolling code remotes. In practice, that means it can be a good fit for some RF devices, but not everything with an RF remote is going to be compatible.

What I used

• A BroadLink RM4 mini for my setup
• The BroadLink RM4 Pro as the better option if you need RF support
• Home Assistant's Broadlink integration
• The original remotes for the devices I wanted to control
• The BroadLink mobile app for initial setup

The official Home Assistant docs note that the manufacturer app is required to get new BroadLink devices onto the network first, which matched my setup experience.

How the setup works

The BroadLink device learns the same commands your physical remote sends. Home Assistant then stores those commands by device and command name, and later replays them through the BroadLink remote using remote.send_command.

That gives you a nice upgrade path for older appliances:

• Learn each device's important commands once
• Wrap those commands in scripts, scenes, or automations
• Trigger them from dashboards, schedules, or voice assistants connected to Home Assistant

The important limitation is that IR is one-way, and many RF remotes are similar from Home Assistant's point of view. Home Assistant can send commands, but it usually does not know the true state of the device unless you model that state yourself with helpers or careful automations. For things like routines, scenes, and simple control surfaces, that tradeoff is often fine.

Setup steps

Here is the setup flow I would recommend for most BroadLink installs.

Initial device setup

1. Install the BroadLink mobile app and follow its setup flow to get the RM4 device connected to your Wi-Fi network.
2. Open the device settings in the BroadLink app and make sure Lock device is disabled so Home Assistant can communicate with it properly.
3. Give the BroadLink device a stable IP address, ideally through a DHCP reservation on your router, so Home Assistant can always find it reliably.
4. If the device is not auto-discovered, enter the device's IP address manually during setup.

Add it to Home Assistant and learn commands

1. Add the BroadLink integration in Home Assistant and complete the setup prompts.
2. Open Developer Tools -> Actions.
3. Select the remote.learn_command action.
4. Fill in the action details:
   • Target: Select the BroadLink remote entity
   • Device: Enter a stable name for the device you are teaching, such as tower_fan
   • Command: Enter the specific button name you want to learn, such as Power
5. Click Perform Action to put the BroadLink device into learning mode.
6. Point the original remote at the BroadLink device and press the matching button.
7. Repeat the process for every command you want Home Assistant to be able to replay later.

This is also the point where naming matters. I found it easiest to pick a stable device name once and then keep command names human-readable.

My tower fan example

Tower fans were the thing that pushed me to set this up in the first place, so here is the concrete example from my house. I grouped everything under the tower_fan device name and taught Home Assistant the following commands:

Once these are learned, Home Assistant can call them at any time with remote.send_command.

Example Home Assistant scripts

After learning the commands, I wrapped a few of them in scripts so they were easier to reuse from automations and dashboards. This example is fan-specific, but the same pattern works for any supported device.

script:
  tower_fan_power_toggle:
    alias: Tower Fan Power Toggle
    sequence:
      - action: remote.send_command
        target:
          entity_id: remote.office_ir
        data:
          device: tower_fan
          command: Power

  tower_fan_rotate:
    alias: Tower Fan Rotate
    sequence:
      - action: remote.send_command
        target:
          entity_id: remote.office_ir
        data:
          device: tower_fan
          command: Rotate

  tower_fan_quiet_mode:
    alias: Tower Fan Quiet Mode
    sequence:
      - action: remote.send_command
        target:
          entity_id: remote.office_ir
        data:
          device: tower_fan
          command: Silence

From there, you can drop those scripts onto a dashboard, expose them to voice assistants, or call them from automations.

A simple automation example

One nice use case is bundling commands into a routine. Here is a simple example that kicks my fans into a quieter mode at night:

automation:
  - alias: Tower Fan Quiet Down At Night
    triggers:
      - trigger: time
        at: "21:30:00"
    actions:
      - action: script.tower_fan_quiet_mode
      - delay: "00:00:01"
      - action: script.tower_fan_rotate

If your fan has a single power toggle instead of separate on and off commands, keep that in mind when building automations. Toggle-based IR devices are easy to control, but they are not perfectly state-aware unless you add your own tracking.

When this approach makes the most sense

The biggest win is that it makes existing hardware more useful without forcing a full replacement cycle. If you already own a device that works well and it has a remote, this is often one of the cheapest ways to pull it into a smart home.

This approach is especially good when:

• Centralized control from Home Assistant
• You want schedules, scenes, and routines
• The device is already remote-controlled and otherwise works fine
• You want to avoid paying a premium for Wi-Fi versions of things you already own

It makes less sense when the device depends heavily on accurate state tracking, uses unsupported RF behavior like rolling codes, or needs bi-directional feedback to be reliable.

Final thoughts

The useful takeaway here is not really about tower fans. It is that a lot of remote-controlled devices can be brought into Home Assistant without replacing hardware that already works.

If the device uses IR, the RM4 mini is usually the straightforward choice. If you need compatible RF support as well, the RM4 Pro is the better option.

If you are happy with the physical device and just want it to participate in automations, scenes, and dashboards, an IR or RF bridge is often the cheapest upgrade path available. In many cases, you do not need a new "smart" version of the device. You just need a way to teach Home Assistant the remote commands it already understands.