Bestand verandert zichzelf steeds

[aawe mwan]

Ik heb een bestand van 600MB waar ik de documenten in zet die ik nodig heb voor het invullen van de jaarlijkse belastingaangifte. Daar verandert dus maar een paar keer per jaar wat aan.

Nou viel me op dat dit bestand de afgelopen weken meerdere keren in de backup zat, terwijl ik niets veranderd had. Om te ontdekken welk proces mijn bestand wijzigt, ben ik de MD5 hash van het bestand gaan loggen.

En ik had bijna meteen „beet”, want wat bleek namelijk: het bestand flipperde uit zichzelf tussen 2 verschillende MD5 waarden! Eén van de twee was gelijk aan de MD5 hash van de laatste weekbackup.

Mijn vraag is nu: hoe kan dit en wat kan ik doen om voortaan eerder alarm te krijgen bij dit soort leesfouten?
Dit gebeurde op een computer die Ubuntu 18.04 LTS draait. De backup maak ik met rsync.

[Verwijderd]

Is het een Truecrypt / Veracrypt bestand toevallig?

[aawe mwan]

Ja dat klopt, een Veracrypt bestand.
Maar de Veracrypt software staat niet op die computer, alleen het bestand.

[Sendy]

Ik zou eens kijken wat er dan verschilt in de twee versies.

[aawe mwan]

Ik ben het VeraCrypt bestand aan het reconstrueren op basis van de backups van het versleutelde bestand. Ik vergelijk de bestanden in alle backups op basis van hun MD5 hashwaarde.

Tot nu toe ben ik 2 verschillen tegengekomen:

In de ene backup zijn een stuk of 10 directories compleet leeg. Dit lijken allemaal directories te zijn waar ik de afgelopen 6 maanden een bestand aan heb toegevoegd.

De andere backup heeft maar 1 beschadigd bestand, dat wil zeggen volgens de bestandsnaam is het een PDF en als je het opent is het een PDF die opent zonder foutmeldingen, maar de inhoud is compleet anders dan in de andere backup. Juist de versie in de andere backup komt overeen met de bestandsnaam.

[aawe mwan]

Door MD5 hashses te vergelijken met een backup van 2 maanden geleden, zag ik dat 2 PDF bestanden niet goed in de laatste backup zaten: de onderste helft van het logo op een bankafschrift was grijs geworden. Maar als ik dit duidelijk corrupte bestand nu open in Document Viewer versie 3.36.7, dan krijg ik geen foutmelding!

Dat storage kapot kan gaan, is iets wat kan gebeuren, na jaren zal gebeuren en daarom maak je backups.

Ik had alleen op z'n minst wel een soort A)bort R)etry I)gnore foutmelding verwacht als het gebeurt.
Maar in dit geval dus:

• Flash geheugen kan data gaan leveren die corrupt is, zonder dat je een foutmelding ziet;
• VeraCrypt geeft geen foutmelding als versleutelde data corrupt is maar „ontsleutelt” die gewoon;
• DocumentViewer geeft geen foutmelding als een plaatje in een PDF document corrupt is.

Dat kan toch niet? Heb ik dan ergens de een of andere beveiliging uitgeschakeld?

[Cpt.Morgan]

aawe mwan schreef op zaterdag 8 mei 2021 @ 10:48:
• Flash geheugen kan data gaan leveren die corrupt is, zonder dat je een foutmelding ziet;

Als er in de flash opslag een, of paar, bitjes zijn veranderd, dan is er zo goed als geen mechanisme om dat te detecteren inderdaad.

aawe mwan schreef op zaterdag 8 mei 2021 @ 10:48:
• VeraCrypt geeft geen foutmelding als versleutelde data corrupt is maar „ontsleutelt” die gewoon;

Encryptie heeft niets te maken met data integrity. Als een encrypted file corrupted is geraakt, kan die nog steeds gedecrypt worden door veel algoritmes, alleen komt er dan natuurlijk geen fatsoenlijke data meer uit.

aawe mwan schreef op zaterdag 8 mei 2021 @ 10:48:
• DocumentViewer geeft geen foutmelding als een plaatje in een PDF document corrupt is.

Sommige software is geoptimaliseerd om gewoon het beste van een beschadigde file te maken bij het openen, in plaats van een foutmelding te geven. Daar heeft de gebruiker over het algemeen ook meer aan.

[ Voor 49% gewijzigd door Cpt.Morgan op 08-05-2021 11:06 ]

[aawe mwan]

Cpt.Morgan schreef op zaterdag 8 mei 2021 @ 11:02:
[...]
Encryptie heeft niets te maken met data integrity. Als een encrypted file corrupted is geraakt, kan die nog steeds gedecrypt worden door veel algoritmes, alleen komt er dan natuurlijk geen fatsoenlijk data meer uit.

Dat klopt en zo staat het ook op de VeraCrypt website.

Ik had verwacht dat het zou werken zoals bijvoorbeeld ZIP het doet: die vergelijkt de lengte en de CRC van de gedecomprimeerde data met die van het originele bestand. Als ze niet identiek zijn, dan krijg je daar een melding van.

VeraCrypt zegt wel netjes dat ze deze check niet doen en dat je daarvoor zelf extra software moet gebruiken.

[Cpt.Morgan]

aawe mwan schreef op zaterdag 8 mei 2021 @ 11:12:
[...]
Ik had verwacht dat het zou werken zoals bijvoorbeeld ZIP het doet: die vergelijkt de lengte en de CRC van de gedecomprimeerde data met die van het originele bestand.

Het hele idee achter TrueCrypt/VeraCrypt is dat zulke checks niet mogelijk zijn, omdat dat allemaal extra informatie kan geven over de informatie die is opgeslagen in de encrypted volumes. Niet vervelend bedoeld, maar ik twijfel een beetje of je VeraCrypt gebruikt waar het voor bedoeld is... Ik denk eigenlijk dat misschien andere software beter geschikt is voor jouw use case.

[ Voor 28% gewijzigd door Cpt.Morgan op 08-05-2021 11:17 ]

[aawe mwan]

Cpt.Morgan schreef op zaterdag 8 mei 2021 @ 11:14:
[...]
Ik denk eigenlijk dat misschien andere software beter geschikt is voor jouw use case.

Kan je een voorbeeld geven? De versleuteling moet in elk geval veilig zijn, de data mag niet te ontsleutelen zijn op de computer waar de data op staat en de verbetering zou moeten zijn dat de integriteit van de (versleutelde of onversleutelde) data gecontroleerd wordt.

Het prettige van een versleuteld bestand is dat ik een backup kan maken door het bestand as-is te kopiëren: ik heb de sleutels daar niet voor nodig.

[ Voor 13% gewijzigd door aawe mwan op 08-05-2021 11:26 ]

[Cpt.Morgan]

Veel hangt van de exacte use case af denk ik.

aawe mwan schreef op zaterdag 8 mei 2021 @ 11:23:
[...]
De versleuteling moet in elk geval veilig zijn

Wat vind jij 'veilig'?

de data mag niet te ontsleutelen zijn op de computer waar de data op staat

Dit is een onmogelijke eis... De versleuteling zal afhankelijk zijn van het al-dan-niet kennen van het wachtwoord, of andere security measures, maar niet van op welke computer het geopend wordt.

En hoe benader je die files nu eigenlijk? Open je ze via een netwerkverbinding, kopieer je ze, of wat is je proces precies?

[aawe mwan]

Ik mount de directory waar de container in staat via een sshfs verbinding over IPv6.

Ik heb wat zitten experimenteren en het valt op dat de MD5 van een container veel vaker verandert dan je zou verwachten. Als ik de container read-only open, dan verandert hij niet. Maar als ik de container normaal mount en meteen weer dismount, zonder te kijken wat er in zit, dan verandert hij al 2 keer. Onder omstandigheden (als er weinig geheugen beschikbaar is?) kan hij zelfs elke keer als je een bestand in de container opent veranderen. Maar wat er verandert is in elk geval niet de atime van het bestand, dat heb ik gecontroleerd.

Deze onnodige schrijfacties zullen ongetwijfeld meegespeeld hebben bij het verslijten van de oude storage.

[ Voor 9% gewijzigd door aawe mwan op 08-05-2021 15:57 ]

[aawe mwan]

Ik ben nu de backups van afgelopen jaar aan het doorwerken en als je de bestanden in een container benadert via de commandline, dat krijg je wel een foutmelding als de directory corrupt is, namelijk:

Structure needs cleaning

[Verwijderd]

sla zoiets voortaan op een zfs volume, liefst op een systeem met ecc ff geheugen en een of meerdere parity drives. dan heb je geen last van bitrot

[hans_lenze]

Ik ben fan van Cryptomator voor het veilig opslaan van bestandjes. Omdat het elk bestand los opslaat in plaats van één container, heeft het wel wat meer info over de inhoud.