Pourquoi le codage base64 nécessite-t-il un remplissage si la longueur d'entrée n'est pas divisible par 3?

Quel est le but du remplissage dans l'encodage base64. Ce qui suit est l'extrait de wikipedia:

"Un caractère de remplissage supplémentaire est alloué et peut être utilisé pour forcer la sortie codée en un multiple entier de 4 caractères (ou de manière équivalente lorsque le texte binaire non codé n'est pas un multiple de 3 octets); ces caractères de remplissage doivent alors être ignorés lors du décodage mais autorise toujours le calcul de la longueur effective du texte non codé, lorsque sa longueur binaire d'entrée ne serait pas un multiple de 3 octets (le dernier caractère non-pad est normalement codé de sorte que le dernier bloc de 6 bits qu'il représente soit nul -padded sur ses bits les moins significatifs, au plus deux caractères de remplissage peuvent apparaître à la fin du flux codé). "

J'ai écrit un programme qui pouvait encoder en base64 n'importe quelle chaîne et décoder n'importe quelle chaîne encodée en base64. Quel problème le rembourrage résout-il?

Votre conclusion selon laquelle le rembourrage n'est pas nécessaire est juste. Il est toujours possible de déterminer la longueur de l'entrée sans ambiguïté à partir de la longueur de la séquence codée.

Cependant, le remplissage est utile dans les situations où les chaînes codées en base64 sont concaténées de telle manière que les longueurs des séquences individuelles sont perdues, comme cela pourrait arriver, par exemple, dans un protocole de réseau très simple.

Si les chaînes non ajoutées sont concaténées, il est impossible de récupérer les données d'origine car les informations sur le nombre d'octets impairs à la fin de chaque séquence individuelle sont perdues. Cependant, si des séquences remplies sont utilisées, il n'y a pas d'ambiguïté et la séquence dans son ensemble peut être décodée correctement.

Edit: une illustration

Supposons que nous ayons un programme qui code les mots en base64, les concatène et les envoie sur un réseau. Il encode "I", "AM" et "TJM", prend en sandwich les résultats ensemble sans remplissage et les transmet.

• Iencode SQ( SQ==avec remplissage)
• AMencode QU0( QU0=avec remplissage)
• TJMencode VEpN( VEpNavec remplissage)

Donc, les données transmises sont SQQU0VEpN. Le récepteur base64-décode ceci comme I\x04\x14\xd1Q)au lieu de l'intention IAMTJM. Le résultat est absurde car l'expéditeur a détruit les informations sur la fin de chaque mot dans la séquence codée. Si l'expéditeur avait envoyé à la SQ==QU0=VEpNplace, le récepteur aurait pu le décoder sous la forme de trois séquences base64 distinctes qui se concaténeraient pour donner IAMTJM.

Pourquoi s'embêter avec le rembourrage?

Pourquoi ne pas simplement concevoir le protocole pour préfixer chaque mot avec une longueur entière? Ensuite, le récepteur pourrait décoder le flux correctement et il n'y aurait pas besoin de remplissage.

C'est une excellente idée, tant que nous connaissons la longueur des données que nous encodons avant de commencer à les encoder. Mais que se passerait-il si, au lieu de mots, nous encodions des morceaux de vidéo à partir d'une caméra en direct? Nous pourrions ne pas connaître la longueur de chaque morceau à l'avance.

Si le protocole utilisait un remplissage, il n'y aurait aucun besoin de transmettre une longueur. Les données pourraient être encodées au fur et à mesure qu'elles venaient de la caméra, chaque morceau se terminant par un remplissage, et le récepteur serait capable de décoder le flux correctement.

C'est évidemment un exemple très artificiel, mais cela illustre peut-être pourquoi le rembourrage pourrait être utile dans certaines situations.

Sur une note connexe, voici un convertisseur de base pour la conversion de base arbitraire que j'ai créé pour vous. Prendre plaisir! https://convert.zamicol.com/

Que sont les caractères de remplissage?

Les caractères de remplissage aident à satisfaire les exigences de longueur et n'ont aucune signification.

Exemple décimal de remplissage: étant donné l'exigence arbitraire que toutes les chaînes doivent avoir une longueur de 8 caractères, le nombre 640 peut répondre à cette exigence en utilisant les 0 précédents comme caractères de remplissage car ils n'ont aucune signification, "00000640".

Encodage binaire

Le paradigme de l'octet: l'octet est l'unité de mesure standard de facto et tout schéma de codage doit se rapporter aux octets.

Base256 s'inscrit exactement dans ce paradigme. Un octet est égal à un caractère en base256.

Base16 , hexadécimal ou hexadécimal, utilise 4 bits pour chaque caractère. Un octet peut représenter deux caractères base16.

Base64 ne rentre pas uniformément dans le paradigme octet (pas plus que base32), contrairement à base256 et base16. Tous les caractères base64 peuvent être représentés en 6 bits, 2 bits à court d'un octet complet.

Nous pouvons représenter le codage base64 par rapport au paradigme octet sous forme de fraction: 6 bits par caractère sur 8 bits par octet . Cette fraction est réduite de 3 octets sur 4 caractères.

Ce ratio, 3 octets pour 4 caractères base64, est la règle que nous voulons suivre lors de l'encodage base64. L'encodage Base64 ne peut que promettre une mesure même avec des faisceaux de 3 octets, contrairement à base16 et base256 où chaque octet peut être autonome.

Alors pourquoi le remplissage est-il encouragé même si l'encodage pourrait fonctionner correctement sans les caractères de remplissage?

Si la longueur d'un flux est inconnue ou s'il peut être utile de savoir exactement quand un flux de données se termine, utilisez le remplissage. Les caractères de remplissage indiquent explicitement que ces points supplémentaires doivent être vides et excluent toute ambiguïté. Même si la longueur est inconnue avec le remplissage, vous saurez où se termine votre flux de données.

À titre d'exemple, certaines normes comme JOSE n'autorisent pas les caractères de remplissage. Dans ce cas, s'il manque quelque chose, une signature cryptographique ne fonctionnera pas ou d'autres caractères non base64 seront manquants (comme le "."). Bien que des hypothèses sur la longueur ne soient pas faites, le remplissage n'est pas nécessaire car s'il y a quelque chose qui ne va pas, cela ne fonctionnera tout simplement pas.

Et c'est exactement ce que dit la RFC base64 ,

Dans certaines circonstances, l'utilisation du remplissage ("=") dans les données codées en base n'est ni requise ni utilisée. Dans le cas général, lorsque des hypothèses sur la taille des données transportées ne peuvent être faites, un remplissage est nécessaire pour produire des données décodées correctes.

[...]

L'étape de remplissage en base 64 [...] si elle est mal implémentée, conduit à des altérations non significatives des données codées. Par exemple, si l'entrée n'est qu'un octet pour un codage en base 64, alors les six bits du premier symbole sont utilisés, mais seuls les deux premiers bits du symbole suivant sont utilisés. Ces bits de remplissage DOIVENT être mis à zéro par des codeurs conformes, ce qui est décrit dans les descriptions sur le remplissage ci-dessous. Si cette propriété ne tient pas, il n'y a pas de représentation canonique des données codées en base, et plusieurs chaînes codées en base peuvent être décodées en les mêmes données binaires. Si cette propriété (et d'autres discutées dans ce document) tient, un encodage canonique est garanti.

Le remplissage nous permet de décoder l'encodage base64 avec la promesse de ne pas perdre de bits. Sans remplissage, il n'y a plus d'acquittement explicite de la mesure dans des faisceaux de trois octets. Sans remplissage, vous ne pourrez peut-être pas garantir la reproduction exacte de l'encodage original sans informations supplémentaires généralement provenant d'un autre endroit de votre pile, comme TCP, des sommes de contrôle ou d'autres méthodes.

Exemples

Voici l'exemple de formulaire RFC 4648 ( http://tools.ietf.org/html/rfc4648#section-8 )

Chaque caractère à l'intérieur de la fonction "BASE64" utilise un octet (base256). Nous traduisons ensuite cela en base64.

BASE64("")       = ""           (No bytes used. 0%3=0.)
BASE64("f")      = "Zg=="       (One byte used. 1%3=1.)
BASE64("fo")     = "Zm8="       (Two bytes. 2%3=2.)
BASE64("foo")    = "Zm9v"       (Three bytes. 3%3=0.)
BASE64("foob")   = "Zm9vYg=="   (Four bytes. 4%3=1.)
BASE64("fooba")  = "Zm9vYmE="   (Five bytes. 5%3=2.)
BASE64("foobar") = "Zm9vYmFy"   (Six bytes. 6%3=0.)

Voici un encodeur avec lequel vous pouvez jouer: http://www.motobit.com/util/base64-decoder-encoder.asp

Il n'y a pas beaucoup d'avantages à cela de nos jours. Donc , le regard let cela comme une question de ce que l' origine peut avoir été but historique.

L'encodage Base64 fait sa première apparition dans la RFC 1421 datée de 1993. Cette RFC est en fait centrée sur le cryptage des e-mails, et base64 est décrite dans une petite section 4.3.2.4 .

Cette RFC n'explique pas le but du remplissage. Le plus proche que nous ayons d'une mention du but initial est cette phrase:

Un quantum de codage complet est toujours terminé à la fin d'un message.

Cela ne suggère pas la concaténation (réponse du haut ici), ni la facilité de mise en œuvre comme objectif explicite du remplissage. Cependant, compte tenu de la description entière, il n'est pas déraisonnable de supposer que cela peut avoir été destiné à aider le décodeur à lire l'entrée en unités de 32 bits ( "quanta" ). Cela ne sert à rien aujourd'hui, mais en 1993, un code C dangereux aurait très probablement profité de cette propriété.