PP pki type

Todo protocolo que firma algo tiene que nombrar el algoritmo, y nombrarlo en un campo que controla el remitente es la manera en que empiezan los ataques de degradación. BIP70 ofrecía tres valores, y uno de ellos se consideraba débil desde años antes de que se redactara la especificación. Los navegadores terminaron de expulsar los certificados SHA-1 en enero de 2017, y el protocolo de pago nunca publicó una actualización.

Cómo funciona

Estado: histórico. PP pki type era el campo 2 de PaymentRequest, con la cadena de caracteres "none" como valor predeterminado, y está ausente de Bitcoin Core desde la versión 0.20.0, del 3 de junio de 2020.

Se definieron tres valores y nunca se registró un cuarto, aunque la especificación dejaba espacio para uno.

"none" significaba una solicitud sin firmar. El campo de certificados quedaba vacío, el campo de firma quedaba vacío, y una billetera podía mostrar el monto y el destino, pero ninguna identidad en absoluto. La mayoría de las solicitudes que circulaban eran exactamente eso.

"x509+sha256" significaba que el comerciante serializaba el mensaje completo con el campo de firma en blanco, calculaba con SHA-256 el hash del resultado y firmaba ese hash con la clave privada correspondiente al primer certificado de la cadena de certificados adjunta.

"x509+sha1" significaba el mismo procedimiento, con SHA-1 en lugar de SHA-256.

Ofrecer la opción débil es lo interesante. Un verificador que respeta cualquier algoritmo que indique el remitente solo es tan fuerte como el peor algoritmo que todavía acepta, y por eso los diseños posteriores establecen el conjunto aceptable del lado del verificador en lugar de leerlo del mensaje. SHA-1 era un mal candidato incluso en 2013. En 2005 se publicó un ataque de colisión más rápido que la fuerza bruta, y el NIST prohibió el uso de SHA-1 para generar nuevas firmas digitales después de 2013. Las autoridades de certificación dejaron de emitir certificados SHA-1 a finales de 2015, Chrome 56 dejó de confiar en ellos en enero de 2017, y un mes después llegó una colisión pública completa.

Dónde aparece

El propio Bitcoin ofrece el contraejemplo de un algoritmo de firma que nombra el remitente, y vale la pena tenerlo presente.

Una transacción de bitcoin nunca negocia su algoritmo de firma con quien la valida. La salida que se gasta zanja la cuestión: una salida anterior a Taproot se verifica con ECDSA sobre secp256k1, y una salida que paga a una clave Taproot se verifica con Schnorr según BIP340, una regla que se activó en el bloque 709.632 en noviembre de 2021. Quien gasta no puede proponer algo más barato de romper, porque la elección quedó determinada cuando se recibieron las monedas.

Esa diferencia explica por qué una capa basada en certificados encajaba tan mal sobre bitcoin. Las reglas de consenso se aplican igual a todos y solo cambian mediante una actualización coordinada, mientras que un campo que nombra un algoritmo es una negociación, y las negociaciones se degradan.

Si usted está eligiendo dónde comprar en lugar de escribir software, la versión útil es limitada pero real. Una plataforma que mantiene viva una opción criptográfica obsoleta "por compatibilidad" le está diciendo cómo pondera la comodidad frente a la seguridad, y ese criterio también se aplica a las partes del sistema que usted no puede inspeccionar.

PP pki type frente a firma SSL

PP pki type nombraba un esquema; la firma SSL era el resultado de ejecutarlo. Tratar ambos como una sola cosa vuelve confusa la antigua documentación de BIP70, porque una solicitud podía nombrar un tipo y no llevar ninguna firma, que es precisamente lo que significaba "none". El TLS moderno conserva el mismo emparejamiento, con un identificador de algoritmo registrado junto a los bytes de la firma, pero un cliente ya no acepta todos los identificadores que alguna vez fueron válidos.