Nathaniel Borenstein y el Base64 que nunca prometió confidencialidad

Resumen

• En MIME, Base64 es una transformación reversible para transportar el cuerpo de una entidad; no cifra, autentica ni autoriza el contenido.
• Un registro verificable debe conservar la entrada codificada, el perfil y alcance aplicados, la política del decodificador, los bytes obtenidos y las comprobaciones de seguridad independientes.

Un analista pega en un buscador interno una cadena que parece opaca. La herramienta la decodifica y muestra una clave de acceso. El informe posterior afirma que la clave «estaba cifrada». Esa palabra desplaza la responsabilidad: sugiere que existió una barrera criptográfica cuando solo había una forma menos legible de escribir los mismos datos.

La historia de MIME ayuda a precisar el error. El perfil de Nathaniel Borenstein en el IETF enumera quince RFC, entre ellas las RFC 2045, 2046 y 2049. Una reseña de Grinnell College de 2013 atribuye a su trabajo en Bellcore el desarrollo de MIME y recuerda el primer mensaje MIME de 1992, con una fotografía y un archivo de sonido. La meta era conseguir que sistemas de correo distintos transportaran material que el canal original no admitía bien, no esconderlo de lectores no autorizados.

La evidencia termina donde termina el campo

La RFC 2045 define Content-Transfer-Encoding mediante dos datos: la transformación aplicada al cuerpo y el dominio de la representación resultante. 7bit, 8bit y binary son transformaciones de identidad. Quoted-printable y Base64 convierten datos para que puedan circular por transportes restringidos a material de 7 bits.

Para una secuencia válida, el algoritmo declarado produce una única secuencia de octetos o señala una entrada ilegal. Esa precisión importa. Permite recuperar lo que se codificó. Pero la misma norma admite representaciones codificadas distintas que son equivalentes y advierte que el valor no identifica el tipo de medio, salvo por lo que dice del algoritmo o de las exigencias del transporte.

Por tanto, decode=ok acredita un acto técnico delimitado. No acredita autoría, consentimiento, secreto, integridad ni ausencia de riesgo. El salto entre esas frases no es una mejora semántica; es la fabricación de una prueba que el campo nunca emitió.

Un adjunto contiene varios objetos de prueba

El cliente de correo presenta «un archivo», mientras MIME organiza entidades anidadas. Una codificación declarada en el encabezado del mensaje se aplica a su cuerpo; declarada dentro de una entidad, se aplica solo a ese cuerpo. Los tipos compuestos multipart y message tienen reglas adicionales. El ámbito exacto debe acompañar al resultado.

En una investigación pueden existir al menos tres huellas: la del mensaje bruto, la del segmento codificado y la de los octetos decodificados. Una pasarela puede cambiar plegados o saltos de línea y mantener el mismo resultado. Dos mensajes con remitentes y recorridos diferentes también pueden entregar bytes idénticos. Deducir origen común de un hash común borra contexto; deducir contenido diferente de dos cadenas diferentes confunde envoltura con carga.

El tratamiento del tipo de medio es otra decisión. La RFC 2046 recomienda para application/octet-stream deshacer la codificación y ofrecer guardar los datos o entregarlos a un proceso elegido explícitamente. Decodificar no ordena ejecutar. Ni el nombre del archivo ni Content-Type reemplazan la inspección y la política de manejo seguro.

Hace falta nombrar el perfil Base64

La RFC 4648 documenta diferencias que una etiqueta genérica suele ocultar: saltos de línea, relleno, caracteres ajenos al alfabeto y elección de alfabeto. MIME permite ignorar ciertos caracteres; otra especificación puede exigir rechazo. Base64url cambia caracteres y no es sinónimo de Base64 ordinario.

También existe una cuestión canónica. Si los bits no significativos del relleno no son cero, varias cadenas pueden decodificar a los mismos bytes. Los caracteres ignorados pueden servir como canal encubierto, eludir comparaciones o activar errores. Un sistema que solo guarda el hash final no podrá demostrar qué toleró. Uno que solo guarda la cadena no podrá saber que otra forma representaba el mismo contenido.

El perfil no es una nota de implementación. Define qué entrada se acepta y qué significado tiene una comparación. Debe figurar junto a la versión de la biblioteca y sus opciones estrictas.

La opacidad visual no crea secreto

La RFC 4648 dice expresamente que la codificación puede ocultar visualmente información reconocible, pero no ofrece confidencialidad computacional ni añade entropía al texto en claro. No hay clave que limite la inversión. Compartir la cadena equivale a compartir una representación recuperable.

Tampoco hay autenticidad o integridad implícitas. Un atacante puede modificar los bytes y volver a codificarlos. Un hash solo confirma igualdad con una referencia; no identifica al autor de la referencia. Una firma o un MAC aportan otra clase de evidencia ligada a una clave y a reglas de validación. El cifrado autenticado puede proteger una carga, pero su existencia debe registrarse, no adivinarse por la forma Base64 del resultado.

La conclusión correcta no es «Base64 es malo». Base64 resuelve bien su problema. La conclusión es que una capa honesta no hereda poderes de la capa siguiente. El error aparece cuando una interfaz llama encrypted, verified o safe a todo lo que el decodificador aceptó.

Un recibo que permita volver a decidir

El primer campo del recibo es la huella de la entrada codificada y sus límites MIME. El segundo nombra el perfil. El tercero registra biblioteca y política: espacios, caracteres extraños, alfabeto y relleno. El cuarto indica aceptación o rechazo y la huella de los octetos resultantes. El quinto anota la interpretación de tipo y la acción segura. El sexto conserva por separado firma, autenticación del transporte, cifrado y autorización.

Si no se verificó una firma, esa casilla queda vacía. Si TLS protegió solo un tramo, se consigna ese tramo. Si el tipo es desconocido, no se completa desde la extensión. Esta disciplina mantiene visibles tanto el límite de la máquina como la responsabilidad de quien decide confiar.

Borenstein ayudó a construir un formato que prosperó porque cada capa decía con precisión lo que hacía. Operar Base64 con la misma modestia produce mejores registros: bytes recuperados, sí; secreto o confianza, solo cuando existe otra prueba.