What this does
Breaks down a strongSwan-style IKEv2/IPsec cipher proposal string — like aes256-sha256-modp2048 — into its encryption, integrity, PRF, and Diffie-Hellman components, explains each one in plain English, and flags legacy or weak choices: 3DES or a null cipher, MD5 or SHA1 digests, and MODP groups below the 2048-bit minimum most current guidance recommends. Entirely in your browser.
Why the same string means different things in an IKE vs. ESP proposal
A proposal string has the same shape whether it's negotiating the initial IKE_SA or a Child SA that actually carries traffic (ESP), but a missing Diffie-Hellman group means something different in each: an IKE_SA always performs a DH exchange, so a proposal without one is unusual. A Child SA can validly skip its own DH exchange (no PFS) and just reuse the IKE_SA's keying material — which is why this tool asks which kind of proposal you're checking before deciding whether a missing group is worth flagging.
FAQ
What's the difference between an IKE_SA and a Child SA (ESP) proposal?
The IKE_SA is the initial authenticated channel two peers set up to negotiate everything else — it always includes a Diffie-Hellman exchange. A Child SA (what actually carries traffic, using ESP) can optionally skip its own DH exchange and just reuse keying material derived from the IKE_SA, which is why a missing DH group is only flagged for IKE proposals, not ESP ones.
Why is an AEAD cipher with a separate integrity algorithm flagged as "redundant" instead of wrong?
AEAD ciphers like AES-GCM or ChaCha20-Poly1305 bundle encryption and integrity into one operation — the authentication tag is built in. Adding a separate integrity algorithm on top doesn't break anything, it's just unnecessary; some configuration examples include one out of habit from the pre-AEAD era, or for compatibility with a peer's proposal list.
Why is a PRF checked the same way as an integrity algorithm?
The PRF (pseudorandom function) is what actually derives session keys during the IKE exchange, and it's usually built from the same digest family as an integrity algorithm (SHA256, SHA1, etc.) — so the same weak-digest concerns apply. It's tracked separately from integrity, though, since a PRF is always required for key derivation, unlike a stand-alone integrity algorithm, which an AEAD cipher makes optional.
Does this tool validate the syntax fully, the way strongSwan itself would?
No — it recognizes the common encryption, integrity, PRF, and DH group names used in strongSwan-style ike=/esp= proposal strings and flags known-weak choices. It doesn't implement strongSwan's full proposal grammar or validate that a given combination is one strongSwan would actually accept; an unrecognized token is simply left uncategorized rather than treated as an error.
Where do the 2048-bit and other thresholds come from?
2048 bits is the widely cited current minimum for MODP (finite-field) Diffie-Hellman groups to resist realistic attacks — NIST and most current VPN hardening guides converge on it. Below 1024 bits (the original 768/1024-bit groups from early IPsec deployments) is flagged more severely, since those are considered breakable well within reach of a well-resourced attacker today.
Try it yourself
For the full picture of how these cipher suites fit into an IKEv2 handshake, see IPsec/IKEv2 Cipher Suites Explained. Checking an OpenVPN or WireGuard config instead? OpenVPN Config Auditor and WireGuard Config Validator cover those.