Quelle est la taille maximale autorisée du fichier (et du dossier) avec eCryptfs?

44

Je suis un nouvel utilisateur d'eCryptfs et j'ai une question très fondamentale que je n'ai pu trouver nulle part. Je suis intéressé par l’utilisation de eCryptfs via mon Synology NAS qui utilise Linux.

En essayant de chiffrer mon dossier (EXT4) via l'application de chiffrement de Synology (eCryptfs), je rencontre des erreurs indiquant que la longueur de mon nom de fichier ne peut pas dépasser 45 caractères (donc, aucun chiffrement).

Si la limite est réellement de 45 caractères, eCryptfs peut ne pas être un outil utilisable pour la plupart.

Quelle est la taille de fichier maximale autorisée lors du cryptage de fichiers et de dossiers avec eCryptfs? Est-ce que Linux 255 est des caractères?

filenames ecryptfs synology

— Fabry
source

6

A mon sens, la manière dont ecryptfs crypte les noms de fichiers est ridicule. Tout d'abord, il donne plus de 20 octets en ajoutant une chaîne fixe "ECRYPTFS_FNEK_ENCRYPTED". à chaque nom de fichier. Ensuite, il ajoute trop d'octets aléatoires pour que les noms identiques aient une apparence différente. EncFS le fait de manière beaucoup plus efficace.

70

Divulgation complète: Je suis l’un des auteurs et le responsable actuel des utilitaires eCryptfs userspace.

Bonne question!

Linux a une longueur de fichier maximale de 255 caractères pour la plupart des systèmes de fichiers (y compris EXT4) et un chemin d'accès maximal de 4096 caractères.

eCryptfs est un système de fichiers en couches. Il se superpose à un autre système de fichiers tel que EXT4, utilisé pour écrire des données sur le disque. eCryptfs chiffre toujours le contenu du fichier, mais il peut éventuellement chiffrer (obscurcir) les noms de fichiers (ou non).

Si les noms de fichiers ne sont pas chiffrés, vous pouvez alors écrire en toute sécurité des noms de fichiers comportant jusqu'à 255 caractères et chiffrer leur contenu, car les noms de fichiers écrits dans le système de fichiers inférieur correspondront simplement. Bien qu'un attaquant ne puisse pas lire le contenu de index.htmlou budget.xls, ils sauraient quels noms de fichiers existent. Cela peut (ou non) laisser échapper des informations sensibles en fonction de votre cas d'utilisation.

Si les noms de fichiers sont cryptés, les choses se compliquent un peu. eCryptfs ajoute un peu de données à l'avant du nom de fichier chiffré, de manière à ce qu'il puisse identifier de manière définitive les noms de fichier chiffrés. En outre, le chiffrement lui-même implique de "remplir" le nom du fichier.

Par exemple, j'ai un fichier crypté, ~/.bashrc. Ce nom de fichier est crypté en utilisant ma clé pour:

/home/kirkland/.Private/ECRYPTFS_FNEK_ENCRYPTED.dWek2i3.WxXtwxzQdkM23hiYK757lNI7Ydf0xqZ1LpDovrdnruDb1-5l67.EU--

Clairement, ce nom de fichier de 7 caractères nécessite maintenant plus de 7 caractères pour être crypté. De manière empirique, nous avons constaté que les noms de fichiers de caractères de plus de 143 caractères commencent à nécessiter le cryptage de plus de 255 caractères. Nous recommandons donc (en tant que développeurs amont d’eCryptfs en amont) de limiter vos noms de fichiers à environ 140 caractères.

Cela étant dit, le Synology NAS est un produit commercial qui intègre et utilise eCryptfs et Linux pour chiffrer et sécuriser les données sur le périphérique. Nous (les développeurs en amont d’eCryptfs) n’avons rien à faire avec Synology ni avec leurs produits, même si nous sommes généralement heureux de voir que les fichiers eCryptfs sont utilisés à l’état sauvage . Il me semble que leur recommandation de 45 caractères est soit une erreur typographique (de notre recommandation de 140 caractères), soit simplement une estimation beaucoup plus conservatrice.

— Dustin Kirkland
source

J'adorerais vraiment voir un système de fichiers superposé FUSE qui résout par lui-même des "noms de fichiers trop longs" et reste juste le proxy 1: 1 avec un système de fichiers sous-jacent. De tels fichiers FUSE seraient utiles pour différents systèmes de fichiers (ecryptfs, EncFS), alors que pour les noms de fichiers actuellement pris en charge, rien ne changerait. Et encore, serait optionnel. - Mon souhait: unix.stackexchange.com/q/283149/9689

— Grzegorz Wierzowiecki,

17

Cette réponse n'est pas tout à fait correcte. La taille maximale d'un nom de fichier est de 255 octets ou de types de caractères C / C ++. Mais les caractères maximum dans un nom de fichier varient. Lorsque vous utilisez UTF-8, qui est la valeur par défaut pour la plupart des systèmes, le nom du fichier peut comporter entre 63 et 255 caractères (ou points de code), si vous utilisez UTF-16, 63-127. Il est important de noter que 1 caractère peut représenter un ou plusieurs octets dans l’espace de stockage et dépend du code défini par l’utilisateur du système.

— Rahly

Suggestion au développeur: Séparez les noms chiffrés de sous-répertoires qui sont cachés à l'utilisateur final pour obtenir la longueur nécessaire, voire supérieure à la longueur maximale autorisée pour le nom d'un système de fichiers externe. Un seul fichier ou répertoire devient "ENCRYPTFS-01-OF-04 [.....] / ENCRYPTFS-02-OF-04 [.....] / ENCRYPTFS-03-OF-04 [..... ] / ENCRYPTFS-04-OF-04 [.....] "- Les btrfs Linux, ext1-4 et autres n'ont pas de profondeur de répertoire définie maximale, de sorte que le système de fichiers peut gérer l'extension du nom des fichiers et des répertoires dans plusieurs sous-répertoires non exposés comme celui-ci. .

— Dale Mahalko

1

Ma suggestion aurait été de stocker les métadonnées que vous stockez dans les xattrs, plutôt que dans le nom du fichier. : |

— Trejkaz

1

Vous dites que eCryptfs "peut éventuellement chiffrer (ou non) les noms de fichiers (ou non)". Comment désactiver le cryptage des noms de fichiers afin de pouvoir récupérer mes noms de fichiers complets de 255 caractères au lieu d'être limité à 143 caractères? Je crois que la façon dont j'ai installé eCryptfs, en passant, consistait à cocher la case "Répertoire chiffré" lors de mon processus d'installation Ubuntu.

— Gabriel Staples

11

Ce fil est très intéressant car je me demandais exactement la même chose. Je peux vivre avec devoir renommer 20 fichiers sur 50 000 si les noms de fichiers doivent comporter 140 caractères ou moins, mais 45 ou moins n'est pas réalisable (dans mon cas) car cela me demanderait de renommer trop de fichiers.

J'ai posé la même question directement à Synology (même en leur indiquant le présent article), et leur réponse était intéressante: "Le nom de fichier du partage crypté est limité à 143 octets. Il peut contenir jusqu'à 140 caractères latins purs ou 45 CJK (chinois). , Japonais et coréen). "

Suite à cette réponse, je me suis plus testé moi-même, avec des fichiers de 45, 46, 140, 143 et 144 caractères. Mes tests montrent que les fichiers contenant jusqu'à 143 caractères (pas les octets, contrairement à ce que m'a dit Synology) seront cryptés, mais que les fichiers de 144 caractères EMPÊCHERONT un dossier d'être crypté. Cependant, le message d’erreur que j’obtiens de mon NAS indique que le nom de fichier doit comporter moins de 45 caractères (alors qu’en réalité, il devrait contenir moins de 144 caractères).

Je n'ai pas fait de tests avec des caractères CJK ... Mais à tous ceux qui lisent ceci, il semble que tout va bien pour vous, jusqu'à 143 caractères, malgré ce que le système vous dit.

— sdasdrewr
source

7

Je tiens à préciser que Linux a une limite de 255 octets par nom de fichier, et non de 255 caractères. Ceci est une différence significative et si vous utilisez par exemple le codage UTF-8, vous pouvez vous retrouver avec des noms de fichiers de 100 caractères maximum.

— Richard Jelinek
source

1

63 est le maximum si chaque caractère utilise le codage maximum de 4 octets par point de code. Il en va de même pour tous les schémas UTF (UTF-16 et UTF-32)

— Rahly,

@Rahly Cela pourrait éventuellement changer, cependant. Avant que le point de code Unicode maximal valide ne soit réduit de manière U+10FFFFà respecter les limites d'UCS-2 (essentiellement UTF-16 sans paires de substitution), UTF-8 pouvait nécessiter un maximum de 6 octets pour représenter un point de code à 32 bits en raison de la méthode de codage utilisée. "début du caractère" et "suite du caractère" pour garantir que la synchronisation de l'analyseur peut être ré-acquise peu importe où vous commencez l'analyse dans un flux d'octets. Il est toujours possible qu'ils décident éventuellement d'inverser cette décision car ils sont à court de points de code non attribués.

— ssokolow

1

Mais très improbable, à moins qu'ils ne commencent à ajouter des personnages comme Mad. A partir de U8.0, seuls 120k sont attribués. Ils ont ajouté ~ 8k caractères dans cette itération. Si cela continue, il faudra développer la version ~ 106.

— Rahly

Et je pense qu'ils devraient d'abord tuer Windows et JavaScript, puisqu'ils s'appuient tous les deux sur UTF-16. (Il serait peut- être possible de remédier à cela dans le cas de JavaScript, cependant?)

— SamB

1

La longueur du nom de fichier d'ecrypt n'était qu'un problème pour moi dans la mesure où j'avais besoin d'une sous-arborescence particulière de mon répertoire personnel pour prendre en charge les noms de fichiers longs.

dd if=/dev/zero of=/home/me/.some.img bs=1024 count=1024
mkfs.ext3 /home/me/.some.img
chmod 777 /home/me/longfilenames
sudo mount /home/me/.some.img /home/me/longfilenames

Cela présente probablement toutes sortes de problèmes d'efficacité, mais cela suffit dans mon cas, car les fichiers ne sont que des résultats de tests créés périodiquement pour mes propres besoins locaux.

Mes collègues ont mis leur image dans / tmp - les données de test ne sont pas particulièrement confidentielles: nous voulons principalement sécuriser notre code source, pas nos résultats de test.

— android.weasel
source