AES-256 vs OFB: Pick a Complete VPN Cipher Construction

AES-256 and OFB answer different questions, and treating them as competing options is where cipher reviews go wrong. One names a block cipher with a key size; the other describes how a block cipher is turned into a stream for a longer message. A runbook for choosing protection has to look at the whole construction, including how the receiver detects a modified packet.

Name the four parts of the construction

Every review reduces to four questions: which primitive and key size, how messages are processed with it, how the receiver rejects unauthorized modification, and how the protocol manages inputs, keys and their lifetime. A list of familiar names answers only the first. The second and third are where most of the real differences live, and the fourth is where implementations quietly diverge. Ask them in that order and write the answers down.

OFB appears among the confidentiality modes in the NIST block-cipher modes publication, and confidentiality is all it provides. A protocol that pairs an encryption mode with a separate MAC has to compose them correctly, and an algorithm name does not prove that composition. That is why the mode's name alone cannot settle a deployment decision.

The fourth question is the one an operator can actually verify on the running system.

Prefer an authenticated construction

Authenticated encryption supplies confidentiality and integrity together, and AEAD constructions also protect associated data from modification without encrypting it. That is a property of packet protection, and it is unrelated to whether a human signed in successfully.

The OpenVPN cryptographic-settings guidance from Netgate points at AEAD options, AES-GCM among them, for the data channel, and that is the kind of supported policy to follow. Use the choices the installed release and the peer clients support instead of copying a historical mode ranking into a new deployment. Legacy compatibility, crypto backends and offload support all constrain what is actually available.

A supported construction beats a clever composition every time.

Read the negotiated result, not the offer

A cipher appearing in an accepted list says nothing about the current session. Read the negotiated data-channel protection from the client or the gateway, then compare it with the policy you intended to enforce. A configuration that still lists a legacy option for one old peer is a compatibility decision, not a statement about the session in front of you.

openvpn --config client.conf --verb 4 2>&1 | grep -Ei 'cipher|data channel|auth'

On a gateway the equivalent output is the security association or the connection's crypto detail, depending on the platform. Either way, the offer and the result are different facts. A list that includes a legacy option for one old peer does not mean every session uses it, and a session that does use it is the thing you needed to know.

Record both facts together, with the date and the client version.

Measure only what you can compare

Throughput depends on the endpoint hardware, the implementation, acceleration, packet sizes and the selected configuration. Neither the key length nor the word OFB tells you which deployment will be faster. That is why a benchmark from another site is at best a hint about the hardware someone else owns. Your own numbers start with your own endpoints.

For an authorized comparison, hold the endpoints, workload and required policy constant, and record the negotiated protection plus the implementation versions. Then judge the result by whether the application finished, how much it lost and what the endpoints were doing, instead of inferring crypto cost from a single speed test. A number produced under different conditions is a story, not a measurement.

If an old peer cannot meet the policy, that is a compatibility decision for its owner.

Keep integrity out of the trade

Disabling integrity checks or accepting an unverified server is not a performance optimization, and it is not a compatibility fix. It changes the security property the construction was chosen to provide. The same applies to widening the accepted cipher list until an old peer connects: the connection succeeds and the policy no longer exists.

Write the accepted construction and its owner into the runbook, so the next change starts from a decision rather than a preference.

What you want is a policy both ends can enforce. Arguing that one name is the strongest is a different conversation, and it usually ends without a decision.