← All stories

Safety Academy · Story 21 · Unsafe encrypted backups

It decrypts. It still fails.

A backup tool hides the text but misses a changed file.

Estimated 4 min read

UNSAFE ENCRYPTED BACKUPS6 scenes

The demo can encrypt and restore a backup.

Vera tests a backup prototype with disposable data. It encrypts and decrypts successfully. Its impressive description does not answer whether it can detect tampering.

Vera
“It looks like nonsense. Excellent security.”
Illustration: The demo can encrypt and restore a backup.

Unreadable output and a successful restore are not enough to establish safe encryption.

The format never checks whether the file changed.

Review finds that the tool hides the data but does not reliably detect changes to it. This missing integrity check is an engineering mistake, not proof of a malicious author. A lock without a seal misses part of the job.

Capitano Ritas
“A locked envelope still needs a tamper check.”
Illustration: The format never checks whether the file changed.

Some encryption designs hide data without detecting changes to it.

A tampered test backup reaches the importer.

In a controlled test, an altered disposable backup is not reliably rejected. Vera stops release. The real backup remains untouched throughout the experiment.

Vera
“The test passed because we never tried a damaged file.”
Illustration: A tampered test backup reaches the importer.

Use disposable test data. Do not experiment with the only copy of a real recovery backup.

Capitano Ritas chooses a reviewed backup format.

Capitano Ritas chooses a maintained, reviewed design that both hides data and detects tampering. He checks its key and nonce requirements. A nonce is a value used by the algorithm; follow the library’s uniqueness rules.

Capitano Ritas
“It opens. Splendid. Does it notice when someone changes it?”
Illustration: Capitano Ritas chooses a reviewed backup format.

A maintained library must still be used correctly. Avoid inventing an encryption format.

The team validates failure cases too.

The team verifies wrong-key and tampered-data rejection, then tests restoration using disposable backups. The encryption key is managed separately from the backup it protects.

Vera
“Damaged input gets a refusal. Not a best guess.”
Illustration: The team validates failure cases too.

Keep encryption keys separate from encrypted data. Protect passwords and backup access too.

The label “encrypted” now comes with evidence.

The prototype now has a reviewed design and a tested recovery path. Vera never experiments on the only copy of valuable data. A successful round trip was the opening question, not the final review.

Vera
“The boring standard was the exciting discovery.”
Illustration: The label “encrypted” now comes with evidence.

Use reviewed cryptography, authenticated formats and tested recovery procedures.

The useful bit

“Encrypted” does not prove a backup resists tampering or protects its key.

  1. Use a reviewed encryption design that detects tampering. Follow its key and nonce rules exactly.
  2. Test that a wrong key and a changed file are both rejected, on disposable backups.
  3. Keep the key separate from the backup. Never experiment on the only copy of real data.

I already did this

If real backups used the flawed format, preserve the originals and stop trusting unchecked restores. Get specialist help to move verified data into a reviewed format and test recovery on copies. Replace exposed keys separately. Re-encryption cannot undo earlier disclosure.

Sources & further reading