Sto utilizzando TLS mbed per l'accordo con la chiave ECDH utilizzando Curve25519. Le chiavi private e pubbliche vengono archiviate e trasmesse come stringhe esadecimali facilmente generate con TLS mbed. Quelle stringhe sono big-endian. Questo ha funzionato abbastanza bene finora.
Ora qualcuno ha cercato di creare coppie di chiavi usando OpenSSL
openssl genpkey -algorithm X25519 -out priv.pem
openssl pkey -in priv.pem -pubout -out pub.pem
e ha estratto le chiavi direttamente da lì alle stringhe esadecimali. Quindi copia i byte chiave usando un visualizzatore ASN.1. Abbiamo avuto l'impressione che questo dovrebbe funzionare in modo impeccabile, poiché I2OSP definisce big-endian per la codifica della chiave.
Ovviamente, non ha funzionato, ma dobbiamo invertire l'ordine dei byte nella stringa per poter analizzare una coppia di chiavi valida.
Sono incline a credere che OpenSSL lo faccia correttamente, ma ho iniziato a scavare nelle RFC per trovare prove e alcuni chiarimenti, perché questo dovrebbe essere diverso per X25519 (e probabilmente X448) per la chiave per RSA o l'altra CE curve (secp ...)
how a private key is encoded is left for the document describing the algorithm itself
ma fa anche riferimento a pacchetti chiave asimmetrici che si riferiscono nuovamente al documento che definisce l'algoritmo. Mentre RFC5915 per ECPrivateKey definisce un ordine di byte big-endian (I2OSP), RFC7748 e RFC8031 menzionano entrambi solo l'ordine di byte little-endian per la formattazione delle chiavi. - draft-ietf-curdle-pkix-10
Ora, questo in qualche modo conferma che OpenSSL ha ragione, ma mi manca ancora il motivo per cui non si dovrebbe usare l'ordine di rete come fatto da ogni altro algoritmo, ma il contrario.
Qualche idea e ulteriori informazioni su questo?