Kurzes Statement, aber bei der langen Diskussion hätte man es tatsächlich auch einfach testen können. @Rainer hat das alles eigentlich schon ziemlich richtig gesagt alles, aber ich fasse den Gedankengang bei der Entwicklung gerne noch mal zusammen:
- Durch die Dateinamensverschlüsselung „bläht“ sich der Dateiname etwas auf, aber nicht „unnötig“ und weil wir Bock drauf haben, sondern weil durch die Verschlüsselung und das Encoding nunmal etwas mehr „dazukommt“. Diese Entscheidung kann man im Nachgang natürlich hinterfragen, aber für das aktuelle Schema haben wir uns für AES-SIV + Base64url-Encoding + Dateiendung
.c9r(4 Zeichen) entschieden. Wenn ich das richtig im Kopf habe, wird der Dateiname um ca. 4/3 größer als der Klartextname. War damals sogar noch „schlimmer“, als wir Base32 benutzt haben, dort war das Verhältnis 8/5, soweit ich weiß. Wir wissen, dass Boxcryptor Base4K entwickelt hat, womit eine weitere Optimierung möglich wäre, aber wir wissen nicht, wie kompatibel das ist mit den verschiedensten Cloud-Speichern und es ist auch nicht so ratsam für uns, das Verschlüsselungsschema ständig zu ändern. Siehe: Use Base4k encoding to reduce encrypted file name length · Issue #2294 · cryptomator/cryptomator · GitHub - Wir könnten uns jetzt natürlich die Hände reiben und dann die Verantwortung auf den User oder das System schieben, wenn Dateinamen „zu lang“ werden (wer auch immer das definiert). Stattdessen haben wir uns für eine Name-Shortening-Methode entschieden, so dass Dateinamen, die „zu lang“ sind, über das beschriebene Verfahren „gekürzt“ werden (und der „lange Name“ wird dann in einer Datei ausgelagert). Warum haben wir uns an 255 orientiert? Weil das bei vielen Systemen nunmal eine Obergrenze zu sein scheint. Wir sind daher noch mal „sicher“ gegangen und haben die Schwelle auf 220 gesenkt, damit Cloud-Speicher im Zweifel noch ihre eigenen Zeichen dranpacken können im Konfliktfall.
- Jetzt haben wir leider das Problem mit den Pfaden. Tresore können natürlich irgendwo beliebig auf dem Dateisystem liegen und Tresore sind nicht vom Speicherort abhängig (können überall verschoben werden). Gegen Dateipfadelimits haben wir zwar keine Maßnahmen im Verschlüsselungsschema, aber im Cryptomator-Client gibt es einen „Capability-Check", der überprüft, wie lang die Namen im Tresor tatsächlich sein dürfen. Dafür gibt’s dann in
settings.jsonden WertmaxCleartextFilenameLength. Ist jetzt extrem technisch, aber wer sich dafür interessiert: From 1.5.x to 1.6.x - Migrating filenameLengthLimit
SO, und all diese Maßnahmen funktionieren auch zu 99%, so dass man sich als Anwender überhaupt nicht um die Länge von Dateinamen kümmern muss. Auf manchen Systemen kann es sein, dass man eine Fehlermeldung bekommt, wenn man Dateinamen hat, die „zu lang“ sind, aber dafür existiert dann auch eine klare Kommunikation.
Was ist mit den 1%? Ein bekanntes Beispiel ist HiDrive. Das Synchronisationstool verweigert den Dienst, wenn der Pfad zu lang ist. Aber leider erscheint der Fehler nicht in Schritt 3, sondern irgendwann im Nachhinein, so dass Cryptomator keine Chance hat zu erfahren, dass ein Limit überschritten wurde. Das ist tatsächlich noch ein ungelöstes Problem.
Was werden wir dagegen tun? Im ersten Schritt wollen wir ermöglichen, diesen Wert von 220 selbst einstellen zu können, siehe: Possibility to set maximum length of encrypted path and file name for a new vault (configurable shorteningThreshold) · Issue #1209 · cryptomator/cryptomator · GitHub
Und IRGENDWANN werden wir aus all der gewonnen Erfahrung das Verschlüsselungsschema an sich verbessern und kompatibler machen, aber das wird kein Schnellschuss, sondern ist eine langfristige Geschichte. Werden wir in Zukunft sicherlich kommunizieren, was da die Pläne sind.