¿Cuál es el tamaño máximo permitido de nombre de archivo (y carpeta) con eCryptfs?

44

Soy un nuevo usuario de eCryptfs y tengo una pregunta muy básica que no pude encontrar en ningún lado. Estoy interesado en usar eCryptfs a través de mi Synology NAS que usa Linux.

Al intentar cifrar mi carpeta (EXT4) a través de la aplicación de cifrado de Synology (eCryptfs) encuentro errores que indican que la longitud de mi nombre de archivo no puede exceder los 45 caracteres (por lo tanto, no hay cifrado).

Si el límite realmente es de 45 caracteres, eCryptfs puede no ser una herramienta utilizable para la mayoría.

¿Cuál es el tamaño máximo permitido para el nombre de archivo al cifrar archivos y carpetas con eCryptfs? ¿Linux tiene 255 caracteres?

filenames ecryptfs synology

— Fabry
fuente

66

En mi opinión, la forma en que ecryptfs encripta nombres de archivos es simplemente ridículo. Primero, regala más de 20 bytes anteponiendo una cadena fija "ECRYPTFS_FNEK_ENCRYPTED". a cada nombre de archivo. Entonces antepone demasiados bytes aleatorios para hacer que los nombres idénticos se vean diferentes. EncFS lo hace de una manera mucho más eficiente.

70

Divulgación completa: soy uno de los autores y el actual responsable de las utilidades de espacio de usuario de eCryptfs.

Gran pregunta!

Linux tiene una longitud máxima de nombre de archivo de 255 caracteres para la mayoría de los sistemas de archivos (incluido EXT4), y una ruta máxima de 4096 caracteres.

eCryptfs es un sistema de archivos en capas. Se apila sobre otro sistema de archivos como EXT4, que en realidad se usa para escribir datos en el disco. eCryptfs siempre encripta el contenido del archivo, pero opcionalmente puede encriptar (ocultar) los nombres de los archivos (o no).

Si los nombres de archivo no están encriptados, puede escribir de manera segura nombres de hasta 255 caracteres y encriptar sus contenidos, ya que los nombres de archivo escritos en el sistema de archivos inferior simplemente coincidirán. Si bien un atacante no podría leer el contenido de index.htmlo budget.xls, sabría qué nombres de archivo existen. Eso puede (o no) filtrar información confidencial dependiendo de su caso de uso.

Si los nombres de archivo están encriptados, las cosas se vuelven un poco más complicadas. eCryptfs antepone un poco de datos en el frente del nombre de archivo cifrado, de modo que pueda identificar los nombres de archivo cifrados definitivamente. Además, el cifrado en sí implica "rellenar" el nombre del archivo.

Por ejemplo, tengo un archivo cifrado, ~/.bashrc. Este nombre de archivo está encriptado usando mi clave para:

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

Claramente, ese nombre de archivo de 7 caracteres ahora requiere más de 7 caracteres para encriptarse. Empíricamente, hemos encontrado que los nombres de archivo de caracteres de más de 143 caracteres comienzan a requerir> 255 caracteres para encriptar. Por lo tanto, nosotros (como desarrolladores ascendentes de eCryptfs) generalmente recomendamos limitar sus nombres de archivo a ~ 140 caracteres.

Ahora, dicho todo esto, Synology NAS es un producto comercial que incorpora y utiliza eCryptfs y Linux para cifrar y proteger los datos en el dispositivo. Nosotros (los desarrolladores anteriores de eCryptfs) no tenemos nada que ver con Synology o sus productos, aunque en general estamos contentos de ver que eCryptfs se utiliza en la naturaleza . Me parece que su recomendación de 45 caracteres es un error tipográfico (de nuestra recomendación de 140 caracteres) o simplemente una estimación mucho más conservadora.

— Dustin Kirkland
fuente

Realmente me encantaría ver, FUSE superpone el sistema de archivos que resuelve por sí mismo "nombres de archivo demasiado largos" y descansa solo proxy 1: 1 con sistema de archivos subyacente. Tales FUSE fs serían útiles para diferentes sistemas de archivos (ecryptfs, EncFS), mientras que para los nombres de archivos compatibles actualmente no cambiarían nada. Y de nuevo, sería opcional. - Mi deseo: unix.stackexchange.com/q/283149/9689

— Grzegorz Wierzowiecki

17

Esta respuesta no es del todo correcta. El tamaño máximo de un nombre de archivo es 255 Bytes o tipos de caracteres C / C ++. Pero los caracteres máximos en un nombre de archivo varían. Cuando se usa UTF-8, que es el valor predeterminado para la mayoría de los sistemas, el nombre de archivo puede tener entre 63-255 caracteres (también conocidos como Puntos de código), si se usa UTF-16, 63-127. Es importante tener en cuenta que 1 carácter puede tener uno o más bytes en el espacio de almacenamiento y depende del conjunto de códigos que esté utilizando el usuario del sistema.

— Rahly

Sugerencia para el desarrollador: divida los nombres cifrados en subdirectorios que están ocultos para el usuario final para obtener la longitud necesaria, posiblemente incluso superando el límite máximo de longitud de nombre de Linux si un sistema de archivos externo lo necesita. Un solo archivo o directorio se convierte en "ENCRYPTFS-01-OF-04 [.....] / ENCRYPTFS-02-OF-04 [.....] / ENCRYPTFS-03-OF-04 [..... ] / ENCRYPTFS-04-OF-04 [.....] "- Linux btrfs, ext1-4 y otros no tienen una profundidad de directorio definida máxima, por lo que el sistema de archivos puede manejar nombres de archivos y directorios expandibles en múltiples subdirectorios no expuestos como este .

— Dale Mahalko

1

Mi sugerencia habría sido almacenar los metadatos que esté almacenando en los xattrs, en lugar de en el nombre del archivo. : |

— Trejkaz

1

Usted dice que eCryptfs "opcionalmente puede encriptar (ocultar) nombres de archivos (o no)". ¿Cómo deshabilito el cifrado de nombre de archivo para poder recuperar mis nombres completos de 255 caracteres en lugar de limitarme a 143 caracteres? Creo que la forma en que instalé eCryptfs, por cierto, fue marcando la casilla o lo que sea para "Directorio de inicio cifrado" durante mi proceso de instalación de Ubuntu.

— Gabriel Staples

11

Este hilo es muy interesante porque me preguntaba exactamente lo mismo. Puedo vivir con tener que renombrar 20 archivos de 50 000 si los nombres de archivo deben tener 140 caracteres o menos, pero 45 o menos no es factible (en mi situación) porque requeriría que cambie el nombre de demasiados archivos.

Le hice exactamente la misma pregunta directamente a Synology (incluso señalándoles el presente artículo), y su respuesta fue interesante: "El límite de nombre de archivo del recurso compartido cifrado es de 143 bytes. Puede tener hasta 140 caracteres latinos puros o 45 CJK (chino , Japoneses y coreanos) ".

Después de esta respuesta, hice más pruebas, probando con archivos de 45, 46, 140, 143 y 144 caracteres. Mis pruebas muestran que los archivos de hasta 143 caracteres (no bytes, al contrario de lo que Synology me dijo) se cifrarán, pero los archivos con 144 caracteres EVITARÁN que una carpeta se cifre. Sin embargo, el MENSAJE DE ERROR que recibo de mi NAS es que el nombre del archivo debe tener menos de 45 caracteres (mientras que la realidad es que debe tener menos de 144 caracteres).

No hice pruebas con caracteres CJK ... Pero, para cualquiera que lea esto, parece que está bien hasta 143 caracteres, a pesar de lo que le dice el sistema.

— sdasdrewr
fuente

7

Me gustaría aclarar que Linux tiene un límite de 255 bytes por nombre de archivo, no 255 caracteres. Esta es una diferencia significativa y si usa, por ejemplo, codificación UTF-8, puede terminar con nombres de archivo de 100 caracteres como máximo.

— Richard Jelinek
fuente

1

63 es el máximo si cada carácter usa la codificación máxima de 4 bytes por punto de código. Esto es lo mismo para cualquiera de los esquemas UTF (UTF-16 y UTF-32)

— Rahly,

@Rahly Eso puede eventualmente cambiar, sin embargo. Antes de que el punto de código Unicode válido máximo se redujera para U+10FFFFcumplir con las limitaciones de UCS-2 (básicamente UTF-16 sin pares sustitutos), UTF-8 podría requerir hasta 6 bytes para representar un punto de código de 32 bits debido a cómo codifica "inicio del carácter" y "continuación del carácter" para garantizar que la sincronización del analizador se pueda volver a adquirir sin importar dónde comience el análisis dentro de una secuencia de bytes. Siempre es una posibilidad que eventualmente decidan revertir esa decisión porque se están quedando sin puntos de código no asignados.

— ssokolow 01 de

1

Pero muy poco probable, a menos que comiencen a agregar personajes como locos. A partir de U8.0, solo se asignan 120k. Agregaron ~ 8k caracteres en esta iteración. Si continúan así, necesitará expandirse en la versión ~ 106.

— Rahly

Y creo que primero también tendrían que matar a Windows un JavaScript, ya que ambos confían en UTF-16. (¿ Podría ser posible rectificar esto en el caso de JavaScript, sin embargo?)

— SamB

1

La longitud del nombre de archivo de ecrypt fue solo un problema para mí, ya que necesitaba un subárbol particular de mi directorio de inicio para admitir nombres de archivo largos, y finalmente me di cuenta de que simplemente podía crear un sistema de archivos dentro de un archivo y montar eso:

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

Probablemente haya todo tipo de problemas de eficiencia con esto, pero es suficiente para mi caso en el que los archivos son solo resultados de pruebas creados periódicamente para mis propios fines locales.

Mis colegas han puesto su imagen en / tmp: los datos de prueba no son particularmente confidenciales: principalmente queremos asegurar nuestro código fuente, no nuestros resultados de prueba.

— android.weasel
fuente