DSM 6.x und darunter 143 Zeichen beim Verschlüsseln

[Holtor]

Hallo,

beim Verschlüsseln besagt eine Meldung des DSM, dass die Länge der Filenamen (ohne Pfad) nur 143 Zeichen betragen darf. Das reicht aber bei mir nicht. Ich habe etliche Male erlebt, dass Ordner nicht verschlüsselt wurden, die Filenamen der Länge 142 enthielten (mit der Meldung, dass nur 143 erlaubt ist). Wenn ich die Namen auf 141 Zeichen gekürzt habe, ging es stets.

Im Zusammenspiel mit MacOS ist das sowieso ein Riesenproblem. Viele Ordner kann ich gar nicht mehr sinnvoll auf die DS kopieren. Ich verwende jetzt MacOS-Disk-Images aus der DS, die ich mounten muss. Erfahrungsgemäß führt das Problemen, wenn die Verbindung abbricht oder der Mac auch nur schlafen geht. Eine gute Lösung sehe ich noch nicht. Ich hatte ca. 2800 Files mit längerem Namen auf der DS gehabt.

Viele Grüße

Holtor

 

[Tommes]

Zu dem 143 Zeichen Missverständnis hier mal ein Link, den ich grade gefunden habe *klick* (leider nur in Englisch)

Tommes

 

[Holtor]

Ja, die 143 Zeichen sind wohl nur eine ungefähre Abschätzung, keine wirklich genaue Angabe. Die richtige Grenze kommt vielleicht erst durch eine Fehlermeldung von eCryptfs zustande. Für Mac-Benutzer liegt die Grenze noch niedriger, weil der DSM beliebt, zu jeder Datei noch eine Datei mit demselben Namen plus

@SynoResource oder
@SynoEAStream

anzulegen. So hat man also plötzlich noch (größtenteils komplett informationsfreie) Dateien mit einem um 13 Zeichen verlängerten Namen, und die Grenze liegt dann bei 128 Zeichen. Das ist schon sehr wenig. Ich habe z.B. von Balzac ein Buch auf der DS mit dem schönen Titel

"Aventures Administratives d’une Idée Heureuse recueillies et publiées par le Futur Auteur de l’Histoire de la Succession du Marquis de Carabas dans le Fief de Cocquatrix",

der hat alleine schon 169 Zeichen (wobei Umlaute oder Akzente vielleicht als mehr als 1 Zeichen gelten). Dutzende solcher Dateinamen habe ich nun von Hand gekürzt, aber einen brauchbaren Weg, die Verschlüsselung zu nutzen, sehe ich nicht. Vielleicht könnte man mit einem Programm jede Datei mit langem Namen in einen speziellen Ordner für diese Datei legen. Der Ordner könnte die erste Hälfte des Namens tragen, und die Datei behält nur die 2. Hälfte. So etwas ähnliches wird bei Deinem Link ja den Entwicklern als automatische Vorgehensweise für eCryptfs vorgeschlagen.

Wie bei Deinem Link ja auch schon angemerkt wird, die Verschwendung von 24 Zeichen durch "ECRYPTFS_FNEK_ENCRYPTED." macht das ganze noch ärgerlicher. Was für ein Hack.

 

[Tommes]

Da stellt sich mir erstmal die Frage, ob ein Buch solch brisanten Informationen enthält, das er verschlüsselt abgelegt werden sollte.

Aber okay... natürlich weiß ich worauf du hinaus willst und natürlich ich das unbefriedigend, wenn auch nicht zu ändern. Es bleibt dir da halt nur auf ein anderes Verschlüsselungssystem umzusteigen, oder dich mit dem zufrieden zu geben, was Synology bzw. ecryptfs dir bietet.

Tommes

 

[Holtor]

Naja, wie gesagt, das Programm, das eine Datei in ein Datei-im-Ordner-Paar aufteilt, wäre schon mal ein Lösungsansatz, das mit den Disk Images ein anderer (leider kein sehr guter). Man kann sich da schon Gedanken machen.

Da stellt sich mir erstmal die Frage, ob ein Buch solch brisanten Informationen enthält, das er verschlüsselt abgelegt werden sollte.

Die Dateien jetzt einzeln darauf durchzugehen, inwieweit sie mir irgendwie schaden können, wenn die DS geklaut wird und die Festplatten weiß Gott wohin verkauft werden, halte ich für deutlich zeitaufwändiger als das Problem mit der Namenslänge. Ich verschlüssele einfach alles.

 

[djewoijd]

ich habe mich auch schon beim Synology Support beschwert, der sagte das sei Absicht mit der Begrenzung (aber das ist wohl Quatsch). Er gibt den Wunsch der Begrenzungs-Aufhebung weiter.

Zum Glück habe ich bei meinem 1TB Windows-Dateien (400.000 Stücke) nur 10 Ausreisser, aber so eine Begrenzung ist totaler Blödsinn (so ähnlich wie die 3GB RAM Begrenzung bei Win32, aber Win32 ist zum Glück inzwischen tot).

Mach doch auch einen Feature-Request beim Support, je mehr desto besser ...

 

[Heinz-G]

Hallo,
so ein Problem hatte ich in der letzten Woche auch.
Ich wollte den "homes" - Ordner nachträglich verschlüsseln, bekam immer wieder die Fehlermeldung mit den 143 Zeichen und der Verschlüsselungsvorgang wurde abgebrochen.
Daraufhin habe ich die Daten aus "homes" in ein einen neuen Ordner verschoben, den "homes" -Ordner verschlüsselt und alle Daten aus dem neuen Ordner wieder nach "homes" verschoben.
Dabei ist keine Fehlermeldung aufgetreten.
Mir ist zwar nicht bekannt, welcher Dateiname zu lang gewesen sein soll und ich vermisse bisher auch keine Datei.

Hat jemand hierzu eine Erkärung?

Ich bin mal gespannt, ob in den nächsten Tagen eine Besonderheit auftaucht.

LG Heinz-G

 

[Tommes]

@djewoijd

Ich glaub, du hast da was nicht richtig verstanden. Synology nutzt als Verschlüsselungsystem ecryptfs und ecryptfs wiederum ist ein eigenständiges System welches unter verschiedensten Linux-Plattformen genutzt werden kann. Synology nutzt dieses System also nur für seine Zwecke ist jedoch nicht Urheber dieses Systems. Wenn du dich also Beschwerden willst, dann bei den Machern von ecryptfs und nicht beim Synology-Support. Von daher wird auch dein Aufruf für einen Feature-Request nicht wirklich was bringen.

Tommes

 

[djewoijd]

@Tommes
doch, das habe ich schon richtig verstanden, Synology nutzt der Einfachheit halber was "auf dem Markt verfügbar ist".
Ich bin aber immer der Meinung dass Software besser werden muss (besser im Sinne der Anwender die keine Beschränkung wollen).
Das bedeutet also 1. Synology muss eigene Verschlüsselung implementieren, 2. eCryptfs "Bescheid" sagen dass sie ihr System aufbohren sollen oder 3. nix passiert weil zu teuer
Mal abwarten ...
PS ich schätze mal das nix passiert weil das Problem zu klein ist, erst wenn gut bezahlende Business-Kunden richtig Probleme damit haben wird was passieren

 

[Tommes]

Ich bin aber immer der Meinung dass Software besser werden muss (besser im Sinne der Anwender die keine Beschränkung wollen).
Das bedeutet also 1. Synology muss eigene Verschlüsselung implementieren, 2. eCryptfs "Bescheid" sagen dass sie ihr System aufbohren

Das Software stets mit der Zeit gehen soll und somit immer besser werden sollte/müsste ist wohl ein erstrebenswertes Ziel jeden Programmierers. Ich denke nur, das du dir das ein wenig zu einfach machst. Warum sollte Synology das Rad neu erfinden wenn es doch bereits funktionierende Crypto-Tools gibt. Sicherlich könnte man sich über das verwendete Tool als solches durchaus streiten aber ich denke das du da ein wenig zu viel verlangst.

Projiziere ich das mal auf Ultimate Backup, dann müssten wir sogesehen rsync neu erfinden um evtuelle Missstände in rsync zu umgehen. Das halte ich für übers Ziel hinaus geschossen.

Nichts desto trotz bin ich sehr interessiert daran, was du von den Machern von ecryptfs als Antwort erhältst und würde mich freuen wenn du diese mt uns teilst.

Tommes

 

[djewoijd]

1. Versuch:
Your message

Subject: 143 character maximum

was not delivered to:

mhalcrow@us.ibm.com

because:

User mhalcrow (mhalcrow@us.ibm.com) not listed in Domino Directory

 

[Holtor]

Die Verschärfung des Problems durch die "@SynoResource"-Files ist doch wohl komplett alleine Synology zuzuschreiben und nicht ecryptfs. Da stossen zwei Hack-Lösungen zusammen. Auf ecryptfs zu setzen, bloß weil es kurzfristig die billigste Lösung ist, ist schon ein bisschen schäbig. Wie gesagt, die Verschwendung von 24 Zeichen durch "ECRYPTFS_FNEK_ENCRYPTED." zeigt doch schon, wie undurchdacht ecryptfs ist. "Funktionierend" ist da eher etwas geschmeichelt ausgedrückt. Von ecryptfs habe ich auch nur eine zeitlich sehr befristete Auditierung gefunden, die ziemlich vernichtende Aussagen enthält ("there are some red flags indicating that it was not designed by a cryptographer, and has not received enough security review").
https://defuse.ca/audits/ecryptfs.htm
Cypto-Tools gibt es viele, z.B. TrueCrypt, EncFS, GnuPG, dm-crypt (ich weiß schon, teilweise Device- und nicht File-basiert).

 

[Tommes]

Sehr interessanter Artikel, den du da verlinkt hast @Holtor

Wie sicher oder unsicher ecryptfs ist, kann ich mangels Backgroundwissen nicht wirklich beurteilen, ich bin auch nur ein "einfacher" Anwender dieses Systems und kein Crypto-Experte. Natürlich bin ich ganz bei euch ein besseres, komfortableres, ausgereifteres und sichereres System zu implementieren, welches auch auf Basis einer File-basierten Verschlüsselung beruht, sollte es dieses denn geben. Synology aber aufzufordern ein eigenes Verschlüsselungssystem zu entwickeln halte ich weiterhin für übers Ziel hinausgeschossen. Wer weiß welche Hintertüren Synology da einbauen würde... dann lieber auf OpenSource setzen.

Tommes

 

[djewoijd]

@Tommes: ich habe dem Synology Support den Wunsch der Begrenzungsaufhebung genannt, mehr nicht.
Hintertüren kann es überall geben, z.B. auch beim HyperBackup wo ich z.B. Backup mit Synology-Verschlüsselung in die Cloud mache. Wenn eine Firma Hintertüren einbaut kommt es irgendwann raus (einer redet immer).
Gruss Marcus
PS bei Windows verlasse ich mich auf BitLocker

 

[Heinz-G]

..... Synology nutzt als Verschlüsselungsystem ecryptfs und ecryptfs wiederum ist ein eigenständiges System welches unter verschiedensten Linux-Plattformen genutzt werden kann.....
Tommes

Ich denke, dies ist die Erklärung für mein Erlebnis.
"ecrptfs" hat meine 134 Zeichen erkannt.
Nachdem diese Dateinen entfernt wurden, lies sich "homes" verschlüsseln.
Anschließend konnten die langen Dateienen wieder in "homes" (Synology Filesystem) eingefügt werden.

 

[Holtor]

Anschließend konnten die langen Dateienen wieder in "homes" (Synology Filesystem) eingefügt werden.

Beim Einfügen werden die Dateinamen doch von ecryptfs wieder zu mit "ECRYPTFS_FNEK_ENCRYPTED." beginnenden Dateien verschlüsselt. Das ginge mit langen Dateinamen gerade nicht, man würde eine mehr oder weniger kryptische Fehlermeldung erhalten. Vielleicht waren es nur irgendwelche temporären Dateien in irgendeinem Cache, die beim Kopieren verschwanden.

 

[blinddark]

Wie habt ihr raus bekommen, welche Dateien einen längeren Namen als die vorgegebene Zeichenanzahl haben?

 

[Fusion]

z.B. mit einem Einzeiler auf der Konsole

i=0; for file in $(find /pfad -type f) ; do if [ $(echo $file | wc -c) -gt 190 ]; then echo $file; i=$(echo $i + 1 | bc); fi; done; echo "Anzahl $i"

 

[blinddark]

Danke Fusion. Bei deiner Abfrage werden mir doch die ganzen Pfade angerechnet oder? Bezieht sich die Verschlüsselung nicht nur auf die einzelne Datei?

 

[Fusion]

Eigentlich sollte er nur die Dateinamen-Länge nehmen, aber vielleicht hab ich mich vertan.