¿Por qué la codificación base64 requiere relleno si la longitud de entrada no es divisible por 3?

¿Cuál es el propósito del relleno en la codificación base64? El siguiente es el extracto de wikipedia:

"Se asigna un carácter de relleno adicional que se puede utilizar para forzar la salida codificada en un múltiplo entero de 4 caracteres (o de manera equivalente cuando el texto binario no codificado no es un múltiplo de 3 bytes); estos caracteres de relleno deben descartarse al decodificar pero todavía permiten el cálculo de la longitud efectiva del texto no codificado, cuando su longitud binaria de entrada no sería un múltiplo de 3 bytes (el último carácter no pad se codifica normalmente de modo que el último bloque de 6 bits que representa sea cero -agregado en sus bits menos significativos, como máximo pueden aparecer dos caracteres de relleno al final de la secuencia codificada).

Escribí un programa que podía codificar en base64 cualquier cadena y decodificar cualquier cadena codificada en base64. ¿Qué problema resuelve el acolchado?

Su conclusión de que el relleno es innecesario es correcta. Siempre es posible determinar la longitud de la entrada sin ambigüedades a partir de la longitud de la secuencia codificada.

Sin embargo, el relleno es útil en situaciones donde las cadenas codificadas en base64 se concatenan de tal manera que se pierden las longitudes de las secuencias individuales, como podría suceder, por ejemplo, en un protocolo de red muy simple.

Si se concatenan cadenas sin relleno, es imposible recuperar los datos originales porque se pierde información sobre el número de bytes impares al final de cada secuencia individual. Sin embargo, si se utilizan secuencias rellenas, no hay ambigüedad y la secuencia en su conjunto se puede decodificar correctamente.

Editar: una ilustración

Supongamos que tenemos un programa que codifica palabras en base64, las concatena y las envía a través de una red. Codifica "I", "AM" y "TJM", empareja los resultados sin rellenar y los transmite.

• Icodifica a SQ( SQ==con relleno)
• AMcodifica a QU0( QU0=con relleno)
• TJMcodifica a VEpN( VEpNcon relleno)

Entonces los datos transmitidos son SQQU0VEpN. El receptor base64-decodifica esto como en I\x04\x14\xd1Q)lugar de lo previsto IAMTJM. El resultado es una tontería porque el remitente ha destruido información sobre dónde termina cada palabra en la secuencia codificada. Si el remitente hubiera enviado en su SQ==QU0=VEpNlugar, el receptor podría haber decodificado esto como tres secuencias base64 separadas que se concatenarían para dar IAMTJM.

¿Por qué molestarse con el acolchado?

¿Por qué no diseñar el protocolo para prefijar cada palabra con una longitud entera? Entonces, el receptor podría decodificar la secuencia correctamente y no habría necesidad de relleno.

Es una gran idea, siempre que sepamos la longitud de los datos que estamos codificando antes de empezar a codificarlos. Pero, ¿y si, en lugar de palabras, codificamos fragmentos de video de una cámara en vivo? Es posible que no sepamos la longitud de cada fragmento de antemano.

Si el protocolo usara relleno, no habría necesidad de transmitir una longitud en absoluto. Los datos podrían codificarse a medida que ingresaban desde la cámara, cada fragmento terminaba con relleno y el receptor podría decodificar la transmisión correctamente.

Obviamente, ese es un ejemplo muy elaborado, pero tal vez ilustra por qué el relleno podría ser útil en algunas situaciones.

En una nota relacionada, aquí hay un convertidor de base para la conversión de base arbitraria que creé para usted. ¡Disfrutar! https://convert.zamicol.com/

¿Qué son los caracteres de relleno?

Los caracteres de relleno ayudan a satisfacer los requisitos de longitud y no tienen significado.

Ejemplo decimal de relleno: dado el requisito arbitrario de que todas las cadenas tengan 8 caracteres de longitud, el número 640 puede cumplir con este requisito utilizando ceros anteriores como caracteres de relleno, ya que no tienen significado, "00000640".

Codificación binaria

El paradigma del byte: el byte es la unidad de medida estándar de facto y cualquier esquema de codificación debe relacionarse con los bytes.

Base256 encaja exactamente en este paradigma. Un byte es igual a un carácter en base256.

Base16 , hexadecimal o hexadecimal, utiliza 4 bits para cada carácter. Un byte puede representar dos caracteres base16.

Base64 no encaja uniformemente en el paradigma de bytes (ni base32), a diferencia de base256 y base16. Todos los caracteres base64 se pueden representar en 6 bits, 2 bits menos que un byte completo.

Podemos representar la codificación base64 frente al paradigma de bytes como una fracción: 6 bits por carácter sobre 8 bits por byte . Reducida esta fracción es de 3 bytes sobre 4 caracteres.

Esta proporción, 3 bytes por cada 4 caracteres base64, es la regla que queremos seguir al codificar base64. La codificación Base64 solo puede prometer una medición uniforme con paquetes de 3 bytes, a diferencia de base16 y base256, donde cada byte puede ser independiente.

Entonces, ¿ por qué se recomienda el relleno a pesar de que la codificación podría funcionar bien sin los caracteres de relleno?

Si se desconoce la longitud de una secuencia o si podría ser útil saber exactamente cuándo termina una secuencia de datos, utilice el relleno. Los caracteres de relleno comunican explícitamente que esos espacios adicionales deben estar vacíos y descarta cualquier ambigüedad. Incluso si se desconoce la longitud con el relleno, sabrá dónde termina su flujo de datos.

Como contraejemplo, algunos estándares como JOSE no permiten caracteres de relleno. En este caso, si falta algo, una firma criptográfica no funcionará o faltarán otros caracteres que no sean base64 (como el "."). Aunque no se hacen suposiciones sobre la longitud, el relleno no es necesario porque si hay algo mal, simplemente no funcionará.

Y esto es exactamente lo que dice el RFC base64 ,

En algunas circunstancias, no se requiere ni se utiliza el uso de relleno ("=") en datos codificados en base. En el caso general, cuando no se pueden hacer suposiciones sobre el tamaño de los datos transportados, se requiere el relleno para producir datos decodificados correctos.

[...]

El paso de relleno en base 64 [...] si se implementa incorrectamente, conduce a alteraciones no significativas de los datos codificados. Por ejemplo, si la entrada es solo un octeto para una codificación base 64, entonces se usan los seis bits del primer símbolo, pero solo se usan los primeros dos bits del siguiente símbolo. Estos bits de relleno DEBEN ponerse a cero mediante codificadores conformes, que se describen en las descripciones de relleno a continuación. Si esta propiedad no se cumple, no existe una representación canónica de datos codificados en base y se pueden decodificar múltiples cadenas codificadas en base a los mismos datos binarios. Si esta propiedad (y otras discutidas en este documento) se mantiene, se garantiza una codificación canónica.

El relleno nos permite decodificar la codificación base64 con la promesa de no perder bits. Sin relleno, ya no existe el reconocimiento explícito de medir en paquetes de tres bytes. Sin relleno, es posible que no pueda garantizar la reproducción exacta de la codificación original sin información adicional, generalmente de algún otro lugar de su pila, como TCP, sumas de comprobación u otros métodos.

Ejemplos

Aquí está el formulario de ejemplo RFC 4648 ( http://tools.ietf.org/html/rfc4648#section-8 )

Cada carácter dentro de la función "BASE64" usa un byte (base256). Luego traducimos eso a 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.)

Aquí hay un codificador con el que puede jugar: http://www.motobit.com/util/base64-decoder-encoder.asp

No tiene mucho beneficio en la actualidad. Así que veamos esto como una cuestión de cuál pudo haber sido el propósito histórico original .

La codificación Base64 hace su primera aparición en RFC 1421 con fecha de 1993. Esta RFC en realidad se centra en el cifrado de correo electrónico, y base64 se describe en una pequeña sección 4.3.2.4 .

Este RFC no explica el propósito del relleno. Lo más cercano que tenemos a una mención del propósito original es esta oración:

Un cuanto de codificación completo siempre se completa al final de un mensaje.

No sugiere la concatenación (respuesta superior aquí), ni la facilidad de implementación como un propósito explícito para el relleno. Sin embargo, considerando la descripción completa, no es descabellado suponer que esto puede haber tenido la intención de ayudar al decodificador a leer la entrada en unidades de 32 bits ( "cuantos" ). Eso no tiene ningún beneficio hoy en día, sin embargo, en 1993, el código C inseguro probablemente se habría aprovechado de esta propiedad.