Guide technique

1 Introduction

nikpak est un archiveur en ligne de commande pour le format .nik. Il a été conçu autour de quatre idées : compresser mieux que les outils établis, le faire plus vite, protéger les données avec une cryptographie moderne, et fonctionner à l'identique sur Windows, macOS et Linux sous la forme d'un seul petit exécutable.

1.1 Objectifs de conception

• Compact. Battre RAR 7 sur les données que les gens archivent réellement en masse. L'audio, les images et la musique tracker sont détectés par leur contenu et compressés avec des codecs sans perte spécialisés ; tout le reste utilise un flux Zstandard réglé et multi-thread.
• Rapide. La compression et l'extraction doivent être limitées par le disque, pas par le processeur. À son niveau rapide -m2, nikpak archive environ 200 MB de fichiers source en moins d'une seconde sur un seul cœur.
• Sûr. Chiffrement authentifié avec une fonction de dérivation de clé à coût mémoire élevé, noms de fichiers toujours masqués, altération toujours détectée, et un extracteur qui ne peut pas être amené à écrire en dehors de son dossier de destination.
• Résistant au quantique. Seule une cryptographie symétrique de 256 bits est utilisée. Il n'y a ni RSA, ni courbe elliptique, ni code Diffie-Hellman nulle part dans nikpak, donc l'algorithme de Shor n'a rien à casser.
• Portable et scriptable. Un seul exécutable lié statiquement, une ligne de commande compatible RAR, des codes de sortie prévisibles, et un -help qui documente chaque option.

1.2 Résultats en un coup d'œil

Mesure	Résultat	Comparé à
Photographies BMP	38.8 % plus petit	RAR 7.00 -m5
Musique stéréo, 44.1 kHz 16 bits	14.6 % plus petit (à égalité avec FLAC -8)	RAR 7.00 -m5
Fichiers MOD ProTracker	13.3 % plus petit	RAR 7.00 -m5
Audio mono, 8 bits et 16 bits	12.2 % et 15.3 % plus petit	RAR 7.00 -m5
197 MB de fichiers source, niveau maximal	5.5 % plus petit (24.4 MB contre 25.9 MB)	RAR 7.00 -m5 -s -md256m
Mêmes données, niveau rapide -m2	0.9 s	RAR 7.00 -m3 solide : 16.7 s
Chiffrement	Argon2id + XChaCha20-Poly1305	RAR5 : AES-256-CBC + PBKDF2
Les 10 jeux de test, niveau maximal, contre 7-Zip	2.4 à 31.7 % plus petit	7-Zip 23.01 -mx9 (section 11.7)
Fichiers Office (doc, docx, xls, xlsx, csv, pdf)	31.7 % plus petit	7-Zip 23.01 -mx9 (section 11.7)
Les 10 jeux de test, niveau maximal, contre ZIP	19.9 à 60.4 % plus petit	ZIP -9, Info-ZIP 3.0 (section 11.7)
Exécutable	un seul fichier, aucune dépendance ; environ 9 MB avec la fenêtre, 2.3 MB en ligne de commande seule	Windows, macOS, Linux

Comment les chiffres ont été obtenus Toutes les mesures proviennent d'une seule machine (machine virtuelle Linux x86-64, un seul cœur de processeur) avec RAR 7.00 et nikpak 1.1.0. Chaque archive a été extraite à nouveau et comparée à l'original octet par octet. La méthode complète, les corpus et les cas où RAR est plus rapide sont décrits au chapitre 11.

1.3 À qui s'adresse-t-il ?

nikpak s'adresse à ceux qui archivent de grandes quantités de médias ou de code source et qui attachent de l'importance à la taille et à la vitesse, aux développeurs qui veulent un archiveur scriptable avec des codes de sortie sains et un format documenté, et à quiconque a besoin d'un chiffrement fort sans faire confiance à une implémentation fermée. Comme la ligne de commande suit les conventions de RAR, des frontaux tels que Total Commander peuvent le piloter avec peu ou pas de reconfiguration.

1.4 Comment lire ce guide

Les chapitres 2 et 3 décrivent ce que fait nikpak et comment l'utiliser. Les chapitres 4 à 7 expliquent l'architecture, le format de fichier, le moteur de compression et les codecs média. Les chapitres 8 à 10 traitent du chiffrement, de la résistance quantique et du durcissement. Le chapitre 11 présente les benchmarks, le chapitre 12 compare honnêtement nikpak à RAR, et les chapitres 13 à 15 traitent de la compilation, des tests et de la feuille de route.

1.5 Communauté et contact

Actualités, questions, idées et signalements de bugs : l'auteur de nikpak est joignable sur

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

Les trois mêmes liens sont affichés sous forme de boutons ronds et colorés en bas de la fenêtre de nikpak, sous le dossier de destination (section 3.7), et à la fin de nikpak -help.

2 Vue d'ensemble des fonctionnalités

2.1 Capacités

Domaine	Ce que fournit nikpak
Compression	Zstandard (multi-thread, solide) de -m1 à -m4, avec une fenêtre de 128 MiB et une correspondance longue distance à -m4. À -m5, un corps multi-moteur : LZMA2 pour les données binaires et PPMd pour le texte, choisis par essai ; fichiers triés par type comme dans 7-Zip.
Intelligence des médias	Détection par contenu de WAV, AIFF, ProTracker MOD et BMP ; essai par fichier entre quatre filtres (NAC, Shuffle, Shuffle+Delta, MED) ; repli automatique vers la compression simple.
Office, PDF, gzip	Recompression Deflate (preflate) : les flux Deflate dans les fichiers docx, xlsx, pptx, odt, ods, epub, jar, zip, pdf et gz sont décodés, bien mieux compressés et reconstruits bit à bit à l'extraction (-m4, -m5).
Chiffrement	Dérivation de clé Argon2id (64 MiB), XChaCha20-Poly1305 en blocs authentifiés de 64 KiB ; les noms, tailles, dates et permissions sont chiffrés.
Mots de passe	Invite interactive avec confirmation, variable d'environnement, stdin, ligne de commande ; génération automatique d'un mot de passe aléatoire fort lorsqu'aucun n'est fourni.
Intégrité	CRC32 des octets d'origine de chaque fichier ; authentification AEAD pour les archives chiffrées ; marqueur de fin avec le nombre d'entrées ; codec audio auto-vérificateur.
Ligne de commande	Commandes de style RAR (a x e l v lb t p d), extraction de fichiers uniques, de dossiers ou par caractères génériques, et commutateurs, alias de style zip, caractères génériques, @listfiles, exclusions, politiques d'écrasement, mode silencieux, codes de sortie explicites.
Sécurité	Protection contre le zip slip, refus des liens symboliques, suppression du setuid, décodeurs bornés, écritures atomiques d'archive, sûreté mémoire de Rust.
Portabilité	Windows (PowerShell, cmd), macOS, Linux ; exécutable statique unique ; résultats octet pour octet identiques sur toutes les plateformes.
Interface graphique	Lancé sans arguments, nikpak ouvre une fenêtre de dépôt minimaliste : déposez (ou choisissez) des fichiers ou des dossiers pour les compresser avec la meilleure compression ; anneau de progression, dossier de destination mémorisé (section 3.7).
Explorateur d'archives	unNik.exe, gratuit pour tous : parcourir les dossiers, rechercher, afficher des fichiers texte et binaires, extraire une sélection et supprimer des fichiers dans les archives .nik (section 3.9).
Skins	55 skins de fenêtre, dont 14 skins de scènes peintes ; une boîte de skins qui se place à côté de la fenêtre avec Appliquer le skin et Annuler ; importez vos propres fichiers .skin.json Nikkomander (section 3.10).
Menu du gestionnaire de fichiers	Un sous-menu « NikPak » dans Explorer, Dolphin, Nemo, Nautilus et Finder : Ajouter à l'archive, Extraire ici, Extraire dans son propre dossier, Ouvrir avec unNik ; une seule archive pour une sélection de plusieurs éléments (section 3.11).

2.2 nikpak et RAR côte à côte

Le tableau ci-dessous compare nikpak 1.1 à RAR 7 tel que mesuré dans ce projet, et indique clairement où RAR est en avance. Le chapitre 12 discute des différents points.

	nikpak 1.1	RAR 7
Compression des médias	Codecs sans perte spécialisés choisis par fichier par essai	Algorithme général avec filtres intégrés
Code source, niveau maximal	24.4 MB (plus petit), 45.6 s	25.9 MB, 26.7 - 36.2 s
Vitesse aux niveaux rapides	0.9 s pour 197 MB (-m2)	9.7 - 16.7 s (-m3)
Chiffrement	Argon2id + XChaCha20-Poly1305 (authentifié)	AES-256-CBC + PBKDF2-HMAC-SHA256
Noms de fichiers toujours chiffrés	Oui	Uniquement avec -hp
Hachage de mot de passe à coût mémoire élevé	Oui (64 MiB)	Non
Générateur de mot de passe aléatoire	Intégré	Non intégré
Code source, langage	Code source complet, Rust (sûr en mémoire)	Propriétaire, C++
Enregistrements de récupération, volumes, SFX, mise à jour sur place	Pas encore	Oui (WinRAR)
Historique éprouvé	Nouveau, pas encore audité	Des décennies

3 Référence de la ligne de commande

nikpak suit la syntaxe que connaissent les utilisateurs de RAR : nikpak [options] [files...]. Les options peuvent apparaître n'importe où, avant le nom de l'archive ou après ; -- met fin à l'analyse des options.

3.1 Commandes

Commande	Signification
a	Crée une nouvelle archive. .nik est ajouté lorsque le nom n'a pas d'extension. Les dossiers sont toujours parcourus récursivement.
x	Extrait avec les chemins complets : tout, ou seulement les noms, dossiers et caractères génériques indiqués après le nom de l'archive (nikpak x backup.nik Docs/report.pdf extrait un fichier). Un séparateur de chemin final (ou -d dir) sélectionne la destination.
e	Extrait sans les chemins : chaque fichier va directement dans le dossier de destination.
l	Liste le contenu (tout, ou seulement les noms correspondants) : attributs, taille, date (UTC), nom, totaux.
v	Liste détaillée : ajoute le CRC32 de chaque fichier.
lb	Liste brute : un nom par ligne, conçue pour les scripts et les frontaux graphiques.
t	Test : décompresse tout, vérifie chaque CRC32 et, pour les archives chiffrées, vérifie l'authentification.
p	Imprime les fichiers sur la sortie standard : tous, ou ceux nommés (nikpak p notes.nik todo.txt | more).
d	Supprime des fichiers ou des dossiers (un dossier emporte son contenu) d'une archive. L'archive est réécrite sans eux ; les archives chiffrées conservent leur mot de passe. Les noms sont obligatoires.
mt	Test des médias : détecte les fichiers WAV/AIFF/MOD/BMP et affiche la taille atteinte par chaque filtre média. N'écrit rien.
(none)	Lancé sans aucun argument (par exemple par un double-clic sur nikpak.exe), nikpak ouvre sa fenêtre à la place (section 3.7).

3.2 Options

Style RAR	style zip	Signification
-p	-e	Chiffre / déchiffre, demande le mot de passe. Une saisie vide génère un mot de passe aléatoire et l'affiche.
-p	-P	Mot de passe sur la ligne de commande (visible par les autres utilisateurs de la machine).
-hp[password]		Identique à -p. Les noms de fichiers sont toujours chiffrés dans nikpak.
-m0 .. -m5	-0 .. -9	Stockage, le plus rapide, rapide, bon, élevé (ajoute la recompression Deflate), maximal (valeur par défaut depuis 1.2.1 ; LZMA2/PPMd, section 6.7). Utilisez -m2 quand la vitesse compte plus que la taille.
-mt		Nombre de threads, de 1 à 256 (par défaut : tous les cœurs).
-mc- / -mc+		Tous les filtres de contenu (codecs média et recompression Deflate) désactivés / filtres média toujours activés. Par défaut : essai automatique par fichier.
-r		Parcourt les dossiers récursivement (toujours activé, accepté pour la compatibilité).
-ep	-j	Stocke uniquement le dernier composant de chemin de chaque argument.
-ep1		Ne stocke pas le nom du dossier de base d'un argument de dossier.
-o+	-o	Écrase les fichiers existants sans demander.
-o-	-n	Ignore les fichiers existants sans demander.
-or		Renomme les fichiers extraits qui existent déjà : name (1).ext.
-y		Suppose Oui à chaque question.
-x	-x	Exclut des fichiers ; peut être répété.
-d	-d	Dossier de destination pour x et e.
-inul -idq	-q	Silencieux : seules les erreurs sont affichées.
@listfile		Lit les noms de fichiers depuis un fichier texte, un par ligne.
-h -help -?		Aide complète. -V affiche la version.

Les options que les frontaux RAR envoient couramment mais qui n'ont pas de signification ici (-s, -ma5, -md64m, -ibck, -idp, -rr, -ts*, -w et similaires) sont acceptées et ignorées, de sorte que les configurations d'outils existantes continuent de fonctionner. Tout le reste produit un message d'erreur clair et le code de sortie 7.

Le menu du gestionnaire de fichiers ajoute quelques options longues (section 3.11) : nikpak --add et --add-here compressent les éléments donnés dans une nouvelle archive, nikpak --install-menu et --uninstall-menu ajoutent ou retirent le menu contextuel (--all-users pour une installation pour tous les utilisateurs), et unNik --extract, --extract-here et --extract-to pilotent l'extraction depuis le menu.

3.3 Les mots de passe en détail

Lorsqu'une archive est créée avec -p, nikpak résout le mot de passe dans cet ordre, et n'échoue jamais simplement parce qu'aucun n'a été fourni :

• -p ou -P sur la ligne de commande : utilisé tel quel (8 caractères minimum).
• La variable d'environnement NIKPAK_PASSWORD, qui garde le mot de passe hors de la liste des processus.
• Une invite interactive, demandée deux fois pour confirmation. Une saisie vide génère un mot de passe aléatoire.
• Sans terminal (par exemple dans une interface graphique), un mot de passe transmis via stdin ; s'il n'y en a aucun, un mot de passe aléatoire est généré.

Un mot de passe généré comporte 24 caractères issus d'un alphabet de 56 symboles sans ambiguïté (pas de 0/O, 1/l/I), soit environ 139 bits d'entropie. Il est affiché une fois dans un encadré sur la console. Il n'y a aucune récupération : une archive dont le mot de passe est perdu ne peut être ouverte par personne.

À l'ouverture d'une archive chiffrée, nikpak utilise les mêmes sources puis échoue avec le code de sortie 11 et un message explicatif ; il ne génère jamais rien, car un mot de passe généré ne pourrait pas correspondre.

3.4 Codes de sortie

Code	Signification	Cause typique
0	Succès
1	Avertissement	Certains fichiers ont été ignorés (illisible, chemin non sûr, lien symbolique)
2	Erreur fatale	Impossible de créer ou de lire un fichier, erreur interne
3	Archive corrompue ou erreur CRC	Archive endommagée ou tronquée, somme de contrôle en échec
7	Erreur de ligne de commande	Option inconnue, nom d'archive manquant
10	Aucune correspondance	Aucun fichier ne correspond aux noms ou caractères génériques
11	Mot de passe incorrect ou manquant	Mauvais mot de passe, ou archive chiffrée altérée

3.5 Exemples

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 Intégration avec Total Commander et d'autres frontaux

Parce que nikpak accepte la syntaxe de commande de RAR (a, x, e, l, t, @listfile, -p, -ep1, -o+, -y, -m), un programme capable de piloter un rar.exe externe peut piloter nikpak.exe. Dans Total Commander, enregistrez l'extension nik sous Configuration, Archiveur, Programmes d'archive supplémentaires et pointez les commandes d'empaquetage et de dépaquetage vers nikpak.exe. Utilisez -o+ ou -y pour une extraction sans surveillance, car sans console nikpak ne peut pas demander s'il faut écraser et ignorera plutôt les fichiers existants. Les noms de menus diffèrent selon les versions de Total Commander ; consultez son aide intégrée pour les champs exacts.

Dossiers avec espaces sous Windows Un chemin entre guillemets qui se termine par une barre oblique inverse, comme "C:\My Folder\", est mal analysé par Windows (le guillemet final est traité comme échappé). Pour les destinations avec espaces, utilisez plutôt -d "C:\My Folder".

3.7 L'interface graphique

nikpak lancé sans arguments, par exemple par un double-clic sur nikpak.exe, ouvre une petite fenêtre au lieu d'afficher son aide d'utilisation. Il fait une seule chose : compresser ce que vous y déposez.

• Déposez un fichier ou un dossier, ou plusieurs à la fois, sur la fenêtre, ou cliquez sur le cercle (ou sur les liens choisir des fichiers / choisir un dossier) pour les sélectionner dans une boîte de dialogue ; un clic sur le cercle fait apparaître les deux boutons Choisir des fichiers et Choisir un dossier dans l'anneau. Ils sont compressés avec la meilleure compression (-m5) dans une archive nommée d'après le fichier (sans son extension), le dossier, ou, pour plusieurs éléments, le dossier dont ils proviennent. Une archive existante n'est jamais écrasée : report.nik devient report (2).nik.
• La progression est affichée sous forme d'un grand pourcentage dans un cadran circulaire, avec la phase (analyse, compression, finition), la quantité traitée et le temps. Le bouton Annuler en dessous (ou la touche Échap) arrête immédiatement une longue compression et supprime l'archive inachevée ; la fenêtre reste ouverte pour la suivante. Fermer la fenêtre pendant une compression fait de même.
• Terminé : l'anneau devient vert et affiche le nom de l'archive, sa taille par rapport à l'original et le temps. Afficher dans le dossier l'ouvre dans Explorer, Finder ou le gestionnaire de fichiers ; Compresser davantage (ou un clic sur le cercle) démarre la suivante.
• Enregistrer dans : le dossier de destination en bas peut être saisi ou choisi avec Parcourir. Il est mémorisé pour la fois suivante (Windows : %APPDATA%\nikpak\settings.txt ; macOS : ~/Library/Application Support/nikpak ; Linux : ~/.config/nikpak). La première fois, c'est le Bureau.
• Communauté : les trois boutons ronds en bas à droite ouvrent les pages Telegram, X et Discord de nikpak (section 1.5).
• Passer à unNik : le bouton rond avec une flèche vers le haut, à gauche du bouton i, ferme NikPak et lance unNik (section 3.9). Après une compression, lui et le lien Ouvrir dans unNik sur l'écran de fin ouvrent immédiatement la nouvelle archive. Le bouton est désactivé pendant la compression.
• Ouvrir le dossier de destination : le bouton de dossier entre le champ Enregistrer dans et Parcourir ouvre ce dossier dans Explorer ou Finder ; après une compression, il l'ouvre avec la nouvelle archive sélectionnée.
• Sons : un clic doux pour les boutons, liens et options, et un son court pour chaque action (début du travail, succès, erreur, annulation, changement de programme, fichiers survolant la fenêtre). Ils sont produits par le programme lui-même, sans fichiers son. Le bouton haut-parleur dans la barre de titre les active et les désactive ; ils sont activés par défaut, et le choix est partagé avec unNik.
• Langue : le bouton en bas à gauche, avec un drapeau et le nom de la langue dans sa propre langue, ouvre un menu des dix langues les plus parlées au monde (Ethnologue 2025) : English, 中文 (mandarin), हिन्दी (hindi), Español, العربية (arabe), Français, বাংলা (bengali), Português, Русский (russe) et Bahasa Indonesia. En choisir une l'enregistre et redémarre nikpak dans cette langue. La première fois, nikpak suit la langue de Windows (ou du système), sinon l'anglais. La ligne de commande reste en anglais.
• Exécution en tant qu'administrateur : Windows ne permet pas de faire glisser des fichiers depuis Explorer vers un programme exécuté en tant qu'administrateur. Lorsque nikpak.exe est démarré en tant qu'administrateur (par exemple depuis un PowerShell administrateur), il se redémarre une fois en tant qu'utilisateur normal via Explorer afin que le glisser-déposer fonctionne. Si ce n'est pas possible, la fenêtre affiche un avis ; choisissez alors les fichiers avec les boutons.
• État et À propos : en haut à gauche s'affichent EVALUATION COPY · REGISTER (un clic ouvre la boîte d'enregistrement) ou REGISTERED TO suivi du titulaire de licence. Le petit bouton i en haut à droite, à côté de réduire et fermer, ouvre la boîte À propos : version, © 2026 Nicolas Choukroun, distribué par Nikkoid LLC, le statut de licence, le site web et les conditions de licence (LICENSE.txt).

La fenêtre mesure 500 × 560 points (environ 9:10), de sorte qu'une capture d'écran de toute la fenêtre tient dans une publication d'image X (Twitter) sans recadrage. Elle est sans cadre : faites-la glisser par sa zone supérieure ; les boutons en haut à droite ouvrent la boîte À propos, la réduisent et la ferment. Lorsque nikpak.exe est démarré depuis Explorer, la fenêtre de console que Windows ouvre pour lui est fermée automatiquement ; démarré depuis une invite de commandes, l'invite est laissée telle quelle. Sans affichage graphique (par exemple via SSH), nikpak affiche son aide d'utilisation comme avant. L'interface utilise egui/eframe et intègre des sous-ensembles des polices Inter, Noto Sans SC, Noto Sans Devanagari, Noto Sans Bengali et Noto Sans Arabic (SIL Open Font License, voir assets/fonts/OFL.txt). Un exécutable en ligne de commande seule est compilé avec cargo build --release --no-default-features.

Le hindi, le bengali et l'arabe nécessitent une mise en forme : les lettres changent de forme et se joignent, les signes vocaliques se déplacent autour de leur consonne, et l'arabe s'écrit de droite à gauche. egui dessine un glyphe par caractère, ce qui afficherait ces langues de façon incorrecte ; nikpak ordonne donc ces textes avec l'algorithme bidirectionnel Unicode (unicode-bidi), les met en forme avec rustybuzz (un portage Rust de HarfBuzz), les rasterise avec ab_glyph et peint le résultat sous forme d'image (textshape.rs). Les mots latins et les nombres qu'ils contiennent conservent la police Inter. Les longues traductions sont réduites pour tenir dans leurs boutons, et les boîtes grandissent avec leur texte. Les traductions (i18n.rs) ont été écrites avec une assistance machine ; une relecture par des locuteurs natifs est la bienvenue.

3.8 Licence et enregistrement (shareware)

NikPak est un shareware, © 2026 Nicolas Choukroun, distribué par Nikkoid LLC, et sous licence comme WinRAR : le même paquet est la copie d'évaluation gratuite et, une fois une clé de licence saisie, la version enregistrée. Rien n'est désactivé dans la copie d'évaluation.

Qui	Conditions
Particuliers	Gratuit pour un usage personnel et non commercial, sans limite de temps. Une licence personnelle ($19) supprime le rappel ; elle couvre tous les ordinateurs utilisés par le titulaire.
Entreprises et organisations	Une licence d'entreprise par poste, après une évaluation gratuite de 40 jours ; les postes sont les ordinateurs ou les utilisateurs, selon le plus élevé. Prix de volume par poste, sur le modèle de WinRAR : 1–9 postes $19, 10–24 $15, 25–49 $12, 50–99 $9, 100–199 $7, 200–499 $6, 500 et plus $5.
Distribution	Le paquet non modifié (avec LICENSE.txt et THIRD-PARTY-NOTICES.txt) peut être mis sur n'importe quel site de shareware ou de téléchargement ; ajouter des clés, des fichiers de clés ou des cracks est interdit. Les archives .nik sont libres de redevances.

• Le rappel apparaît lorsqu'une copie non enregistrée ouvre sa fenêtre. Il comporte deux boutons, S'enregistrer et Tester gratuitement, dont l'ordre gauche/droite change aléatoirement à chaque démarrage. Tester gratuitement (ou Échap) le ferme ; nikpak fonctionne alors sans restriction.
• La boîte d'enregistrement demande le nom, l'adresse e-mail et la clé de licence. Les trois doivent correspondre : la clé est une signature du nom et de l'e-mail. La casse, les espaces supplémentaires et les caractères ressemblants O/0 et I/L/1 n'ont pas d'importance. Acheter une licence ouvre https://nikpak.nikkoid.com/buy.php.
• Une fois enregistré, nikpak ne redemande plus jamais sur cet ordinateur pour cet utilisateur. La licence est stockée dans %APPDATA%\nikpak\license.txt (macOS : ~/Library/Application Support/nikpak ; Linux : ~/.config/nikpak). Une entreprise peut à la place placer un fichier nikpak.key à côté de nikpak.exe, ce qui enregistre tous les utilisateurs de ce PC.
• Ligne de commande : nikpak register "Jane Doe" jane@example.com NPK1-… enregistre ; nikpak license affiche le statut ; nikpak unregister supprime la licence. nikpak -V et nikpak -help affichent aussi le statut. Les copies non enregistrées affichent un avis d'évaluation d'une ligne sur la sortie d'erreur (stderr), jamais sur la sortie standard ; -q le supprime.

Fonctionnement des clés

Une clé de licence se lit NPK1- suivi de 108 caractères en groupes de cinq (base32 Crockford). Elle contient le type de licence (personnelle ou entreprise), le nombre de postes et une signature Ed25519 de NIKPAK-LICENSE-1, du type, des postes, du nom et de l'adresse e-mail, chacun normalisé (espaces réduits, minuscules). nikpak ne contient que la clé publique de 32 octets, dans src/license_pubkey.rs, de sorte qu'étudier le programme ne permet à personne de fabriquer des clés.

Les clés sont fabriquées avec la clé privée, qui ne quitte jamais Nikkoid LLC : soit avec l'outil privé nikpak-keygen (cargo run --release --features keygen --bin nikpak-keygen -- make --name "Jane Doe" --email jane@example.com ; --company --seats 25 pour les entreprises ; newkeys crée une nouvelle paire de clés), soit sur le serveur web avec le kit PHP dans server/ (PHP 7.2+, MySQL 5.7), qui émet une clé par paiement et produit exactement les mêmes clés. server/README.md décrit la configuration et le flux de paiement.

3.9 unNik, l'explorateur d'archives gratuit

unNik (unNik.exe) est le second programme du paquet. Il ouvre les archives .nik, montre ce qu'elles contiennent et extrait ce que vous choisissez. Il est gratuit pour tous, entreprises comprises, sans enregistrement et sans rappel (LICENSE.txt, section 2a). Le programme d'installation l'installe à côté de nikpak.exe, l'ajoute au menu Démarrer et en fait le programme pour les fichiers .nik, de sorte qu'un double-clic sur une archive l'ouvre dans unNik ; unNik archive.nik fait de même depuis une invite de commandes.

La fenêtre vide ressemble exactement à celle de NikPak, avec une flèche vers le haut dans l'anneau. Déposez une archive .nik dessus, cliquez sur l'anneau, ou choisissez l'une des archives récentes : la fenêtre s'agrandit pour devenir l'explorateur (1120 × 720, redimensionnable depuis ses bords, et pouvant être maximisé). Les archives chiffrées demandent d'abord leur mot de passe.

• Naviguez avec l'arborescence des dossiers, le fil d'Ariane, Précédent, Suivant et Monter (Alt+Gauche, Alt+Droite, Retour arrière) et les double-clics. Recherchez (Ctrl+F) trouve les fichiers par nom dans toute l'archive ; chaque résultat affiche son dossier.
• Sélectionnez avec un clic, Ctrl+clic, Maj+clic, les cases à cocher, Ctrl+A ou les touches fléchées. Cliquez sur un titre de colonne pour trier par nom, taille, type ou date. Un clic droit ouvre un menu avec toutes les actions.
• Tout extraire, ou la sélection (Ctrl+E) : choisissez la destination (par défaut un dossier nommé d'après l'archive, à côté d'elle), conservez les dossiers ou non, et choisissez quoi faire lorsqu'un fichier existe déjà : le remplacer, garder les deux (name (1).ext) ou l'ignorer. Les fichiers pris à l'intérieur d'un dossier sont créés sans le chemin de ce dossier, comme dans WinRAR. La lecture s'arrête juste après le dernier fichier choisi.
• Afficher (F3, ou un double-clic sur un fichier texte) : texte avec numéros de ligne, recherche avec surlignage, retour à la ligne et copie ; fichiers binaires en hexadécimal. Les 16 premiers MB sont affichés ; Ouvrir dans le Bloc-notes ouvre tout le fichier. Ouvrir démarre un fichier avec son propre programme (il est d'abord extrait dans un dossier temporaire).
• Supprimer (Suppr) retire des fichiers et des dossiers de l'archive après une confirmation. L'archive est solide, elle est donc réécrite sans eux, dans un fichier temporaire qui ne remplace l'original que lorsque tout a réussi. Les archives chiffrées conservent leur mot de passe ; les autres entrées conservent leur filtre média ou Deflate et leur moteur -m5.
• Tester décompresse toute l'archive et vérifie chaque fichier. Le volet détails affiche la taille, la date, le dossier, le CRC32, la façon dont le fichier est stocké et ses attributs ; pour l'archive elle-même, sa taille, sa méthode et son chiffrement. Le résumé sous l'arborescence montre l'espace économisé.
• Les mêmes dix langues, le bouton de langue, la boîte À propos (i) et les boutons de communauté que NikPak. Les noms de fichiers dans n'importe quelle écriture sont dessinés avec les polices du système en repli.
• Passer à NikPak : le bouton rond avec une flèche vers le bas, à gauche du bouton i, ferme unNik et lance NikPak. Les deux programmes se trouvent dans le même dossier. Ils partagent un seul fichier de paramètres, de sorte que la langue choisie dans l'un est utilisée par l'autre, et une fenêtre déjà ouverte suit le changement en deux secondes.
• Ouvrir le dossier de destination : le bouton à gauche du bouton d'éjection ouvre le dossier de la dernière extraction dans Explorer ou Finder (avant toute extraction, le dossier de l'archive). unNik joue les mêmes sons que NikPak, avec des sons pour l'ouverture d'une archive, l'extraction, la suppression et le test ; son bouton haut-parleur et celui de NikPak partagent un même réglage.

3.10 Skins

NikPak et unNik partagent les mêmes 55 skins de fenêtre : les 41 skins de Nikkomander — de Nikkoid Blue (par défaut) et Nikkoid Bright à Dracula, Nord, Solarized, Classic Blue, Matrix, Pizza, Christmas et 8-Bit Game — plus 14 skins peints dont les fonds sont dessinés par le programme lui-même : Moon, America, Pattaya Neons, Burgers Tokyo, Sushi, Amiga, MSX, Colecovision, ZX Spectrum, Cat Life, Dog Life, Mario Bros, Counter Strike et Chess.

• Bouton Skins (une palette, dans la barre de titre des deux programmes) : ouvre le menu des skins, où chaque skin est dessiné dans ses propres couleurs. Pointer un skin l'affiche sur toute la fenêtre ; un clic le conserve ; Échap ou un clic à l'extérieur revient au skin précédent.
• Le bouton soleil / lune à côté bascule entre Nikkoid Blue (sombre) et Nikkoid Bright en un clic.
• La boîte de skins se tient à l'extérieur du programme. Pendant que la boîte est ouverte, la fenêtre s'élargit de la largeur de la boîte, à droite : le programme conserve son panneau de 500 × 560 et la boîte se place dans l'espace transparent supplémentaire à côté, de sorte que toute l'interface reste visible derrière le skin essayé. La boîte peut être déplacée par sa barre de titre au-dessus du programme ou n'importe où ailleurs dans la fenêtre, et elle comporte des boutons Appliquer le skin et Annuler. Un clic sur un skin l'essaie sur toute la fenêtre ; Appliquer le conserve et l'enregistre pour les deux programmes ; Annuler (ou Échap ou le ×) revient au skin précédent. Un clic sur le programme ne ferme plus la boîte. La fenêtre d'unNik n'est pas élargie.
• Le skin choisi est enregistré (skin= dans le fichier de paramètres) et partagé : un skin choisi dans un programme est repris par l'autre en deux secondes.
• Vos propres skins : « Importer un skin… » en bas du menu lit un fichier .skin.json Nikkomander (un nom et une liste de couleurs) et le copie dans le dossier skins à côté du fichier de paramètres ; le × sur la vignette d'un skin importé le supprime.
• Les skins peints passent derrière l'interface. Les fonds peints sont dessinés par src/skin_scenes.rs, pas par des dégradés CSS, ils s'adaptent donc à toute taille de fenêtre. Depuis la 1.6.2, chacun passe par un traitement discreet() dans src/skin.rs : le dessin est ramené vers sa propre moyenne locale, légèrement flouté et estompé vers la couleur de fond du skin — surtout derrière l'anneau de dépôt et la colonne de texte, un peu plus au-dessus du logo — afin que le titre, l'anneau et le texte d'état restent nets sur les quatorze.

3.11 Le menu du gestionnaire de fichiers

Un sous-menu « NikPak » dans le menu contextuel du gestionnaire de fichiers, comme celui de WinRAR, est installé par le programme d'installation (Windows : une option cochée par défaut ; Linux : nikpak --install-menu ; macOS : Actions rapides du Finder).

• Sur les fichiers et dossiers : Ajouter à l'archive… (demande le nom et le dossier, puis compresse dans la fenêtre de NikPak) et Ajouter à l'archive ici (l'archive va à côté des éléments, nommée comme lors d'un dépôt sur la fenêtre).
• Sur les archives .nik : Ouvrir avec unNik, Extraire les fichiers…, Extraire ici et Extraire dans son propre dossier.
• Plusieurs éléments vont dans une seule archive ; plusieurs archives sélectionnées sont extraites l'une après l'autre dans une seule fenêtre.
• Les commandes passent par unNik.exe, de sorte qu'aucune fenêtre de console ne clignote ; les libellés suivent la langue de NikPak. Windows 10 affiche le sous-menu directement, Windows 11 sous Afficher plus d'options (Maj+F10) ; Linux ajoute des menus de service KDE Dolphin, des actions Nemo et des scripts Nautilus, et macOS ajoute les Actions rapides du Finder.
• Nouvelles options de ligne de commande utilisées par le menu : nikpak --add et --add-here (compressent les éléments donnés), nikpak --install-menu, --uninstall-menu et --all-users ; unNik --extract, --extract-here et --extract-to. Extraire ici / dans son propre dossier affiche la petite fenêtre d'unNik avec l'anneau de progression (la boîte de mot de passe pour les archives chiffrées) et la ferme lorsque tout est extrait ; les avertissements et les erreurs restent à l'écran.
• Un second programme d'installation, unnik--setup.exe, installe unNik seul (l'explorateur gratuit) pour ceux qui ne font que recevoir des archives .nik ; lorsque NikPak est déjà installé, il n'installe que le programme, de sorte que les menus ne se doublent jamais.

4 Architecture

nikpak est un programme Rust unique d'environ 9 600 lignes (tests unitaires compris) réparties sur seize fichiers source, plus l'outil privé de licence nikpak-keygen. Sa règle de conception centrale est le flux continu : les fichiers sont lus par morceaux de 256 KiB, poussés à travers une chaîne d'écrivains, et jamais conservés en mémoire en entier (les seules exceptions sont les données de pixels BMP, limitées à 256 MiB, et les tampons de travail de 64 KiB des codecs).

4.1 Flux de données lors de la création d'une archive

Chaque étage est une implémentation du trait standard Write enveloppant le suivant, de sorte que le même chemin de code sert une archive simple, une archive chiffrée et l'essai média.

4.2 Carte du code source

Fichier	Responsabilité
main.rs	Point d'entrée. Analyse les arguments, répartit la commande, convertit les erreurs en codes de sortie. Gère silencieusement un tube fermé (nikpak lb x | head).
cli.rs	Analyseur d'arguments de style RAR/zip écrit à la main, les tables d'options et le texte complet de -help. Les bibliothèques de style Clap ne peuvent pas exprimer proprement des commutateurs tels que -pSECRET ou -m5.
archive.rs	Création, listage, test, extraction (par filtres ou par un choix exact), suppression, impression et le test des médias ; également l'index et la lecture de fichier unique utilisés par unNik. Contient l'écrivain et le lecteur de flux d'entrées, la politique d'écrasement et la logique de fichier temporaire atomique.
media.rs	Détection de contenu pour WAV, AIFF, MOD et BMP ; les filtres Shuffle, Delta et MED ; sélection par essai ; aides au CRC et au découpage en blocs.
nac.rs	Le codec audio sans perte NAC : décorrélation stéréo, prédicteurs, codage des résidus.
bits.rs	Écrivain et lecteur de bits MSB-en-premier utilisés par NAC.
crypto.rs	Dérivation de clé Argon2id et l'écrivain et le lecteur de blocs XChaCha20-Poly1305.
format.rs	Constantes du format sur disque : nombre magique, versions, types d'enregistrement, limites de la KDF.
util.rs	Invite et génération de mot de passe, assainissement des chemins, correspondance de caractères génériques, formatage des dates et des tailles.
error.rs	Le type d'erreur, ses codes de sortie et la classification des erreurs d'E/S (corruption contre défaillance système).
engine.rs	Corps multi-moteur de -m5 : écrivain et lecteur de blocs, moteurs LZMA2 et PPMd, l'essai de moteur (sections 5.6, 6.7).
recomp.rs	Recompression Deflate des conteneurs ZIP, PDF et gzip avec preflate (section 7.9).
gui.rs	L'interface graphique : fenêtre de dépôt, anneau de progression, réglage de destination, liens de communauté (section 3.7).
unnik.rs	unNik, l'explorateur d'archives : arborescence, liste, recherche, visionneuse, boîtes d'extraction et de suppression (section 3.9).
lib.rs, bin/unnik.rs	La bibliothèque partagée par nikpak et unNik, et le point d'entrée de unNik.exe (un programme fenêtré, sans console).
license.rs	Licence shareware : format de clé, vérification Ed25519, stockage de la licence, enregistrement (section 3.8).
i18n.rs	Traductions de la fenêtre dans les dix langues les plus parlées ; réglage de la langue (section 3.7).
textshape.rs	Texte mis en forme pour le hindi, le bengali et l'arabe : ordre bidirectionnel, mise en forme, rasterisation (section 3.7).

4.3 Créer une archive, étape par étape

• Validez l'emplacement de sortie. Une archive existante n'est remplacée qu'avec -o+ (ou un oui interactif) ; sinon nikpak explique que l'ajout n'est pas pris en charge.
• Collectez l'entrée : les caractères génériques sont développés (PowerShell ne le fait pas), les @listfiles sont lus, les exclusions appliquées, les liens symboliques et les fichiers spéciaux ignorés avec un avertissement, et l'archive elle-même n'est jamais ajoutée à elle-même.
• Résolvez le mot de passe si le chiffrement a été demandé (section 3.3) et dérivez la clé avec Argon2id.
• Écrivez l'en-tête, puis construisez la chaîne d'écrivains : fichier, écrivain tamponné, chiffreur de blocs optionnel, encodeur Zstandard.
• Écrivez chaque entrée. Les fichiers média passent par la détection et l'essai (chapitre 7) ; tout le reste est copié par morceaux de 256 KiB pendant qu'un CRC32 est calculé.
• Écrivez le marqueur de fin avec le nombre d'entrées, terminez la trame Zstandard, scellez le dernier bloc chiffré et videz vers le disque.
• Renommez name.nik.tmp en name.nik. Si quelque chose échoue avant, un objet garde-fou supprime le fichier temporaire, de sorte qu'une archive à moitié écrite ne remplace jamais une bonne archive.

4.4 Extraire une archive, étape par étape

• Lisez et validez l'en-tête : nombre magique, version, drapeaux, méthode et, pour les archives chiffrées, les paramètres Argon2id, qui sont vérifiés en plage avant toute allocation de mémoire.
• Obtenez le mot de passe et dérivez la clé. Le premier bloc authentifié prouve ou réfute alors le mot de passe.
• Parcourez le flux d'entrées. Chaque nom d'entrée est assaini (section 10.1) avant tout accès au système de fichiers.
• Écrivez les fichiers avec create_new, définissez les horodatages et les permissions, et vérifiez le CRC32 des octets reconstruits. Un fichier dont le CRC échoue est supprimé plutôt que conservé.
• Vérifiez la fin de l'archive : après le marqueur de fin, le flux doit réellement se terminer et, si chiffré, le dernier bloc authentifié doit avoir été traité. Cela détecte la troncature et les données ajoutées.

4.5 Mémoire et threads

Zstandard utilise des threads de travail pour la compression (tous les cœurs par défaut, -mt pour limiter). La décompression, le codec audio et le chiffrement s'exécutent sur le thread appelant. Argon2id a besoin de 64 MiB pour la dérivation de clé, et les deux niveaux les plus élevés utilisent une fenêtre de correspondance de 128 MiB, donc la décompression de telles archives nécessite jusqu'à cette quantité de mémoire.

5 Le format de conteneur .nik

Un fichier .nik est un petit en-tête fixe suivi d'un corps. Le corps est un unique flux solide : toutes les entrées sont concaténées, compressées ensemble, et éventuellement chiffrées. La version 2 du format ajoute les enregistrements média ; les archives de version 1 restent lisibles.

5.1 En-tête

Décalage	Taille	Champ	Notes
0	8	Nombre magique	89 4E 49 4B 0D 0A 1A 0A (l'idée du PNG : détecte les dommages de transfert en mode texte)
8	1	Version	3 (1 et 2 restent lisibles)
9	1	Drapeaux	bit 0 = chiffré ; les autres bits doivent être 0
10	1	Méthode	0 = stockage, 1 = Zstandard, 2 = blocs multi-moteurs (5.6)
11	1	Réservé	0
12	4	Mémoire Argon2id (KiB)	archives chiffrées uniquement, petit-boutiste
16	4	Passes Argon2id	chiffrées uniquement
20	4	Voies Argon2id	chiffrées uniquement
24	16	Sel	aléatoire par archive, chiffrées uniquement
40	19	Préfixe de nonce de flux	aléatoire par archive, chiffrées uniquement

L'en-tête complet (12 octets, ou 59 octets lorsqu'il est chiffré) est ensuite authentifié comme données associées de chaque bloc chiffré, de sorte qu'il ne peut pas être modifié sans être détecté.

5.2 Enregistrements d'entrée

À l'intérieur du flux (déchiffré, décompressé), chaque entrée est un enregistrement. Tous les entiers sont petit-boutistes.

Type	Disposition
0 END	count:u64. Marque la fin et indique combien d'entrées le précèdent.
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

• Les noms sont en UTF-8 avec des séparateurs /, d'au plus 4096 octets.
• mtime est en secondes Unix ; mode est le mot de permission Unix (les fichiers Windows reçoivent 0644 ou 0755, 0444 en lecture seule).
• Le CRC32 couvre toujours les octets d'origine, ce qui rend les filtres média vérifiables.
• Dans un enregistrement MEDIA, size est la taille d'origine. Le framed_stream est une suite de blocs [u32 length][bytes] terminés par une longueur nulle, de sorte qu'un lecteur peut toujours sauter une entrée média sans comprendre son filtre.

Paramètres média

Filtre	Paramètres	Contenu
1 Audio	19 octets	offset:u64 frames:u64 channels:u8 bits:u8 flags:u8 (bit de drapeau 0 = gros-boutiste, bit 1 = signé)
2 Image	21 octets	offset:u64 width:u32 rows:u32 bpp:u8 stride:u32
3 Deflate	0 octets	none: the framed stream holds raw segments and recompressed Deflate streams (section 7.9)

Tout ce qui précède offset (en-têtes, balises, palettes, motifs MOD) et tout ce qui suit la région d'échantillons ou de pixels (blocs de fin) est stocké inchangé autour des données filtrées.

5.3 Découpage du corps chiffré

Lorsque le drapeau de chiffrement est activé, la sortie zstd est découpée en blocs de 64 KiB de texte en clair. Chaque bloc est stocké sous forme d'une longueur 32 bits gros-boutiste suivie du texte chiffré, qui fait 16 octets de plus à cause de l'étiquette Poly1305. Un bloc n'est scellé que lorsqu'au moins un octet de plus suit, de sorte que le dernier bloc n'est jamais vide et peut être marqué comme final (section 8.3).

5.4 Pourquoi un flux solide ?

Compresser tous les fichiers en un seul flux permet au compresseur de trouver des répétitions entre fichiers, ce qui compte énormément pour les arborescences de sources et les collections de documents (le benchmark du chapitre 11 montre que la sortie non solide de RAR est presque deux fois plus grande que sa sortie solide sur 10 949 fichiers). Le prix à payer est l'accès séquentiel : extraire un seul fichier exige de décompresser ce qui le précède. nikpak réduit ce coût pour les entrées média en les sautant sans les décoder.

5.5 Versionnage

L'octet de version est comparé à la version la plus élevée que le programme comprend. Une archive plus récente produit le message Version d'archive non prise en charge N ; veuillez mettre à jour nikpak plutôt qu'une erreur de corruption trompeuse. Les drapeaux, méthodes ou filtres média inconnus sont rejetés de la même manière.

5.6 Corps multi-moteur (version 3)

Les archives créées avec -m5 utilisent la méthode 2. Le flux d'enregistrements interne décrit en 5.2 est inchangé, mais il est découpé, uniquement entre les entrées, en blocs, et chaque bloc est compressé avec son propre moteur. Mis bout à bout, les blocs décompressés sont exactement le flux d'enregistrements d'une archive à moteur unique, de sorte que le listage, le test et l'extraction fonctionnent de la même façon.

Élément	Disposition
corps	bloc* suivi d'un seul octet 0
bloc	paramètres engine:u8, puis trames [longueur u32 de 1 .. 1 MiB][octets compressés], terminées par une longueur nulle
moteur 1	Zstandard (aucun paramètre)
moteur 2	Flux brut LZMA2 : taille de dictionnaire u32, lc u8, lp u8, pb u8
moteur 3	PPMd variante I (PPMd8) : ordre u8, taille de modèle u32, méthode de restauration u8 (0 = redémarrage)

Le découpage permet à un lecteur de trouver la fin de chaque bloc sans faire confiance au décodeur, et chaque paramètre est vérifié en plage avant l'allocation de mémoire (dictionnaire LZMA2 d'au plus 1.5 GiB, modèle PPMd d'au plus 1 GiB, ordre de 2 à 16). Lorsqu'il est chiffré, le corps est protégé par les mêmes blocs authentifiés que toute autre archive (chapitre 8).

6 Le moteur de compression

6.1 Pourquoi Zstandard

Zstandard combine la correspondance LZ77 avec un étage d'entropie construit à partir du codage de Huffman et de l'entropie à états finis (FSE). Comparé à l'algorithme Deflate de ZIP, il trouve des correspondances sur une fenêtre bien plus grande, modélise les littéraux et les longueurs de correspondance avec des codes d'entropie plus serrés, et décode à des gigaoctets par seconde. C'est aussi un format ouvert et largement audité, ce qui garde les données de nikpak récupérables par des outils indépendants.

6.2 Correspondance des niveaux

nikpak accepte à la fois les niveaux de style RAR (-m0 .. -m5) et les niveaux de style zip (-0 .. -9) et les fait correspondre aux niveaux Zstandard :

Option	Niveau Zstandard	Caractère
-m0	aucun (stocké)	Aucune compression, aucun filtre média
-m1	1	Le plus rapide
-m2	3	Rapide ; environ 0.9 s pour 197 MB sur un cœur (valeur par défaut jusqu'à la 1.2.0)
-m3	9	Bon équilibre
-m4	15	Élevé ; fenêtre de 128 MiB et correspondance longue distance ; recompression Deflate (7.9)
-m5 (default)	LZMA2 / PPMd	Maximal, et valeur par défaut depuis 1.2.1 : corps multi-moteur (6.7) et recompression Deflate

Les niveaux de style zip correspondent comme suit : -0 stocke, -1 à -6 utilisent Zstandard 1 à 6, -7 utilise 9, -8 utilise 12 et -9 équivaut à -m5.

6.3 Grande fenêtre et correspondance longue distance

Au niveau Zstandard 15 et au-delà, nikpak active une fenêtre de correspondance de 2^27 octets (128 MiB) et la correspondance longue distance. Les arborescences de sources, les jeux de documents et les sauvegardes contiennent de nombreux fichiers presque identiques qui se trouvent loin les uns des autres dans le flux ; une fenêtre normale de 8 MiB ne peut pas voir au-delà. Sur le jeu de test de 197 MB, cela a réduit la sortie à -m5 de 26.3 MB à 24.4 MB et à -m4 de 29.5 MB à 26.8 MB, sans coût en vitesse pour -m4 et avec un petit coût pour -m5. Une fenêtre de 2^27 reste dans la limite de décodeur par défaut de Zstandard, donc tout décodeur standard peut lire les données.

6.4 Multi-threading

L'encodeur divise l'entrée en tâches qui s'exécutent sur des threads de travail (tous les cœurs par défaut). La vitesse de compression évolue donc avec le nombre de cœurs, tandis que le format reste un flux unique. Tous les chiffres de ce guide ont été mesurés sur un seul cœur ; sur une machine multi-cœur typique, nikpak est considérablement plus rapide qu'illustré.

6.5 Intégrité à l'intérieur du flux

La trame Zstandard porte sa propre somme de contrôle de contenu, nikpak ajoute un CRC32 par fichier et un marqueur de fin avec le nombre d'entrées. Une archive simple endommagée est donc détectée à trois niveaux : la somme de contrôle de trame, le CRC par fichier et le marqueur de fin.

6.6 Mode stockage

-m0 écrit les entrées sans compression. C'est utile pour les données déjà compressées, et c'est aussi le seul mode dans lequel les filtres média sont délibérément contournés : un utilisateur qui demande le stockage ne s'attend pas à ce que les données soient transformées.

6.7 Le niveau maximal : LZMA2 et PPMd

Zstandard est le bon moteur pour la vitesse, mais à ses réglages les plus forts, il reste de quelques pour cent derrière LZMA2 sur le code source et les documents, et bien derrière PPMd sur la prose. Depuis la version 1.2, -m5 construit donc l'archive à partir de deux blocs (format en 5.6) :

• Bloc binaire. Les dossiers, les fichiers binaires, les entrées média et les entrées recompressées en Deflate sont compressés avec LZMA2 : préréglage 9, longueur agréable 273, profondeur de recherche de correspondance 32, et un dictionnaire dimensionné selon les données (1 à 128 MiB).
• Bloc texte. Les fichiers dont les premiers 64 KiB ne contiennent aucun octet nul et presque aucun caractère de contrôle (code source, texte, CSV, HTML, XML ...) vont dans un second bloc. Quatre séries contiguës de 1 MiB de ces fichiers sont compressées à l'essai avec PPMd variante I (ordre 8, modèle de 192 MiB) et avec LZMA2 réglé pour le texte (lc 4, pb 0), et le plus petit résultat l'emporte. La prose favorise PPMd ; les grandes arborescences de sources avec de nombreux fichiers presque identiques favorisent LZMA2, car il peut copier de longues répétitions entre fichiers.
• Ordre. Dans chaque bloc, les fichiers sont triés par extension, puis par nom de fichier, comme le fait 7-Zip, afin que les fichiers identiques ou similaires soient voisins. Avec l'échantillon d'essai contigu, cela a rendu le jeu de données général 7.5 % plus petit.

Les réglages LZMA2 « extrêmes » ont été mesurés et rejetés : sur le XML de tableur, ils étaient jusqu'à dix fois plus lents sans être plus petits. -m5 s'exécute sur un seul thread, quel que soit -mt.

7 Intelligence des médias

Un compresseur généraliste voit des octets. Il ne sait pas qu'un fichier WAV est une forme d'onde dont l'échantillon suivant est prédictible à partir des précédents, ni que les pixels voisins d'une photographie sont presque égaux. La couche média de nikpak apporte ce savoir : elle reconnaît ces fichiers, applique une transformée sans perte qui expose la redondance, et laisse le compresseur (ou un codec dédié) l'exploiter. C'est là que nikpak gagne le plus face à RAR.

7.1 Détection par le contenu

La détection regarde les premiers octets de chaque fichier d'au moins 8 KiB et ne fait jamais confiance à l'extension, de sorte qu'un WAV renommé en .dat est toujours trouvé et qu'un fichier texte appelé .wav ne l'est pas.

Type	Comment il est reconnu	Ce qui est filtré
WAV	RIFF..WAVE, un bloc fmt avec PCM entier (format 1, ou WAVE_FORMAT_EXTENSIBLE avec le sous-format PCM), 8/16/24/32 bits, de 1 à 8 canaux, alignement de bloc cohérent ; puis le bloc data	La région d'échantillons. Une longueur de données nulle, trop grande ou invalide est ramenée au fichier ; les octets restants et les blocs de fin sont conservés tels quels.
AIFF / AIFC	FORM..AIFF ou AIFC (compression NONE ou twos), blocs COMM et SSND, échantillons signés gros-boutistes	La région de données sonores.
ProTracker MOD	Signature au décalage 1080 : M.K., M!K!, FLT4, 4CHN, 6CHN, 8CHN, FLT8, OCTA ou CD81	La zone d'échantillons 8 bits après les données de motifs (section 7.6).
BMP	BM, un en-tête DIB de 40 octets ou plus, sans compression, 8, 24 ou 32 bits par pixel, des lignes de pixels qui tiennent dans le fichier, région entre 4 KiB et 256 MiB	Les lignes de pixels (section 7.7).

Non pris en charge, et donc stockés avec une compression normale : WAV à virgule flottante, ADPCM et autre audio compressé, BMP RLE ou à champs de bits, et les formats tracker autres que ProTracker MOD. Les médias déjà compressés comme MP3, JPEG, FLAC, PNG et MP4 ne sont pas du tout reconnus et sont laissés tels quels, car les transformer n'aiderait pas.

7.2 L'essai : choisir le meilleur filtre par fichier

Aucune transformée unique n'est la meilleure pour chaque fichier. Le codage prédictif l'emporte sur la musique enregistrée ; la séparation en plans d'octets l'emporte sur l'audio issu d'une source compandée 8 bits (où seulement un millier de valeurs 16 bits distinctes apparaissent) ; la compression simple l'emporte sur le silence et les échantillons tracker très répétitifs. nikpak mesure donc au lieu de deviner.

• Prélevez un échantillon : toute la région d'échantillons lorsqu'elle fait jusqu'à 3 MiB, sinon trois fenêtres de 768 KiB à 5 %, 45 % et 85 % de l'audio. Pour les images, les premières lignes jusqu'à environ 4 MiB.
• Compressez l'échantillon avec Zstandard simple au niveau 3 (la référence) et avec chaque filtre applicable : NAC, Shuffle et Shuffle+Delta pour l'audio 16/24/32 bits ; NAC et Shuffle+Delta pour l'audio 8 bits ; MED pour les images.
• Gardez le filtre avec la plus petite estimation, mais seulement s'il bat la référence d'au moins 2 %. Sinon, le fichier est stocké avec une compression normale.
• Écrivez le fichier avec le gagnant. Tout cela se produit par fichier, de sorte qu'une archive peut contenir des WAV codés avec des méthodes différentes à côté de fichiers ordinaires.

nikpak mt effectue la même mesure sur le fichier entier et affiche un tableau, ce qui est la façon dont le benchmark du chapitre 11 a été exploré. Dans les options, -mc- désactive les filtres et -mc+ force le filtre par défaut sans essai.

Sans perte, vérifié et contournable Chaque filtre est exactement réversible. Le CRC32 stocké avec chaque entrée est calculé sur les octets d'origine et vérifié à l'extraction, l'encodeur NAC vérifie chaque bloc pendant l'écriture (section 7.4), et -mc- désactive toute la couche.

7.3 Le codec audio NAC

NAC (codec audio de nikpak) est un codec sans perte par blocs pour le PCM entier. Il appartient à la même famille que FLAC : prédiction linéaire suivie d'un codage de Rice. Il possède son propre flux de bits, conçu pour cette archive, et est utilisé pour WAV, AIFF et les données d'échantillons des fichiers MOD.

Blocs et décorrélation stéréo

L'audio est découpé en blocs de 4096 trames d'échantillons, chacun codé indépendamment, ce qui rend le codec robuste (une erreur ne peut pas se propager) et permet à l'encodeur de s'adapter au matériau changeant. Pour la stéréo, l'encodeur choisit l'une des quatre représentations par bloc :

Mode	Canaux codés	Reconstruction
0	Gauche, Droite	direct
1	Gauche, Côté	R = L - S
2	Côté, Droite	L = R + S
3	Milieu, Côté	sum = (M << 1) | (S & 1), L = (sum + S) >> 1, R = (sum - S) >> 1

avec Side = L - R et Mid = (L + R) >> 1. Le canal latéral a besoin d'un bit de plus qu'un canal normal et est codé avec bits + 1. Le mode est choisi à moindre coût : l'encodeur additionne les valeurs absolues du résidu du prédicteur fixe d'ordre 2 de L, R, M et S et prend la paire avec le plus petit total. Pour les enregistrements dont les canaux sont fortement corrélés, Milieu/Côté économise généralement plusieurs pour cent.

Types de sous-trames

Chaque canal codé d'un bloc est stocké comme l'une des quatre sous-trames, selon celle qui est la plus petite :

Type	Usage	Coût
Constante	Tous les échantillons égaux (silence numérique)	2 + bits de largeur d'échantillon pour tout un bloc
Verbatim	Matériau de type bruit, ou le repli de sécurité	n x bits de largeur
Fixe	Prédicteur polynomial d'ordre 0 à 4	échantillons d'échauffement + résidus
LPC	Prédicteur linéaire d'ordre 1 à 32 avec coefficients transmis	coefficients + échauffement + résidus

Bits gaspillés. Si les bits bas de chaque échantillon d'un bloc sont toujours nuls (un enregistrement 8 bits stocké dans des conteneurs 16 bits, ou un signal quantifié), ils sont supprimés et leur nombre est stocké sur 5 bits.

Prédicteurs fixes

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]

Les premiers order échantillons d'un bloc sont stockés tels quels comme valeurs d'échauffement.

Codage prédictif linéaire (LPC)

Pour la musique tonale et harmonique, un prédicteur dont les coefficients sont ajustés au bloc est bien meilleur qu'un polynôme fixe. L'encodeur les calcule comme suit :

• Appliquez une fenêtre de Tukey (atténuation sur le premier et le dernier quart) au bloc, afin que ses bords ne faussent pas les statistiques.
• Calculez l'autocorrélation r[0..32] du signal fenêtré.
• Exécutez la récursion de Levinson-Durbin, qui produit le jeu de coefficients optimal pour chaque ordre de 1 à 32 en une seule passe : 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).
• Quantifiez les coefficients réels en entiers avec une précision de 12, 14 ou 15 bits (selon la largeur d'échantillon), en choisissant une échelle puissance de deux (shift, de 0 à 20) pour que le plus grand coefficient tienne juste. L'arrondi utilise un retour d'erreur, de sorte que les erreurs de quantification ne s'accumulent pas entre les coefficients.
• Évaluez plusieurs ordres (l'ensemble dépend du niveau d'effort, ci-dessous), calculez le résidu de chacun, et gardez celui avec la plus petite taille totale estimée, y compris le coût d'envoi de ses coefficients.

Le prédicteur lui-même est de l'arithmétique entière pure, ce que le décodeur exécute :

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 virgule flottante n'est utilisée que par l'encodeur pour décider quels coefficients entiers envoyer. Le décodeur ne touche jamais à la virgule flottante, de sorte que le décodage est exact au bit près sur chaque processeur et chaque compilateur.

Codage des résidus

Les erreurs de prédiction sont mappées en nombres non signés avec la transformée en zigzag (u = (e << 1) XOR (e >> 63), de sorte que les petites valeurs positives et négatives deviennent de petits nombres) et codées avec des codes de Rice partitionnés. Le résidu d'un bloc est divisé en 2^p partitions (p de 0 à 8, choisi par l'encodeur) ; chaque partition reçoit son propre paramètre de Rice k (5 bits). Une valeur est écrite sous forme de u >> k en unaire (autant de zéros et un un) suivi des k bits bas. Le meilleur k d'une partition est dérivé de la somme de ses valeurs, de sorte que le coût de chaque prédicteur candidat peut être estimé à moindre coût à partir de sommes courantes au lieu de l'encoder.

Niveaux d'effort

Le niveau de l'archive (option -m) choisit combien d'ordres LPC sont essayés par bloc. Plus d'ordres signifient un résultat légèrement plus petit et un encodeur plus lent ; la vitesse du décodeur est la même.

Niveau d'archive	Effort NAC	Ordres LPC essayés
-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

Les prédicteurs fixes d'ordre 0 à 4 sont toujours essayés. Dans le benchmark, le niveau d'effort a changé le résultat de la musique stéréo de moins de 0.05 % : le grand gain vient du simple fait d'utiliser la prédiction.

Disposition des bits d'un bloc

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

Chaque bloc est stocké dans l'archive avec une longueur de 32 bits devant, de sorte que le décodeur sait toujours où commence le bloc suivant.

7.4 Auto-vérification

Écrire une archive est la seule occasion de détecter un bug d'encodeur, donc l'encodeur NAC ne se fait pas confiance. Après avoir encodé chaque bloc, il décode à nouveau le bloc et compare le résultat aux échantillons d'origine. À la moindre différence, il ré-encode le bloc en verbatim (ce qui ne peut pas échouer) et vérifie à nouveau ; si même cela échoue, l'archivage s'arrête avec une erreur explicite et la suggestion d'utiliser -mc-. Le chemin de repli est exercé par les tests unitaires, qui forcent le codage verbatim pour chaque combinaison de profondeur de bits et de nombre de canaux, et le mécanisme transforme un éventuel bug silencieux de perte de données en une condition détectée et récupérable.

En plus de cela, le décodeur est fuzzé : des milliers de blocs d'octets aléatoires et de blocs avec des bits inversés lui sont soumis dans les tests unitaires, et il doit renvoyer une erreur sans paniquer ni allouer des quantités déraisonnables de mémoire. Pendant le développement, cela a trouvé un vrai bug (pour le matériau 32 bits, la recherche du paramètre de Rice pouvait revenir vide et retomber sur un paramètre qui aurait produit un code de plusieurs gigaoctets) ; il est corrigé et couvert par un test.

7.5 Shuffle et Shuffle+Delta

Certains audio ne réagissent pas à la prédiction. Les fichiers WAV de la galerie utilisés dans le benchmark sont en 16 bits, mais ne contiennent qu'environ un millier de valeurs d'échantillons distinctes, car ils proviennent d'une source compandée 8 bits. Un prédicteur ne peut pas l'exploiter, et FLAC les compresse à 84 % de l'original tandis que Zstandard simple a besoin de 63 %. Ce qui aide, c'est d'arranger les octets pour que le compresseur voie des données homogènes :

• Shuffle sépare les octets des échantillons en plans : tous les octets de poids faible du canal 0, puis tous les octets de poids fort du canal 0, puis le canal 1, et ainsi de suite, par blocs de 32768 trames. Le plan d'octets hauts est lisse et le plan d'octets bas a un alphabet très restreint ; le codeur d'entropie de Zstandard modélise chacun bien mieux que le mélange entrelacé.
• Shuffle+Delta remplace d'abord chaque échantillon par sa différence avec l'échantillon précédent du même canal (modulo la largeur d'échantillon, de sorte que c'est exactement réversible, avec un état reporté entre les blocs) puis mélange. Cela aide lorsque le signal est lisse mais pas assez prédictible pour que NAC gagne.

Sur les 35 fichiers de la galerie, l'archive avec le meilleur filtre par fichier (choisi par l'essai) fait 51 % de la taille d'origine à -m2 et 47 % à -m5, contre 63 % pour Zstandard simple.

7.6 Fichiers MOD ProTracker

Un module MOD est un en-tête de 1084 octets (titre, 31 descripteurs d'échantillons, une table d'ordre de motifs de 128 entrées et une signature de 4 octets au décalage 1080), puis les données de motifs, puis les échantillons bruts signés 8 bits de tous les instruments. nikpak calcule où les échantillons commencent et quelle est leur longueur :

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

L'en-tête et les motifs sont stockés tels quels (le compresseur gère bien ces événements de notes répétitifs) et la zone d'échantillons est traitée comme un unique flux mono, signé, 8 bits pour l'essai. Par fichier, NAC, Shuffle+Delta ou la compression simple l'emporte : les instruments échantillonnés favorisent surtout NAC, tandis que sur certains modules (par exemple ceux avec des échantillons très courts ou très répétitifs), la compression simple gagne. Les modules tronqués sont gérés en ramenant la région aux données réellement présentes.

7.7 Images BMP

Un BMP non compressé stocke des lignes de pixels rembourrées jusqu'à un multiple de quatre octets. Le filtre fonctionne en quatre étapes :

• Séparez la région de pixels en un plan par canal (B, V, R, et A pour 32 bits), en mémorisant séparément les octets de rembourrage par ligne.
• Décorrélez la couleur. Soustrayez le plan vert des plans bleu et rouge (modulo 256). Dans les photographies, les trois canaux sont fortement corrélés, de sorte que les différences sont petites.
• Prédisez chaque pixel à partir de ses voisins avec le prédicteur MED (détecteur médian de contours), celui utilisé par le codeur d'images LOCO-I : pour la gauche a, le dessus b et le dessus-gauche c, la prédiction est min(a,b) si c >= max(a,b), max(a,b) si c <= min(a,b), et a + b - c sinon. L'erreur de prédiction remplace le pixel (modulo 256). Sur les contours, le prédicteur suit le contour ; sur les dégradés lisses, il extrapole le dégradé.
• Concaténez les plans de résidus et les octets de rembourrage et laissez Zstandard les compresser. Les régions lisses deviennent des suites d'octets proches de zéro.

Le décodeur inverse exactement les étapes. Les BMP 8 bits sautent l'étape de couleur ; l'essai décide alors si la prédiction aide pour cette palette, car prédire des indices de palette n'a de sens que pour les palettes en niveaux de gris ou ordonnées de façon lisse. Les fichiers BMP de plus de 256 MiB ne sont pas filtrés, afin de borner l'utilisation mémoire.

7.8 Pourquoi cela bat RAR

RAR compresse les médias avec son moteur général de correspondance et de Huffman plus un petit ensemble de filtres d'octets. nikpak, à la place, donne à l'audio un vrai codec prédictif avec décorrélation stéréo par bloc et codage de Rice adaptatif, donne aux images un vrai prédicteur 2-D avec décorrélation de couleur, et choisit par fichier par la mesure. La conséquence est visible dans le benchmark : 12 à 15 % plus petit sur l'audio de toute sorte, 13 % sur la musique tracker et 39 % sur les photographies, et le résultat NAC pour la piste stéréo est à 0.2 % de l'encodeur FLAC dédié.

7.9 Documents Office, PDF et gzip : recompression Deflate

Les fichiers Office modernes sont des archives ZIP de XML (docx, xlsx, pptx, odt, ods), et les fichiers PDF stockent leurs pages dans des flux Deflate (FlateDecode). Leur contenu est donc déjà compressé, et aucun archiveur ne peut beaucoup le réduire : dans le benchmark 1.1, 6.6 MB de fichiers .xlsx ne descendaient qu'à 5.6 MB avec 7-Zip. nikpak 1.2 supprime cet obstacle.

• Détection par le contenu. Un en-tête local ZIP (PK\x03\x04) au début du fichier, %PDF- ou un en-tête gzip ; l'extension n'est jamais utilisée.
• Décodage. Chaque flux Deflate est trouvé (entrées ZIP avec la méthode 8, flux PDF avec un en-tête zlib, chaque membre gzip) et analysé avec preflate (preflate-rs de Microsoft). preflate renvoie les données en clair plus un petit enregistrement de corrections qui décrit exactement comment l'encodeur d'origine a fait ses choix, quel que soit cet encodeur.
• Stockage. Le fichier est stocké comme une séquence de segments bruts et de paires (clair, corrections). Le XML ou la description de page en clair entre alors dans le flux solide, où LZMA2 le compresse à une fraction de sa taille Deflate.
• Vérification. Avant d'utiliser le résultat, nikpak reconstruit chaque flux Deflate et compare la longueur et le CRC32 de tout le fichier avec l'original. Si quelque chose diffère, ou si preflate échoue ou panique sur un fichier mal formé, le fichier est simplement stocké normalement.
• Extraction. Les flux Deflate sont recréés bit à bit, de sorte que le .docx ou .pdf extrait est identique octet pour octet, et son CRC32 est vérifié comme pour chaque entrée.

Sur le jeu Office de la section 11.7, c'est ce qui rend nikpak plus petit que tous les autres archiveurs. Les 6.6 MB de fichiers .xlsx contiennent 71 MB de XML une fois décodés, et ce XML se compresse bien mieux que Deflate ne l'a fait. Le coût est le temps : preflate analyse environ 15 MB de données en clair par seconde. Pour cette raison, la recompression n'est utilisée qu'à -m4 et -m5, où elle est rentable (mesuré : -m3 gagnait 0.5 % pour six fois le temps). Limites : fichiers jusqu'à 512 MiB, et par flux jusqu'à 512 MiB de données en clair et 64 MiB de corrections. -mc- la désactive.

8 Chiffrement

Le chiffrement de nikpak est entièrement construit à partir de composants standard et bien étudiés (les implémentations RustCrypto d'Argon2id et de XChaCha20-Poly1305). Aucune primitive n'a été inventée pour ce projet ; le travail consiste à les combiner correctement.

8.1 Modèle de menace

La conception suppose un attaquant qui obtient le fichier d'archive et peut l'étudier et le modifier à loisir, et qui peut essayer un nombre illimité de mots de passe hors ligne. nikpak vise à garantir :

• Confidentialité du contenu des fichiers et de tout ce qui les concerne : noms, tailles, horodatages, permissions et nombre de fichiers.
• Intégrité et authenticité : tout changement de l'archive, que ce soit dans les données, l'en-tête, l'ordre des données ou sa longueur, est détecté avant que des données incorrectes soient acceptées.
• Résistance aux tentatives : chaque tentative de mot de passe est rendue aussi coûteuse que possible.

Il ne masque pas le fait qu'une archive existe, ni sa taille approximative, et il ne peut pas protéger contre un logiciel malveillant sur la machine qui crée ou ouvre l'archive, ni contre un mot de passe faible.

8.2 Du mot de passe à la clé : Argon2id

Un mot de passe est une mauvaise clé : court, prévisible et tapé par un humain. Il est transformé en une clé de 256 bits avec Argon2id, le vainqueur de la Password Hashing Competition et l'algorithme normalisé dans la RFC 9106. Argon2id est délibérément à coût mémoire élevé : calculer une clé nécessite un grand bloc de mémoire qui est rempli puis relu à plusieurs reprises selon un motif dépendant des données. nikpak utilise le profil à faible mémoire de la RFC :

Paramètre	Valeur	Signification
Mémoire	64 MiB	Chaque tentative nécessite 64 MiB de mémoire rapide
Passes	3	La mémoire est traitée trois fois
Voies	4	Degré de parallélisme à l'intérieur d'une dérivation
Sel	16 octets aléatoires	Nouveaux pour chaque archive : des mots de passe identiques donnent des clés différentes, et les tables précalculées sont inutiles
Sortie	32 octets	La clé XChaCha20-Poly1305

Le coût mémoire élevé est ce qui distingue Argon2id de l'ancien PBKDF2 (utilisé par RAR5 et par le mode AES de ZIP) : PBKDF2 n'a besoin de presque aucune mémoire, de sorte qu'une carte graphique ou une puce personnalisée peut tester d'énormes nombres de tentatives en parallèle. Avec Argon2id, le matériel de l'attaquant doit fournir 64 MiB par tentative parallèle, ce qui supprime la majeure partie de cet avantage. Le coût pour l'utilisateur légitime est une fraction de seconde, payée une fois par archive.

Les paramètres sont stockés dans l'en-tête, de sorte que les versions futures pourront les augmenter sans casser les anciennes archives. À la lecture, ils sont d'abord vérifiés en plage (mémoire 8 x voies jusqu'à 1 GiB, passes de 1 à 64, voies de 1 à 64) afin qu'une archive malveillante ne puisse pas faire allouer à nikpak des quantités absurdes de mémoire avant que le mot de passe n'ait été vérifié.

8.3 XChaCha20-Poly1305 dans la construction STREAM

Les données en masse sont protégées avec XChaCha20-Poly1305, un chiffrement authentifié avec données associées (AEAD) : ChaCha20 fournit un chiffrement de flux à clé de 256 bits, la variante X étend son nonce à 192 bits (assez grand pour être choisi au hasard sans jamais se répéter), et Poly1305 ajoute une étiquette d'authentification de 128 bits à chaque message scellé. ChaCha20 est rapide sur chaque processeur sans instructions spéciales et, contrairement à l'AES à base de tables, naturellement exempt de fuites de temporisation de cache.

Une archive est bien plus grande qu'un seul message, donc nikpak utilise la construction STREAM (la même que celle des outils modernes de chiffrement de fichiers) : les données sont découpées en blocs de 64 KiB et le bloc numéro i est scellé sous le nonce

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

| chunk counter (4 bytes, big endian)

| last-chunk flag (1 byte)

Cela donne trois garanties à la fois. Chaque bloc a un nonce unique, ce qui est essentiel pour les chiffrements de flux. Comme le compteur fait partie du nonce, réordonner ou dupliquer des blocs fait échouer l'authentification. Comme le dernier bloc porte un drapeau différent, raccourcir l'archive, même exactement à une frontière de bloc, fait échouer l'authentification : le nouveau dernier bloc a été scellé comme non final. Le préfixe de 19 octets est aléatoire par archive.

De plus, l'en-tête complet de l'archive (version, drapeaux, méthode, paramètres Argon2id, sel et préfixe de nonce) est transmis comme données associées à chaque bloc. Il est authentifié mais non chiffré ; inverser un seul de ses bits fait échouer chaque bloc. Cela bloque aussi les attaques par rétrogradation qui tenteraient d'affaiblir les paramètres stockés.

Élément	Valeur
Chiffre	XChaCha20-Poly1305 : clé de 256 bits, nonce de 192 bits, étiquette de 128 bits
Bloc	jusqu'à 64 KiB de texte en clair ; stocké sous forme de u32 length + texte chiffré + étiquette de 16 octets
Surcoût en taille	environ 0.03 % (20 octets par 64 KiB), mesuré à 0.03 % sur un jeu de données de 222 MB
Surcoût en vitesse	mesuré : +0.3 s au total sur un jeu de données de 222 MB (0.92 s au lieu de 0.64 s), dérivation de clé comprise
Mauvais mot de passe	Détecté au premier bloc ; aucun texte en clair n'est produit

8.4 Ce qu'un observateur peut et ne peut pas voir

Visible sans le mot de passe	Protégé
Le nombre magique, la version, les drapeaux et la méthode de compression	Les noms de fichiers et la structure des dossiers
Les paramètres Argon2id, le sel et le préfixe de nonce	Les tailles de fichiers, horodatages et permissions
La taille totale de l'archive et le nombre de blocs	Le nombre de fichiers
Le fait qu'il s'agisse d'une archive nikpak	Tout le contenu, y compris le fait qu'il contienne ou non des médias

Une conséquence de compresser avant de chiffrer est que la taille de l'archive reflète à quel point les données sont compressibles. C'est inhérent à tout archiveur qui compresse et chiffre ; cela n'a d'importance que si un attaquant peut contrôler une partie des données et observer la taille, ce qui ne s'applique pas à l'archivage de fichiers.

8.5 Gestion des mots de passe

• Longueur minimale. 8 caractères lors de la création d'une archive ; les mots de passe plus courts sont refusés avec une explication.
• Confirmation. L'invite interactive demande deux fois, n'affiche pas les caractères saisis et rejette une non-correspondance.
• Génération. Sans mot de passe, nikpak tire 24 caractères d'un alphabet de 56 symboles qui omet les ressemblants (0/O, 1/l/I), en utilisant un échantillonnage par rejet sur le générateur aléatoire cryptographiquement sûr du système d'exploitation afin qu'aucun symbole ne soit plus probable qu'un autre. Cela fait 24 x log2(56), soit environ 139 bits d'entropie, et il est affiché une fois, dans un encadré clairement marqué.
• Hygiène mémoire. La clé dérivée et les chaînes de mot de passe sont effacées de la mémoire lorsqu'elles ne sont plus nécessaires (la crate zeroize).
• Canaux. Ligne de commande (-p), variable d'environnement NIKPAK_PASSWORD, invite interactive, ou stdin lorsqu'il n'y a pas de terminal. La forme en ligne de commande est pratique mais visible dans la liste des processus ; les autres formes sont préférables.

8.6 Tests d'attaque

Les manipulations suivantes d'archives chiffrées ont été menées contre le programme fini. Toutes ont été détectées avant que des données incorrectes ne soient acceptées :

Manipulation	Résultat
Inverser un seul octet au milieu du texte chiffré	Rejeté : échec d'authentification (sortie 11)
Inverser un octet du sel dans l'en-tête	Rejeté (l'en-tête est une donnée associée et la clé change)
Changer l'octet de méthode dans l'en-tête	Rejeté
Tronquer le fichier de 100 octets	Rejeté comme endommagé (sortie 3)
Supprimer le dernier bloc exactement à une frontière de bloc	Rejeté : le nouveau dernier bloc n'a pas le drapeau final
Échanger deux blocs	Rejeté : non-correspondance de compteur
Fournir le mauvais mot de passe	Rejeté au premier bloc (sortie 11)
Donner un fichier aléatoire comme archive	Rejeté : mauvaise signature (sortie 3)

Risques résiduels, énoncés clairement Un mot de passe faible peut toujours être deviné ; Argon2id le rend coûteux mais ne peut pas sauver password123. nikpak n'a pas été audité de façon indépendante. Il ne peut pas se défendre contre les enregistreurs de frappe, les logiciels malveillants ou quelqu'un lisant la mémoire du processus en cours d'exécution. Pour des données dont l'exposition serait gravement préjudiciable, faites d'abord examiner l'implémentation par un cryptographe.

9 Résistance quantique

Les ordinateurs quantiques menacent gravement certaines cryptographies et à peine les autres. nikpak a été conçu du côté qui n'est presque pas affecté.

9.1 Ce que changent les ordinateurs quantiques

Algorithme	Effet	Qui est affecté
Shor (1994)	Factorise des entiers et calcule des logarithmes discrets en temps polynomial	RSA, Diffie-Hellman, DSA, cryptographie à courbes elliptiques : cassés par un grand ordinateur quantique
Grover (1996)	Cherche dans un espace non structuré de N éléments en environ la racine carrée de N étapes	Clés symétriques et fonctions de hachage : la longueur de clé effective est réduite de moitié

L'algorithme de Shor est le spectaculaire : il casserait tout système reposant sur les mathématiques à clé publique, c'est pourquoi les gouvernements et les organismes de normalisation migrent vers des algorithmes à clé publique post-quantiques tels que ML-KEM (FIPS 203). L'algorithme de Grover est le doux : une clé de 256 bits offre environ 128 bits de sécurité contre lui, et les itérations de Grover sont intrinsèquement séquentielles, de sorte que répartir le travail sur de nombreuses machines quantiques ne donne que la racine carrée de leur nombre en accélération.

9.2 La position de nikpak

Composant	Primitive	Impact quantique
Chiffrement	XChaCha20, clé de 256 bits	Meilleure attaque connue : Grover, environ 2^128 opérations. Hors de portée.
Authentification	Poly1305, étiquette de 128 bits, dérivée du secret de 256 bits	Aucune mathématique à clé publique impliquée
Du mot de passe à la clé	Argon2id, 64 MiB, 3 passes	Grover pourrait au mieux réduire de moitié l'entropie du mot de passe, et chaque itération exigerait d'évaluer une fonction à coût mémoire élevé
Aléa	CSPRNG du système d'exploitation	Non affecté
Cryptographie à clé publique	Aucune	Rien à attaquer pour l'algorithme de Shor

Une clé symétrique de 256 bits est la référence de la catégorie de sécurité la plus élevée (catégorie 5) de la normalisation post-quantique du NIST : les algorithmes à clé publique normalisés par le NIST sont évalués selon leur proximité avec la difficulté d'une recherche exhaustive d'une clé AES de 256 bits. Autrement dit, le chiffrement des données de nikpak se situe déjà à la force visée par les normes post-quantiques.

9.3 Et le mot de passe ?

L'espace de clés du chiffrement est de 256 bits, mais la clé est dérivée d'un mot de passe, donc la force réelle est la plus petite entre l'entropie du mot de passe et 256 bits. Face à un adversaire quantique, l'entropie du mot de passe est, au mieux pour l'attaquant, réduite de moitié :

Mot de passe	Entropie	Recherche classique	Recherche de Grover (au mieux)
généré par nikpak (24 symboles)	environ 139 bits	environ 2^139 tentatives	environ 2^70 itérations, chacune nécessitant une évaluation Argon2id cohérente de 64 MiB
Six mots Diceware aléatoires	environ 77 bits	environ 2^77 tentatives	environ 2^39 itérations du même circuit coûteux
Un mot de passe de 10 caractères choisi par un humain	typiquement 30 - 45 bits	réalisable	réalisable

La conclusion est la familière, énoncée plus nettement : le point faible est le mot de passe, pas le chiffrement. Utilisez le mot de passe généré ou une longue phrase secrète aléatoire et l'archive résiste à la fois aux attaquants classiques et quantiques pour tout avenir prévisible. Argon2id aide dans les deux mondes, car le coût de chaque tentative est dominé par la mémoire, que l'algorithme de Grover ne rend pas moins chère.

9.4 « Récolter maintenant, déchiffrer plus tard »

Une menace quantique souvent citée est qu'un adversaire enregistre aujourd'hui des données chiffrées et les déchiffre lorsqu'un ordinateur quantique existera. Pour les systèmes qui échangent des clés avec RSA ou des courbes elliptiques, comme les connexions TLS ou le chiffrement des e-mails, c'est réel. Une archive nikpak n'a pas d'échange de clé : sa clé provient d'un secret qui ne quitte jamais la tête de l'utilisateur ou son gestionnaire de mots de passe. Une copie stockée ne peut être ouverte plus tard qu'en devinant ce secret, et les ordinateurs quantiques ne rendent pas cela fondamentalement plus facile.

9.5 Limites honnêtes et la route à suivre

• « Résistant au quantique » signifie qu'aucun algorithme quantique connu ne bat la recherche générique contre ces primitives. Ce n'est pas une preuve ; la cryptanalyse de ChaCha20 et d'Argon2 continue, et le format est versionné afin que les paramètres ou les algorithmes puissent être changés.
• Si le partage à clé publique est un jour ajouté (chiffrer une archive vers la clé d'un destinataire), il utilisera un schéma hybride, X25519 combiné à ML-KEM, de sorte qu'il reste sûr si l'un des deux composants tient.
• La résistance quantique ne protège pas contre les erreurs d'implémentation. Voir les sections 8.6 et 10.

10 Durcissement et robustesse

Un archiveur lit des fichiers écrits par des inconnus et écrit des fichiers sur le disque de son utilisateur, ce qui en fait une cible classique. nikpak traite chaque archive comme une entrée non fiable.

10.1 Extraction sûre

• Traversée de chemin (« zip slip »). Chaque nom d'entrée est normalisé : les barres obliques inverses deviennent des barres obliques, les composants vides et . sont supprimés, et tout composant .. entraîne l'ignorance de l'entrée avec un avertissement. Les noms absolus perdent leur racine, de sorte que /etc/passwd est extrait à l'intérieur du dossier de destination.
• Noms Windows. Lors de l'exécution sous Windows, les composants contenant < > : " | ? * ou des caractères de contrôle, se terminant par un espace ou un point, ou égaux à un nom de périphérique réservé (CON, PRN, AUX, NUL, COM1-9, LPT1-9) sont rejetés.
• Liens symboliques. Avant l'écriture, chaque composant existant du chemin cible sous la destination est vérifié ; un lien n'est jamais suivi. Un fichier existant est d'abord supprimé et le nouveau est créé avec create_new, qui refuse d'ouvrir un chemin existant, de sorte qu'un lien ne peut pas être utilisé pour rediriger l'écriture.
• Bits privilégiés. Les bits setuid, setgid et collant ne sont jamais restaurés ; les permissions sont masquées aux bits rwx ordinaires.
• Fichiers en échec. Un fichier dont le CRC32 ne correspond pas est supprimé, pas laissé derrière.

Une archive fabriquée à la main contenant ../../evil.txt, /tmp/evil.txt, ..\..\evil.txt et ok/../../evil.txt a été extraite dans les tests : rien ne s'est échappé de la destination, les entrées non sûres ont été signalées et ignorées, et un lien symbolique planté dans la destination a été refusé.

10.2 Décodeurs bornés

• Les paramètres Argon2id sont vérifiés en plage avant toute allocation (section 8.2).
• Les blocs chiffrés doivent avoir une longueur entre 16 octets et 64 KiB + 16 ; les noms au plus 4096 octets ; les blocs audio doivent déclarer une longueur plausible ; les régions BMP sont limitées à 256 MiB ; les codes de Rice unaires sont plafonnés.
• Les décodeurs audio et média ont reçu des milliers d'entrées aléatoires et à bits inversés dans les tests unitaires et doivent renvoyer une erreur, jamais paniquer ni s'interrompre.
• Le code propre de nikpak ne contient aucun bloc unsafe, et la vérification des bornes de Rust transforme toute erreur de logique qui serait un bug de corruption mémoire en C en un échec propre.

nikpak ne limite pas le taux d'expansion d'une archive, de sorte que, comme tout archiveur, une « bombe de compression » délibérément fabriquée peut remplir un disque à l'extraction. Testez d'abord les archives inconnues avec t si cela compte.

10.3 Création sûre et erreurs honnêtes

• L'archive est écrite dans name.nik.tmp et renommée seulement lorsqu'elle est complète ; un garde-fou supprime le fichier temporaire en cas d'échec, de sorte qu'une exécution interrompue ne laisse jamais une archive à moitié écrite ou remplacée.
• Si un fichier devient plus court pendant qu'il est archivé, nikpak s'interrompt avec un message explicite au lieu d'écrire une entrée incohérente. Les fichiers illisibles, les liens symboliques et les fichiers spéciaux sont ignorés avec un avertissement (code de sortie 1) et l'archive n'est jamais ajoutée à elle-même.
• Les erreurs sont classées afin que les scripts puissent réagir : une erreur de somme de contrôle ou de trame à l'intérieur d'une archive est une corruption (sortie 3), un échec d'authentification est un mauvais mot de passe ou une altération (sortie 11), une écriture refusée est une erreur fatale (sortie 2).

11 Benchmarks

Ce chapitre rapporte des mesures, pas des affirmations. Il décrit exactement ce qui a été mesuré, inclut les résultats qui ne favorisent pas nikpak, et donne les commandes nécessaires pour tout reproduire.

Les sections 11.1 à 11.6 ont été mesurées avec nikpak 1.1.0, dont le -m5 utilisait encore Zstandard. La section 11.7 compare nikpak 1.2.0 à RAR, 7-Zip et ZIP sur une machine.

11.1 Méthode

Élément	Détail
Machine	Machine virtuelle Linux x86-64, un seul cœur de processeur. Tous les temps sont des secondes d'horloge murale sur ce cœur unique ; les machines multi-cœurs sont plus rapides pour les deux outils.
Logiciels	RAR 7.00 (26 février 2024, build d'essai Linux, format -ma5) ; nikpak 1.1.0 compilé en mode release avec LTO ; FLAC 1.x -8 comme référence audio.
Réglages RAR	-m3 (défaut de RAR) et -m5 (meilleur). Pour le test de données générales, aussi -s (solide) et -md256m (dictionnaire de 256 MB), car les archives nikpak sont toujours solides et une comparaison juste exige d'autoriser RAR à faire de même.
Vérification	Chaque archive nikpak a été extraite et comparée à l'original (cmp pour les fichiers média, SHA-256 de tous les 10 949 fichiers pour le jeu général).

Le matériel de test

Jeu	Contenu
WAV de la galerie	35 fichiers son de la galerie de LibreOffice : mono 16 bits, 23 à 11 025 Hz et 12 à 22 050 Hz. Ils ne contiennent qu'environ un millier de valeurs d'échantillons distinctes (sources compandées) et sont un cas délibérément difficile pour le codage prédictif.
Musique	Un morceau multi-instruments de 100 secondes (piano, cordes, basse, flûte, batterie) rendu avec TiMidity++ et le jeu de sons Freepats en stéréo 44.1 kHz 16 bits (17.4 MB). SoX en a dérivé une version mono 16 bits à 22.05 kHz, une mono 8 bits à 22.05 kHz et une stéréo 24 bits à 48 kHz.
MOD	16 modules ProTracker de la collection de test libxmp.
BMP	6 images : cinq photographies du jeu d'échantillons scikit-image (24 bits, plus une conversion en niveaux de gris 8 bits de l'une d'elles) et une texture de TeX Live.
Données générales	197.6 MB dans 10 949 fichiers : la bibliothèque standard Python et ses paquets, la documentation et les en-têtes C de la machine de test, liens symboliques supprimés.

Limites de ce matériel de test La musique est synthétique : elle a été rendue depuis du MIDI et contient des passages répétés, ce qui aide tous les outils basés sur LZ, y compris l'étage Zstandard après NAC. Les enregistrements réels contiennent moins de répétitions exactes, donc les tailles absolues différeront. La comparaison traite tous les outils de la même façon, et le résultat de FLAC sur le même fichier confirme que le codec audio lui-même est compétitif, mais les lecteurs avec un matériel spécifique devraient le mesurer : nikpak mt fait exactement cela.

11.2 Fichiers média

Jeu	Original	RAR 7 -m5	nikpak -m2	nikpak -m5	m5 contre RAR
6 photographies BMP	9,183,956	2,862,744	2,035,223	1,750,706	38.8 % plus petit
16 fichiers MOD ProTracker	2,507,557	1,070,290	966,622	927,973	13.3 % plus petit
35 WAV de la galerie (mono 16 bits)	2,991,820	1,605,879	1,529,219	1,418,532	11.7 % plus petit
Musique 44.1 kHz stéréo 16 bits	17,371,848	11,024,411	9,415,519	9,411,898	14.6 % plus petit
Musique 22.05 kHz mono 16 bits	4,342,996	3,112,135	2,635,819	2,634,669	15.3 % plus petit
Musique 22.05 kHz mono 8 bits	2,171,520	844,160	742,462	740,751	12.2 % plus petit
Musique 48 kHz stéréo 24 bits	28,362,206	21,467,283 (-m3)	18,689,529	18,688,030	12.9 % plus petit

Toutes les tailles sont en octets. Pour le fichier 24 bits, RAR n'a été mesuré qu'à -m3, de sorte que cette ligne est une comparaison plus faible que les autres.

Ce qu'apportent les filtres média

Le même nikpak sans les filtres média (version 1.0, Zstandard simple au niveau par défaut) est la bonne référence pour la valeur de la couche média :

Jeu	nikpak 1.0 (sans filtres)	nikpak 1.1 -m2	Réduction
6 photographies BMP	3,580,971	2,035,223	43.2 %
16 fichiers MOD ProTracker	1,260,607	966,622	23.3 %
35 WAV de la galerie (mono 16 bits)	1,876,722	1,529,219	18.5 %
Musique 44.1 kHz stéréo 16 bits	15,585,422	9,415,519	39.6 %
Musique 22.05 kHz mono 16 bits	3,887,183	2,635,819	32.2 %
Musique 22.05 kHz mono 8 bits	1,078,493	742,462	31.2 %

Comparaison avec FLAC

Pour la musique stéréo 44.1 kHz, FLAC -8, l'encodeur de référence dédié, produit 9 407 019 octets. Le flux NAC pour le même audio fait 9 425 305 octets, à 0.2 % près, et l'archive nikpak finie 9 415 519 octets. Pour les versions mono 22 kHz et 8 bits, NAC est plus petit que FLAC (2 635 446 contre 2 638 954, et 785 890 contre 798 810 pour la seule région audio), et pour le 24 bits, l'archive (18.69 MB) est plus petite que les 19.12 MB de FLAC. FLAC est bien plus faible sur les fichiers de la galerie (2.50 MB contre 1.61 MB pour RAR), pour la raison expliquée dans la section 7.5 ; c'est le cas dans lequel les autres filtres gagnent leur place.

11.3 Données générales

Le code source et les documents ne sont pas des médias, donc ce test vérifie si les gains de nikpak ailleurs lui coûtent quelque chose sur les fichiers ordinaires.

Outil et niveau	Taille (octets)	Temps	Extraction
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 (défaut 1.1)	36,266,743	0.9 s	0.8 s
RAR 7 -m5 (défaut, non solide)	50,851,230	14.8 s
RAR 7 -m3 (défaut, non solide)	50,974,773	9.7 s	2.3 s

Lire le tableau honnêtement :

• Niveau maximal : nikpak produit une archive 5.5 % plus petite que le meilleur de RAR (24.4 contre 25.9 MB). RAR est plus rapide à ce niveau (26.7 à 36.2 s contre 45.6 s).
• Taille égale : nikpak -m4 est à environ 1 % du niveau solide par défaut de RAR en 81 % du temps (13.5 s contre 16.7 s).
• Niveaux rapides : -m2 troque le taux contre la vitesse : 18 fois plus rapide que RAR solide -m3, et 37 % plus grand. C'est le niveau pour les sauvegardes et les pipelines où le temps compte plus que les derniers mégaoctets.
• Non solide : les archives par défaut (non solides) de RAR sont presque deux fois plus grandes que ses archives solides sur ces données à nombreux petits fichiers. Quiconque compare nikpak à RAR devrait ajouter -s à RAR.

11.4 Vitesse sur un seul gros fichier média

Opération	nikpak	RAR 7	Taille
Création, rapide / défaut RAR	1.45 s (-m2)	2.54 s (-m3)	9,415,519 vs 11,128,595
Création, niveau maximal	3.14 s (-m5)	5.87 s (-m5)	9,411,898 vs 11,024,411
Extraction	0.28 s	0.23 s	même sortie

Sur les médias, nikpak est à la fois plus petit et plus rapide à créer. RAR extrait un peu plus vite ; une raison probable est que le décodage NAC effectue une prédiction entière pour chaque échantillon, ce qui coûte un peu plus que la copie de correspondances qui domine le décodage général.

11.5 Surcoût du chiffrement

Sur le jeu de données de 222 MB, une archive chiffrée a pris 0.92 s contre 0.64 s sans chiffrement, et était plus grande de 11 087 octets (0.03 %). La différence inclut la dérivation Argon2id, de sorte que le coût est dominé par une fraction fixe de seconde.

11.6 Reproduire les résultats

# 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 Deuxième passe : nikpak, RAR 7, 7-Zip et ZIP

Mis à jour pour nikpak 1.2.0. Dans la première version de cette passe, avec nikpak 1.1.0, 7-Zip -mx9 était en avance sur le texte (de 1.4 %), les fichiers Office (3.3 %) et le code source (8.5 %). nikpak 1.2.0 ajoute la recompression Deflate (7.9) et un nouveau niveau maximal construit sur LZMA2 et PPMd (6.7), et a été mesuré à nouveau sur la même machine avec les mêmes fichiers. Les chiffres de RAR, 7-Zip et ZIP proviennent de la première passe.

Les sections 11.2 à 11.5 ne comparent nikpak qu'à RAR. Cette deuxième passe ajoute les deux archiveurs que la plupart des gens possèdent déjà, 7-Zip et le format classique ZIP, et deux types de fichiers archivés chaque jour : le texte brut et les documents Office (.doc, .docx, .xls, .xlsx, .csv, .pdf). Les quatre outils ont été exécutés l'un après l'autre sur la même machine et les mêmes fichiers, et RAR a été mesuré à nouveau. Les corpus ont été reconstruits à partir des mêmes sources publiques, de sorte que les tailles et les temps absolus diffèrent de ceux des sections 11.2 à 11.4. Comparez les chiffres au sein de cette section, pas entre les sections.

Méthode

Élément	Détail
Machine	Machine virtuelle Linux x86-64 (Intel Xeon, 2.8 GHz). Chaque commande a été épinglée sur un cœur de processeur avec taskset et exécutée en mono-thread (nikpak -mt1, RAR -mt1, 7-Zip -mmt=1 ; ZIP est mono-thread par conception).
Logiciels	nikpak 1.2.0 (build release) ; RAR 7.00 (-ma5, solide) ; 7-Zip 23.01 (format .7z, LZMA2, solide par défaut) ; Info-ZIP Zip 3.0 et UnZip 6.0 (Deflate).
Niveaux	nikpak : le niveau rapide -m2 et le maximal -m5, qui est le défaut depuis la 1.2.1 (et -m4). Les autres : défaut et maximal, RAR -m3 -s / -m5 -s, 7-Zip -mx5 / -mx9, ZIP -6 / -9. RAR a reçu le mode solide (-s), car les trois autres sont solides ou, dans le cas de ZIP, ne peuvent pas l'être.
Chronométrage	Secondes d'horloge murale. Jeux de moins de 50 MB : meilleur de trois exécutions. Le jeu général : une exécution.
Vérification	Les 92 archives ont toutes été extraites et comparées à l'original avec diff -r. Toutes étaient identiques.

Le matériel de test

Jeu	Fichiers	Taille (octets)	Contenu
Images BMP	8	6,987,840	Six photographies du jeu d'échantillons scikit-image en BMP 24 bits, plus une photographie en niveaux de gris 8 bits et une texture de gravier 8 bits.
ProTracker MOD	16	2,252,604	Les 16 plus grands modules ProTracker de la collection de test libxmp.
WAV de la galerie	35	2,991,820	Les mêmes 35 sons de la galerie LibreOffice qu'en 11.1.
Musique, quatre formats	4 × 1	53,417,226	Un nouveau morceau de 100 secondes (piano, cordes, basse, flûte, batterie) rendu avec TiMidity++ et Freepats en stéréo 44.1 kHz 16 bits, puis converti par SoX en mono 16 bits et 8 bits à 22.05 kHz et en stéréo 24 bits à 48 kHz.
Texte brut	18	11,793,318	Dix-huit livres du Projet Gutenberg en .txt (Austen, Melville, Shakespeare, la Bible du roi Jacques et d'autres).
Fichiers Office	60	39,100,915	12 rapports en .docx, .doc et .pdf (texte, titres, tableaux et quelques photos) et 8 classeurs de ventes de 500 à 30 000 lignes en .xlsx, .xls et .csv (avec formules), enregistrés par LibreOffice.
Données générales	11,473	190,454,632	Les bibliothèques standard Python 3.12 et 3.13, les paquets Python Debian, les en-têtes C (/usr/include) et /usr/share/doc. Liens symboliques supprimés.

Niveaux maximaux : taille d'archive

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

Toutes les tailles sont en octets. La plus petite archive de chaque ligne est affichée en gras.

Niveaux rapides : taille et temps de création

Jeu	nikpak -m2	RAR 7 -m3	7-Zip -mx5	ZIP -6
8 images BMP	54.0 % · 0.39 s	63.0 % · 2.09 s	60.1 % · 3.51 s	71.2 % · 0.35 s
16 fichiers MOD 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 galerie (mono 16 bits)	51.1 % · 0.41 s	53.6 % · 0.71 s	49.6 % · 1.96 s	61.9 % · 0.24 s
Musique 44.1 kHz stéréo 16 bits	49.2 % · 1.72 s	59.9 % · 3.60 s	60.1 % · 14.03 s	85.7 % · 0.82 s
Musique 22.05 kHz mono 16 bits	55.4 % · 0.58 s	64.1 % · 0.95 s	62.7 % · 2.14 s	84.2 % · 0.22 s
Musique 22.05 kHz mono 8 bits	27.4 % · 0.77 s	33.3 % · 0.52 s	28.9 % · 2.13 s	38.2 % · 0.32 s
Musique 48 kHz stéréo 24 bits	62.8 % · 2.06 s	73.6 % · 7.54 s	88.1 % · 13.54 s	93.0 % · 1.19 s
18 livres en texte brut (.txt)	35.2 % · 0.11 s	30.4 % · 5.53 s	27.7 % · 11.76 s	36.0 % · 0.89 s
60 fichiers Office	38.0 % · 0.22 s	29.5 % · 8.25 s	26.2 % · 21.85 s	44.7 % · 1.83 s
Données générales (11 473 fichiers)	25.3 % · 1.67 s	18.0 % · 48.19 s	17.0 % · 93.71 s	32.9 % · 7.32 s

nikpak -m2 contre le niveau par défaut des autres outils. Chaque cellule affiche la taille de l'archive en pourcentage de l'original et le temps de création sur un cœur. La plus petite archive de chaque ligne est en gras.

Données générales en détail

Outil et niveau	Taille (octets)	% de l'original	Création	Extraction
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 (non solide)	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 la 1.1.0 à la 1.2.0

Jeu	nikpak 1.1.0 -m5	nikpak 1.2.0 -m5	7-Zip -mx9	1.2.0 contre 7-Zip
18 livres en texte brut	3,306,819	2,741,898	3,259,868	15.9 % plus petit
60 fichiers Office	10,417,750	6,887,729	10,085,779	31.7 % plus petit
Données générales	31,322,041	28,175,618	28,879,398	2.4 % plus petit

Lire les résultats honnêtement

• nikpak -m5 est le plus petit sur chaque jeu. Contre 7-Zip -mx9, il est 2.4 à 31.7 % plus petit, contre RAR 7 -m5 10.8 à 38.4 % et contre ZIP -9 19.9 à 60.4 %. Sur l'audio enregistré, NAC prédit ce que les compresseurs basés sur LZ ne peuvent que faire correspondre : sur la musique 24 bits, 7-Zip économise 12 % et nikpak 37 %.
• Fichiers Office : 31.7 % plus petit que 7-Zip. La recompression Deflate transforme 6.6 MB de .xlsx et 1.9 MB de .docx en XML brut que LZMA2 compresse bien mieux que Deflate ne l'a fait (6.89 MB contre 10.09 MB). Même -m4 est 1.3 % plus petit que 7-Zip -mx9 et plus rapide (16 s contre 26 s). Le prix à -m5 est le temps : 81 s contre 26 s.
• Texte : 15.9 % plus petit, en moitié moins de temps. PPMd gagne sur la prose (6.4 s contre 12.9 s pour créer). Comme PPMd décode aussi lentement qu'il encode, l'extraction prend 2.7 s au lieu de 0.2 s.
• Code source : 2.4 % plus petit, une avance étroite. 28.2 MB contre 28.9 MB, en 154 s contre 121 s. Trier par type de fichier et choisir le moteur sur des échantillons contigus (6.7) a fait la différence.
• Niveau rapide -m2 : le plus rapide, pas le plus petit. nikpak -m2 a besoin de 1.7 s pour le jeu général, contre 93.7 s pour 7-Zip -mx5 (56 fois plus long), 48.2 s pour RAR et 7.3 s pour ZIP. Il est plus petit que 7-Zip -mx5 sur les images et la plupart de l'audio (les fichiers MOD et les WAV de la galerie sont 1 à 3 % plus grands), mais plus grand sur le texte, les fichiers Office et le code source (49.0 % sur le jeu général). Pour cette raison, depuis la version 1.2.1, nikpak utilise -m5 par défaut ; -m2 doit être demandé explicitement.
• ZIP est rapide mais le plus grand partout. Même nikpak -m2 bat ZIP -9 sur chaque jeu. ZIP crée de petites archives média plus vite que nikpak -m2, car Deflate fait bien moins de travail que le codec NAC, mais il est plus lent sur le texte, les fichiers Office et le code source.
• Extraction. Le jeu général s'extrait en 0.9 s (nikpak -m2) ou 5.6 s (-m5), contre 6.0 s pour 7-Zip, 6.7 s pour RAR et 6.9 s pour ZIP. Les archives avec des flux Deflate recompressés s'extraient plus lentement, car chaque flux est reconstruit (2.1 s contre 0.7 s pour le jeu Office).
• RAR sur cette machine. RAR a été plus lent ici qu'en 11.3 (72 s au lieu de 27 s pour -m5 -s sur une quantité similaire de code source). La machine et les données diffèrent, donc les deux sections ne doivent pas être mélangées. Au sein de cette passe, chaque outil a rencontré les mêmes conditions.

Ce que cela signifie pour nikpak

Au niveau maximal, nikpak 1.2.0 produit la plus petite archive des quatre outils sur chaque jeu mesuré, 2.4 à 31.7 % plus petit que 7-Zip -mx9. Le coût est la vitesse : -m5 est mono-thread et plus lent que 7-Zip sur les fichiers Office et le code source. Le rendre plus rapide figure sur la feuille de route (section 15.2).

12 nikpak et RAR comparés

RAR est un excellent archiveur largement utilisé, et ce chapitre ne prétend pas le contraire. Il expose où les mesures et la conception favorisent nikpak, où RAR est en avance, et qui devrait choisir quoi.

12.1 Où nikpak est en avance

Domaine	nikpak	Preuve
Audio, images, musique tracker	12 - 39 % plus petit que RAR 7 -m5 sur chaque jeu média mesuré	Section 11.2
Code source, niveau maximal	5.5 % plus petit que le meilleur réglage solide de RAR	Section 11.3
Vitesse au niveau rapide -m2	0.9 s contre 9.7 - 16.7 s pour 197 MB ; 1.45 s contre 2.54 s pour un WAV	Sections 11.3, 11.4
Chiffrement et mode	XChaCha20-Poly1305, authentifié ; RAR5 utilise AES-256 en mode CBC, qui n'est pas authentifié et repose sur des sommes de contrôle séparées	Chapitre 8
Hachage du mot de passe	Argon2id, à coût mémoire élevé (64 MiB) ; RAR5 utilise PBKDF2-HMAC-SHA256, qui est lié au processeur et se parallélise à bas coût sur les GPU	Section 8.2
Confidentialité des noms de fichiers	Toujours chiffrés ; RAR a besoin du commutateur -hp	Section 8.4
Génération de mot de passe	Intégrée : mot de passe aléatoire fort lorsqu'aucun n'est fourni	Section 3.3
Preuve d'altération	Le réordonnancement, la troncature et les changements d'en-tête sont détectés cryptographiquement	Section 8.6
Transparence	Source complète et format documenté ; implémentation en Rust sûr en mémoire	Chapitres 5, 10
Distribution	Un exécutable statique (fenêtre de dépôt et ligne de commande ; environ 2.3 MB sans la fenêtre), ou un petit installateur Windows ; shareware, gratuit pour un usage personnel (3.8)	Chapitre 13

12.2 Où RAR est en avance

Domaine	RAR 7	nikpak aujourd'hui
Enregistrements de récupération	Peut réparer les archives endommagées	Détecte les dommages, ne peut pas les réparer
Archives multivolumes	Oui	Non
Archives auto-extractibles	Oui	Non
Mise à jour d'une archive	Ajoute, remplace et supprime des fichiers sur place	Créer ou écraser uniquement
Interface graphique	WinRAR, avec intégration au shell	Fenêtre de dépôt pour compresser (3.7) ; pas d'intégration au shell, extraction en ligne de commande
Vitesse au niveau maximal	26.7 - 36.2 s sur le jeu général	45.6 s
Vitesse d'extraction sur les médias	0.23 s pour le WAV de 17 MB	0.28 s
Maturité et portée	Des décennies de tests sur le terrain ; des millions de fichiers .rar existants	Nouveau ; aucun audit indépendant ; ne lit que le .nik

12.3 La résistance quantique en perspective

nikpak et RAR5 chiffrent tous deux avec une clé symétrique de 256 bits, donc tous deux sont épargnés par l'algorithme de Shor et conservent environ 128 bits de sécurité contre celui de Grover. Aucune des deux revendications ne les distingue. Ce que nikpak ajoute par-dessus est une étape de mot de passe à coût mémoire élevé (qui rend l'attaque réelle dominante, le devinement de mot de passe, bien plus coûteuse) et un chiffrement authentifié (qui rend l'altération détectable). Il a aussi été conçu dès le départ sur l'hypothèse qu'aucune primitive à clé publique ne fera jamais partie du format d'archive, et sa feuille de route s'engage sur un schéma hybride post-quantique si le partage à clé publique est ajouté.

12.4 Lequel choisir

• Choisissez nikpak pour les archives d'audio, d'images, de musique tracker et de code source où la taille et la vitesse comptent, pour les sauvegardes scriptées, pour un chiffrement fort par défaut, et lorsqu'un format ouvert et documenté est précieux.
• Choisissez RAR lorsque vous avez besoin d'enregistrements de récupération, d'archives multivolumes ou auto-extractibles, de mises à jour sur place, ou que vous devez échanger des archives avec des personnes qui n'ont que des outils RAR.
• Utilisez les deux : rien n'empêche un flux de travail d'utiliser nikpak pour les médias en masse et les sauvegardes chiffrées tout en gardant RAR pour la distribution.

12.5 Et 7-Zip et ZIP ?

La section 11.7 mesure aussi nikpak 1.2 contre 7-Zip 23.01 et Info-ZIP 3.0. En bref :

• Choisissez nikpak -m5 pour la plus petite archive. Il est 2.4 à 31.7 % plus petit que 7-Zip -mx9 sur chaque jeu mesuré : 31.7 % sur les fichiers Office, 15.9 % sur le texte et 2.4 % sur le code source. Choisissez nikpak -m2 pour des sauvegardes rapides (56 fois plus rapide que le défaut de 7-Zip sur le code source). nikpak a aussi un chiffrement plus fort : 7-Zip utilise AES-256 avec une dérivation de clé SHA-256 qui n'est pas à coût mémoire élevé, et il ne masque les noms de fichiers qu'avec -mhe.
• Choisissez 7-Zip lorsque le temps compte davantage au niveau maximal (il est plus rapide sur les grands jeux Office et de code source), lorsque vous avez besoin que son niveau par défaut soit petit sur les documents, ou lorsque vous devez ouvrir les nombreux formats que 7-Zip lit.
• Choisissez ZIP uniquement pour la compatibilité. Chaque système d'exploitation l'ouvre sans logiciel supplémentaire, mais nikpak -m5 est 19.9 à 60.4 % plus petit, et le chiffrement traditionnel de ZIP est faible.

13 Compilation, déploiement et intégration

13.1 Windows avec PowerShell

nikpak est écrit en Rust et compilé avec Cargo. Sous Windows, Rust a besoin d'un éditeur de liens C/C++, fourni par les Visual Studio Build Tools. Dans un PowerShell administrateur, installez les deux une fois puis rouvrez 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 n'est pas disponible, installez Rust depuis rustup.rs et les Build Tools for Visual Studio avec la charge de travail Développement de bureau en C++. Ensuite, dans le dossier qui contient les sources :

.\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 vérifie que Cargo est installé (et indique comment l'installer sinon), lance la compilation, explique la cause habituelle en cas d'échec, et copie l'exécutable vers dist\nikpak.exe.

L'installateur Windows

.\build.ps1 -Installer (ou npm run installer) compile aussi le programme d'installation dist\nikpak--setup.exe avec Inno Setup 6.3 ou plus récent (installez-le une fois avec winget install JRSoftware.InnoSetup). Le script est installer\nikpak.iss ; la version est prise dans Cargo.toml. C'est ce fichier d'installation qui est mis en ligne sur les sites de shareware et de téléchargement.

• Par défaut, il installe uniquement pour l'utilisateur courant, sans droits d'administrateur ni invite UAC, dans %LOCALAPPDATA%\Programs\NikPak. Sa première page propose « installer pour tous les utilisateurs » (Program Files, nécessite des droits d'administrateur).
• Il affiche LICENSE.txt pour acceptation et installe nikpak.exe, unNik.exe, les icônes, LICENSE.txt, THIRD-PARTY-NOTICES.txt et CHANGELOG.md. Il ajoute une entrée au menu Démarrer, une icône de bureau optionnelle et, sur demande, le dossier au PATH pour la ligne de commande. Il enregistre un désinstalleur dans Paramètres > Applications.
• Raccourcis : NikPak, unNik et la licence dans le menu Démarrer ; NikPak sur le bureau (toujours) et unNik sur le bureau en option.
• Les fichiers .nik sont toujours enregistrés (depuis la 1.5.2) : ils reçoivent leur propre icône (nikfile.ico, une page avec une fermeture éclair, comme les fichiers .zip), le nom de type « NikPak archive », et un double-clic les ouvre dans unNik (« Ouvrir avec unNik » dans le menu contextuel). unNik est aussi listé dans « Ouvrir avec » et dans Applications par défaut. Le désinstalleur retire l'enregistrement. Si les fichiers .nik étaient déjà configurés pour s'ouvrir avec un autre programme, Windows conserve ce choix jusqu'à ce qu'unNik soit choisi une fois dans « Ouvrir avec ».
• Le dernier « Lancer NikPak » démarre NikPak en tant qu'utilisateur normal, jamais en tant qu'administrateur, afin que le glisser-déposer fonctionne. Les mises à jour s'installent par-dessus la version précédente (AppId fixe). La licence dans %APPDATA%\nikpak est conservée lors de la mise à jour et de la désinstallation. Le programme d'installation ne contient jamais de clés ni de fichiers de clés.
• L'installateur s'exécute en anglais ou en français, selon Windows. Avant la publication, signez nikpak.exe et le programme d'installation avec un certificat de signature de code, afin que Windows SmartScreen n'avertisse pas d'un éditeur inconnu.

buildall.ps1 compile tout ce qui est publié en une seule passe — nikpak.exe, unNik.exe, les deux programmes d'installation et SHA256SUMS.txt — les copie dans binaries\, reconstruit le site web et le met en ligne par FTP (-NoUpload saute la mise en ligne). Le second programme d'installation, unnik--setup.exe (installer\unnik.iss), installe unNik seul, l'explorateur d'archives gratuit ; lorsque NikPak est déjà installé, il n'installe que le programme, de sorte que les menus ne se doublent jamais.

13.2 Compilation avec npm

Les projets Rust n'utilisent pas npm, donc npm n'est jamais requis. Pour plus de commodité, le projet contient un petit package.json dont les scripts appellent simplement Cargo, afin qu'un développeur habitué à un flux Node.js puisse taper des commandes familières :

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 exécutable autonome

Le fichier .cargo/config.toml lie statiquement le runtime C pour les cibles Windows MSVC. Le nikpak.exe résultant (plusieurs MB avec l'interface graphique, environ 2.3 MB sans) n'a donc aucune dépendance DLL et n'a pas besoin du Visual C++ Redistributable sur les machines où il s'exécute. Copiez-le dans un dossier du PATH pour l'utiliser partout. Le profil release active l'optimisation complète, l'optimisation à l'édition de liens, une unité de génération de code unique, la suppression des symboles et panic = abort pour un binaire petit et rapide.

13.4 macOS et Linux

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

# or: cargo build --release

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

Sur macOS, installez d'abord les outils en ligne de commande (xcode-select --install) ; sur Debian ou Ubuntu, installez un compilateur C (sudo apt install build-essential). Rust lui-même s'installe via curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh. La bibliothèque de compression est compilée depuis ses sources C par Cargo, donc aucune bibliothèque système n'est nécessaire.

Les téléchargements macOS et Linux du site sont fabriqués par ./package-unix.sh, qui compile nikpak et unNik et les empaquette avec un install.sh dans binaries\nikpak--macos.zip (un binaire universel : Intel + Apple silicon) ou binaries\nikpak--linux-.tar.gz. Définissez ZIG=1 sur Linux pour compiler avec cargo-zigbuild contre la glibc 2.28, afin que les programmes fonctionnent aussi sur les anciennes distributions.

13.5 Dépendances

Depuis la version 1.2, nikpak nécessite Rust 1.89 ou plus récent. build.ps1 et build.sh vérifient la version installée et exécutent rustup update stable lorsqu'elle est plus ancienne. Avec npm, exécutez rustup update une fois avant npm run build.

nikpak dépend d'un petit ensemble de crates matures. Leurs versions exactes sont figées dans Cargo.lock, qui fait partie du paquet source, de sorte que chaque compilation utilise le même code.

Crate	But
zstd	Compression Zstandard, avec multi-threading
chacha20poly1305	XChaCha20-Poly1305 et la construction STREAM (RustCrypto)
argon2	Dérivation de clé Argon2id (RustCrypto)
rand	Accès au générateur aléatoire sûr du système d'exploitation
zeroize	Effacement des clés et des mots de passe de la mémoire
rpassword	Lecture d'un mot de passe sans écho, sur chaque plateforme
crc32fast	CRC32 rapide
glob	Développement des caractères génériques (PowerShell ne développe pas les caractères génériques pour les programmes natifs)
liblzma	Moteur LZMA2 pour -m5 (liblzma, compilé statiquement depuis les sources C)
ppmd-rust	Moteur PPMd variante I pour le texte à -m5
preflate-rs	Recompression Deflate exacte au bit près (Microsoft, Apache-2.0) ; une copie vendored dans vendor/preflate-rs dont le codeur d'entropie LGPL (cabac) est remplacé par le propre codeur à plages de nikpak, de sorte que nikpak ne contient aucun code LGPL. Nécessite Rust 1.89 ou plus récent
eframe / egui	L'interface graphique (fonctionnalité cargo optionnelle gui, activée par défaut)
rfd	Boîte de dialogue de dossier native pour Parcourir
ed25519-dalek	Vérification des signatures de clés de licence (section 3.8)
rustybuzz, unicode-bidi	Mise en forme et ordre de droite à gauche du hindi, du bengali et de l'arabe dans la fenêtre (fonctionnalité cargo optionnelle gui)

13.6 Scripts

Des codes de sortie prévisibles et le mot de passe par variable d'environnement rendent nikpak facile à scripter. Une sauvegarde PowerShell qui considère les avertissements comme acceptables et tout ce qui est pire comme un échec :

$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" }

La même chose dans un script shell, en utilisant la commande de liste brute pour alimenter d'autres outils :

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

L'intégration décrite dans la section 3.6 repose sur le fait que nikpak suit la syntaxe de RAR. Une courte liste de vérification : enregistrez l'extension nik ; utilisez a pour empaqueter et x pour dépaqueter ; laissez le frontal transmettre @listfile pour les longues listes de fichiers ; donnez -o+ ou -y pour une extraction sans surveillance ; et transmettez le mot de passe avec -p ou la variable NIKPAK_PASSWORD, car un frontal graphique n'a pas de console sur laquelle demander.

14 Tests et vérification

Parce qu'un archiveur détient les données des gens, nikpak est testé à quatre niveaux.

14.1 Tests unitaires

Trente-quatre tests automatisés s'exécutent avec cargo test --release :

Domaine	Ce qui est vérifié
Flux de chiffrement	Allers-retours à 0, 1, 100, 65 535, 65 536, 65 537, 131 072, 131 077 et 327 803 octets (autour des frontières de blocs de 64 KiB) ; un mauvais en-tête (données associées), une mauvaise clé et la troncature doivent tous échouer.
Limites de dérivation de clé	Les paramètres Argon2id hostiles (mémoire énorme, zéro passe, zéro voie, passes excessives) sont refusés.
Codec audio NAC	Aller-retour sans perte pour l'audio 8/16/24/32 bits, 1, 2, 3 et 6 canaux, neuf types de signaux (silence, sinusoïde bruitée, bruit blanc, onde carrée pleine échelle, rampe, impulsion unique, maximum constant, bits bas gaspillés, minimum constant), huit longueurs de bloc de 1 à 5000 échantillons, trois niveaux d'effort et le codage verbatim forcé.
Méthodes audio	NAC, Shuffle et Shuffle+Delta sur toutes les profondeurs de bits, nombres de canaux, ordres d'octets et signes, y compris les blocs qui ne se divisent pas de façon égale.
Détection et fichiers	WAV (mono, stéréo, 8/16/24/32 bits, extensible, six canaux, blocs de fin, octets restants impairs, longueur de données nulle et trop grande), AIFF, MOD (aussi tronqués) et BMP (8/24/32 bits, rembourrage de ligne, données de fin) ; les WAV à virgule flottante, les petits fichiers et le texte ne doivent pas être détectés ; chaque fichier fait un aller-retour à travers chaque filtre applicable.
Robustesse	Des milliers de blocs aléatoires et à bits inversés soumis au décodeur audio et au décodeur média : ils doivent renvoyer des erreurs, jamais paniquer ni épuiser la mémoire.
Découpage et aides	Découpage en blocs avec données de fin, assainissement des chemins, correspondance de caractères génériques et de filtres, formatage des dates, génération de mot de passe.
Recompression Deflate	Conteneurs ZIP aux niveaux Deflate 1, 3, 6 et 9, PDF avec deux flux zlib, gzip à trois membres, non-conteneurs ; 400 flux recompressés endommagés ou tronqués doivent échouer proprement (les paniques de preflate sont interceptées).
Blocs multi-moteurs	Allers-retours à travers les blocs zstd, LZMA2 et PPMd autour de la frontière de trame de 256 KiB ; 300 corps endommagés ou tronqués ; paramètres de moteur hostiles ; l'essai PPMd/LZMA2.
Interface graphique	Exécutés sur un affichage virtuel (Xvfb) : écrans d'attente, de survol, de progression et de fin vérifiés visuellement ; un dossier déposé archivé et extrait octet pour octet ; Annuler et fermer pendant la compression ne laissent aucun fichier derrière ; sans affichage, repli sur le texte d'aide.
Licence	Les clés fabriquées par nikpak-keygen et par le kit PHP sont identiques et acceptées ; un nom, e-mail, type ou clé modifié, et les clés signées par une autre clé, sont rejetés. Sur un affichage virtuel : rappel dans les deux ordres de boutons, erreur de mauvaise clé, enregistrement réussi, redémarrage sans rappel ; le texte reste à l'intérieur des boîtes.
Langues	Chaque langue traduit chaque texte avec les mêmes espaces réservés ; les signes vocaliques dévanagari et la jointure arabe sont mis en forme ; sur un affichage virtuel, les dix langues ont été vérifiées écran par écran (rappel, attente, progression, fin, À propos, enregistrement, menu des langues) ; choisir une langue l'enregistre et redémarre nikpak dans cette langue.
API d'archive	Lecture de l'index, extraction d'un fichier à l'intérieur d'un dossier (il arrive sans le chemin du dossier), suppression d'un dossier avec son contenu et suppression de tout, pour les archives -m5, zstd + chiffrement et stockées ; un mauvais mot de passe est signalé comme tel.
Explorateur d'archives	Construction de l'arborescence avec dossiers implicites, détection et décodage de texte (UTF-8, UTF-16, Windows-1252), retour à la ligne et recherche dans la visionneuse. Sur un affichage virtuel : ouverture, mot de passe, navigation, sélection, recherche, visionneuse, extraction, suppression et test, dans plusieurs langues.
Skins et menu du gestionnaire de fichiers	Les fichiers de menu Linux sont générés et vérifiés ; une archive pour une sélection démarrée comme trois programmes ; --add-here avec trois éléments et --extract-here / --extract-to sous un affichage virtuel ; les archives chiffrées demandent leur mot de passe et extraient des fichiers identiques ; chaque nouveau texte d'interface est traduit dans les dix langues (l'assertion chaque-langue-traduit-chaque-texte).

14.2 Tests de bout en bout

• Chaque archive de benchmark a été extraite et comparée à sa source, octet pour octet (SHA-256 pour le jeu de 10 949 fichiers), à plusieurs niveaux.
• Une archive mixte (WAV, MOD, BMP, texte, données aléatoires, sous-dossiers) a été créée, listée, testée, extraite complètement, et un seul fichier a été extrait de son milieu.
• La même archive a été créée avec chiffrement, testée avec le bon et le mauvais mot de passe, puis extraite.
• Les archives écrites par la version de format précédente (1.0) ont été ouvertes par la 1.1.
• La saisie interactive du mot de passe a été exercée via un pseudo-terminal : mots de passe correspondants, une non-correspondance, une saisie vide (génération), bons et mauvais mots de passe à l'ouverture.

14.3 Tests d'attaque

L'altération, la troncature, le réordonnancement de blocs, la manipulation d'en-tête, les fichiers poubelle et les archives à traversée de chemin de la section 10.1 ont été exécutés contre chaque version candidate. Les résultats sont tabulés dans les sections 8.6 et 10.1 ; le résultat attendu dans chaque cas est un refus, un message clair et un code de sortie non nul, jamais une panique et jamais une écriture hors de la destination.

14.4 Défauts trouvés par les tests

La campagne de tests est la raison pour laquelle plusieurs défauts n'existent pas dans le programme publié. Deux exemples : une recherche de paramètre de Rice qui échouait pour l'audio 32 bits et aurait écrit un code de plusieurs gigaoctets (trouvée par la matrice de tests unitaires et corrigée), et un échec de somme de contrôle zstd qui était signalé avec le code de sortie générique 2 au lieu de 3 (trouvé dans les tests d'altération et corrigé). Un troisième exemple est la méthodologie de benchmark elle-même : la première comparaison avec RAR utilisait son défaut non solide, ce qui flattait nikpak sur le code source ; elle a été refaite en mode solide, et les résultats du chapitre 11 sont les corrigés.

15 Limites et feuille de route

15.1 Limites actuelles

Limite	Détail et contournement
Pas d'enregistrements de récupération, de volumes ni de SFX	Les dommages sont détectés, pas réparés (gardez une seconde copie des archives importantes) ; découpez les grandes archives avec un outil général si nécessaire.
Pas de mise à jour sur place	Le format est un flux solide unique. Supprimer (nikpak d, ou Supprimer dans unNik) réécrit l'archive ; ajouter des fichiers à une archive existante n'est pas pris en charge : créez une nouvelle archive, ou écrasez avec -o+.
Accès séquentiel	Extraire un fichier d'une très grande archive lit ce qui le précède (les entrées média sont sautées sans décodage) ; unNik cesse de lire après le dernier fichier choisi.
Couverture des médias	WAV et AIFF en PCM entier, ProTracker MOD, BMP non compressé. Les WAV à virgule flottante, ADPCM, XM/S3M/IT et les images compressées sont stockés avec une compression normale.
Mémoire aux niveaux élevés	Les archives -m4 et -m5 utilisent une fenêtre de 128 MiB ; les décompresser nécessite autant de mémoire.
Niveau maximal -m5	Single-threaded and the slowest level. Creating needs up to about 1.1 GB of memory, extracting up to about 350 MB.
Liens symboliques et dates	Les liens sont ignorés à l'archivage et refusés à l'extraction ; les dates sont listées en UTC.
Revue de sécurité	Pas audité de façon indépendante.
Compilations Windows et macOS	Développé, testé et benchmarké sur Linux. Les chemins de code spécifiques à Windows et macOS ont été relus à la main mais n'ont pas encore été exercés sur ces systèmes : exécutez cargo test --release là-bas avant de vous fier à une compilation.

15.2 Feuille de route

Élément	But
Enregistrements de récupération	Parité Reed-Solomon afin que les archives endommagées puissent être réparées, la principale fonctionnalité qui manque aux utilisateurs de RAR.
Archives multivolumes et prise en charge de la mise à jour	Découpage de grandes archives, ajout et remplacement de fichiers.
Partage à clé publique avec un schéma hybride	Chiffrer une archive vers la clé d'un destinataire avec X25519 combiné à ML-KEM, sûr si l'un des composants tient.
Davantage de filtres média	Audio à virgule flottante, trackers XM/S3M/IT, recompression du PNG, un filtre 2-D pour TGA et TIFF non compressé.
Lecture de ZIP et de RAR, intégration au shell	Dépaqueter les formats courants dans unNik et faire glisser des fichiers hors d'unNik, afin que nikpak puisse être le seul outil installé. (Les menus contextuels d'Explorer et du Finder sont arrivés dans la 1.5.5, section 3.11.)
Niveau maximal plus rapide	-m5 est mono-thread et jusqu'à trois fois plus lent que 7-Zip -mx9 sur les fichiers Office : blocs LZMA2 et PPMd multi-threads, déduplication de fichiers identiques, et un filtre BCJ pour les exécutables.
Revue de sécurité externe	Un audit indépendant du code cryptographique et de l'extracteur.

Licence : NikPak est un shareware à source fermée, © 2026 Nicolas Choukroun, distribué par Nikkoid LLC (LICENSE.txt, section 3.8) ; unNik est un freeware (section 3.9). Les composants open source qu'il contient sont listés avec leurs licences dans THIRD-PARTY-NOTICES.txt, qui doit être livré avec chaque copie. Gardez la clé de licence privée (keys/nikpak-private.key) hors de tout paquet publié et hors de la racine web. Gardez Cargo.lock dans le dépôt afin que les compilations soient reproductibles, et exécutez cargo test --release dans la tâche d'intégration continue de chaque plateforme que vous prenez en charge.

A Annexe A : constantes et limites du format

Élément	Valeur
Nombre magique	89 4E 49 4B 0D 0A 1A 0A
Version du format	3 (les lecteurs acceptent 1, 2 et 3)
Taille de l'en-tête	12 octets ; 59 octets lorsqu'il est chiffré
Types d'enregistrement	0 END, 1 FILE, 2 DIR, 3 MEDIA
Méthodes d'archive	0 stockage, 1 Zstandard, 2 blocs multi-moteurs
Moteurs de bloc	1 Zstandard ; 2 LZMA2 (dictionnaire jusqu'à 128 MiB écrits, 1.5 GiB acceptés) ; 3 PPMd8 (ordre 8, 192 MiB écrits ; ordre 2-16, 1 GiB accepté)
Recompression Deflate	ZIP, PDF, gzip ; fichier jusqu'à 512 MiB ; par flux jusqu'à 512 MiB de données en clair et 64 MiB de corrections
Longueur maximale de nom	4096 octets
Bloc chiffré	64 KiB de texte en clair + étiquette de 16 octets, longueur u32 gros-boutiste devant
Argon2id (écrit)	64 MiB, 3 passes, 4 voies, sel de 16 octets, clé de 32 octets
Argon2id (accepté)	mémoire 8 x voies .. 1 GiB, passes 1 .. 64, voies 1 .. 64
Nonce de flux	préfixe aléatoire de 19 octets + compteur 32 bits + drapeau de fin de 1 octet = 24 octets
Longueur minimale du mot de passe	8 caractères
Mot de passe généré	24 caractères, alphabet de 56 symboles, environ 139 bits
Taille minimale de fichier média	8 KiB (région d'au moins 4 KiB)
Bloc NAC	4096 trames d'échantillons ; bloc Shuffle de 32768 trames
Essai	jusqu'à trois fenêtres de 768 KiB (5 %, 45 %, 85 %) ; région entière si jusqu'à 3 MiB ; marge de 2 %
Limite de région BMP	256 MiB
Fenêtre Zstandard	par défaut ; 2^27 avec correspondance longue distance à -m4 et -m5
Threads	1 .. 256 (-mt)

B Annexe B : glossaire

Terme	Signification
AEAD	Chiffrement authentifié avec données associées : chiffre et détecte toute modification, y compris des données envoyées en clair (comme l'en-tête).
Argon2id	Une fonction de hachage de mot de passe à coût mémoire élevé normalisée dans la RFC 9106 ; transforme un mot de passe en clé à un coût mémoire délibérément élevé.
CRC32	Une somme de contrôle de 32 bits qui détecte les dommages accidentels. Ce n'est pas une fonction de sécurité.
FSE	Entropie à états finis : le codeur d'entropie piloté par tables utilisé par Zstandard.
Algorithme de Grover	Un algorithme de recherche quantique avec une accélération quadratique ; réduit de moitié la longueur effective des clés symétriques.
LPC	Codage prédictif linéaire : prédire un échantillon à partir d'une somme pondérée des précédents.
Levinson-Durbin	Une récursion qui calcule les coefficients de prédicteur optimaux de chaque ordre à partir de l'autocorrélation d'un signal.
LZMA2	L'algorithme en chaîne de Lempel-Ziv-Markov utilisé par 7-Zip et xz : correspondance LZ77 avec analyse optimale et un codeur à plages binaire.
MED	Détecteur médian de contours : un prédicteur de pixels du codeur d'images LOCO-I / JPEG-LS.
À coût mémoire élevé	Une fonction dont le coût est dominé par la mémoire, ce qui limite l'accélération disponible avec les GPU et les puces personnalisées.
NAC	Le codec audio sans perte de nikpak.
PPMd	Prediction by Partial Matching (variante I) : prédit chaque octet à partir des jusqu'à 8 octets précédents ; très fort sur le texte.
preflate	Une méthode (et une bibliothèque) qui transforme un flux Deflate en ses données en clair plus de petites corrections, à partir desquelles le flux Deflate identique peut être reconstruit.
Codage de Rice	Un code simple et rapide pour les nombres à distribution à peu près géométrique : un quotient unaire et un nombre fixe de bits bas.
Algorithme de Shor	Un algorithme quantique qui factorise des entiers et calcule des logarithmes discrets, cassant RSA et la cryptographie à courbes elliptiques.
Archive solide	Une archive compressée comme un flux continu unique, de sorte que la redondance entre les fichiers peut être exploitée.
STREAM	Une construction qui chiffre un long message sous forme de blocs authentifiés avec compteur et drapeau de dernier bloc dans le nonce.
Mappage en zigzag	Mappage des entiers signés vers des entiers non signés (0, -1, 1, -2 ... vers 0, 1, 2, 3 ...), de sorte que les petites magnitudes deviennent de petits nombres.
Zstandard	Un format de compression moderne et ouvert combinant la correspondance LZ77 avec le codage d'entropie Huffman et FSE.

Version 1.6.2 · Octobre 2026 Page 19