Estoy usando mbed TLS para el acuerdo de la clave ECDH con Curve25519. Las claves privadas y públicas se almacenan y transmiten como cadenas hexadecimales, como se genera fácilmente con mbed TLS. Esas cuerdas son big-endian. Esto funcionó bastante bien hasta ahora.
Ahora alguien intentó crear pares de claves utilizando OpenSSL
openssl genpkey -algorithm X25519 -out priv.pem
openssl pkey -in priv.pem -pubout -out pub.pem
y extrajo las claves directamente desde allí a las cadenas Hex. Tan solo copiando los bytes de clave usando un visor ASN.1. Teníamos la impresión de que esto debería funcionar sin problemas, ya que I2OSP define big-endian para la codificación de claves.
Obviamente, no funcionó, pero necesitamos revertir el orden de bytes en la cadena para poder analizar un par de claves válido.
Tengo la tendencia a creer que OpenSSL hace esto correctamente, pero comencé a profundizar en los RFC para encontrar pruebas y algunas aclaraciones, por qué esto debería ser diferente para X25519 (y probablemente X448) a la clave para RSA o la otra EC curvas (secp ...)
cómo se deja una clave privada para el documento que describe el algoritmo en sí
pero también se refiere a paquetes de claves asimétricas que nuevamente se refieren al documento que define el algoritmo. Mientras que RFC5915 para ECPrivateKey define un orden de bytes big-endian (I2OSP), RFC7748 y RFC8031 solo mencionan el orden de bytes little-endian para el formato de las claves. - draft-ietf-curdle-pkix-10
Ahora, esto me confirma de alguna manera, que OpenSSL tiene razón, pero aún me falta la razón por la que uno no solo debe usar el orden de la red como lo hace cualquier otro algoritmo, sino el opuesto directo.
¿Alguna idea y más información sobre eso?