Static Key File Bit Count Is Not OpenVPN Cipher Strength

A scanner or a colleague points at the bit count printed inside an OpenVPN static key file and asks why the tunnel is not using a cipher of that size. The question sounds reasonable, and the answer is not a number: the banner counts stored key material, while a cipher consumes only the portion its key size requires. Treating that total as a strength setting leads to edits that change nothing. The format was built to hold more material than any single algorithm uses.

Two questions get mixed together here: how much key material the file stores, and how strong the negotiated cipher is. Only the second describes the tunnel.

What the Number in the Banner Actually Counts

The container serializes cipher material and HMAC material as separate structures, and the bidirectional form holds two such sets so each direction can carry its own keys. The writing code derives the printed count from the number of serialized structures, their size, and eight bits per byte. That is arithmetic over storage, not a statement that one cipher consumes every stored byte. The header also fixes a maximum cipher-material allocation so a library change cannot silently resize the format.

Compare that with a certificate key, where the bit count does describe one object's size. A 4,096-bit RSA key and a key file whose banner reads 4,096 bits are different artifacts with different jobs, and lining them up as two settings on one dial produces bad conclusions.

Two Key Sets in One File

Each half of the file supplies encryption and authentication material because the pre-shared-key mode protects packets in both directions with those separate pieces. The active cipher uses only the bytes its key size requires, and the digest uses its own output size, which is why usable strength comes from the options rather than from the file's length. Extending the hexadecimal blob does not ask the configured algorithm to consume more of it. Editing the comment with a larger number changes even less.

If a longer key is what you actually want, the setting to change is the cipher or the digest, and the generator produces whatever the selected algorithms need.

Reading the Profile Tells You Which Mode You Have

The same file format serves two quite different jobs, and only the profile says which one you have. A legacy secret line makes the file the tunnel's only key material, while tls-auth or tls-crypt makes it control-channel protection alongside certificates. Neither use turns it into a client's certificate private key, however similar the block looks. Identify the option and the version before generating a replacement, and use the documented generator rather than appending characters.

That distinction also decides the response to an exposure. A tls-auth key that leaks does not expose the session keys, but it does let an attacker inject control-channel traffic, so it still needs replacing. A leaked secret key is worse, because it was the material protecting the data itself.

What a Security Review Should Record

Record three things separately: the negotiated data-channel protection, the control-channel protection, and how peers authenticate. A line such as data-ciphers AES-256-GCM describes only the first, and a report that stops there cannot answer whether the control channel is protected at all. The static key file belongs in the second bucket when it is used with tls-auth or tls-crypt, and in neither when it is not used. Reviewers who conflate the buckets ask for a bigger key file when what they want is a stronger cipher.

If the file was exposed, rotate and redistribute it through the approved channel. Adding characters to a compromised secret is not rotation, and it leaves the exposed material valid.

Keep the rotation record with the profile it belongs to. The next review will ask which key protected which period, and the banner will not answer that.