IKE / IPsec shared secret

IPsec Pre-Shared Key Generator

Create high-entropy pre-shared key material for an IKE or IPsec connection. Choose the random-byte size and text encoding required by both VPN endpoints.

Generate an IPsec PSK

The 256-bit hexadecimal default is broadly portable. Both endpoints must receive the exact same value and interpret its encoding identically.

Use at least as much unpredictability as the strongest negotiated key.
Confirm how each VPN device distinguishes encoded bytes from literal text.
0x identifies hex and 0s identifies Base64 in strongSwan configuration.

256 random bits32 random bytes64 encoded characters
Generated locallyThe PSK is created in this browser tab. Distribute it to the two authorized endpoints through a protected out-of-band channel.

What is an IPsec pre-shared key?

A pre-shared key is secret material installed on both IKE peers before they connect. Each side must use the same underlying value. It is not a finished VPN profile, a user password, a WireGuard public/private keypair, or a certificate.

Why generate random bytes instead of a phrase?

RFC 7296 warns that shared keys derived from passwords, names, or other low-entropy sources are vulnerable to dictionary and social-engineering attacks. It says the PSK should contain as much unpredictability as the strongest key being negotiated. This tool draws every byte from the browser's cryptographically secure random-number generator instead of asking you to invent a memorable phrase.

Choose 256, 264, or 512 bits

The 256-bit preset produces 32 random bytes. The 264-bit preset produces 33 bytes, matching strongSwan's documented command example for output with more than 256 bits of entropy. The 512-bit preset produces 64 bytes; RFC 7296 says an IKEv2 management interface must accept ASCII strings of at least 64 octets and a hexadecimal encoding. A particular appliance can still impose its own smaller limit, so verify both endpoints before deployment.

Hexadecimal and Base64 are encodings

Encoding changes how the random bytes are written, not their entropy. A 256-bit value becomes 64 hexadecimal characters or 44 padded Base64 characters. Some devices decode marked hex or Base64; others treat every displayed character as the literal shared secret. A connection fails when the two peers interpret the same-looking text differently.

Using the strongSwan value

strongSwan documents a 0x prefix for hex-encoded values and 0s for Base64-encoded values in swanctl.conf. The second output adds the correct prefix without changing the random material. Do not copy that prefixed representation into another vendor's product unless its documentation defines the same syntax.

Avoid group PSKs where possible

NIST discourages one group PSK shared by every remote-access VPN client because disclosure can let an attacker impersonate the server. NIST prefers public-key authentication and recommends EAP-TLS or machine certificates for remote access. Use a PSK only where the deployment requires it, restrict it to the intended peer relationship, and rotate it after suspected exposure.

Share and store the PSK securely

Both administrators need the exact secret, but ordinary email, chat, tickets, and source repositories create durable copies. Use an approved secrets manager or protected out-of-band exchange, limit who can read it, avoid shell history, and coordinate rotation so both endpoints change together.

Official references

Randomness and interface requirements follow RFC 7296 section 2.15. The 33-byte Base64 example and 0s/0x syntax follow strongSwan's security recommendations. Deployment cautions follow NIST SP 800-77 Revision 1.

Related tools

Random key generator creates generic encoded secrets. AES key generator creates exact AES encryption keys. Wi-Fi password generator creates router passphrases; a Wi-Fi PSK workflow is not the same as IKE/IPsec authentication.