WireGuard Says the Private Key Length Is Wrong: Now What?

The message says the private key has the wrong length, and that wording points at encoding before it points at cryptography. WireGuard keys encode 32 bytes as base64, which yields 44 characters including a trailing pad, so a value of another size is not a key however random it looks. Padding the string until the parser accepts it produces a well-formed value that no peer will ever recognise.

Two different jobs hide behind this error: repairing the text of a valid key, and replacing an identity you no longer hold. They have different consequences, and one of them invalidates the other end.

What the Parser Expects

A WireGuard key is 32 bytes of key material in base64 with standard padding, which gives a fixed 44-character string. The tools reject anything that does not decode to exactly 32 bytes, because the underlying curve takes a 32-byte scalar and nothing else. Public and private values use the same encoding, so the parser cannot tell from the format alone which one you pasted. That ambiguity causes half the confusion around this error.

wg genkey | tee private.key | wg pubkey > public.key
base64 -d private.key | wc -c
wc -c private.key
wg show wg0 public-key

If your value decodes to 32 bytes, the length is fine and the complaint comes from somewhere else in the file. If it decodes to something shorter, you have truncated material rather than a formatting problem.

Formatting Damage or Wrong Material?

Formatting damage clusters around the edges: quotes added by a shell, a label such as private_key copied along with the value, a line break inserted by a chat client, or a trailing space that survived the paste. Each of those changes the string without changing the bytes, so removing it restores the original identity. Compare the file against the provisioning record character by character instead of stripping punctuation until the parser goes quiet.

Wrong material is a different situation. A password, a certificate key or a public value can all look plausible and decode to the wrong size. No amount of cleaning turns any of them into the scalar the peer expects. That case needs a new identity rather than an edit.

A Public Key in the Private Field

The commonest confusion is a public value pasted into the private field, or the reverse. Both are valid base64 of 32 bytes, so the length check passes and the handshake fails later without a useful message. A private key is the scalar that produces the public one, so you can settle it by deriving the public value and comparing that with what the peer authorises. When the derived value does not match the record, you are holding the wrong identity rather than a typo.

Replacing the client's private key without updating the authorised public key at the far end recreates the same mismatch, with the extra confusion that the client's own file now looks self-consistent. Change both ends in one operation, or the next person will debug the wrong half.

Repair the Profile, Then Prove the Handshake

Once the key decodes to the right size and matches the authorised pair, the remaining work is the profile and the path. The commands below generate a fresh pair when one is needed, verify the decoded size of an existing key, and read the public value the interface is actually using. Never paste a private value into a ticket or a decoder site.

wg genkey | tee new.key | wg pubkey > new.pub
base64 -d private.key | wc -c
ip route get 10.60.9.5
wg show wg0 latest-handshakes

The size check answers whether the material is key-shaped, and the route query answers whether a packet would ever reach the interface. A handshake line that stays empty after both checks pass moves the diagnosis to the peer's endpoint and allowed addresses. Read the interface's public key against the provisioning record one last time, because a stale saved profile can look correct while the active one differs.

Record which value you replaced and where the authorised copy lives. Whoever touches this peer next needs to know which end changed.