Guía técnica

1 Introducción

nikpak es un archivador de línea de comandos para el formato .nik. Se diseñó en torno a cuatro ideas: comprimir mejor que las herramientas establecidas, hacerlo más rápido, proteger los datos con criptografía moderna y ejecutarse sin cambios en Windows, macOS y Linux como un único ejecutable pequeño.

1.1 Objetivos de diseño

• Pequeño. Supera a RAR 7 en los datos que la gente archiva realmente en grandes cantidades. El audio, las imágenes y la música de tracker se detectan por su contenido y se comprimen con códecs sin pérdida especializados; todo lo demás utiliza un flujo Zstandard multihilo afinado.
• Rápido. La compresión y la extracción deben estar limitadas por el disco, no por la CPU. En su nivel rápido -m2 nikpak archiva unos 200 MB de archivos de código fuente en menos de un segundo en un núcleo.
• Seguro. Cifrado autenticado con una función de derivación de clave que exige mucha memoria, nombres de archivo siempre ocultos, manipulación siempre detectada y un extractor al que no se puede engañar para que escriba fuera de su carpeta de destino.
• Resistente a la computación cuántica. Solo se utiliza criptografía simétrica de 256 bits. No hay código RSA, ni de curvas elípticas ni Diffie-Hellman en ninguna parte de nikpak, por lo que no hay nada que el algoritmo de Shor pueda romper.
• Portátil y apto para scripts. Un ejecutable enlazado estáticamente, línea de comandos compatible con RAR, códigos de salida predecibles y un -help que documenta todas las opciones.

1.2 Resultados de un vistazo

Medida	Resultado	Comparado con
Fotografías BMP	38.8 % más pequeño	RAR 7.00 -m5
Música estéreo, 44.1 kHz de 16 bits	14.6 % más pequeño (a la par con FLAC -8)	RAR 7.00 -m5
Archivos MOD de ProTracker	13.3 % más pequeño	RAR 7.00 -m5
Audio mono, de 8 y 16 bits	12.2 % y 15.3 % más pequeño	RAR 7.00 -m5
197 MB de archivos de código fuente, nivel máximo	5.5 % más pequeño (24.4 MB frente a 25.9 MB)	RAR 7.00 -m5 -s -md256m
Los mismos datos, nivel rápido -m2	0.9 s	RAR 7.00 -m3 sólido: 16.7 s
Cifrado	Argon2id + XChaCha20-Poly1305	RAR5: AES-256-CBC + PBKDF2
Los 10 conjuntos de prueba, nivel máximo, frente a 7-Zip	2.4 a 31.7 % más pequeño	7-Zip 23.01 -mx9 (sección 11.7)
Archivos de Office (doc, docx, xls, xlsx, csv, pdf)	31.7 % más pequeño	7-Zip 23.01 -mx9 (sección 11.7)
Los 10 conjuntos de prueba, nivel máximo, frente a ZIP	19.9 a 60.4 % más pequeño	ZIP -9, Info-ZIP 3.0 (sección 11.7)
Ejecutable	un solo archivo, sin dependencias; unos 9 MB con la ventana, 2.3 MB solo de línea de comandos	Windows, macOS, Linux

Cómo se obtuvieron las cifras Todas las mediciones proceden de una misma máquina (máquina virtual Linux x86-64, un núcleo de CPU) con RAR 7.00 y nikpak 1.1.0. Cada archivo se extrajo de nuevo y se comparó con el original byte a byte. El método completo, los corpus y los casos en los que RAR es más rápido se describen en el capítulo 11.

1.3 ¿Para quién es?

nikpak está dirigido a quienes archivan grandes cantidades de medios o código fuente y valoran el tamaño y la velocidad, a desarrolladores que quieren un archivador apto para scripts con códigos de salida sensatos y un formato documentado, y a cualquiera que necesite un cifrado fuerte sin confiar en una implementación cerrada. Como la línea de comandos sigue las convenciones de RAR, los front-ends como Total Commander pueden manejarlo con poca o ninguna reconfiguración.

1.4 Cómo leer esta guía

Los capítulos 2 y 3 describen qué hace nikpak y cómo usarlo. Los capítulos 4 a 7 explican la arquitectura, el formato de archivo, el motor de compresión y los códecs de medios. Los capítulos 8 a 10 tratan el cifrado, la resistencia cuántica y el endurecimiento. El capítulo 11 presenta los puntos de referencia, el capítulo 12 compara nikpak con RAR con honestidad y los capítulos 13 a 15 tratan de la compilación, las pruebas y la hoja de ruta.

1.5 Comunidad y contacto

Noticias, preguntas, ideas e informes de errores: se puede contactar con el autor de nikpak en

• Telegramhttps://t.me/cryptonikko
• Xhttps://x.com/cryptonikkoid
• Discordhttps://discord.com/users/1537826350759415811

Los mismos tres enlaces se muestran como botones redondos y de colores en la parte inferior de la ventana de nikpak, debajo de la carpeta de destino (sección 3.7), y al final de nikpak -help.

2 Resumen de características

2.1 Capacidades

Área	Qué ofrece nikpak
Compresión	Zstandard (multihilo, sólido) de -m1 a -m4, con una ventana de 128 MiB y coincidencia a larga distancia en -m4. En -m5 un cuerpo de motores múltiples: LZMA2 para datos binarios y PPMd para texto, elegidos por prueba; archivos ordenados por tipo como en 7-Zip.
Inteligencia de medios	Detección basada en el contenido de WAV, AIFF, ProTracker MOD y BMP; prueba por archivo entre cuatro filtros (NAC, Shuffle, Shuffle+Delta, MED); retroceso automático a la compresión normal.
Office, PDF, gzip	Recompresión Deflate (preflate): los flujos Deflate dentro de los archivos docx, xlsx, pptx, odt, ods, epub, jar, zip, pdf y gz se decodifican, se comprimen mucho mejor y se reconstruyen bit a bit en la extracción (-m4, -m5).
Cifrado	Derivación de clave Argon2id (64 MiB), XChaCha20-Poly1305 en fragmentos autenticados de 64 KiB; los nombres, tamaños, fechas y permisos están cifrados.
Contraseñas	Aviso interactivo con confirmación, variable de entorno, stdin, línea de comandos; generación automática de una contraseña aleatoria fuerte cuando no se suministra ninguna.
Integridad	CRC32 de los bytes originales de cada archivo; autenticación AEAD para archivos cifrados; marcador final con el número de entradas; códec de audio autoverificable.
Línea de comandos	Comandos al estilo RAR (a x e l v lb t p d), extracción de archivos, carpetas o comodines sueltos, e interruptores, alias al estilo zip, comodines, @listfiles, exclusiones, políticas de sobrescritura, modo silencioso, códigos de salida explícitos.
Seguridad	Protección contra zip-slip, rechazo de enlaces simbólicos, eliminación de setuid, decodificadores acotados, escrituras atómicas de archivos, seguridad de memoria de Rust.
Portabilidad	Windows (PowerShell, cmd), macOS, Linux; un único ejecutable estático; resultados idénticos byte a byte en todas las plataformas.
Interfaz gráfica	Iniciado sin argumentos, nikpak abre una ventana de soltar minimalista: suelte (o elija) archivos o carpetas para comprimirlos con la mejor compresión; anillo de progreso, carpeta de destino recordada (sección 3.7).
Explorador de archivos	unNik.exe, gratis para todos: explorar carpetas, buscar, ver archivos de texto y binarios, extraer una selección y eliminar archivos en archivos .nik (sección 3.9).
Temas	55 temas de ventana, incluidos 14 temas de escena pintados; una caja de temas que se sitúa junto a la ventana con Aplicar tema y Cancelar; importe sus propios archivos .skin.json de Nikkomander (sección 3.10).
Menú del gestor de archivos	Un submenú “NikPak” en Explorer, Dolphin, Nemo, Nautilus y Finder: Añadir al archivo, Extraer aquí, Extraer a su propia carpeta, Abrir con unNik; un archivo para una selección de varios elementos (sección 3.11).

2.2 nikpak y RAR lado a lado

La siguiente tabla compara nikpak 1.1 con RAR 7 tal como se midió en este proyecto, y señala con franqueza dónde aventaja RAR. El capítulo 12 analiza los puntos individuales.

	nikpak 1.1	RAR 7
Compresión de medios	Códecs sin pérdida especializados elegidos por archivo mediante prueba	Algoritmo general con filtros integrados
Código fuente, nivel máximo	24.4 MB (más pequeño), 45.6 s	25.9 MB, 26.7 - 36.2 s
Velocidad en niveles rápidos	0.9 s para 197 MB (-m2)	9.7 - 16.7 s (-m3)
Cifrado	Argon2id + XChaCha20-Poly1305 (autenticado)	AES-256-CBC + PBKDF2-HMAC-SHA256
Nombres de archivo siempre cifrados	Sí	Solo con -hp
Derivación de contraseñas exigente en memoria	Sí (64 MiB)	No
Generador de contraseñas aleatorias	Integrado	No integrado
Código fuente, lenguaje	Código fuente completo, Rust (seguro en memoria)	Propietario, C++
Registros de recuperación, volúmenes, SFX, actualización in situ	Todavía no	Sí (WinRAR)
Trayectoria	Nuevo, aún sin auditar	Décadas

3 Referencia de la línea de comandos

nikpak sigue la sintaxis que conocen los usuarios de RAR: nikpak [options] [files...]. Las opciones pueden aparecer en cualquier lugar antes o después del nombre del archivo; -- finaliza el análisis de opciones.

3.1 Comandos

Comando	Significado
a	Crea un archivo nuevo. Se añade .nik cuando el nombre no tiene extensión. Las carpetas siempre se recorren de forma recursiva.
x	Extrae con rutas completas: todo, o solo los nombres, carpetas y comodines indicados después del nombre del archivo (nikpak x backup.nik Docs/report.pdf extrae un archivo). Un separador de ruta final (o -d dir) selecciona el destino.
e	Extrae sin rutas: cada archivo va directamente a la carpeta de destino.
l	Enumera el contenido (todo, o solo los nombres que coinciden): atributos, tamaño, fecha (UTC), nombre, totales.
v	Listado detallado: añade el CRC32 de cada archivo.
lb	Listado escueto: un nombre por línea, pensado para scripts y front-ends de interfaz gráfica.
t	Comprueba: descomprime todo, verifica cada CRC32 y, para archivos cifrados, valida la autenticación.
p	Imprime archivos en la salida estándar: todos, o los indicados (nikpak p notes.nik todo.txt | more).
d	Elimina archivos o carpetas (una carpeta incluye su contenido) de un archivo. El archivo se vuelve a escribir sin ellos; los archivos cifrados conservan su contraseña. Los nombres son obligatorios.
mt	Prueba de medios: detecta archivos WAV/AIFF/MOD/BMP y muestra el tamaño que consigue cada filtro de medios. No escribe nada.
(none)	Iniciado sin ningún argumento (por ejemplo, haciendo doble clic en nikpak.exe), nikpak abre su ventana en su lugar (sección 3.7).

3.2 Opciones

Estilo RAR	estilo zip	Significado
-p	-e	Cifra / descifra, pide la contraseña. Una entrada vacía genera una contraseña aleatoria y la muestra.
-p	-P	Contraseña en la línea de comandos (visible para otros usuarios de la máquina).
-hp[password]		Igual que -p. En nikpak los nombres de archivo siempre están cifrados.
-m0 .. -m5	-0 .. -9	Almacenar, rapidísimo, rápido, bueno, alto (añade recompresión Deflate), máximo (el valor por defecto desde 1.2.1; LZMA2/PPMd, sección 6.7). Use -m2 cuando la velocidad importe más que el tamaño.
-mt		Número de hilos, de 1 a 256 (por defecto: todos los núcleos).
-mc- / -mc+		Todos los filtros de contenido (códecs de medios y recompresión Deflate) desactivados / filtros de medios siempre activados. Por defecto: prueba automática por archivo.
-r		Recorre las carpetas (siempre activado, aceptado por compatibilidad).
-ep	-j	Almacena solo el último componente de ruta de cada argumento.
-ep1		No almacena el nombre de la carpeta base de un argumento de carpeta.
-o+	-o	Sobrescribe los archivos existentes sin preguntar.
-o-	-n	Omite los archivos existentes sin preguntar.
-or		Renombra los archivos extraídos que ya existen: name (1).ext.
-y		Asume Sí en todas las preguntas.
-x	-x	Excluye archivos; se puede repetir.
-d	-d	Carpeta de destino para x y e.
-inul -idq	-q	Silencioso: solo se imprimen los errores.
@listfile		Lee nombres de archivo de un archivo de texto, uno por línea.
-h -help -?		Ayuda completa. -V imprime la versión.

Las opciones que los front-ends de RAR suelen enviar pero que aquí no tienen significado (-s, -ma5, -md64m, -ibck, -idp, -rr, -ts*, -w y similares) se aceptan y se ignoran, de modo que las configuraciones existentes de herramientas siguen funcionando. Cualquier otra cosa produce un mensaje de error claro y el código de salida 7.

El menú del gestor de archivos añade unas pocas opciones largas (sección 3.11): nikpak --add y --add-here comprimen los elementos indicados en un archivo nuevo, nikpak --install-menu y --uninstall-menu añaden o quitan el menú contextual (--all-users para una instalación para todos los usuarios), y unNik --extract, --extract-here y --extract-to gestionan la extracción desde el menú.

3.3 Las contraseñas en detalle

Cuando se crea un archivo con -p, nikpak resuelve la contraseña en este orden y nunca falla simplemente porque no se haya indicado ninguna:

• -p o -P en la línea de comandos: se usa tal cual (mínimo 8 caracteres).
• La variable de entorno NIKPAK_PASSWORD, que mantiene la contraseña fuera de la lista de procesos.
• Un aviso interactivo, solicitado dos veces para confirmación. Una entrada vacía genera una contraseña aleatoria.
• Sin terminal (por ejemplo dentro de una interfaz gráfica), una contraseña canalizada por stdin; si no hay ninguna, se genera una contraseña aleatoria.

Una contraseña generada tiene 24 caracteres de un alfabeto de 56 símbolos inequívocos (sin 0/O, 1/l/I), unos 139 bits de entropía. Se imprime una sola vez en un recuadro de la consola. No hay recuperación: un archivo cuya contraseña se ha perdido no puede abrirlo nadie.

Al abrir un archivo cifrado, nikpak usa las mismas fuentes y después falla con el código de salida 11 y un mensaje explicativo; nunca genera nada, porque una contraseña generada no podría coincidir.

3.4 Códigos de salida

Código	Significado	Causa típica
0	Éxito
1	Advertencia	Se omitieron algunos archivos (ilegibles, ruta insegura, enlace simbólico)
2	Error grave	No se puede crear o leer un archivo, error interno
3	Archivo dañado o error de CRC	Archivo dañado o truncado, suma de comprobación fallida
7	Error de línea de comandos	Opción desconocida, falta el nombre del archivo
10	Nada coincidió	Ningún archivo coincidió con los nombres o comodines
11	Contraseña incorrecta o ausente	Contraseña incorrecta, o un archivo cifrado manipulado

3.5 Ejemplos

nikpak a backup.nik C:\Docs\*.txt Photos\ # create an archive

nikpak a -m5 -mt8 big.nik Projects\ # maximum, 8 threads

nikpak a -p secret.nik Taxes2026\ # encrypted, prompts

nikpak a -pMyLongPassw0rd s.nik f.pdf # password given

nikpak x backup.nik C:\Restore\ # extract with paths

nikpak e backup.nik *.jpg C:\Pics\ # only *.jpg, flat

nikpak x backup.nik Docs/report.pdf # extract ONE file

nikpak e backup.nik Docs/report.pdf -d C:\Out # one file, no path

nikpak x backup.nik Photos -d C:\Restore # one folder

nikpak l backup.nik *.pdf # list only PDFs

nikpak p backup.nik notes.txt # show a file

nikpak d backup.nik Temp *.bak # delete entries

nikpak l backup.nik # list

nikpak t secret.nik # test (asks password)

nikpak mt song.wav tracker.mod photo.bmp # which filter wins?

3.6 Integración con Total Commander y otros front-ends

Como nikpak acepta la sintaxis de comandos de RAR (a, x, e, l, t, @listfile, -p, -ep1, -o+, -y, -m), un programa capaz de manejar un rar.exe externo puede manejar nikpak.exe. En Total Commander, registre la extensión nik en Configuración, Empaquetador, Programas empaquetadores adicionales y dirija los comandos de empaquetar y desempaquetar a nikpak.exe. Use -o+ o -y para la extracción desatendida, porque sin consola nikpak no puede preguntar si debe sobrescribir y, en su lugar, omitirá los archivos existentes. Los nombres de menú difieren entre versiones de Total Commander; consulte su ayuda integrada para conocer los campos exactos.

Carpetas con espacios en Windows Una ruta entre comillas que termina en barra invertida, como "C:\My Folder\", es malinterpretada por Windows (la comilla final se trata como escapada). Para destinos con espacios use -d "C:\My Folder" en su lugar.

3.7 La interfaz gráfica

nikpak iniciado sin argumentos, por ejemplo haciendo doble clic en nikpak.exe, abre una ventana pequeña en lugar de imprimir su uso. Hace una sola cosa: comprime lo que se suelte sobre ella.

• Suelte un archivo o una carpeta, o varios a la vez, sobre la ventana, o haga clic en el círculo (o en los enlaces elegir archivos / elegir una carpeta) para seleccionarlos en un diálogo; al hacer clic en el círculo se muestran los dos botones Elegir archivos y Elegir una carpeta dentro del anillo. Se comprimen con la mejor compresión (-m5) en un archivo con el nombre del archivo (sin su extensión), de la carpeta o, para varios elementos, de la carpeta de la que proceden. Un archivo existente nunca se sobrescribe: report.nik pasa a ser report (2).nik.
• El progreso se muestra como un gran porcentaje dentro de un medidor circular, con la fase (analizando, comprimiendo, finalizando), la cantidad procesada y el tiempo. El botón Cancelar situado debajo (o la tecla Esc) detiene de inmediato una compresión larga y elimina el archivo incompleto; la ventana permanece abierta para el siguiente. Cerrar la ventana durante una compresión hace lo mismo.
• Listo: el anillo se vuelve verde y muestra el nombre del archivo, su tamaño frente al original y el tiempo. Mostrar en la carpeta lo abre en Explorer, Finder o el gestor de archivos; Comprimir más (o un clic en el círculo) inicia el siguiente.
• Guardar en: la carpeta de destino de la parte inferior se puede escribir o elegir con Examinar. Se recuerda para la próxima vez (Windows: %APPDATA%\nikpak\settings.txt; macOS: ~/Library/Application Support/nikpak; Linux: ~/.config/nikpak). La primera vez es el Escritorio.
• Comunidad: los tres botones redondos de la parte inferior derecha abren las páginas de Telegram, X y Discord de nikpak (sección 1.5).
• Cambiar a unNik: el botón redondo con una flecha hacia arriba, a la izquierda del botón i, cierra NikPak e inicia unNik (sección 3.9). Tras una compresión, este y el enlace Abrir en unNik de la pantalla de finalización abren el nuevo archivo de inmediato. El botón está desactivado mientras se comprime.
• Abrir la carpeta de destino: el botón de carpeta entre el campo Guardar en y Examinar abre esa carpeta en Explorer o Finder; tras una compresión la abre con el nuevo archivo seleccionado.
• Sonidos: un clic suave para botones, enlaces y opciones, y un sonido breve para cada acción (inicio del trabajo, éxito, error, cancelación, cambio de programa, archivos pasando sobre la ventana). Los genera el propio programa, sin archivos de sonido. El botón de altavoz de la barra de título los apaga y los enciende; están activados por defecto y la elección se comparte con unNik.
• Idioma: el botón de la parte inferior izquierda, con una bandera y el nombre del idioma en su propia lengua, abre un menú con los diez idiomas más hablados del mundo (Ethnologue 2025): English, 中文 (chino mandarín), हिन्दी (hindi), Español, العربية (árabe), Français, বাংলা (bengalí), Português, Русский (ruso) y Bahasa Indonesia. Al elegir uno se guarda y reinicia nikpak en ese idioma. La primera vez, nikpak sigue el idioma de Windows (o del sistema); en caso contrario, el inglés. La línea de comandos permanece en inglés.
• Ejecutar como administrador: Windows no permite arrastrar archivos desde Explorer a un programa que se ejecuta como administrador. Cuando nikpak.exe se inicia como administrador (por ejemplo, desde un PowerShell de administrador), se reinicia una vez como usuario normal a través de Explorer para que arrastrar y soltar funcione. Si eso no es posible, la ventana muestra un aviso; elija los archivos con los botones en su lugar.
• Estado y Acerca de: la parte superior izquierda muestra COPIA DE EVALUACIÓN · REGISTRAR (un clic abre la caja de registro) o REGISTRADO A y el titular de la licencia. El pequeño botón i de la parte superior derecha, junto a minimizar y cerrar, abre la caja Acerca de: versión, © 2026 Nicolas Choukroun, distribuido por Nikkoid LLC, el estado de la licencia, el sitio web y los términos de la licencia (LICENSE.txt).

La ventana mide 500 × 560 puntos (aproximadamente 9:10), de modo que una captura de toda la ventana cabe en una publicación de imagen de X (Twitter) sin recortar. No tiene marco: arrástrela por su zona superior; los botones de la parte superior derecha abren la caja Acerca de, la minimizan y la cierran. Cuando nikpak.exe se inicia desde Explorer, la ventana de consola que Windows abre para él se cierra automáticamente; si se inicia desde un símbolo del sistema, el símbolo se deja intacto. Sin pantalla gráfica (por ejemplo a través de SSH), nikpak imprime su uso como antes. La interfaz usa egui/eframe e incorpora subconjuntos de las tipografías Inter, Noto Sans SC, Noto Sans Devanagari, Noto Sans Bengali y Noto Sans Arabic (SIL Open Font License, véase assets/fonts/OFL.txt). Un ejecutable solo de línea de comandos se compila con cargo build --release --no-default-features.

El hindi, el bengalí y el árabe necesitan conformado: las letras cambian de forma y se unen, los signos vocálicos se desplazan alrededor de su consonante y el árabe se escribe de derecha a izquierda. egui dibuja un glifo por carácter, lo que imprimiría estos idiomas de forma incorrecta, así que nikpak ordena esos textos con el algoritmo bidireccional de Unicode (unicode-bidi), les da forma con rustybuzz (una adaptación a Rust de HarfBuzz), los rasteriza con ab_glyph y pinta el resultado como una imagen (textshape.rs). Las palabras y números latinos que contienen conservan la tipografía Inter. Las traducciones largas se reducen para caber en sus botones, y las cajas crecen con su texto. Las traducciones (i18n.rs) se escribieron con ayuda de máquinas; se agradece una revisión por hablantes nativos.

3.8 Licencia y registro (shareware)

NikPak es shareware, © 2026 Nicolas Choukroun, distribuido por Nikkoid LLC, y se licencia como WinRAR: el mismo paquete es la copia de evaluación gratuita y, una vez introducida una clave de licencia, la versión registrada. En la copia de evaluación no se desactiva nada.

Quién	Condiciones
Particulares	Gratis para uso personal no comercial, sin límite de tiempo. Una licencia personal ($19) elimina el recordatorio; cubre todos los ordenadores que use el titular.
Empresas y organizaciones	Una licencia de empresa por puesto, tras una evaluación gratuita de 40 días; los puestos son ordenadores o usuarios, lo que sea mayor. Precios por volumen y por puesto, siguiendo el modelo de WinRAR: 1–9 puestos $19, 10–24 $15, 25–49 $12, 50–99 $9, 100–199 $7, 200–499 $6, 500 y más $5.
Distribución	El paquete sin modificar (con LICENSE.txt y THIRD-PARTY-NOTICES.txt) puede publicarse en cualquier sitio de shareware o descargas; está prohibido añadir claves, archivos de claves o cracks. Los archivos .nik están libres de regalías.

• El recordatorio aparece cuando una copia sin registrar abre su ventana. Tiene dos botones, Registrarse y Probar gratis, cuyo orden izquierda/derecha cambia aleatoriamente en cada inicio. Probar gratis (o Esc) lo cierra; nikpak funciona entonces sin restricción.
• La caja de registro pide el nombre, la dirección de correo electrónico y la clave de licencia. Las tres deben coincidir: la clave es una firma del nombre y el correo electrónico. Las mayúsculas, los espacios adicionales y los caracteres parecidos O/0 e I/L/1 no importan. Comprar una licencia abre https://nikpak.nikkoid.com/buy.php.
• Una vez registrado, nikpak no vuelve a preguntar en ese ordenador para ese usuario. La licencia se guarda en %APPDATA%\nikpak\license.txt (macOS: ~/Library/Application Support/nikpak; Linux: ~/.config/nikpak). Una empresa puede, en su lugar, colocar un archivo nikpak.key junto a nikpak.exe, lo que registra a todos los usuarios de ese PC.
• Línea de comandos: nikpak register "Jane Doe" jane@example.com NPK1-… registra; nikpak license muestra el estado; nikpak unregister elimina la licencia. nikpak -V y nikpak -help también muestran el estado. Las copias sin registrar imprimen un aviso de evaluación de una línea en la salida de errores (stderr), nunca en la salida estándar; -q lo suprime.

Cómo funcionan las claves

Una clave de licencia se lee como NPK1- seguida de 108 caracteres en grupos de cinco (Crockford base32). Contiene el tipo de licencia (personal o empresa), el número de puestos y una firma Ed25519 de NIKPAK-LICENSE-1, el tipo, los puestos, el nombre y la dirección de correo electrónico, cada uno normalizado (espacios contraídos, minúsculas). nikpak contiene solo la clave pública de 32 bytes, en src/license_pubkey.rs, de modo que estudiar el programa no permite a nadie crear claves.

Las claves se crean con la clave privada, que nunca sale de Nikkoid LLC: bien con la herramienta privada nikpak-keygen (cargo run --release --features keygen --bin nikpak-keygen -- make --name "Jane Doe" --email jane@example.com; --company --seats 25 para empresas; newkeys crea un nuevo par de claves), o bien en el servidor web con el kit PHP de server/ (PHP 7.2+, MySQL 5.7), que emite una clave por pago y produce exactamente las mismas claves. server/README.md describe la configuración y el flujo de pago.

3.9 unNik, el explorador de archivos gratuito

unNik (unNik.exe) es el segundo programa del paquete. Abre archivos .nik, muestra lo que hay dentro y extrae lo que usted elija. Es gratis para todos, incluidas las empresas, sin registro y sin recordatorio (LICENSE.txt, sección 2a). El instalador lo coloca junto a nikpak.exe, lo añade al menú Inicio y lo convierte en el programa para los archivos .nik, de modo que un doble clic en un archivo lo abre en unNik; unNik archive.nik hace lo mismo desde un símbolo del sistema.

La ventana vacía tiene exactamente el mismo aspecto que la de NikPak, con una flecha hacia arriba en el anillo. Suelte un archivo .nik sobre ella, haga clic en el anillo o elija uno de los archivos recientes: la ventana crece hasta convertirse en el explorador (1120 × 720, redimensionable desde sus bordes, y se puede maximizar). Los archivos cifrados piden primero su contraseña.

• Navegue con el árbol de carpetas, las migas de pan, Atrás, Adelante y Arriba (Alt+Flecha izquierda, Alt+Flecha derecha, Retroceso) y los dobles clics. Buscar (Ctrl+F) encuentra archivos por nombre en todo el archivo; cada resultado muestra su carpeta.
• Seleccione con un clic, Ctrl+clic, Mayús+clic, las casillas de verificación, Ctrl+A o las teclas de flecha. Haga clic en el título de una columna para ordenar por nombre, tamaño, tipo o fecha. Un clic derecho abre un menú con todas las acciones.
• Extraer todo, o la selección (Ctrl+E): elija el destino (por defecto, una carpeta con el nombre del archivo, junto a él), mantener las carpetas o no, y qué hacer cuando un archivo ya existe: reemplazarlo, conservar ambos (name (1).ext) u omitirlo. Los archivos tomados del interior de una carpeta se crean sin la ruta de esa carpeta, como en WinRAR. La lectura se detiene justo después del último archivo elegido.
• Ver (F3, o un doble clic en un archivo de texto): texto con números de línea, búsqueda con resaltado, ajuste de línea y copia; archivos binarios en hexadecimal. Se muestran los primeros 16 MB; Abrir en Bloc de notas abre el archivo completo. Abrir inicia un archivo con su propio programa (antes se extrae a una carpeta temporal).
• Eliminar (Supr) quita archivos y carpetas del archivo tras una confirmación. El archivo es sólido, por lo que se vuelve a escribir sin ellos, en un archivo temporal que solo sustituye al original cuando todo ha tenido éxito. Los archivos cifrados conservan su contraseña; las demás entradas conservan su filtro de medios o Deflate y su motor -m5.
• Comprobar descomprime todo el archivo y verifica cada archivo. El panel de detalles muestra el tamaño, la fecha, la carpeta, el CRC32, cómo está almacenado el archivo y sus atributos; para el propio archivo, su tamaño, método y cifrado. El resumen bajo el árbol muestra el espacio ahorrado.
• Los mismos diez idiomas, botón de idioma, caja Acerca de (i) y botones de comunidad que NikPak. Los nombres de archivo en cualquier escritura se dibujan con las tipografías del sistema como recurso de reserva.
• Cambiar a NikPak: el botón redondo con una flecha hacia abajo, a la izquierda del botón i, cierra unNik e inicia NikPak. Ambos programas se encuentran en la misma carpeta. Comparten un único archivo de configuración, de modo que el idioma elegido en uno lo usa el otro, y una ventana ya abierta sigue el cambio en dos segundos.
• Abrir la carpeta de destino: el botón a la izquierda del botón de expulsión abre la carpeta de la última extracción en Explorer o Finder (antes de cualquier extracción, la carpeta del archivo). unNik reproduce los mismos sonidos que NikPak, con sonidos para abrir un archivo, extraer, eliminar y comprobar; su botón de altavoz y el de NikPak comparten una única configuración.

3.10 Temas

NikPak y unNik comparten los mismos 55 temas de ventana: los 41 temas de Nikkomander — de Nikkoid Blue (el predeterminado) y Nikkoid Bright a Dracula, Nord, Solarized, Classic Blue, Matrix, Pizza, Christmas y 8-Bit Game — más 14 temas pintados cuyos fondos los dibuja el propio programa: Moon, America, Pattaya Neons, Burgers Tokyo, Sushi, Amiga, MSX, Colecovision, ZX Spectrum, Cat Life, Dog Life, Mario Bros, Counter Strike y Chess.

• Botón de temas (una paleta, en la barra de título de ambos programas): abre el menú de temas, donde cada tema se dibuja con sus propios colores. Señalar un tema lo muestra en toda la ventana; un clic lo conserva; Esc o un clic fuera vuelve al tema que tenía.
• Botón de sol / luna, a su lado, cambia entre Nikkoid Blue (oscuro) y Nikkoid Bright con un clic.
• La caja de temas queda fuera del programa. Mientras la caja está abierta, la ventana se ensancha por la derecha el ancho de la caja: el programa conserva su panel de 500 × 560 y la caja se sitúa en el espacio transparente adicional a su lado, de modo que toda la interfaz sigue visible detrás del tema que se está probando. La caja se puede arrastrar por su barra de título de nuevo sobre el programa o a cualquier otro lugar de la ventana, y tiene botones Aplicar tema y Cancelar. Un clic en un tema lo prueba en toda la ventana; Aplicar lo conserva y lo guarda para ambos programas; Cancelar (o Esc o la ×) vuelve al tema que tenía. Un clic en el programa ya no cierra la caja. La ventana de unNik no se ensancha.
• El tema elegido se guarda (skin= en el archivo de configuración) y se comparte: un tema elegido en un programa lo adopta el otro en dos segundos.
• Sus propios temas: “Importar un tema…” en la parte inferior del menú lee un archivo .skin.json de Nikkomander (un nombre y una lista de colores) y lo copia a la carpeta skins junto al archivo de configuración; la × de la ficha de un tema importado lo elimina.
• Los temas pintados quedan detrás de la interfaz. Los fondos pintados los dibuja src/skin_scenes.rs, no gradientes CSS, de modo que se adaptan a cualquier tamaño de ventana. Desde 1.6.2 cada uno pasa por una pasada discreet() en src/skin.rs: el arte se acerca a su propia media local, se desenfoca ligeramente y se desvanece hacia el color de fondo del tema — sobre todo detrás del anillo de soltar y de la columna de texto, y un poco más sobre el logotipo — para que el título, el anillo y el texto de estado permanezcan nítidos en los catorce.

3.11 El menú del gestor de archivos

Un submenú “NikPak” en el menú contextual del gestor de archivos, como el de WinRAR, lo instala el instalador (Windows: una opción marcada por defecto; Linux: nikpak --install-menu; macOS: Acciones rápidas de Finder).

• Sobre archivos y carpetas: Añadir al archivo… (pide el nombre y la carpeta y luego comprime en la ventana de NikPak) y Añadir al archivo aquí (el archivo se coloca junto a los elementos, con el nombre como si se soltaran en la ventana).
• Sobre archivos .nik: Abrir con unNik, Extraer archivos…, Extraer aquí y Extraer a su propia carpeta.
• Varios elementos van a un solo archivo; varios archivos seleccionados se extraen uno tras otro en una sola ventana.
• Los comandos se ejecutan a través de unNik.exe, de modo que no parpadea ninguna ventana de consola; las etiquetas siguen el idioma de NikPak. Windows 10 muestra el submenú directamente y Windows 11 bajo Mostrar más opciones (Mayús+F10); Linux añade menús de servicio de KDE Dolphin, acciones de Nemo y scripts de Nautilus, y macOS añade Acciones rápidas de Finder.
• Nuevas opciones de línea de comandos que usa el menú: nikpak --add y --add-here (comprimen los elementos indicados), nikpak --install-menu, --uninstall-menu y --all-users; unNik --extract, --extract-here y --extract-to. Extraer aquí / a su propia carpeta muestran la ventana pequeña de unNik con el anillo de progreso (la caja de contraseña para archivos cifrados) y la cierran cuando todo está extraído; las advertencias y los errores permanecen en pantalla.
• Un segundo instalador, unnik--setup.exe, instala solo unNik (el explorador gratuito) para quienes únicamente reciben archivos .nik; cuando NikPak ya está instalado, solo instala el programa, de modo que los menús nunca se duplican.

4 Arquitectura

nikpak es un único programa Rust de unas 9.600 líneas (incluidas sus pruebas unitarias) en dieciséis archivos de código fuente, más la herramienta privada de licencias nikpak-keygen. Su regla de diseño central es el procesamiento por flujo: los archivos se leen en trozos de 256 KiB, se empujan a través de una cadena de escritores y nunca se mantienen completos en memoria (las únicas excepciones son los datos de píxeles BMP, limitados a 256 MiB, y los búferes de trabajo de 64 KiB de los códecs).

4.1 Flujo de datos al crear un archivo

Cada etapa es una implementación del rasgo estándar Write envuelta alrededor de la siguiente, de modo que la misma ruta de código sirve para un archivo normal, un archivo cifrado y la prueba de medios.

4.2 Mapa del código fuente

Archivo	Responsabilidad
main.rs	Punto de entrada. Analiza los argumentos, despacha el comando y convierte los errores en códigos de salida. Gestiona una tubería cerrada sin ruido (nikpak lb x | head).
cli.rs	Analizador de argumentos al estilo RAR/zip escrito a mano, las tablas de opciones y el texto completo de -help. Las bibliotecas al estilo Clap no pueden expresar interruptores como -pSECRET o -m5 con claridad.
archive.rs	Crear, listar, comprobar, extraer (por filtros o por una elección exacta), eliminar, imprimir y la prueba de medios; también el índice y la lectura de archivos individuales que usa unNik. Contiene el escritor y el lector del flujo de entradas, la política de sobrescritura y la lógica atómica de archivos temporales.
media.rs	Detección de contenido para WAV, AIFF, MOD y BMP; los filtros Shuffle, Delta y MED; selección por prueba; auxiliares de CRC y de encuadre de fragmentos.
nac.rs	El códec de audio sin pérdida NAC: descorrelación estéreo, predictores y codificación de residuos.
bits.rs	Escritor y lector de bits con el bit más significativo primero, usados por NAC.
crypto.rs	Derivación de clave Argon2id y el escritor y lector de fragmentos XChaCha20-Poly1305.
format.rs	Constantes del formato en disco: magia, versiones, tipos de registro y límites de la KDF.
util.rs	Solicitud y generación de contraseñas, saneamiento de rutas, coincidencia de comodines y formato de fechas y tamaños.
error.rs	El tipo de error, sus códigos de salida y la clasificación de los errores de E/S (corrupción frente a fallo del sistema).
engine.rs	Cuerpo multimotor de -m5: escritor y lector de bloques, motores LZMA2 y PPMd, y la prueba de motores (secciones 5.6, 6.7).
recomp.rs	Recompresión Deflate de contenedores ZIP, PDF y gzip con preflate (sección 7.9).
gui.rs	La interfaz gráfica: ventana de soltar, anillo de progreso, ajuste de destino y enlaces de comunidad (sección 3.7).
unnik.rs	unNik, el explorador de archivos: árbol, lista, búsqueda, visor y cajas de extraer y eliminar (sección 3.9).
lib.rs, bin/unnik.rs	La biblioteca compartida por nikpak y unNik, y el punto de entrada de unNik.exe (un programa de ventana, sin consola).
license.rs	Licencia shareware: formato de clave, verificación Ed25519, almacenamiento de la licencia y registro (sección 3.8).
i18n.rs	Traducciones de la ventana a los diez idiomas más hablados; ajuste de idioma (sección 3.7).
textshape.rs	Texto conformado para hindi, bengalí y árabe: ordenación bidireccional, conformado y rasterización (sección 3.7).

4.3 Crear un archivo, paso a paso

• Valide la ubicación de salida. Un archivo existente solo se sustituye con -o+ (o un sí interactivo); en caso contrario, nikpak explica que no se admite añadir.
• Recopile la entrada: se expanden los comodines (PowerShell no lo hace), se leen los @listfiles, se aplican las exclusiones, se omiten con una advertencia los enlaces simbólicos y los archivos especiales, y el archivo nunca se añade a sí mismo.
• Resuelva la contraseña si se solicitó cifrado (sección 3.3) y derive la clave con Argon2id.
• Escriba la cabecera y después construya la cadena de escritores: archivo, escritor con búfer, cifrador de fragmentos opcional y codificador Zstandard.
• Escriba cada entrada. Los archivos de medios pasan por la detección y la prueba (capítulo 7); todo lo demás se copia en trozos de 256 KiB mientras se calcula un CRC32.
• Escriba el marcador final con el número de entradas, finalice la trama Zstandard, selle el último fragmento cifrado y vuelque a disco.
• Renombre name.nik.tmp a name.nik. Si algo falla antes, un objeto de guardia elimina el archivo temporal, de modo que un archivo a medio escribir nunca sustituye a uno bueno.

4.4 Extraer un archivo, paso a paso

• Lea y valide la cabecera: magia, versión, indicadores, método y, para archivos cifrados, los parámetros Argon2id, que se verifican en rango antes de asignar memoria.
• Obtenga la contraseña y derive la clave. El primer fragmento autenticado confirma o desmiente entonces la contraseña.
• Recorra el flujo de entradas. Cada nombre de entrada se sanea (sección 10.1) antes de cualquier acceso al sistema de archivos.
• Escriba los archivos con create_new, establezca las marcas de tiempo y los permisos, y verifique el CRC32 de los bytes reconstruidos. Un archivo cuyo CRC falla se elimina en lugar de conservarse.
• Verifique el final del archivo: después del marcador final el flujo debe terminar de verdad y, si está cifrado, el último fragmento autenticado debe haberse procesado. Esto detecta los truncamientos y los datos añadidos.

4.5 Memoria e hilos

Zstandard usa hilos de trabajo para la compresión (todos los núcleos por defecto, -mt para limitarlo). La descompresión, el códec de audio y el cifrado se ejecutan en el hilo que llama. Argon2id necesita 64 MiB para la derivación de clave, y los dos niveles más altos usan una ventana de coincidencia de 128 MiB, de modo que descomprimir tales archivos necesita hasta esa cantidad de memoria.

5 El formato contenedor .nik

Un archivo .nik es una cabecera fija pequeña seguida de un cuerpo. El cuerpo es un único flujo sólido: todas las entradas se concatenan, se comprimen juntas y, opcionalmente, se cifran. La versión 2 del formato añade registros de medios; los archivos de la versión 1 siguen siendo legibles.

5.1 Cabecera

Desplazamiento	Tamaño	Campo	Notas
0	8	Número mágico	89 4E 49 4B 0D 0A 1A 0A (la idea de PNG: detecta daños por transferencia en modo texto)
8	1	Versión	3 (1 y 2 siguen siendo legibles)
9	1	Indicadores	bit 0 = cifrado; los demás bits deben ser 0
10	1	Método	0 = almacenar, 1 = Zstandard, 2 = bloques multimotor (5.6)
11	1	Reservado	0
12	4	Memoria Argon2id (KiB)	solo archivos cifrados, little endian
16	4	Pasadas Argon2id	solo cifrado
20	4	Líneas Argon2id	solo cifrado
24	16	Sal	aleatoria por archivo, solo cifrado
40	19	Prefijo del nonce del flujo	aleatoria por archivo, solo cifrado

La cabecera completa (12 bytes, o 59 bytes cuando está cifrada) se autentica después como datos asociados de cada fragmento cifrado, de modo que no se puede alterar sin que se detecte.

5.2 Registros de entrada

Dentro del flujo (descifrado y descomprimido), cada entrada es un registro. Todos los enteros son little endian.

Tipo	Estructura
0 END	count:u64. Marca el final e indica cuántas entradas lo preceden.
1 FILE	name_len:u16 name mtime:i64 mode:u32 size:u64 data[size] crc32:u32
2 DIR	name_len:u16 name mtime:i64 mode:u32
3 MEDIA	name_len:u16 name mtime:i64 mode:u32 size:u64 filter:u8 method:u8 params_len:u8 params framed_stream crc32:u32

• Los nombres son UTF-8 con separadores /, de 4096 bytes como máximo.
• mtime son segundos Unix; mode es la palabra de permisos Unix (los archivos de Windows reciben 0644 o 0755, y 0444 si son de solo lectura).
• El CRC32 siempre cubre los bytes originales, que es lo que hace verificables los filtros de medios.
• En un registro MEDIA, size es el tamaño original. El framed_stream es una serie de fragmentos [u32 length][bytes] terminados por una longitud cero, de modo que un lector siempre puede saltarse una entrada de medios sin entender su filtro.

Parámetros de medios

Filtro	Parámetros	Contenido
1 Audio	19 bytes	offset:u64 frames:u64 channels:u8 bits:u8 flags:u8 (indicador bit 0 = big endian, bit 1 = con signo)
2 Imagen	21 bytes	offset:u64 width:u32 rows:u32 bpp:u8 stride:u32
3 Deflate	0 bytes	none: the framed stream holds raw segments and recompressed Deflate streams (section 7.9)

Todo lo anterior a offset (cabeceras, etiquetas, paletas, patrones MOD) y todo lo posterior a la región de muestras o píxeles (fragmentos finales) se almacena sin cambios alrededor de los datos filtrados.

5.3 Encuadre del cuerpo cifrado

Cuando está activado el indicador de cifrado, la salida zstd se corta en fragmentos de 64 KiB de texto claro. Cada fragmento se almacena como una longitud de 32 bits en big endian seguida del texto cifrado, que es 16 bytes más largo debido a la etiqueta Poly1305. Un fragmento solo se sella cuando le sigue al menos un byte más, de modo que el último fragmento nunca está vacío y puede marcarse como final (sección 8.3).

5.4 ¿Por qué un flujo sólido?

Comprimir todos los archivos como un solo flujo permite al compresor encontrar repeticiones entre archivos, lo que importa enormemente para árboles de código fuente y colecciones de documentos (el punto de referencia del capítulo 11 muestra que la salida no sólida de RAR es casi el doble de grande que su salida sólida en 10.949 archivos). El precio es el acceso secuencial: extraer un único archivo requiere descomprimir lo que lo precede. nikpak reduce este coste para las entradas de medios saltándoselas sin decodificarlas.

5.5 Control de versiones

El byte de versión se compara con la versión más alta que el programa entiende. Un archivo más nuevo produce el mensaje Versión de archivo no compatible N; actualice nikpak en lugar de un engañoso error de corrupción. Los indicadores, métodos o filtros de medios desconocidos se rechazan de la misma manera.

5.6 Cuerpo multimotor (versión 3)

Los archivos creados con -m5 usan el método 2. El flujo interno de registros descrito en 5.2 no cambia, pero se corta, solo entre entradas, en bloques, y cada bloque se comprime con su propio motor. Concatenados, los bloques descomprimidos son exactamente el flujo de registros de un archivo de un solo motor, de modo que listar, comprobar y extraer funcionan de la misma manera.

Elemento	Estructura
body	block* seguido de un único byte 0
block	engine:u8 parameters, después tramas [u32 length 1 .. 1 MiB][compressed bytes], terminadas por una longitud cero
motor 1	Zstandard (sin parámetros)
motor 2	Flujo bruto LZMA2: tamaño de diccionario u32, lc u8, lp u8, pb u8
motor 3	PPMd variante I (PPMd8): orden u8, tamaño de modelo u32, método de restauración u8 (0 = reinicio)

El encuadre permite al lector encontrar el final de cada bloque sin confiar en el decodificador, y todos los parámetros se verifican en rango antes de asignar memoria (diccionario LZMA2 de 1.5 GiB como máximo, modelo PPMd de 1 GiB como máximo, orden de 2 a 16). Cuando está cifrado, el cuerpo está protegido por los mismos fragmentos autenticados que cualquier otro archivo (capítulo 8).

6 El motor de compresión

6.1 Por qué Zstandard

Zstandard combina la coincidencia LZ77 con una etapa de entropía basada en codificación Huffman y entropía de estados finitos (FSE). Comparado con el algoritmo Deflate de ZIP, encuentra coincidencias en una ventana mucho mayor, modela los literales y las longitudes de coincidencia con códigos de entropía más ajustados y decodifica a gigabytes por segundo. Es además un formato abierto y ampliamente auditado, lo que mantiene los datos de nikpak recuperables por herramientas independientes.

6.2 Correspondencia de niveles

nikpak acepta tanto niveles al estilo RAR (-m0 .. -m5) como niveles al estilo zip (-0 .. -9) y los asigna a niveles de Zstandard:

Opción	Nivel Zstandard	Carácter
-m0	ninguno (almacenado)	Sin compresión, sin filtros de medios
-m1	1	Rapidísimo
-m2	3	Rápido; unos 0.9 s para 197 MB en un núcleo (el valor por defecto hasta 1.2.0)
-m3	9	Buen equilibrio
-m4	15	Alto; ventana de 128 MiB y coincidencia a larga distancia; recompresión Deflate (7.9)
-m5 (default)	LZMA2 / PPMd	Máximo, y el valor por defecto desde 1.2.1: cuerpo multimotor (6.7) y recompresión Deflate

Los niveles al estilo zip se asignan así: -0 almacena, -1 a -6 usan Zstandard 1 a 6, -7 usa 9, -8 usa 12 y -9 es lo mismo que -m5.

6.3 Ventana grande y coincidencia a larga distancia

En el nivel 15 de Zstandard y superiores, nikpak activa una ventana de coincidencia de 2^27 bytes (128 MiB) y la coincidencia a larga distancia. Los árboles de código fuente, los conjuntos de documentos y las copias de seguridad contienen muchos archivos casi duplicados que quedan muy separados en el flujo; una ventana normal de 8 MiB no puede abarcarlos. En el conjunto de prueba de 197 MB esto redujo la salida en -m5 de 26.3 MB a 24.4 MB y en -m4 de 29.5 MB a 26.8 MB, sin coste de velocidad para -m4 y con uno pequeño para -m5. Una ventana de 2^27 está dentro del límite por defecto del decodificador de Zstandard, de modo que cualquier decodificador estándar puede leer los datos.

6.4 Multihilo

El codificador divide la entrada en trabajos que se ejecutan en hilos de trabajo (todos los núcleos por defecto). La velocidad de compresión escala por tanto con el número de núcleos, mientras el formato sigue siendo un único flujo. Todas las cifras de esta guía se midieron en un núcleo; en una máquina multinúcleo típica nikpak es considerablemente más rápido de lo mostrado.

6.5 Integridad dentro del flujo

La trama Zstandard lleva su propia suma de comprobación de contenido, nikpak añade un CRC32 por archivo y un marcador final con el número de entradas. Un archivo normal dañado se detecta por tanto en tres niveles: la suma de comprobación de la trama, el CRC por archivo y el marcador final.

6.6 Modo almacenar

-m0 escribe las entradas sin comprimir. Es útil para datos que ya están comprimidos, y es además el único modo en que los filtros de medios se omiten a propósito: un usuario que pide almacenar no espera que los datos se transformen.

6.7 El nivel máximo: LZMA2 y PPMd

Zstandard es el motor adecuado para la velocidad, pero en sus ajustes más potentes sigue estando unos puntos porcentuales por detrás de LZMA2 en código fuente y documentos, y muy por detrás de PPMd en prosa. Desde la versión 1.2, -m5 construye por tanto el archivo a partir de dos bloques (formato en 5.6):

• Bloque binario. Las carpetas, los archivos binarios, las entradas de medios y las entradas recompimidas con Deflate se comprimen con LZMA2: preset 9, longitud agradable 273, profundidad del buscador de coincidencias 32 y un diccionario dimensionado según los datos (de 1 a 128 MiB).
• Bloque de texto. Los archivos cuyos primeros 64 KiB no contienen ningún byte cero y casi ningún carácter de control (código fuente, texto, CSV, HTML, XML ...) van a un segundo bloque. Cuatro tramos contiguos de 1 MiB de estos archivos se comprimen a prueba con PPMd variante I (orden 8, modelo de 192 MiB) y con LZMA2 afinado para texto (lc 4, pb 0), y gana el resultado más pequeño. La prosa favorece a PPMd; los árboles de código fuente grandes con muchos archivos casi idénticos favorecen a LZMA2, porque puede copiar repeticiones largas entre archivos.
• Orden. Dentro de cada bloque, los archivos se ordenan por extensión y después por nombre de archivo, como hace 7-Zip, para que los archivos idénticos o similares queden contiguos. Junto con la muestra de prueba contigua, esto hizo el conjunto de datos general un 7.5 % más pequeño.

Los ajustes "Extreme" de LZMA2 se midieron y se descartaron: en el XML de las hojas de cálculo eran hasta diez veces más lentos y no más pequeños. -m5 se ejecuta en un hilo, independientemente de -mt.

7 Inteligencia de medios

Un compresor de propósito general ve bytes. No sabe que un archivo WAV es una forma de onda cuya siguiente muestra es predecible a partir de las anteriores, ni que los píxeles vecinos de una fotografía son casi iguales. La capa de medios de nikpak aporta ese conocimiento: reconoce tales archivos, aplica una transformación sin pérdida que pone de manifiesto la redundancia y deja que el compresor (o un códec dedicado) la aproveche. Es aquí donde nikpak gana más frente a RAR.

7.1 Detección por contenido

La detección examina los primeros bytes de cada archivo de al menos 8 KiB y nunca se fía de la extensión, de modo que un WAV renombrado a .dat se encuentra igualmente y un archivo de texto llamado .wav no.

Tipo	Cómo se reconoce	Qué se filtra
WAV	RIFF..WAVE, un fragmento fmt con PCM entero (formato 1, o WAVE_FORMAT_EXTENSIBLE con el subformato PCM), 8/16/24/32 bits, de 1 a 8 canales, alineación de bloque coherente; después el fragmento data	La región de muestras. Una longitud de datos nula, desmesurada o falsa se ajusta al archivo; los bytes sobrantes y los fragmentos finales se conservan tal cual.
AIFF / AIFC	FORM..AIFF o AIFC (compresión NONE o twos), fragmentos COMM y SSND, muestras con signo en big endian	La región de datos de sonido.
ProTracker MOD	Firma en el desplazamiento 1080: M.K., M!K!, FLT4, 4CHN, 6CHN, 8CHN, FLT8, OCTA o CD81	La zona de muestras de 8 bits después de los datos de patrón (sección 7.6).
BMP	BM, una cabecera DIB de 40 bytes o más, sin compresión, 8, 24 o 32 bits por píxel, filas de píxeles que caben en el archivo, región entre 4 KiB y 256 MiB	Las filas de píxeles (sección 7.7).

No gestionados, y por tanto almacenados con compresión normal: WAV de coma flotante, ADPCM y otro audio comprimido, BMP con RLE o de campos de bits, y formatos de tracker distintos de ProTracker MOD. Los medios ya comprimidos como MP3, JPEG, FLAC, PNG y MP4 no se reconocen en absoluto y se dejan intactos, ya que transformarlos no ayudaría.

7.2 La prueba: elegir el mejor filtro por archivo

Ninguna transformación es la mejor para todos los archivos. La codificación predictiva gana en música grabada; la separación en planos de bytes gana en audio procedente de una fuente compandida de 8 bits (donde solo aparecen unos mil valores distintos de 16 bits); la compresión normal gana en silencio y en muestras de tracker muy repetitivas. nikpak, por tanto, mide en lugar de adivinar.

• Tome una muestra: toda la región de muestras cuando es de hasta 3 MiB; en caso contrario, tres ventanas de 768 KiB al 5 %, 45 % y 85 % del audio. Para las imágenes, las primeras filas hasta unos 4 MiB.
• Comprima la muestra con Zstandard normal de nivel 3 (la línea base) y con cada filtro que corresponda: NAC, Shuffle y Shuffle+Delta para audio de 16/24/32 bits; NAC y Shuffle+Delta para audio de 8 bits; MED para imágenes.
• Conserve el filtro con la estimación más pequeña, pero solo si supera la línea base en al menos un 2 %. En caso contrario, el archivo se almacena con compresión normal.
• Escriba el archivo con el ganador. Todo esto ocurre por archivo, de modo que un archivo puede contener WAV codificados con métodos distintos junto a archivos normales.

nikpak mt ejecuta la misma medición sobre el archivo completo e imprime una tabla, que es como se exploró el punto de referencia del capítulo 11. En las opciones, -mc- desactiva los filtros y -mc+ fuerza el filtro por defecto sin prueba.

Sin pérdida, verificable y desactivable Cada filtro es exactamente reversible. El CRC32 almacenado con cada entrada se calcula sobre los bytes originales y se comprueba en la extracción, el codificador NAC verifica cada bloque mientras escribe (sección 7.4), y -mc- desactiva toda la capa.

7.3 El códec de audio NAC

NAC (códec de audio de nikpak) es un códec sin pérdida basado en bloques para PCM entero. Pertenece a la misma familia que FLAC: predicción lineal seguida de codificación Rice. Tiene su propio flujo de bits, diseñado para este archivador, y se usa para WAV, AIFF y los datos de muestras de los archivos MOD.

Bloques y descorrelación estéreo

El audio se corta en bloques de 4096 tramas de muestras, cada uno codificado de forma independiente, lo que hace robusto el códec (un error no puede propagarse) y permite al codificador adaptarse al material cambiante. Para estéreo, el codificador elige una de cuatro representaciones por bloque:

Modo	Canales codificados	Reconstrucción
0	Left, Right	direct
1	Left, Side	R = L - S
2	Side, Right	L = R + S
3	Mid, Side	sum = (M << 1) | (S & 1), L = (sum + S) >> 1, R = (sum - S) >> 1

con Side = L - R y Mid = (L + R) >> 1. El canal lateral necesita un bit más que un canal normal y se codifica con bits + 1. El modo se elige de forma económica: el codificador suma los valores absolutos del residuo del predictor fijo de orden 2 de L, R, M y S y toma el par con el total más pequeño. Para grabaciones cuyos canales están muy correlacionados, Mid/Side suele ahorrar varios puntos porcentuales.

Tipos de subtrama

Cada canal codificado de un bloque se almacena como una de cuatro subtramas, la que sea más pequeña:

Tipo	Uso	Coste
Constante	Todas las muestras iguales (silencio digital)	2 + bits del ancho de muestra para un bloque completo
Verbatim	Material similar a ruido, o el recurso de seguridad	n x width bits
Fijo	Predictor polinómico de orden 0 a 4	muestras de calentamiento + residuos
LPC	Predictor lineal de orden 1 a 32 con coeficientes transmitidos	coeficientes + calentamiento + residuos

Bits desperdiciados. Si los bits bajos de cada muestra de un bloque son siempre cero (una grabación de 8 bits almacenada en contenedores de 16 bits, o una señal cuantificada), se eliminan y su cantidad se almacena en 5 bits.

Predictores fijos

order 0: e[i] = x[i]

order 1: e[i] = x[i] - x[i-1]

order 2: e[i] = x[i] - 2*x[i-1] + x[i-2]

order 3: e[i] = x[i] - 3*x[i-1] + 3*x[i-2] - x[i-3]

order 4: e[i] = x[i] - 4*x[i-1] + 6*x[i-2] - 4*x[i-3] + x[i-4]

Las primeras order muestras de un bloque se almacenan literalmente como valores de calentamiento.

Codificación predictiva lineal (LPC)

Para música tonal y armónica, un predictor cuyos coeficientes se ajustan al bloque es mucho mejor que un polinomio fijo. El codificador los calcula así:

• Aplique una ventana de Tukey (atenuación en el primer y último cuarto) al bloque, para que sus bordes no distorsionen las estadísticas.
• Calcule la autocorrelación r[0..32] de la señal enventanada.
• Ejecute la recursión de Levinson-Durbin, que produce el conjunto óptimo de coeficientes para cada orden de 1 a 32 en una sola pasada: k = (r[i] - sum a[j] r[i-j]) / err, a[i] = k, a[j] = a[j] - k a[i-j], err = err (1 - k^2).
• Cuantifique los coeficientes reales a enteros con una precisión de 12, 14 o 15 bits (según el ancho de muestra), eligiendo una escala de potencia de dos (shift, de 0 a 20) de modo que el mayor coeficiente quepa justo. El redondeo usa realimentación de error, de modo que los errores de cuantificación no se acumulan entre coeficientes.
• Evalúe varios órdenes (el conjunto depende del nivel de esfuerzo, más abajo), calcule el residuo de cada uno y conserve el que tenga el tamaño total estimado más pequeño, incluido el coste de enviar sus coeficientes.

El predictor en sí es aritmética entera pura, que es lo que ejecuta el decodificador:

pred[i] = (q[0]*x[i-1] + q[1]*x[i-2] + ... + q[n-1]*x[i-n]) >> shift

e[i] = x[i] - pred[i] (n = order; the sum uses 64 bits)

La coma flotante la usa solo el codificador para decidir qué coeficientes enteros enviar. El decodificador nunca toca la coma flotante, de modo que la decodificación es exacta bit a bit en cualquier procesador y compilador.

Codificación de residuos

Los errores de predicción se transforman en números sin signo con la transformación zig-zag (u = (e << 1) XOR (e >> 63), de modo que los valores pequeños positivos y negativos se convierten en números pequeños) y se codifican con códigos Rice particionados. El residuo de un bloque se divide en 2^p particiones (p de 0 a 8, elegido por el codificador); cada partición recibe su propio parámetro Rice k (5 bits). Un valor se escribe como u >> k en unario (tantos ceros y un uno) seguido de los k bits bajos. El mejor k de una partición se obtiene de la suma de sus valores, de modo que el coste de cada predictor candidato puede estimarse de forma económica a partir de sumas acumuladas en lugar de codificándolo.

Niveles de esfuerzo

El nivel del archivo (opción -m) selecciona cuántos órdenes LPC se prueban por bloque. Más órdenes significan un resultado ligeramente más pequeño y un codificador más lento; la velocidad del decodificador es la misma.

Nivel del archivo	Esfuerzo NAC	Órdenes LPC probados
-m1	0	8, 16
-m2, -m3	1	4, 8, 12, 16, 24, 32
-m4, -m5	2	2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 24, 28, 32

Los predictores fijos de orden 0 a 4 se prueban siempre. En el punto de referencia, el nivel de esfuerzo cambió el resultado de la música estéreo en menos del 0.05 %: la gran ganancia proviene de usar predicción en absoluto.

Disposición de bits de un bloque

block := [stereo mode: 2 bits] sub-frame [sub-frame] (byte-padded)

sub-frame := type:2 ...

CONSTANT : value:width

VERBATIM : wasted:5 samples:(n x (width - wasted))

FIXED : wasted:5 order:3 warm-up residual

LPC : wasted:5 order-1:5 precision-1:4 shift:5

coefficients warm-up residual

residual := partition-order:4 per partition: k:5 Rice-coded values

Cada bloque se almacena en el archivo con una longitud de 32 bits delante, de modo que el decodificador siempre sabe dónde empieza el siguiente bloque.

7.4 Autoverificación

Escribir un archivo es la única oportunidad de detectar un error del codificador, por lo que el codificador NAC no se fía de sí mismo. Después de codificar cada bloque, vuelve a decodificar el bloque y compara el resultado con las muestras originales. Ante cualquier diferencia, vuelve a codificar el bloque como verbatim (lo que no puede fallar) y comprueba de nuevo; si incluso eso falla, el archivado se detiene con un error explícito y la sugerencia de usar -mc-. La ruta de respaldo la ejercitan las pruebas unitarias, que fuerzan la codificación verbatim para cada combinación de profundidad de bits y número de canales, y el mecanismo convierte un posible error silencioso de pérdida de datos en una condición detectada y recuperable.

Además, el decodificador se somete a fuzzing: en las pruebas unitarias se le suministran miles de bloques de bytes aleatorios y bloques con bits invertidos, y debe devolver un error sin entrar en pánico ni asignar cantidades de memoria irrazonables. Durante el desarrollo esto encontró un error real (para material de 32 bits, la búsqueda del parámetro Rice podía quedar vacía y recurrir a un parámetro que habría producido un código de varios gigabytes); está corregido y cubierto por una prueba.

7.5 Shuffle y Shuffle+Delta

Parte del audio no responde a la predicción. Los archivos WAV de la galería usados en el punto de referencia son de 16 bits, pero contienen solo unos mil valores de muestra distintos, porque se produjeron a partir de una fuente compandida de 8 bits. Un predictor no puede aprovechar eso, y FLAC los comprime al 84 % del original mientras que Zstandard normal necesita el 63 %. Lo que ayuda es disponer los bytes de modo que el compresor vea datos homogéneos:

• Shuffle separa los bytes de las muestras en planos: todos los bytes menos significativos del canal 0, después todos los bytes más significativos del canal 0, después el canal 1, y así sucesivamente, en bloques de 32768 tramas. El plano de bytes altos es suave y el plano de bytes bajos tiene un alfabeto muy restringido; el codificador de entropía de Zstandard modela cada uno mucho mejor que la mezcla entrelazada.
• Shuffle+Delta sustituye primero cada muestra por su diferencia con la muestra anterior del mismo canal (módulo el ancho de muestra, de modo que es exactamente reversible, con estado transportado entre bloques) y después baraja. Esto ayuda cuando la señal es suave pero no lo bastante predecible para que gane NAC.

En los 35 archivos de la galería, el archivo con el mejor filtro por archivo (elegido por la prueba) es el 51 % del tamaño original en -m2 y el 47 % en -m5, frente al 63 % de Zstandard normal.

7.6 Archivos MOD de ProTracker

Un módulo MOD es una cabecera de 1084 bytes (título, 31 descriptores de muestra, una tabla de orden de patrones de 128 entradas y una firma de 4 bytes en el desplazamiento 1080), después los datos de patrón y después las muestras brutas de 8 bits con signo de todos los instrumentos. nikpak calcula dónde empiezan las muestras y cuánto miden:

patterns = max(order table) + 1

sample_start = 1084 + patterns * 256 * channels (4 ch: 1024 B per pattern)

sample_bytes = sum of (length in words * 2) over the 31 descriptors,

clamped to the end of the file

La cabecera y los patrones se almacenan tal cual (el compresor maneja bien esos eventos de notas repetitivos) y la zona de muestras se trata como un único flujo mono, con signo y de 8 bits para la prueba. Por archivo, gana NAC, Shuffle+Delta o la compresión normal: los instrumentos muestreados favorecen sobre todo a NAC, mientras que en algunos módulos (por ejemplo los de muestras muy cortas o muy repetitivas) gana la compresión normal. Los módulos truncados se gestionan ajustando la región a los datos realmente presentes.

7.7 Imágenes BMP

Un BMP sin comprimir almacena filas de píxeles rellenadas hasta un múltiplo de cuatro bytes. El filtro trabaja en cuatro pasos:

• Divida la región de píxeles en un plano por canal (B, G, R y A para 32 bits), recordando los bytes de relleno por fila por separado.
• Descorrelacione el color. Reste el plano verde de los planos azul y rojo (módulo 256). En las fotografías los tres canales están muy correlacionados, de modo que las diferencias son pequeñas.
• Prediga cada píxel a partir de sus vecinos con el predictor MED (detector de bordes por mediana), el que usa el codificador de imágenes LOCO-I: para el izquierdo a, el superior b y el superior izquierdo c, la predicción es min(a,b) si c >= max(a,b), max(a,b) si c <= min(a,b), y a + b - c en caso contrario. El error de predicción sustituye al píxel (módulo 256). En los bordes el predictor sigue el borde; en los degradados suaves extrapola el degradado.
• Concatene los planos residuales y los bytes de relleno y deje que Zstandard los comprima. Las regiones suaves se convierten en rachas de bytes casi nulos.

El decodificador invierte los pasos exactamente. Los BMP de 8 bits se saltan el paso de color; la prueba decide entonces si la predicción ayuda para esa paleta, ya que predecir índices de paleta solo tiene sentido para paletas en escala de grises o suavemente ordenadas. Los archivos BMP de más de 256 MiB no se filtran, para limitar el uso de memoria.

7.8 Por qué esto supera a RAR

RAR comprime los medios con su motor general de coincidencias y Huffman más un pequeño conjunto de filtros de bytes. nikpak, en cambio, da al audio un verdadero códec predictivo con descorrelación estéreo por bloque y codificación Rice adaptativa, da a las imágenes un predictor 2-D adecuado con descorrelación de color, y elige por archivo mediante medición. La consecuencia es visible en el punto de referencia: un 12 a 15 % más pequeño en audio de todo tipo, un 13 % en música de tracker y un 39 % en fotografías, y el resultado NAC para la pista estéreo está dentro del 0.2 % del codificador FLAC dedicado.

7.9 Documentos de Office, PDF y gzip: recompresión Deflate

Los archivos de Office modernos son archivos ZIP de XML (docx, xlsx, pptx, odt, ods), y los archivos PDF almacenan sus páginas en flujos Deflate (FlateDecode). Su contenido ya está por tanto comprimido, y ningún archivador puede reducirlo mucho: en el punto de referencia 1.1, 6.6 MB de archivos .xlsx solo bajaban a 5.6 MB con 7-Zip. nikpak 1.2 elimina ese obstáculo.

• Detección por contenido. Una cabecera local ZIP (PK\x03\x04) al inicio del archivo, %PDF- o una cabecera gzip; nunca se usa la extensión.
• Decodificación. Se encuentra cada flujo Deflate (entradas ZIP con método 8, flujos PDF con cabecera zlib, cada miembro gzip) y se analiza con preflate (preflate-rs de Microsoft). preflate devuelve los datos simples más un pequeño registro de correcciones que describe exactamente cómo hizo sus elecciones el codificador original, fuera cual fuera.
• Almacenamiento. El archivo se almacena como una secuencia de segmentos brutos y pares (simple, correcciones). El XML o la descripción de página simples pasan entonces al flujo sólido, donde LZMA2 lo comprime a una fracción de su tamaño Deflate.
• Verificación. Antes de usar el resultado, nikpak reconstruye cada flujo Deflate y compara la longitud y el CRC32 del archivo completo con el original. Si algo difiere, o preflate falla o entra en pánico con un archivo mal formado, el archivo simplemente se almacena de forma normal.
• Extracción. Los flujos Deflate se recrean bit a bit, de modo que el .docx o .pdf extraído es idéntico byte a byte, y su CRC32 se comprueba como en cada entrada.

En el conjunto de Office de la sección 11.7, esto es lo que hace a nikpak más pequeño que cualquier otro archivador. Los 6.6 MB de archivos .xlsx contienen 71 MB de XML una vez decodificados, y ese XML se comprime mucho mejor de lo que lo hizo Deflate. El coste es el tiempo: preflate analiza unos 15 MB de datos simples por segundo. Por eso la recompresión se usa solo en -m4 y -m5, donde compensa (medido: -m3 ganaba un 0.5 % por seis veces el tiempo). Límites: archivos de hasta 512 MiB, y por flujo hasta 512 MiB de datos simples y 64 MiB de correcciones. -mc- lo desactiva.

8 Cifrado

El cifrado de nikpak se construye por completo con componentes estándar y bien estudiados (las implementaciones de RustCrypto de Argon2id y XChaCha20-Poly1305). No se inventó ninguna primitiva para este proyecto; el trabajo está en combinarlas correctamente.

8.1 Modelo de amenazas

El diseño supone un atacante que obtiene el archivo y puede estudiarlo y modificarlo a placer, y que puede probar sin límite conjeturas de contraseña sin conexión. nikpak pretende garantizar:

• Confidencialidad del contenido de los archivos y de todo lo relativo a ellos: nombres, tamaños, marcas de tiempo, permisos y número de archivos.
• Integridad y autenticidad: cualquier cambio en el archivo, ya sea en los datos, en la cabecera, en el orden de los datos o en su longitud, se detecta antes de aceptar datos incorrectos.
• Resistencia a la adivinación: cada conjetura de contraseña se hace tan costosa como resulte práctico.

No oculta que existe un archivo ni su tamaño aproximado, y no puede proteger contra el malware en la máquina que crea o abre el archivo, ni contra una contraseña débil.

8.2 De la contraseña a la clave: Argon2id

Una contraseña es una clave pobre: corta, predecible y escrita por un humano. Se convierte en una clave de 256 bits con Argon2id, el ganador del Password Hashing Competition y el algoritmo estandarizado en RFC 9106. Argon2id es deliberadamente exigente en memoria: calcular una clave necesita un gran bloque de memoria que se llena y después se lee repetidamente en un patrón dependiente de los datos. nikpak usa el perfil de memoria baja del RFC:

Parámetro	Valor	Significado
Memoria	64 MiB	Cada conjetura necesita 64 MiB de memoria rápida
Pasadas	3	La memoria se procesa tres veces
Líneas	4	Grado de paralelismo dentro de una derivación
Sal	16 bytes aleatorios	Nueva para cada archivo: contraseñas idénticas dan claves distintas, y las tablas precalculadas son inútiles
Salida	32 bytes	La clave XChaCha20-Poly1305

La exigencia de memoria es lo que separa Argon2id del antiguo PBKDF2 (usado por RAR5 y por el modo AES de ZIP): PBKDF2 casi no necesita memoria, de modo que una tarjeta gráfica o un chip personalizado pueden probar enormes cantidades de conjeturas en paralelo. Con Argon2id, el hardware del atacante debe aportar 64 MiB por conjetura paralela, lo que elimina la mayor parte de esa ventaja. El coste para el usuario legítimo es una fracción de segundo, pagada una vez por archivo.

Los parámetros se almacenan en la cabecera, de modo que las versiones futuras pueden aumentarlos sin romper archivos antiguos. Al leer, primero se comprueban en rango (memoria 8 x líneas hasta 1 GiB, pasadas de 1 a 64, líneas de 1 a 64) para que un archivo malicioso no pueda hacer que nikpak asigne cantidades absurdas de memoria antes de que se haya comprobado la contraseña.

8.3 XChaCha20-Poly1305 en la construcción STREAM

Los datos a granel se protegen con XChaCha20-Poly1305, un cifrado de cifrado autenticado con datos asociados (AEAD): ChaCha20 proporciona un cifrado de flujo con clave de 256 bits, la variante X amplía su nonce a 192 bits (lo bastante grande para elegirlo al azar sin repetirlo nunca) y Poly1305 añade una etiqueta de autenticación de 128 bits a cada mensaje sellado. ChaCha20 es rápido en cualquier CPU sin instrucciones especiales y, a diferencia del AES basado en tablas, está naturalmente libre de fugas por temporización de caché.

Un archivo es mucho mayor que un mensaje, de modo que nikpak usa la construcción STREAM (la misma que usan las herramientas modernas de cifrado de archivos): los datos se cortan en fragmentos de 64 KiB y el fragmento número i se sella con el nonce

nonce (24 bytes) = random prefix (19 bytes)

| chunk counter (4 bytes, big endian)

| last-chunk flag (1 byte)

Esto da tres garantías a la vez. Cada fragmento tiene un nonce único, esencial para los cifrados de flujo. Como el contador forma parte del nonce, reordenar o duplicar fragmentos hace fallar la autenticación. Como el fragmento final lleva un indicador distinto, cortar el archivo, incluso exactamente en un límite de fragmento, hace fallar la autenticación: el nuevo último fragmento se selló como no final. El prefijo de 19 bytes es aleatorio por archivo.

Además, la cabecera completa del archivo (versión, indicadores, método, parámetros Argon2id, sal y prefijo del nonce) se pasa como datos asociados a cada fragmento. Está autenticada pero no cifrada; invertir cualquiera de sus bits hace fallar todos los fragmentos. Esto también bloquea los ataques de degradación que intentarían debilitar los parámetros almacenados.

Elemento	Valor
Cifrado	XChaCha20-Poly1305: clave de 256 bits, nonce de 192 bits, etiqueta de 128 bits
Fragmento	hasta 64 KiB de texto claro; almacenado como u32 length + texto cifrado + etiqueta de 16 bytes
Sobrecoste de tamaño	alrededor del 0.03 % (20 bytes por 64 KiB), medido 0.03 % en un conjunto de datos de 222 MB
Sobrecoste de velocidad	medido: +0.3 s en total en un conjunto de datos de 222 MB (0.92 s en lugar de 0.64 s), incluida la derivación de clave
Contraseña incorrecta	Se detecta en el primer fragmento; no se produce texto claro

8.4 Lo que un observador puede y no puede ver

Visible sin la contraseña	Protegido
El número mágico, la versión, los indicadores y el método de compresión	Los nombres de archivo y la estructura de carpetas
Los parámetros Argon2id, la sal y el prefijo del nonce	Los tamaños de archivo, las marcas de tiempo y los permisos
El tamaño total del archivo y el número de fragmentos	El número de archivos
El hecho de que es un archivo de nikpak	Todo el contenido, incluido si contiene medios

Una consecuencia de comprimir antes de cifrar es que el tamaño del archivo refleja lo comprimibles que son los datos. Esto es inherente a todo archivador que comprime y cifra; solo importa si un atacante puede controlar parte de los datos y observar el tamaño, lo que no se aplica al archivado de archivos.

8.5 Gestión de contraseñas

• Longitud mínima. 8 caracteres al crear un archivo; las contraseñas más cortas se rechazan con una explicación.
• Confirmación. El aviso interactivo pregunta dos veces, no muestra los caracteres escritos y rechaza una discrepancia.
• Generación. Sin contraseña, nikpak extrae 24 caracteres de un alfabeto de 56 símbolos que omite los parecidos (0/O, 1/l/I), usando muestreo por rechazo sobre el generador aleatorio criptográficamente seguro del sistema operativo, de modo que ningún símbolo es más probable que otro. Eso son 24 x log2(56), unos 139 bits de entropía, y se muestra una sola vez, en una caja claramente marcada.
• Higiene de memoria. La clave derivada y las cadenas de contraseña se borran de la memoria cuando ya no se necesitan (la crate zeroize).
• Canales. Línea de comandos (-p), variable de entorno NIKPAK_PASSWORD, aviso interactivo o stdin cuando no hay terminal. La forma de línea de comandos es cómoda pero visible en la lista de procesos; las demás formas son preferibles.

8.6 Pruebas de ataque

Las siguientes manipulaciones de archivos cifrados se llevaron a cabo contra el programa terminado. Todas se detectaron antes de aceptar ningún dato incorrecto:

Manipulación	Resultado
Invertir un único byte en medio del texto cifrado	Rechazado: fallo de autenticación (salida 11)
Invertir un byte de la sal de la cabecera	Rechazado (la cabecera es datos asociados y la clave cambia)
Cambiar el byte de método de la cabecera	Rechazado
Truncar el archivo en 100 bytes	Rechazado como dañado (salida 3)
Eliminar el fragmento final exactamente en un límite de fragmento	Rechazado: el nuevo último fragmento carece del indicador final
Intercambiar dos fragmentos	Rechazado: discrepancia del contador
Suministrar la contraseña incorrecta	Rechazado en el primer fragmento (salida 11)
Suministrar un archivo aleatorio como archivo	Rechazado: firma incorrecta (salida 3)

Riesgos residuales, expuestos con franqueza Una contraseña débil siempre se puede adivinar; Argon2id la encarece pero no puede rescatar password123. nikpak no ha sido auditado de forma independiente. No puede defenderse de los keyloggers, del malware ni de alguien que lea la memoria del proceso en ejecución. Para datos cuya exposición fuera gravemente perjudicial, haga revisar antes la implementación por un criptógrafo.

9 Resistencia cuántica

Los ordenadores cuánticos amenazan gravemente parte de la criptografía y apenas afectan a otra. nikpak se diseñó en el lado que apenas se ve afectado.

9.1 Qué cambian los ordenadores cuánticos

Algoritmo	Efecto	A quién afecta
Shor (1994)	Factoriza enteros y calcula logaritmos discretos en tiempo polinómico	RSA, Diffie-Hellman, DSA, criptografía de curvas elípticas: rotos por un gran ordenador cuántico
Grover (1996)	Busca en un espacio no estructurado de N elementos en aproximadamente la raíz cuadrada de N pasos	Claves simétricas y funciones hash: la longitud efectiva de la clave se reduce a la mitad

El algoritmo de Shor es el dramático: rompería todos los sistemas que dependen de las matemáticas de clave pública, por lo que los gobiernos y los organismos de normalización están migrando a algoritmos de clave pública poscuánticos como ML-KEM (FIPS 203). El algoritmo de Grover es el suave: una clave de 256 bits ofrece unos 128 bits de seguridad frente a él, y las iteraciones de Grover son intrínsecamente secuenciales, de modo que repartir el trabajo entre muchas máquinas cuánticas solo produce la raíz cuadrada de su número como aceleración.

9.2 La posición de nikpak

Componente	Primitiva	Impacto cuántico
Cifrado	XChaCha20, clave de 256 bits	Mejor ataque conocido: Grover, unas 2^128 operaciones. Fuera de alcance.
Autenticación	Poly1305, etiqueta de 128 bits, con clave derivada del secreto de 256 bits	No intervienen matemáticas de clave pública
De contraseña a clave	Argon2id, 64 MiB, 3 pasadas	Grover como mucho podría reducir a la mitad la entropía de la contraseña, y cada iteración requeriría evaluar una función exigente en memoria
Aleatoriedad	CSPRNG del sistema operativo	No afectado
Criptografía de clave pública	Ninguna	Nada que el algoritmo de Shor pueda atacar

Una clave simétrica de 256 bits es la referencia para la categoría de seguridad más alta (categoría 5) de la normalización poscuántica del NIST: los algoritmos de clave pública estandarizados por el NIST se clasifican según lo cerca que estén de la dificultad de una búsqueda exhaustiva de una clave AES de 256 bits. En otras palabras, el cifrado de datos de nikpak ya se sitúa en la solidez a la que aspiran los estándares poscuánticos.

9.3 ¿Y la contraseña?

El espacio de claves del cifrado es de 256 bits, pero la clave se deriva de una contraseña, de modo que la solidez real es la menor entre la entropía de la contraseña y 256 bits. Frente a un adversario cuántico, la entropía de la contraseña se reduce, en el mejor de los casos para el atacante, a la mitad:

Contraseña	Entropía	Búsqueda clásica	Búsqueda de Grover (en el mejor caso)
generada por nikpak (24 símbolos)	unos 139 bits	unas 2^139 conjeturas	unas 2^70 iteraciones, cada una de las cuales necesita una evaluación Argon2id coherente de 64 MiB
Seis palabras Diceware aleatorias	unos 77 bits	unas 2^77 conjeturas	unas 2^39 iteraciones del mismo circuito costoso
Una contraseña de 10 caracteres elegida por un humano	típicamente 30 - 45 bits	factible	factible

La conclusión es la conocida, expresada con más rotundidad: la contraseña es el punto débil, no el cifrado. Use la contraseña generada o una frase de contraseña aleatoria larga y el archivo resistirá tanto a los atacantes clásicos como a los cuánticos en cualquier futuro previsible. Argon2id ayuda en ambos mundos, porque el coste de cada conjetura lo domina la memoria, que el algoritmo de Grover no abarata.

9.4 "Recolectar ahora, descifrar después"

Una amenaza cuántica citada con frecuencia es que un adversario grabe hoy datos cifrados y los descifre cuando exista un ordenador cuántico. Para los sistemas que intercambian claves con RSA o curvas elípticas, como las conexiones TLS o el cifrado del correo electrónico, esto es real. Un archivo de nikpak no tiene intercambio de claves: su clave procede de un secreto que nunca sale de la cabeza del usuario ni de su gestor de contraseñas. Una copia almacenada solo puede abrirse más tarde adivinando ese secreto, y los ordenadores cuánticos no lo hacen fundamentalmente más fácil.

9.5 Límites honestos y camino por delante

• "Resistente a la computación cuántica" significa que ningún algoritmo cuántico conocido supera la búsqueda genérica contra estas primitivas. No es una demostración; el criptoanálisis de ChaCha20 y Argon2 continúa, y el formato está versionado para que los parámetros o los algoritmos puedan cambiarse.
• Si algún día se añade el intercambio de clave pública (cifrar un archivo para la clave de un destinatario), usará un esquema híbrido, X25519 combinado con ML-KEM, de modo que sea seguro si cualquiera de los componentes se mantiene.
• La resistencia cuántica no protege contra los errores de implementación. Véanse las secciones 8.6 y 10.

10 Endurecimiento y robustez

Un archivador lee archivos escritos por desconocidos y escribe archivos en el disco de su usuario, lo que lo convierte en un objetivo clásico. nikpak trata cada archivo como entrada no fiable.

10.1 Extracción segura

• Recorrido de rutas ("zip slip"). Cada nombre de entrada se normaliza: las barras invertidas se convierten en barras, los componentes vacíos y . se descartan, y cualquier componente .. hace que la entrada se omita con una advertencia. Los nombres absolutos pierden su raíz, de modo que /etc/passwd se extrae dentro de la carpeta de destino.
• Nombres de Windows. Al ejecutarse en Windows, los componentes que contienen < > : " | ? * o caracteres de control, que terminan en espacio o punto, o que son iguales a un nombre de dispositivo reservado (CON, PRN, AUX, NUL, COM1-9, LPT1-9) se rechazan.
• Enlaces simbólicos. Antes de escribir, se comprueba cada componente existente de la ruta de destino por debajo del destino; nunca se sigue un enlace. Un archivo existente se elimina primero y el nuevo se crea con create_new, que se niega a abrir una ruta existente, de modo que un enlace no puede usarse para redirigir la escritura.
• Bits privilegiados. Los bits setuid, setgid y sticky nunca se restauran; los permisos se enmascaran a los bits rwx ordinarios.
• Archivos fallidos. Un archivo cuyo CRC32 no coincide se elimina, no se deja atrás.

En las pruebas se extrajo un archivo hecho a mano que contenía ../../evil.txt, /tmp/evil.txt, ..\..\evil.txt y ok/../../evil.txt: nada escapó del destino, las entradas inseguras se notificaron y se omitieron, y un enlace simbólico plantado en el destino se rechazó.

10.2 Decodificadores acotados

• Los parámetros Argon2id se comprueban en rango antes de cualquier asignación (sección 8.2).
• Los fragmentos cifrados deben tener una longitud entre 16 bytes y 64 KiB + 16; los nombres, 4096 bytes como máximo; los bloques de audio deben declarar una longitud plausible; las regiones BMP están limitadas a 256 MiB; los códigos Rice unarios están limitados.
• A los decodificadores de audio y de medios se les suministraron miles de entradas aleatorias y con bits invertidos en las pruebas unitarias, y deben devolver un error, nunca entrar en pánico ni abortar.
• El código propio de nikpak no contiene bloques unsafe, y la comprobación de límites de Rust convierte cualquier error lógico que en C sería un fallo de corrupción de memoria en un fallo limpio.

nikpak no limita la relación de expansión de un archivo, de modo que, como todo archivador, una "bomba de compresión" deliberadamente fabricada puede llenar un disco al extraerse. Compruebe los archivos desconocidos con t primero si eso importa.

10.3 Creación segura y errores honestos

• El archivo se escribe en name.nik.tmp y solo se renombra cuando está completo; un guardián elimina el archivo temporal ante cualquier fallo, de modo que una ejecución interrumpida nunca deja un archivo a medio escribir ni sustituido.
• Si un archivo se acorta mientras se está archivando, nikpak aborta con un mensaje explícito en lugar de escribir una entrada incoherente. Los archivos ilegibles, los enlaces simbólicos y los archivos especiales se omiten con una advertencia (código de salida 1) y el archivo nunca se añade a sí mismo.
• Los errores se clasifican para que los scripts puedan reaccionar: un error de suma de comprobación o de trama dentro de un archivo es corrupción (salida 3), un fallo de autenticación es contraseña incorrecta o manipulación (salida 11) y una escritura rechazada es un error grave (salida 2).

11 Puntos de referencia

Este capítulo presenta mediciones, no afirmaciones. Describe exactamente qué se midió, incluye los resultados que no favorecen a nikpak y da los comandos necesarios para repetir todo.

Las secciones 11.1 a 11.6 se midieron con nikpak 1.1.0, cuyo -m5 todavía usaba Zstandard. La sección 11.7 compara nikpak 1.2.0 con RAR, 7-Zip y ZIP en una máquina.

11.1 Método

Elemento	Detalle
Máquina	Máquina virtual Linux x86-64, un núcleo de CPU. Todos los tiempos son segundos de reloj en ese único núcleo; las máquinas multinúcleo son más rápidas para ambas herramientas.
Software	RAR 7.00 (26 Feb 2024, compilación de prueba para Linux, formato -ma5); nikpak 1.1.0 compilado en modo release con LTO; FLAC 1.x -8 como referencia de audio.
Ajustes de RAR	-m3 (el valor por defecto de RAR) y -m5 (el mejor). Para la prueba de datos generales también -s (sólido) y -md256m (diccionario de 256 MB), porque los archivos de nikpak siempre son sólidos y una comparación justa necesita que a RAR se le permita lo mismo.
Verificación	Cada archivo de nikpak se extrajo y se comparó con el original (cmp para los archivos de medios, SHA-256 de los 10.949 archivos para el conjunto general).

El material de prueba

Conjunto	Contenido
WAV de la galería	35 archivos de sonido de la galería de LibreOffice: mono de 16 bits, 23 a 11,025 Hz y 12 a 22,050 Hz. Contienen solo unos mil valores de muestra distintos (fuentes compandidas) y son un caso deliberadamente incómodo para la codificación predictiva.
Música	Una pieza multiinstrumento de 100 segundos (piano, cuerdas, bajo, flauta, batería) interpretada con TiMidity++ y el conjunto de sonidos Freepats a 44.1 kHz estéreo de 16 bits (17.4 MB). SoX derivó una versión mono de 22.05 kHz y 16 bits, una mono de 22.05 kHz y 8 bits y una estéreo de 48 kHz y 24 bits.
MOD	16 módulos ProTracker de la colección de pruebas de libxmp.
BMP	6 imágenes: cinco fotografías del conjunto de muestras de scikit-image (de 24 bits, más una conversión a escala de grises de 8 bits de una de ellas) y una textura de TeX Live.
Datos generales	197.6 MB en 10.949 archivos: la biblioteca estándar y los paquetes de Python, documentación y cabeceras C de la máquina de prueba, sin enlaces simbólicos.

Límites de este material de prueba La música es sintética: se interpretó a partir de MIDI y contiene pasajes repetidos, lo que ayuda a toda herramienta basada en LZ, incluida la etapa Zstandard posterior a NAC. Las grabaciones reales contienen menos repeticiones exactas, de modo que los tamaños absolutos diferirán. La comparación trata a todas las herramientas por igual, y el resultado de FLAC en el mismo archivo confirma que el códec de audio en sí es competitivo, pero los lectores con material específico deberían medirlo: nikpak mt hace exactamente eso.

11.2 Archivos de medios

Conjunto	Original	RAR 7 -m5	nikpak -m2	nikpak -m5	m5 frente a RAR
6 fotografías BMP	9,183,956	2,862,744	2,035,223	1,750,706	38.8 % más pequeño
16 archivos MOD de ProTracker	2,507,557	1,070,290	966,622	927,973	13.3 % más pequeño
35 WAV de la galería (mono de 16 bits)	2,991,820	1,605,879	1,529,219	1,418,532	11.7 % más pequeño
Música 44.1 kHz estéreo de 16 bits	17,371,848	11,024,411	9,415,519	9,411,898	14.6 % más pequeño
Música 22.05 kHz mono de 16 bits	4,342,996	3,112,135	2,635,819	2,634,669	15.3 % más pequeño
Música 22.05 kHz mono de 8 bits	2,171,520	844,160	742,462	740,751	12.2 % más pequeño
Música 48 kHz estéreo de 24 bits	28,362,206	21,467,283 (-m3)	18,689,529	18,688,030	12.9 % más pequeño

Todos los tamaños están en bytes. Para el archivo de 24 bits, RAR solo se midió en -m3, de modo que esa fila es una comparación más débil que las demás.

Qué aportan los filtros de medios

El mismo nikpak sin filtros de medios (versión 1.0, Zstandard normal en el nivel por defecto) es la vara de medir adecuada para el valor de la capa de medios:

Conjunto	nikpak 1.0 (sin filtros)	nikpak 1.1 -m2	Reducción
6 fotografías BMP	3,580,971	2,035,223	43.2 %
16 archivos MOD de ProTracker	1,260,607	966,622	23.3 %
35 WAV de la galería (mono de 16 bits)	1,876,722	1,529,219	18.5 %
Música 44.1 kHz estéreo de 16 bits	15,585,422	9,415,519	39.6 %
Música 22.05 kHz mono de 16 bits	3,887,183	2,635,819	32.2 %
Música 22.05 kHz mono de 8 bits	1,078,493	742,462	31.2 %

Comparación con FLAC

Para la música estéreo de 44.1 kHz, FLAC -8, el codificador de referencia dedicado, produce 9,407,019 bytes. El flujo NAC para el mismo audio son 9,425,305 bytes, dentro del 0.2 %, y el archivo nikpak terminado, 9,415,519 bytes. Para las versiones mono y de 8 bits de 22 kHz, NAC es más pequeño que FLAC (2,635,446 frente a 2,638,954, y 785,890 frente a 798,810 solo para la región de audio), y para 24 bits el archivo (18.69 MB) es más pequeño que los 19.12 MB de FLAC. FLAC es mucho más débil en los archivos de la galería (2.50 MB frente a los 1.61 MB de RAR), por la razón explicada en la sección 7.5; este es el caso en el que los demás filtros se ganan su lugar.

11.3 Datos generales

El código fuente y los documentos no son medios, de modo que esta prueba comprueba si las ganancias de nikpak en otros ámbitos le cuestan algo en los archivos ordinarios.

Herramienta y nivel	Tamaño (bytes)	Tiempo	Extracción
nikpak -m5	24,443,483	45.6 s	1.8 s
RAR 7 -m5 -s -md256m	25,862,475	36.2 s
RAR 7 -m5 -s	26,002,812	26.7 s
RAR 7 -m3 -s	26,536,863	16.7 s	1.5 s
nikpak -m4	26,814,023	13.5 s
nikpak -m3	30,329,965	2.0 s
nikpak -m2 (valor por defecto de 1.1)	36,266,743	0.9 s	0.8 s
RAR 7 -m5 (por defecto, no sólido)	50,851,230	14.8 s
RAR 7 -m3 (por defecto, no sólido)	50,974,773	9.7 s	2.3 s

Leyendo la tabla con honestidad:

• Nivel máximo: nikpak produce un archivo un 5.5 % más pequeño que el mejor de RAR (24.4 frente a 25.9 MB). RAR es más rápido en este nivel (26.7 a 36.2 s frente a 45.6 s).
• Igual tamaño: nikpak -m4 queda a alrededor del 1 % del nivel sólido por defecto de RAR en el 81 % del tiempo (13.5 s frente a 16.7 s).
• Niveles rápidos: -m2 cambia ratio por velocidad: 18 veces más rápido que el -m3 sólido de RAR y un 37 % más grande. Este es el nivel para copias de seguridad y cadenas de procesamiento donde el tiempo importa más que los últimos megabytes.
• No sólido: los archivos por defecto (no sólidos) de RAR tienen casi el doble de tamaño que los sólidos en estos datos de muchos archivos pequeños. Quien compare nikpak con RAR debería añadir -s a RAR.

11.4 Velocidad en un único archivo de medios grande

Operación	nikpak	RAR 7	Tamaño
Crear, rápido / por defecto de RAR	1.45 s (-m2)	2.54 s (-m3)	9,415,519 frente a 11,128,595
Crear, nivel máximo	3.14 s (-m5)	5.87 s (-m5)	9,411,898 frente a 11,024,411
Extraer	0.28 s	0.23 s	misma salida

En medios, nikpak es a la vez más pequeño y más rápido de crear. RAR extrae un poco más rápido; una razón probable es que la decodificación NAC realiza predicción entera para cada muestra, lo que cuesta algo más que la copia de coincidencias que domina la decodificación general.

11.5 Sobrecoste del cifrado

En el conjunto de datos de 222 MB, un archivo cifrado tardó 0.92 s frente a 0.64 s sin cifrar, y fue 11,087 bytes (0.03 %) más grande. La diferencia incluye la derivación Argon2id, de modo que el coste lo domina una fracción fija de segundo.

11.6 Reproducir los resultados

# media: which filter wins, per file

nikpak mt song.wav tracker.mod photo.bmp

# archive with nikpak and RAR, then compare

nikpak a -q -ep -m2 test.nik *.wav

rar a -ep -m5 -ma5 test.rar *.wav

# fair comparison on many files: give RAR solid mode

rar a -r -s -m5 -ma5 -md256m data.rar data

nikpak a -m5 data.nik data

# verify

nikpak x -o+ test.nik restore\

11.7 Segunda ronda: nikpak, RAR 7, 7-Zip y ZIP

Actualizado para nikpak 1.2.0. En la primera versión de esta ronda, con nikpak 1.1.0, 7-Zip -mx9 iba por delante en texto (en un 1.4 %), archivos de Office (3.3 %) y código fuente (8.5 %). nikpak 1.2.0 añade recompresión Deflate (7.9) y un nuevo nivel máximo basado en LZMA2 y PPMd (6.7), y se midió de nuevo en la misma máquina con los mismos archivos. Las cifras de RAR, 7-Zip y ZIP proceden de la primera ronda.

Las secciones 11.2 a 11.5 comparan nikpak solo con RAR. Esta segunda ronda añade los dos archivadores que ya tiene la mayoría, 7-Zip y el clásico formato ZIP, y dos clases de archivos que se archivan a diario: texto plano y documentos de Office (.doc, .docx, .xls, .xlsx, .csv, .pdf). Las cuatro herramientas se ejecutaron una tras otra en la misma máquina y con los mismos archivos, y RAR se midió de nuevo. Los corpus se reconstruyeron a partir de las mismas fuentes públicas, de modo que los tamaños y tiempos absolutos difieren de los de 11.2 a 11.4. Compare las cifras dentro de esta sección, no entre secciones.

Método

Elemento	Detalle
Máquina	Máquina virtual Linux x86-64 (Intel Xeon, 2.8 GHz). Cada comando se fijó a un núcleo de CPU con taskset y se ejecutó con un solo hilo (nikpak -mt1, RAR -mt1, 7-Zip -mmt=1; ZIP es de un solo hilo por diseño).
Software	nikpak 1.2.0 (compilación release); RAR 7.00 (-ma5, sólido); 7-Zip 23.01 (formato .7z, LZMA2, sólido por defecto); Info-ZIP Zip 3.0 y UnZip 6.0 (Deflate).
Niveles	nikpak: el nivel rápido -m2 y el máximo -m5, que es el valor por defecto desde 1.2.1 (y -m4). Los demás: por defecto y máximo, RAR -m3 -s / -m5 -s, 7-Zip -mx5 / -mx9, ZIP -6 / -9. A RAR se le dio modo sólido (-s), porque los otros tres son sólidos o, en el caso de ZIP, no pueden serlo.
Medición de tiempos	Segundos de reloj. Conjuntos de menos de 50 MB: el mejor de tres ejecuciones. El conjunto general: una ejecución.
Verificación	Los 92 archivos se extrajeron y se compararon con el original usando diff -r. Todos eran idénticos.

El material de prueba

Conjunto	Archivos	Tamaño (bytes)	Contenido
Imágenes BMP	8	6,987,840	Seis fotografías del conjunto de muestras de scikit-image como BMP de 24 bits, más una fotografía en escala de grises de 8 bits y una textura de grava de 8 bits.
ProTracker MOD	16	2,252,604	Los 16 módulos ProTracker más grandes de la colección de pruebas de libxmp.
WAV de la galería	35	2,991,820	Los mismos 35 sonidos de la galería de LibreOffice que en 11.1.
Música, cuatro formatos	4 × 1	53,417,226	Una nueva pieza de 100 segundos (piano, cuerdas, bajo, flauta, batería) interpretada con TiMidity++ y Freepats a 44.1 kHz estéreo de 16 bits, convertida después con SoX a 22.05 kHz mono de 16 bits y de 8 bits y a 48 kHz estéreo de 24 bits.
Texto plano	18	11,793,318	Dieciocho libros del Proyecto Gutenberg como .txt (Austen, Melville, Shakespeare, la Biblia del Rey Jacobo y otros).
Archivos de Office	60	39,100,915	12 informes como .docx, .doc y .pdf (texto, encabezados, tablas y algunas fotos) y 8 libros de ventas de 500 a 30,000 filas como .xlsx, .xls y .csv (con fórmulas), guardados por LibreOffice.
Datos generales	11,473	190,454,632	Bibliotecas estándar de Python 3.12 y 3.13, paquetes Python de Debian, cabeceras C (/usr/include) y /usr/share/doc. Sin enlaces simbólicos.

Niveles máximos: tamaño del archivo

Conjunto	Original	nikpak -m5	RAR 7 -m5	7-Zip -mx9	ZIP -9
8 imágenes BMP	6,987,840	3,557,350	4,394,310	4,195,043	4,974,680
16 archivos MOD de ProTracker	2,252,604	1,127,607	1,264,245	1,166,855	1,408,085
35 WAV de la galería (mono de 16 bits)	2,991,820	1,346,484	1,596,971	1,484,879	1,852,279
Música 44.1 kHz estéreo de 16 bits	17,760,408	8,731,989	10,460,042	10,666,922	15,225,764
Música 22.05 kHz mono de 16 bits	4,440,136	2,458,867	2,797,026	2,784,080	3,736,722
Música 22.05 kHz mono de 8 bits	2,220,090	606,840	725,416	642,341	836,989
Música 48 kHz estéreo de 24 bits	28,996,592	18,198,056	21,229,465	25,542,036	26,980,770
18 libros de texto plano (.txt)	11,793,318	2,741,898	3,519,622	3,259,868	4,223,579
60 archivos de Office	39,100,915	6,887,729	11,186,217	10,085,779	17,399,998
Datos generales (11,473 archivos)	190,454,632	28,175,618	33,606,893	28,879,398	62,198,510

Todos los tamaños están en bytes. El archivo más pequeño de cada fila se muestra en negrita.

Niveles rápidos: tamaño y tiempo de creación

Conjunto	nikpak -m2	RAR 7 -m3	7-Zip -mx5	ZIP -6
8 imágenes BMP	54.0 % · 0.39 s	63.0 % · 2.09 s	60.1 % · 3.51 s	71.2 % · 0.35 s
16 archivos MOD de ProTracker	52.4 % · 0.61 s	56.2 % · 0.43 s	51.9 % · 0.69 s	62.7 % · 0.10 s
35 WAV de la galería (mono de 16 bits)	51.1 % · 0.41 s	53.6 % · 0.71 s	49.6 % · 1.96 s	61.9 % · 0.24 s
Música 44.1 kHz estéreo de 16 bits	49.2 % · 1.72 s	59.9 % · 3.60 s	60.1 % · 14.03 s	85.7 % · 0.82 s
Música 22.05 kHz mono de 16 bits	55.4 % · 0.58 s	64.1 % · 0.95 s	62.7 % · 2.14 s	84.2 % · 0.22 s
Música 22.05 kHz mono de 8 bits	27.4 % · 0.77 s	33.3 % · 0.52 s	28.9 % · 2.13 s	38.2 % · 0.32 s
Música 48 kHz estéreo de 24 bits	62.8 % · 2.06 s	73.6 % · 7.54 s	88.1 % · 13.54 s	93.0 % · 1.19 s
18 libros de texto plano (.txt)	35.2 % · 0.11 s	30.4 % · 5.53 s	27.7 % · 11.76 s	36.0 % · 0.89 s
60 archivos de Office	38.0 % · 0.22 s	29.5 % · 8.25 s	26.2 % · 21.85 s	44.7 % · 1.83 s
Datos generales (11,473 archivos)	25.3 % · 1.67 s	18.0 % · 48.19 s	17.0 % · 93.71 s	32.9 % · 7.32 s

nikpak -m2 frente al nivel por defecto de las demás herramientas. Cada celda muestra el tamaño del archivo como porcentaje del original y el tiempo de creación en un núcleo. El archivo más pequeño de cada fila está en negrita.

Datos generales en detalle

Herramienta y nivel	Tamaño (bytes)	% del original	Creación	Extracción
nikpak -m5	28,175,618	14.8 %	154.3 s	5.6 s
7-Zip -mx9	28,879,398	15.2 %	120.9 s	6.0 s
RAR 7 -m5 -s -md256m	32,350,575	17.0 %	73.6 s	7.0 s
7-Zip -mx5	32,375,802	17.0 %	93.7 s	4.5 s
nikpak -m4	33,295,133	17.5 %	37.8 s	3.3 s
RAR 7 -m5 -s	33,606,893	17.6 %	72.4 s	6.7 s
RAR 7 -m3 -s	34,236,198	18.0 %	48.2 s	5.9 s
nikpak -m2	48,229,284	25.3 %	1.7 s	0.9 s
RAR 7 -m3 (no sólido)	56,038,351	29.4 %	20.2 s	6.9 s
ZIP -9	62,198,510	32.7 %	28.2 s	6.9 s
ZIP -6	62,672,415	32.9 %	7.3 s	5.4 s

De 1.1.0 a 1.2.0

Conjunto	nikpak 1.1.0 -m5	nikpak 1.2.0 -m5	7-Zip -mx9	1.2.0 frente a 7-Zip
18 libros de texto plano	3,306,819	2,741,898	3,259,868	15.9 % más pequeño
60 archivos de Office	10,417,750	6,887,729	10,085,779	31.7 % más pequeño
Datos generales	31,322,041	28,175,618	28,879,398	2.4 % más pequeño

Leyendo los resultados con honestidad

• nikpak -m5 es el más pequeño en todos los conjuntos. Frente a 7-Zip -mx9 es un 2.4 a 31.7 % más pequeño, frente a RAR 7 -m5 un 10.8 a 38.4 % y frente a ZIP -9 un 19.9 a 60.4 %. En audio grabado, NAC predice lo que los compresores basados en LZ solo pueden igualar: en la música de 24 bits, 7-Zip ahorra un 12 % y nikpak un 37 %.
• Archivos de Office: un 31.7 % más pequeños que 7-Zip. La recompresión Deflate convierte 6.6 MB de .xlsx y 1.9 MB de .docx en XML simple que LZMA2 comprime mucho mejor de lo que lo hizo Deflate (6.89 MB frente a 10.09 MB). Incluso -m4 es un 1.3 % más pequeño que 7-Zip -mx9 y más rápido (16 s frente a 26 s). El precio en -m5 es el tiempo: 81 s frente a 26 s.
• Texto: un 15.9 % más pequeño, en la mitad de tiempo. PPMd gana en prosa (6.4 s frente a 12.9 s para crear). Como PPMd decodifica tan despacio como codifica, la extracción tarda 2.7 s en lugar de 0.2 s.
• Código fuente: un 2.4 % más pequeño, una ventaja estrecha. 28.2 MB frente a 28.9 MB, en 154 s frente a 121 s. Ordenar por tipo de archivo y elegir el motor en muestras contiguas (6.7) marcó la diferencia.
• Nivel rápido -m2: el más rápido, no el más pequeño. nikpak -m2 necesita 1.7 s para el conjunto general, frente a 93.7 s de 7-Zip -mx5 (56 veces más), 48.2 s de RAR y 7.3 s de ZIP. Es más pequeño que 7-Zip -mx5 en imágenes y en la mayoría del audio (los archivos MOD y los WAV de la galería son un 1 a 3 % más grandes), pero más grande en texto, archivos de Office y código fuente (49.0 % en el conjunto general). Por esta razón, desde la versión 1.2.1 nikpak usa -m5 por defecto; -m2 hay que pedirlo.
• ZIP es rápido pero el más grande en todo. Incluso nikpak -m2 supera a ZIP -9 en todos los conjuntos. ZIP crea archivos de medios pequeños más rápido que nikpak -m2, porque Deflate hace mucho menos trabajo que el códec NAC, pero es más lento en texto, archivos de Office y código fuente.
• Extracción. El conjunto general se extrae en 0.9 s (nikpak -m2) o 5.6 s (-m5), frente a 6.0 s de 7-Zip, 6.7 s de RAR y 6.9 s de ZIP. Los archivos con flujos Deflate recompimidos se extraen más despacio, porque cada flujo se reconstruye (2.1 s frente a 0.7 s para el conjunto de Office).
• RAR en esta máquina. RAR fue más lento aquí que en 11.3 (72 s en lugar de 27 s para -m5 -s en una cantidad similar de código fuente). La máquina y los datos difieren, de modo que las dos secciones no deberían mezclarse. Dentro de esta ronda, todas las herramientas tuvieron las mismas condiciones.

Qué significa esto para nikpak

En el nivel máximo, nikpak 1.2.0 crea el archivo más pequeño de las cuatro herramientas en todos los conjuntos medidos, un 2.4 a 31.7 % más pequeño que 7-Zip -mx9. El coste es la velocidad: -m5 es de un solo hilo y más lento que 7-Zip en archivos de Office y código fuente. Hacerlo más rápido está en la hoja de ruta (sección 15.2).

12 nikpak y RAR comparados

RAR es un archivador excelente y muy utilizado, y este capítulo no pretende lo contrario. Expone dónde las mediciones y el diseño favorecen a nikpak, dónde aventaja RAR y quién debería elegir qué.

12.1 Dónde aventaja nikpak

Área	nikpak	Evidencia
Audio, imágenes, música de tracker	Un 12 - 39 % más pequeño que RAR 7 -m5 en todos los conjuntos de medios medidos	Sección 11.2
Código fuente, nivel máximo	Un 5.5 % más pequeño que el mejor ajuste sólido de RAR	Sección 11.3
Velocidad en el nivel rápido -m2	0.9 s frente a 9.7 - 16.7 s para 197 MB; 1.45 s frente a 2.54 s para un WAV	Secciones 11.3, 11.4
Cifrado y modo	XChaCha20-Poly1305, autenticado; RAR5 usa AES-256 en modo CBC, que no está autenticado y depende de sumas de comprobación separadas	Capítulo 8
Derivación de contraseñas	Argon2id, exigente en memoria (64 MiB); RAR5 usa PBKDF2-HMAC-SHA256, que está limitado por la CPU y se paraleliza a bajo coste en GPU	Sección 8.2
Privacidad de los nombres de archivo	Siempre cifrados; RAR necesita el interruptor -hp	Sección 8.4
Generación de contraseñas	Integrada: contraseña aleatoria fuerte cuando no se da ninguna	Sección 3.3
Evidencia de manipulación	La reordenación, el truncamiento y los cambios de cabecera se detectan criptográficamente	Sección 8.6
Transparencia	Código fuente completo y formato documentado; implementación en Rust seguro en memoria	Capítulos 5, 10
Distribución	Un ejecutable estático (ventana de soltar y línea de comandos; unos 2.3 MB sin la ventana), o un pequeño instalador de Windows; shareware, gratis para uso personal (3.8)	Capítulo 13

12.2 Dónde aventaja RAR

Área	RAR 7	nikpak hoy
Registros de recuperación	Puede reparar archivos dañados	Detecta los daños, no puede repararlos
Archivos multivolumen	Sí	No
Archivos autoextraíbles	Sí	No
Actualizar un archivo	Añadir, sustituir y eliminar archivos in situ	Solo crear o sobrescribir
Interfaz gráfica	WinRAR, con integración en el shell	Ventana de soltar para comprimir (3.7); sin integración en el shell, extracción desde la línea de comandos
Velocidad en el nivel máximo	26.7 - 36.2 s en el conjunto general	45.6 s
Velocidad de extracción en medios	0.23 s para el WAV de 17 MB	0.28 s
Madurez y alcance	Décadas de pruebas de campo; millones de archivos .rar existentes	Nuevo; sin auditoría independiente; lee solo .nik

12.3 La resistencia cuántica en perspectiva

Tanto nikpak como RAR5 cifran con una clave simétrica de 256 bits, de modo que ambos quedan intactos ante el algoritmo de Shor y ambos conservan unos 128 bits de seguridad frente al de Grover. Ninguna de las dos afirmaciones los distingue. Lo que nikpak añade por encima es un paso de contraseña exigente en memoria (que encarece mucho el ataque dominante en el mundo real, la adivinación de contraseñas) y cifrado autenticado (que hace detectable la manipulación). Además se ha diseñado desde el principio con el supuesto de que ninguna primitiva de clave pública formará jamás parte del formato de archivo, y su hoja de ruta se compromete a un esquema poscuántico híbrido si se añade el intercambio de clave pública.

12.4 Cuál elegir

• Elija nikpak para archivos de audio, imágenes, música de tracker y código fuente donde importan el tamaño y la velocidad, para copias de seguridad automatizadas, para un cifrado fuerte por defecto y cuando valga la pena un formato abierto y documentado.
• Elija RAR cuando necesite registros de recuperación, archivos multivolumen o autoextraíbles, actualizaciones in situ, o deba intercambiar archivos con personas que solo tienen herramientas de RAR.
• Use ambos: nada impide que un flujo de trabajo use nikpak para grandes volúmenes de medios y copias de seguridad cifradas mientras mantiene RAR para la distribución.

12.5 ¿Y 7-Zip y ZIP?

La sección 11.7 mide también nikpak 1.2 frente a 7-Zip 23.01 e Info-ZIP 3.0. En resumen:

• Elija nikpak -m5 para el archivo más pequeño. Es un 2.4 a 31.7 % más pequeño que 7-Zip -mx9 en todos los conjuntos medidos: un 31.7 % en archivos de Office, un 15.9 % en texto y un 2.4 % en código fuente. Elija nikpak -m2 para copias de seguridad rápidas (56 veces más rápido que el valor por defecto de 7-Zip en código fuente). nikpak tiene además un cifrado más fuerte: 7-Zip usa AES-256 con una derivación de clave SHA-256 que no es exigente en memoria, y solo oculta los nombres de archivo con -mhe.
• Elija 7-Zip cuando el tiempo importe más en el nivel máximo (es más rápido en conjuntos grandes de Office y código fuente), cuando necesite que su nivel por defecto sea pequeño en documentos, o cuando necesite abrir los muchos formatos que lee 7-Zip.
• Elija ZIP solo por compatibilidad. Todo sistema operativo lo abre sin software adicional, pero nikpak -m5 es un 19.9 a 60.4 % más pequeño, y el cifrado tradicional de ZIP es débil.

13 Compilar, desplegar e integrar

13.1 Windows con PowerShell

nikpak está escrito en Rust y se compila con Cargo. En Windows, Rust necesita un enlazador de C/C++, que procede de las Visual Studio Build Tools. En un PowerShell de administrador, instale ambos una vez y vuelva a abrir PowerShell:

winget install Rustlang.Rustup

$o = '--wait --passive --add Microsoft.VisualStudio.Workload.VCTools'

$o += ' --includeRecommended'

winget install Microsoft.VisualStudio.2022.BuildTools --override $o

Si winget no está disponible, instale Rust desde rustup.rs y las Build Tools for Visual Studio con la carga de trabajo Desktop development with C++. Después, en la carpeta que contiene el código fuente:

.\build.ps1 # builds dist\nikpak.exe and dist\unNik.exe

.\build.ps1 -Test # runs the unit tests first

# if PowerShell refuses to run scripts:

powershell -ExecutionPolicy Bypass -File .\build.ps1

build.ps1 comprueba que Cargo está instalado (y dice cómo instalarlo si no lo está), ejecuta la compilación, explica la causa habitual si falla y copia el ejecutable a dist\nikpak.exe.

El instalador de Windows

.\build.ps1 -Installer (o npm run installer) compila también el programa de instalación dist\nikpak--setup.exe con Inno Setup 6.3 o más reciente (instálelo una vez con winget install JRSoftware.InnoSetup). El script es installer\nikpak.iss; la versión se toma de Cargo.toml. Este archivo de instalación es lo que se sube a los sitios de shareware y descargas.

• Por defecto se instala solo para el usuario actual, sin derechos de administrador ni aviso de UAC, en %LOCALAPPDATA%\Programs\NikPak. Su primera página ofrece "instalar para todos los usuarios" (Program Files, necesita derechos de administrador).
• Muestra LICENSE.txt para su aceptación e instala nikpak.exe, unNik.exe, los iconos, LICENSE.txt, THIRD-PARTY-NOTICES.txt y CHANGELOG.md. Añade una entrada al menú Inicio, un icono de escritorio opcional y, si se pide, la carpeta al PATH para la línea de comandos. Registra un desinstalador en Configuración > Aplicaciones.
• Accesos directos: NikPak, unNik y la licencia en el menú Inicio; NikPak en el escritorio (siempre) y unNik en el escritorio como opción.
• Los archivos .nik siempre se registran (desde 1.5.2): reciben su propio icono (nikfile.ico, una página con una cremallera, como los archivos .zip), el nombre de tipo "archivo de NikPak", y un doble clic los abre en unNik ("Abrir con unNik" en el menú contextual). unNik también aparece en "Abrir con" y en Aplicaciones predeterminadas. El desinstalador elimina el registro. Si los archivos .nik ya estaban configurados para abrirse con otro programa, Windows conserva esa elección hasta que se elija unNik una vez en "Abrir con".
• El "Iniciar NikPak" final inicia NikPak como usuario normal, nunca como administrador, para que arrastrar y soltar funcione. Las actualizaciones se instalan sobre la versión anterior (AppId fijo). La licencia en %APPDATA%\nikpak se conserva al actualizar y al desinstalar. El instalador nunca contiene claves ni archivos de claves.
• El instalador se ejecuta en inglés o francés, siguiendo a Windows. Antes de publicar, firme nikpak.exe y el instalador con un certificado de firma de código, para que Windows SmartScreen no advierta sobre un editor desconocido.

buildall.ps1 compila todo lo que se publica en una sola ejecución — nikpak.exe, unNik.exe, los dos instaladores y SHA256SUMS.txt — los copia en binaries\, reconstruye el sitio web y lo sube por FTP (-NoUpload omite la subida). El segundo instalador, unnik--setup.exe (installer\unnik.iss), instala solo unNik, el explorador de archivos gratuito; cuando NikPak ya está instalado, solo instala el programa, de modo que los menús nunca se duplican.

13.2 Compilar con npm

Los proyectos de Rust no usan npm, de modo que nunca se requiere npm. Por comodidad, el proyecto contiene un pequeño package.json cuyos scripts simplemente llaman a Cargo, para que un desarrollador que vive en un flujo de trabajo de Node.js pueda escribir comandos familiares:

npm run build # cargo build --release

npm run dist # build.ps1 -> dist\nikpak.exe

npm test # cargo test --release

npm run clean # cargo clean

13.3 Un ejecutable autónomo

El archivo .cargo/config.toml enlaza estáticamente el runtime de C para los objetivos MSVC de Windows. El nikpak.exe resultante (varios MB con la interfaz gráfica, unos 2.3 MB sin ella) no tiene por tanto dependencias de DLL y no necesita el Visual C++ Redistributable en las máquinas donde se ejecuta. Cópielo a una carpeta del PATH para usarlo en cualquier lugar. El perfil release activa la optimización completa, la optimización en tiempo de enlace, una única unidad de generación de código, la eliminación de símbolos y panic = abort para un binario pequeño y rápido.

13.4 macOS y Linux

./build.sh # builds and copies the result to dist/nikpak

# or: cargo build --release

sudo cp dist/nikpak /usr/local/bin/

En macOS instale primero las herramientas de línea de comandos (xcode-select --install); en Debian o Ubuntu instale un compilador de C (sudo apt install build-essential). Rust se instala con curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh. La biblioteca de compresión la compila Cargo a partir de sus fuentes en C, de modo que no se necesita ninguna biblioteca del sistema.

Las descargas de macOS y Linux del sitio las crea ./package-unix.sh, que compila nikpak y unNik y los empaqueta con un install.sh en binaries\nikpak--macos.zip (un binario universal: Intel + Apple silicon) o binaries\nikpak--linux-.tar.gz. Establezca ZIG=1 en Linux para compilar con cargo-zigbuild contra glibc 2.28, de modo que los programas también funcionen en distribuciones antiguas.

13.5 Dependencias

Desde la versión 1.2, nikpak necesita Rust 1.89 o más reciente. build.ps1 y build.sh comprueban la versión instalada y ejecutan rustup update stable cuando es más antigua. Con npm, ejecute rustup update una vez antes de npm run build.

nikpak depende de un pequeño conjunto de crates maduras. Sus versiones exactas están fijadas en Cargo.lock, que forma parte del paquete de código fuente, de modo que cada compilación usa el mismo código.

Crate	Propósito
zstd	Compresión Zstandard, con multihilo
chacha20poly1305	XChaCha20-Poly1305 y la construcción STREAM (RustCrypto)
argon2	Derivación de clave Argon2id (RustCrypto)
rand	Acceso al generador aleatorio seguro del sistema operativo
zeroize	Borrado de claves y contraseñas de la memoria
rpassword	Lectura de una contraseña sin eco, en todas las plataformas
crc32fast	CRC32 rápido
glob	Expansión de comodines (PowerShell no expande los comodines para programas nativos)
liblzma	Motor LZMA2 para -m5 (liblzma, compilada estáticamente a partir de fuentes C)
ppmd-rust	Motor PPMd variante I para texto en -m5
preflate-rs	Recompresión Deflate exacta bit a bit (Microsoft, Apache-2.0); una copia incorporada en vendor/preflate-rs cuyo codificador de entropía LGPL (cabac) se sustituye por el codificador de rango propio de nikpak, de modo que nikpak no contiene código LGPL. Requiere Rust 1.89 o más reciente
eframe / egui	La interfaz gráfica (característica opcional de cargo gui, activada por defecto)
rfd	Diálogo nativo de carpeta para Examinar
ed25519-dalek	Verificación de las firmas de las claves de licencia (sección 3.8)
rustybuzz, unicode-bidi	Conformado y ordenación de derecha a izquierda del hindi, bengalí y árabe en la ventana (característica opcional de cargo gui)

13.6 Scripts

Los códigos de salida predecibles y la contraseña por variable de entorno hacen que nikpak sea fácil de automatizar con scripts. Una copia de seguridad en PowerShell que trata las advertencias como aceptables y cualquier cosa peor como un fallo:

$archive = "D:\Backups\docs-$(Get-Date -Format yyyy-MM-dd).nik"

# the password comes from a file or secret store, not from the script

$env:NIKPAK_PASSWORD = Get-Content "$env:USERPROFILE\.nikpak-secret"

nikpak a -p -m3 -inul $archive "$env:USERPROFILE\Documents"

if ($LASTEXITCODE -gt 1) { throw "nikpak failed: $LASTEXITCODE" }

nikpak t -inul $archive # verify what was written

if ($LASTEXITCODE -ne 0) { throw "archive verification failed" }

Lo mismo en un script de shell, usando el comando de listado escueto para alimentar otras herramientas:

export NIKPAK_PASSWORD="$(cat ~/.nikpak-secret)"

nikpak a -p -m3 -inul "backup-$(date +%F).nik" ~/Documents || [ $? -eq 1 ]

nikpak lb backup-2026-10-16.nik | grep -i '\.wav$'

13.7 Total Commander

La integración descrita en la sección 3.6 se basa en que nikpak siga la sintaxis de RAR. Una lista de comprobación breve: registre la extensión nik; use a para empaquetar y x para desempaquetar; deje que el front-end pase @listfile para listas largas de archivos; dé -o+ o -y para la extracción desatendida; y pase la contraseña con -p o la variable NIKPAK_PASSWORD, ya que un front-end gráfico no tiene consola en la que preguntar.

14 Pruebas y verificación

Como un archivador guarda los datos de las personas, nikpak se prueba en cuatro niveles.

14.1 Pruebas unitarias

Treinta y cuatro pruebas automatizadas se ejecutan con cargo test --release:

Área	Qué se comprueba
Flujo de cifrado	Idas y vueltas en 0, 1, 100, 65,535, 65,536, 65,537, 131,072, 131,077 y 327,803 bytes (alrededor de los límites de fragmento de 64 KiB); una cabecera incorrecta (datos asociados), una clave incorrecta y el truncamiento deben fallar todos.
Límites de la derivación de clave	Los parámetros Argon2id hostiles (memoria enorme, cero pasadas, cero líneas, pasadas excesivas) se rechazan.
Códec de audio NAC	Ida y vuelta sin pérdida para audio de 8/16/24/32 bits, 1, 2, 3 y 6 canales, nueve tipos de señal (silencio, seno ruidoso, ruido blanco, onda cuadrada a plena escala, rampa, impulso único, máximo constante, bits bajos desperdiciados, mínimo constante), ocho longitudes de bloque de 1 a 5000 muestras, tres niveles de esfuerzo y codificación verbatim forzada.
Métodos de audio	NAC, Shuffle y Shuffle+Delta en todas las profundidades de bits, números de canales, órdenes de bytes y signos, incluidos los bloques que no se dividen de manera uniforme.
Detección y archivos	WAV (mono, estéreo, 8/16/24/32 bits, extensible, seis canales, fragmentos finales, bytes sobrantes impares, longitud de datos nula y desmesurada), AIFF, MOD (también truncado) y BMP (8/24/32 bits, relleno de filas, datos finales); el WAV de coma flotante, los archivos diminutos y el texto no deben detectarse; cada archivo hace la ida y vuelta por cada filtro aplicable.
Robustez	Miles de bloques aleatorios y con bits invertidos suministrados al decodificador de audio y al decodificador de medios: deben devolver errores, nunca entrar en pánico ni agotar la memoria.
Encuadre y auxiliares	Encuadre de fragmentos con datos finales, saneamiento de rutas, coincidencia de comodines y filtros, formato de fechas y generación de contraseñas.
Recompresión Deflate	Contenedores ZIP en niveles Deflate 1, 3, 6 y 9, PDF con dos flujos zlib, gzip de tres miembros, no contenedores; 400 flujos recompimidos dañados o truncados deben fallar limpiamente (los pánicos de preflate se capturan).
Bloques multimotor	Idas y vueltas por bloques zstd, LZMA2 y PPMd alrededor del límite de trama de 256 KiB; 300 cuerpos dañados o truncados; parámetros de motor hostiles; la prueba PPMd/LZMA2.
Interfaz gráfica	Ejecutado en una pantalla virtual (Xvfb): pantallas de reposo, paso del ratón, progreso y finalización comprobadas visualmente; una carpeta soltada archivada y extraída byte a byte; Cancelar y cerrar durante la compresión no dejan ningún archivo atrás; sin pantalla se recurre al texto de uso.
Licencia	Las claves hechas por nikpak-keygen y por el kit PHP son idénticas y se aceptan; un nombre, correo electrónico, tipo o clave modificados, y las claves firmadas por otra clave, se rechazan. En una pantalla virtual: recordatorio en ambos órdenes de botones, error de clave incorrecta, registro correcto, reinicio sin recordatorio; el texto permanece dentro de las cajas.
Idiomas	Cada idioma traduce todos los textos con los mismos marcadores de posición; los signos vocálicos devanagari y la unión del árabe se conforman; en una pantalla virtual se comprobaron los diez idiomas pantalla por pantalla (recordatorio, reposo, progreso, finalización, Acerca de, registro, menú de idiomas); elegir un idioma lo guarda y reinicia nikpak en él.
API del archivo	Lectura del índice, extracción de un archivo del interior de una carpeta (aterriza sin la ruta de la carpeta), eliminación de una carpeta con su contenido y eliminación de todo, para archivos -m5, zstd + cifrado y almacenados; una contraseña incorrecta se notifica como tal.
Explorador de archivos	Construcción del árbol con carpetas implícitas, detección y decodificación de texto (UTF-8, UTF-16, Windows-1252), ajuste de línea y búsqueda en el visor. En una pantalla virtual: apertura, contraseña, navegación, selección, búsqueda, visor, extracción, eliminación y comprobación, en varios idiomas.
Temas y menú del gestor de archivos	Los archivos de menú de Linux se generan y comprueban; un archivo para una selección iniciada como tres programas; --add-here con tres elementos y --extract-here / --extract-to en una pantalla virtual; los archivos cifrados piden su contraseña y extraen archivos idénticos; cada texto nuevo de la interfaz se traduce en los diez idiomas (la aserción de que cada idioma traduce todos los textos).

14.2 Pruebas de extremo a extremo

• Cada archivo de los puntos de referencia se extrajo y se comparó con su fuente, byte a byte (SHA-256 para el conjunto de 10.949 archivos), en varios niveles.
• Un archivo mixto (WAV, MOD, BMP, texto, datos aleatorios, subcarpetas) se creó, listó, comprobó, extrajo por completo, y un único archivo se extrajo de su mitad.
• El mismo archivo se creó con cifrado, se comprobó con la contraseña correcta e incorrecta y se extrajo.
• Los archivos escritos por la versión de formato anterior (1.0) los abrió la 1.1.
• La entrada interactiva de contraseña se ejercitó mediante un pseudoterminal: contraseñas coincidentes, una discrepancia, una entrada vacía (generación), contraseñas correctas e incorrectas al abrir.

14.3 Pruebas de ataque

Manipulación, truncamiento, reordenación de fragmentos, manipulación de cabeceras, archivos basura y los archivos de recorrido de rutas de la sección 10.1 se ejecutaron contra cada candidato a versión. Los resultados se tabulan en las secciones 8.6 y 10.1; el resultado esperado en cada caso es un rechazo, un mensaje claro y un código de salida distinto de cero, nunca un pánico y nunca una escritura fuera del destino.

14.4 Defectos encontrados por las pruebas

La campaña de pruebas es la razón por la que varios defectos no existen en el programa publicado. Dos ejemplos: una búsqueda del parámetro Rice que fallaba para audio de 32 bits y habría escrito un código de varios gigabytes (encontrado por la matriz de pruebas unitarias y corregido), y un fallo de suma de comprobación de zstd que se notificaba con el código de salida genérico 2 en lugar de 3 (encontrado en las pruebas de manipulación y corregido). Un tercer ejemplo es la propia metodología de los puntos de referencia: la primera comparación con RAR usó su valor por defecto no sólido, lo que favorecía a nikpak en código fuente; se rehizo en modo sólido, y los resultados del capítulo 11 son los corregidos.

15 Limitaciones y hoja de ruta

15.1 Limitaciones actuales

Limitación	Detalle y solución alternativa
Sin registros de recuperación, volúmenes ni SFX	Los daños se detectan, no se reparan (guarde una segunda copia de los archivos importantes); divida los archivos grandes con una herramienta general si es necesario.
Sin actualización in situ	El formato es un único flujo sólido. Eliminar (nikpak d, o Eliminar en unNik) vuelve a escribir el archivo; añadir archivos a un archivo existente no está soportado: cree un archivo nuevo, o sobrescriba con -o+.
Acceso secuencial	Extraer un archivo de un archivo muy grande lee lo que lo precede (las entradas de medios se saltan sin decodificar); unNik deja de leer después del último archivo elegido.
Cobertura de medios	WAV y AIFF de PCM entero, ProTracker MOD, BMP sin comprimir. El WAV de coma flotante, ADPCM, XM/S3M/IT y las imágenes comprimidas se almacenan con compresión normal.
Memoria en niveles altos	Los archivos -m4 y -m5 usan una ventana de 128 MiB; descomprimirlos necesita esa cantidad de memoria.
Nivel máximo -m5	Single-threaded and the slowest level. Creating needs up to about 1.1 GB of memory, extracting up to about 350 MB.
Enlaces simbólicos y fechas	Los enlaces se omiten al archivar y se rechazan al extraer; las fechas se muestran en UTC.
Revisión de seguridad	Sin auditoría independiente.
Compilaciones de Windows y macOS	Desarrollado, probado y evaluado en Linux. Las rutas de código específicas de Windows y macOS se revisaron a mano, pero aún no se han ejercitado en esos sistemas: ejecute allí cargo test --release antes de confiar en una compilación.

15.2 Hoja de ruta

Elemento	Propósito
Registros de recuperación	Paridad Reed-Solomon para que los archivos dañados puedan repararse, la principal característica que echan de menos los usuarios de RAR.
Archivos multivolumen y soporte de actualización	División de archivos grandes, adición y sustitución de archivos.
Intercambio de clave pública con un esquema híbrido	Cifrar un archivo para la clave de un destinatario con X25519 combinado con ML-KEM, seguro si cualquiera de los componentes se mantiene.
Más filtros de medios	Audio de coma flotante, trackers XM/S3M/IT, recompresión de PNG, un filtro 2-D para TGA y TIFF sin comprimir.
Lectura de ZIP y RAR, integración en el shell	Desempaquetar los formatos comunes en unNik y arrastrar archivos fuera de unNik, para que nikpak pueda ser la única herramienta instalada. (Los menús contextuales de Explorer y Finder llegaron en 1.5.5, sección 3.11.)
Nivel máximo más rápido	-m5 es de un solo hilo y hasta tres veces más lento que 7-Zip -mx9 en archivos de Office: bloques LZMA2 y PPMd multihilo, deduplicación de archivos idénticos y un filtro BCJ para ejecutables.
Revisión de seguridad externa	Una auditoría independiente del código criptográfico y del extractor.

Licencia: NikPak es shareware de código cerrado, © 2026 Nicolas Choukroun, distribuido por Nikkoid LLC (LICENSE.txt, sección 3.8); unNik es freeware (sección 3.9). Los componentes de código abierto que contiene se enumeran con sus licencias en THIRD-PARTY-NOTICES.txt, que debe distribuirse con cada copia. Mantenga la clave de licencia privada (keys/nikpak-private.key) fuera de todo paquete publicado y fuera de la raíz web. Mantenga Cargo.lock en el repositorio para que las compilaciones sean reproducibles, y ejecute cargo test --release en el trabajo de integración continua de cada plataforma que soporte.

A Apéndice A: constantes y límites del formato

Elemento	Valor
Número mágico	89 4E 49 4B 0D 0A 1A 0A
Versión del formato	3 (los lectores aceptan 1, 2 y 3)
Tamaño de la cabecera	12 bytes; 59 bytes cuando está cifrada
Tipos de registro	0 END, 1 FILE, 2 DIR, 3 MEDIA
Métodos de archivo	0 almacenar, 1 Zstandard, 2 bloques multimotor
Motores de bloque	1 Zstandard; 2 LZMA2 (diccionario de hasta 128 MiB escrito, 1.5 GiB aceptado); 3 PPMd8 (orden 8, 192 MiB escrito; orden 2-16, 1 GiB aceptado)
Recompresión Deflate	ZIP, PDF, gzip; archivo de hasta 512 MiB; por flujo hasta 512 MiB de datos simples y 64 MiB de correcciones
Longitud máxima de nombre	4096 bytes
Fragmento cifrado	64 KiB de texto claro + etiqueta de 16 bytes, longitud u32 big endian delante
Argon2id (escrito)	64 MiB, 3 pasadas, 4 líneas, sal de 16 bytes, clave de 32 bytes
Argon2id (aceptado)	memoria 8 x líneas .. 1 GiB, pasadas 1 .. 64, líneas 1 .. 64
Nonce del flujo	prefijo aleatorio de 19 bytes + contador de 32 bits + indicador final de 1 byte = 24 bytes
Longitud mínima de contraseña	8 caracteres
Contraseña generada	24 caracteres, alfabeto de 56 símbolos, unos 139 bits
Tamaño mínimo de archivo de medios	8 KiB (región de al menos 4 KiB)
Bloque NAC	4096 tramas de muestras; bloque Shuffle de 32768 tramas
Prueba	hasta tres ventanas de 768 KiB (5 %, 45 %, 85 %); toda la región si es de hasta 3 MiB; margen del 2 %
Límite de región BMP	256 MiB
Ventana Zstandard	por defecto; 2^27 con coincidencia a larga distancia en -m4 y -m5
Hilos	1 .. 256 (-mt)

B Apéndice B: glosario

Término	Significado
AEAD	Cifrado autenticado con datos asociados: cifra y detecta cualquier modificación, también de los datos que se envían en claro (como la cabecera).
Argon2id	Una función de derivación de contraseñas exigente en memoria, estandarizada en RFC 9106; convierte una contraseña en una clave con un coste de memoria deliberadamente alto.
CRC32	Una suma de comprobación de 32 bits que detecta daños accidentales. No es una función de seguridad.
FSE	Entropía de estados finitos: el codificador de entropía basado en tablas que usa Zstandard.
Algoritmo de Grover	Un algoritmo de búsqueda cuántico con una aceleración cuadrática; reduce a la mitad la longitud efectiva de las claves simétricas.
LPC	Codificación predictiva lineal: predecir una muestra a partir de una suma ponderada de las anteriores.
Levinson-Durbin	Una recursión que calcula coeficientes predictores óptimos de cada orden a partir de la autocorrelación de una señal.
LZMA2	El algoritmo de cadena Lempel-Ziv-Markov que usan 7-Zip y xz: coincidencia LZ77 con análisis óptimo y un codificador de rango binario.
MED	Detector de bordes por mediana: un predictor de píxeles del codificador de imágenes LOCO-I / JPEG-LS.
Exigente en memoria	Una función cuyo coste lo domina la memoria, lo que limita la aceleración disponible con GPU y chips personalizados.
NAC	El códec de audio sin pérdida de nikpak.
PPMd	Predicción por Coincidencia Parcial (variante I): predice cada byte a partir de los hasta 8 bytes anteriores; muy potente en texto.
preflate	Un método (y una biblioteca) que convierte un flujo Deflate en sus datos simples más pequeñas correcciones, a partir de las cuales se puede reconstruir el flujo Deflate idéntico.
Codificación Rice	Un código simple y rápido para números con una distribución aproximadamente geométrica: un cociente unario y un número fijo de bits bajos.
Algoritmo de Shor	Un algoritmo cuántico que factoriza enteros y calcula logaritmos discretos, rompiendo RSA y la criptografía de curvas elípticas.
Archivo sólido	Un archivo comprimido como un flujo continuo único, de modo que se puede aprovechar la redundancia entre archivos.
STREAM	Una construcción que cifra un mensaje largo como fragmentos autenticados con contador e indicador de último fragmento en el nonce.
Transformación zig-zag	Transformación de enteros con signo a sin signo (0, -1, 1, -2 ... a 0, 1, 2, 3 ...), de modo que las magnitudes pequeñas se convierten en números pequeños.
Zstandard	Un formato de compresión abierto y moderno que combina la coincidencia LZ77 con la codificación de entropía Huffman y FSE.

Versión 1.6.2 · octubre de 2026 Página 19