TurboCrypt cambia a Base84 para cifrar nombres de fichero en Windows
El cifrado de nombres de fichero necesitaba un alfabeto que Windows aceptara sin romper Unix. La respuesta son 84 caracteres, cinco bits por vuelta y sin nombres reservados.
TurboCrypt, una herramienta de cifrado de ficheros, cambia su codificación de nombres cifrados de Base91 a Base84. El objetivo es que los nombres de fichero y directorio cifrados funcionen igual en Linux, macOS y Windows, algo que la codificación anterior no garantizaba. La implementación vive en zig-base84, un proyecto aparte que cualquiera puede reutilizar.
Por qué hacía falta un alfabeto nuevo
TurboCrypt cifra no solo el contenido, sino también los nombres. Hasta ahora codificaba el resultado en Base91, que encaja bien en Unix pero se rompe en Windows: su sistema de ficheros prohíbe nueve caracteres que el alfabeto imprimible de ASCII sí admite. Y no es solo el sistema de ficheros, también las librerías y aplicaciones que los leen; el Finder de macOS, por ejemplo, no traga con según qué nombres. El salto a Windows obligaba a recortar el alfabeto.
El cálculo es sencillo. De los 94 caracteres imprimibles de ASCII, excluyendo el espacio, Windows veta nueve: < > : " / \ | ? *. Quedan 85. Pero un nombre que termina en punto tampoco pasa de forma fiable por el shell ni por las APIs de fichero, así que el punto también sale de la ecuación. Resultado: 84 caracteres que pueden aparecer en cualquier posición de un componente de nombre. El alfabeto, en orden de codificación, es ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789!#$%&'()+,-;=@[]^_`{}~
El empaquetado, en grupos de cinco
La implementación empaqueta los bits de cinco en cinco caracteres. El cinco no es casual: 84⁵ son 4.182.119.424, apenas un 2,6% por debajo de 2³². Eso deja sitio para que un grupo cargue 32 bits la mayor parte de las veces. El codificador mira los siguientes 31 bits; si su valor queda por debajo de 84⁵ menos 2³¹, hay hueco para un bit más y consume 32. Si no, se queda en 31. Sobre entrada aleatoria son unos 31,95 bits por grupo, o 6,39 bits por carácter, con una expansión del 25,2% respecto al binario original.
El peor caso llega al 29%: una entrada rellena de 0xff fuerza a cada grupo a consumir solo 31 bits. Para comparar, Base64 expande un 33,3% tanto en media como en el peor caso.
Hay un detalle práctico. La mayoría de sistemas de ficheros limita un nombre a 255 bytes, y como el alfabeto es ASCII eso son 255 caracteres. Cinco divide 255 de forma exacta, así que un nombre de longitud máxima aloja grupos completos sin bits sueltos. Base84 garantiza hueco para 197 bytes de entrada, frente a los 191 de Base64 sin relleno.
Sin nombres reservados
El empaquetado de cinco caracteres trae un efecto secundario útil. Con el alfabeto estándar, el codificador no puede escribir un nombre de dispositivo reservado de Windows ni con entradas cortas. Una salida de tres caracteres termina siempre en A hasta J, lo que descarta CON, PRN, AUX y NUL. Una de cuatro caracteres acaba siempre en mayúscula o en a, b, c, nunca en dígito, así que COM1 a COM9 y LPT1 a LPT9 quedan fuera. Y como el alfabeto no tiene puntos, tampoco aparecen nombres reservados con extensión. No hace falta ningún tratamiento especial para evitarlos.
Para nombres que solo van a vivir en Unix queda la variante de zig-base91, que cambia la barra del alfabeto estándar por un apóstrofo. Empaqueta unos 6,51 bits por carácter y expande cerca del 23%, algo menos que Base84, a cambio de no ser portable a Windows.
