DES vs 3DES in a VPN: Why Both Are the Wrong Upgrade

Both ciphers are obsolete, and neither is the right target for new traffic. The useful comparison is not DES against 3DES; it is a retired algorithm against a maintained one. If a gateway still offers either, the work is to find what requires it and remove that requirement, not to pick the stronger of two dead ends.

The comparison people still search for is the wrong one

Answers written in the 2000s compare DES with triple DES and conclude that triple DES is stronger. That was reasonable then and is useless now, because both are retired for protecting new traffic and the choice between them is a choice between two dead ends.

NIST withdrew the DES standard in 2005, and its TDEA recommendation was withdrawn in January 2024 after the deadline for applying TDEA to new cryptographic protection passed at the end of 2023. Those dates describe a transition, not a ranking. A short session or a low-value message does not reopen the question, because the algorithm's status does not depend on how long the key is used.

Key renewal is a separate control, and it does not restore approval.

Separate negotiation from the data path

VPN protocols negotiate protection in more than one place. A control channel may use one suite while the carried data uses another, and a proposal list says only what a peer is willing to accept. Read the negotiated result, not the offer. That distinction explains a common confusion: a gateway still lists a legacy algorithm and an operator assumes it is in use, when it may be offered and never selected, or selected only for one old peer.

On an IPsec gateway the relevant output is the security association; on OpenVPN it is the cipher and TLS settings in the connection log. Both tell you what was selected. Neither is proven by a legacy option still existing in a configuration file.

If you cannot see the negotiated result, you cannot claim the cipher was retired.

Find the component that still asks for it

Legacy requirements come from three places: an old client that offers nothing better, a gateway policy that still lists the algorithm, and an appliance that only speaks the old protocol. Each has a different fix. Ask the owner of the constraint which one it is before enabling a compatibility provider, because enabling it affects every peer that connects.

For a single appliance that cannot be replaced yet, put a maintained gateway in front of it and limit what that boundary carries. That contains the old cipher without making every remote user inherit it.

Containment is not a patch, and it does not make the legacy host trustworthy.

Migrate with the checks you already have

A migration is finished when the intended peers connect with the maintained profile, the negotiated suite is the one you expected, and the application works. Keep server identity verification and account checks in place throughout; a cipher change is not a reason to relax them.

openvpn --version
openssl ciphers -v 'DEFAULT:!DES:!3DES'

Record the client and gateway versions next to the negotiated result, so the next review can tell what actually changed.

Retire the old allowance through its owner, then confirm that a peer offering only the retired algorithm is now refused. A migration that leaves the old option enabled is a migration that has not happened. Keep the refusal evidence with the change record, because the next audit will ask how you know, and a removed configuration line is weaker evidence than a logged rejection. Add the test date and the peer identity to that record while the session is still fresh.

Historical data is a different problem

Reading an archive protected years ago may legitimately require the old algorithm. That is decryption of existing material, and it is not the same task as protecting new traffic.

Keep such work on an isolated host with a documented purpose and a short list of who may run it.

The distinction matters because it is the one honest reason to keep a retired cipher available. It justifies a scoped tool, never a permanent line in a public VPN profile.