Pourquoi un fichier chiffré serait-il ~ 35% plus volumineux qu'un fichier non chiffré?
Selon la documentation ownCloud , si vous activez le cryptage, les tailles de fichier peuvent être ~ 35% plus grandes que leurs formes non cryptées.
D'après ma compréhension du chiffrement, les tailles de fichier devraient être plus ou moins identiques (peut-être quelques bits 0 complétés à la fin pour en faire un multiple de la taille de la clé).
Est-ce que c'est incorrect? Sinon, pourquoi?
Très probablement, le fichier crypté est codé en base64, ce qui représenterait une augmentation de 33,3% du fichier (vous codez trois octets de données en quatre octets de données en base64). L'insertion d'une nouvelle ligne tous les 64 caractères pour faciliter la lecture (comme cela se fait par ASCII armure dans openssl, GPG, PGP) augmentera la taille de 65/64.
En combinant ces deux effets, le nouveau fichier est (4/3) * (65/64) = 135,4% de la taille de l'original ou une augmentation de la taille du fichier de 35,4%.
J'ai parcouru le calcul dans cette réponse ici .
Vous avez raison, cependant, le chiffrement ne devrait pas avoir besoin de modifier considérablement la taille du fichier. Il ajoute éventuellement quelques blocs de données s'il y a un en-tête, un vecteur d'initialisation/nonce, un rembourrage pour en faire un bloc complet et/ou MAC pour vérifier l'intégrité, bien que ces modifications soient insignifiantes pour les gros fichiers (par exemple, en ajoutant quatre les blocs d'un fichier codé AES de 1 Mo augmenteraient le fichier de 0,006%).
Cependant, pour ne pas augmenter la taille des fichiers, vous devez être bien avec le stockage et la transmission des données chiffrées sous forme de binaire arbitraire. Les binaires arbitraires sont souvent bloqués par courrier électronique pour empêcher la propagation de virus informatiques et sont souvent difficiles à ouvrir en dehors des hexéditeurs. Les fichiers encodés en Base64 sont plus faciles à transmettre et sont un format plus portable que les fichiers binaires d'un type de fichier inconnu.
Si les fichiers sont en cours de compression, vous pouvez constater cette différence.
Les algorithmes de compression fonctionnent mieux sur des données non aléatoires. Le chiffrement vise à générer un caractère aléatoire à partir des informations. Les informations sont généralement faciles à compresser car elles ont des motifs. Cependant, si vous le cryptez, vous effacez généralement tous les modèles (et informations).
Exemple: 2,75 Go de fichiers d'archive de messagerie peuvent être facilement compressés à <0,5 Go. Si ces archives de courrier électronique étaient cryptées, la version compressée serait alors beaucoup plus proche de 2,75 Go.
Normalement, la marque% indique que le fichier peut être codé en Base64 après le cryptage, et peut également obtenir une somme de contrôle sur chaque bloc pour éviter la corruption. Base64 code les caractères de 8 bits en caractères de 6 bits, ce qui signifie que le fichier en question est environ 30% plus volumineux en raison du nombre de caractères requis pour rendre le fichier entier. Ajoutez une somme de contrôle par bloc et vous êtes jusqu'à 35%.
Normalement, le cryptage lui-même ajoute une surcharge. Normalement, la surcharge est en-tête + pied de page, clé cryptée éventuelle, paramètres, sels, somme de contrôle, et également une taille de bloc moins 1, car si les données cryptées ne sont pas divisibles de manière égale avec la taille du bloc, vous devrez remplir avec jusqu'au bloc taille - 1.
Mais toutes ces données dans la phrase précédente ajouteraient une quantité statique de données à chaque fichier, quelle que soit sa taille, même si sa taille est de 1 ou 100 Go.
L'agrandissement des données exprimé en% indique qu'il s'agit d'un processus de réencodage comme base64 ou quelque chose de similaire.