---
{
  "title": "Legacy cryptography",
  "summary": "Understand historical algorithms without treating them as current defaults.",
  "topic": "foundations",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "units": [
    8
  ],
  "aliases": [],
  "sources": [
    {
      "title": "NIST: Cryptographic Standards and Guidelines",
      "url": "https://csrc.nist.gov/projects/cryptographic-standards-and-guidelines"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---

## The idea

Older algorithms and protocols can remain in course examples and inherited systems even when they are unsuitable for new security designs. DES has an inadequate key size for modern protection. MD5 and SHA-1 have important collision weaknesses and should not be chosen for new collision-sensitive security uses. Migration requires knowing where a legacy mechanism is used, what goal it serves, and which compatible replacement is supported.

## In practice

A team inventories certificates, software signing, and application dependencies before replacing a weak algorithm, then tests the replacement with consumers.

## A common misunderstanding

An old algorithm appearing in a lab is not a recommendation for production. Also, different weaknesses affect different uses, so explain the relevant security property.

## Check your understanding

What should a migration plan include?

**Think it through:** Affected uses, required compatibility, replacement choices, testing, owners, and a retirement date.

## Migrate a use, not just an algorithm name

A fictional manufacturer discovers an old signing mechanism in its software updater. Replacing the algorithm involves the publisher, update format, verification code, trusted keys, and devices already deployed. Some consumers may not understand the replacement until they receive an earlier compatibility update. The migration therefore needs a sequence, not merely a configuration edit.

Identify the security property at issue. Collision resistance, resistance to exhaustive key search, and protocol downgrade behavior are different concerns. Explaining the relevant weakness helps owners prioritize the affected use instead of declaring every appearance of an old name equally urgent. Historical test data may be harmless, while a live trust decision can be consequential.

Avoid leaving permanent fallback as an undocumented compatibility solution. If a verifier continues accepting the retired mechanism indefinitely, attackers may still reach the weak path. Define a retirement point and verify that unsupported consumers are identified before enforcement. Exceptions should have owners and an explicit review date.

## Build a transition inventory

For the updater example, list producers, consumers, key material, stored signatures, and external dependencies. Record which versions support the new format and how failed verification is reported. Use synthetic packages to test both the transition period and the final rejection of the retired mechanism.

Consider archived data separately. Removing an old decryption key before required records are migrated may make them unavailable, while retaining a weak signing trust indefinitely can preserve exposure. Document the operational and security consequences of each choice. A successful migration produces evidence that the replacement works and the unsafe live use has actually ended, rather than only showing that a new algorithm appears somewhere in the system.

## Keep exploring

- [[aes]]
- [[hashing]]
- [[cryptanalysis]]
- [[key-management]]