---
title: "WireGuard keys explained: private, public and preshared"
description: "What WireGuard's private, public and preshared keys are, how wg genkey makes them, why session keys change every two minutes, and what to do if a key leaks."
section: "Guides"
group: "How the technology works"
source: https://wrapvpn.com/en/guides/wireguard-keys-explained
last_reviewed: 2026-11-03
---

# WireGuard keys explained: private, public and preshared

Open a WireGuard config file and you'll find no username and no password, just a few lines of what looks like keyboard mash after words such as PrivateKey and PublicKey. Those lines are the whole of WireGuard's idea of who you are, so it's worth knowing what each one does.

TL;DR: Every WireGuard device has a private key it never shows anyone and a public key it hands to the machines it talks to. An optional preshared key, known to exactly two peers, adds a symmetric secret on top. None of them encrypts your traffic directly: they prove identity, and the keys that do the encrypting are made fresh at each handshake and replaced every couple of minutes.

## What a key actually looks like

A WireGuard key is 32 bytes of random data, or 256 bits. That isn't something you can type, so the tools write it in Base64, a way of spelling binary data with letters, digits and a couple of symbols. Every key comes out as 44 characters ending in an equals sign.

On this page we'll write keys as placeholders in angle brackets, naming whose key goes where. Partly that's because a real one would mean nothing to you, and partly because pasting real keys into web pages is exactly the habit we're about to talk you out of.

You'll meet three kinds in a config file: a private key, a public key and, optionally, a preshared key. All three are long-term keys that stay the same from one day to the next. A fourth kind, the session key, never appears in any file, and we'll come to it.

To keep this concrete, we'll follow one small setup from start to finish: your laptop, a small server you rent, and the keys that let the two talk, right up to the day the laptop goes missing.

## Making a key pair takes one line

On a machine with the WireGuard tools installed, a key pair takes one line, plus a bit of housekeeping. Run it once on the laptop and once on the server, so that each machine has a pair of its own.

The step that matters most is the one that makes the public key. It's calculated from the private key with Curve25519, the elliptic-curve cryptography WireGuard uses for its key pairs, and there's no practical way to run that calculation backwards with any computer that exists today. That's why one half can be shown to the world and the other can't. Here's the line, then each piece of it.

*Make a key pair*

```
umask 077
wg genkey | tee private.key | wg pubkey > public.key
```

- umask 077 tells the shell that new files should be readable by you alone, so the private key isn't left open to other users of the machine.
- wg genkey makes a brand-new random private key and prints it.
- tee private.key saves a copy in a file called private.key and passes the key along.
- wg pubkey reads that private key and works out the public key that belongs to it.
- The final > public.key writes the public key to a file of its own.

## Private stays home, public gets passed around

Now the swap. The laptop needs the server's public key, and the server needs the laptop's. How you copy them across is up to you, whether that's pasting over an SSH session or reading one off the screen. WireGuard deliberately has no opinion, much as SSH doesn't care how your public key reached a server.

A handy way to think about it: a public key is like your email address. People need it to reach you, and there's no harm in them having it. The private key is more like a password, with one big difference: nobody else ever needs it, not even the server you connect to.

Each machine's own private key goes in the [Interface] part of its config, and the other side's public key goes in a [Peer] part. The server's config is the mirror image, with one [Peer] block for each device it should accept. That list of public keys is its whole guest list, and a handshake from a key that isn't on it gets no reply at all. Our guide to WireGuard config files walks through every other line.

*The laptop's config, keys only*

```
[Interface]
PrivateKey = <the laptop's private key>

[Peer]
PublicKey = <the server's public key>
```

## The preshared key: optional, and shared by exactly two

The third kind is different. A preshared key isn't half of a pair: it's one random 32-byte secret that two peers both hold. You make it with wg genpsk, then add a PresharedKey line with that same value to the [Peer] section on both machines.

Shared by exactly two means one per pair. A server with fifty devices should hold fifty different preshared keys, not one password for everyone. It's a secret between two machines, and every extra copy makes it a little less secret.

During the handshake, WireGuard stirs the preshared key in with the results of the Curve25519 maths, so the session keys depend on both. Leave it out and WireGuard quietly uses 32 zero bytes in its place, so the handshake works the same way either way.

It's there as a hedge. If someone records your traffic today and one day breaks Curve25519 (the usual suspect is a large quantum computer), the preshared key is a second lock they'd still have to get past. Our guide to WireGuard and quantum computers follows that thread. The protection runs the other way too: if the preshared key leaks on its own, the key pairs are still guarding the tunnel.

*Make a preshared key*

```
wg genpsk > preshared.key
```

## Static keys stay put, session keys come and go

Bring the tunnel up and here's the surprise: none of the keys so far encrypts a single byte of your traffic. They're static keys, used only during the handshake, to prove who's who and to feed into the keys that do the real work.

Each handshake makes a throwaway key pair on each side, combines everything, and produces session keys, one for each direction. Those are what seal your packets, and they only ever live in memory. Our WireGuard explainer follows that handshake message by message.

Session keys are short-lived by design. While the tunnel is busy, WireGuard starts a fresh handshake once the current keys are two minutes old, and it refuses to use any that are more than three minutes old. If the tunnel falls silent, it wipes the old ones from memory after several minutes.

Static keys are the opposite: nothing rotates them for you. The laptop's private key today will still be its private key in five years unless someone replaces it. That's why the throwaway keys matter. Because each session's keys came from one-off pairs that were then deleted, someone who steals a static private key later still can't open traffic they recorded before. Cryptographers call this forward secrecy.

## Where the keys live

A private key is only as safe as the place it's kept, so WireGuard software leans on whatever the operating system offers for secrets.

On a Linux server, keys usually sit in files, either key files like the ones above or the config itself under /etc/wireguard, and the rule is that only the administrator should be able to read them. That's what umask 077 was for. WireGuard's own apps keep tunnel configs, private keys included, in the system's protected storage: the keychain on iPhone, iPad and Mac, and an encrypted store on Windows that ordinary users can't open.

Two habits follow. Don't email, message or paste a private key anywhere. And don't copy a working config onto a second machine: machines sharing a key look like a single peer to the server, which sends its replies to whichever of them spoke last.

## When a key is lost or exposed

Now the bad day. The laptop is left on a train with its private key on the disk, and whoever ends up with it may be able to connect to your server as you.

There's no password to change, because the key is the identity. The fix is to remove the laptop's public key from the server's peer list, which shuts the door at once, then make a new pair on the replacement laptop and add its public key instead. If the server reads its peers from a config file, delete that [Peer] block too, or the old key will be back the next time the tunnel comes up.

Forward secrecy is still on your side here: anyone who had been recording your traffic can't open it with the stolen key. And the same logic covers the other keys. If the server's private key leaks, the server needs a new pair and every device needs its new public key. If only a preshared key leaks, replace it on both sides.

*On the server*

```
wg set wg0 peer <the laptop's old public key> remove
```

## Your keys in WrapVPN

In WrapVPN you never see any of this. There's nothing to generate, copy or paste: you sign in with Apple or Google, pick a location and tap Connect, and the app and our servers put the keys in place for you. Our configurations include a preshared key too, and the session keys come and go every couple of minutes, exactly as described above.

If you'd like to put all those keys to work without ever typing one, install WrapVPN and start with the free plan.

## Questions

### Can you work out a WireGuard private key from the public key?

Not with any computer that exists today. The public key is calculated from the private key with Curve25519, and running that calculation backwards is the hard problem the whole design rests on. A large quantum computer could change that one day, which is what WireGuard's optional preshared key hedges against.

### Is it safe to share my WireGuard public key?

Yes, that's what it's for. A peer needs it to recognise your device during the handshake, but on its own it can't be used to connect as you or to read your traffic. Keep the private key to yourself, and treat a preshared key as a secret too.

### Do I need a WireGuard preshared key?

No, it's optional, and WireGuard is secure without one by today's standards. It adds a symmetric secret to every handshake, which keeps recorded traffic sealed if Curve25519 is ever broken, provided the preshared key itself was shared safely. The cost is one more secret to make, copy safely and replace, separately for every pair of peers.

### How often does WireGuard change its keys?

The session keys that encrypt your traffic are replaced automatically about every two minutes while the tunnel is in use. The static private, public and preshared keys never change on their own. They stay the same until someone replaces them.

### Where is the WireGuard private key stored?

In the device's own configuration. On a Linux server that's usually a file under /etc/wireguard that only the administrator can read, and WireGuard's apps keep it in the operating system's protected storage, such as the keychain on Apple devices. In WrapVPN you never handle it, because the app and our servers put the keys in place.

---

Source: https://wrapvpn.com/en/guides/wireguard-keys-explained
Last reviewed: 2026-11-03