Skip to content

X25519 PKCS#8/RFC 8410 keys are imported and exported in reversed byte order #11673

Description

@MarkAtwood

wolfSSL reads and writes the X25519 key values in PKCS#8 and SubjectPublicKeyInfo DER in big-endian order. RFC 8410 carries the RFC 7748 octets, which are little-endian. wc_Curve25519KeyDecode and wc_Curve25519PrivateKeyDecode import with EC25519_BIG_ENDIAN, and wc_Curve25519PrivateKeyToDer/KeyToDer write the same reversed order. So an X25519 key from OpenSSL or any other RFC 8410 implementation loads as a different key, and wolfSSL's keys don't work elsewhere.

Repro: RFC 7748 section 6.1 Alice private key 77076d0a...2c2a as RFC 8410 DER. OpenSSL derives public key 8520f009...4e6a (the RFC value). wolfSSL wc_Curve25519KeyDecode + wc_curve25519_export_public gives 01801c91...428f, which is what you get by reversing the bytes in and out.

wolfSSL round-trips its own keys, so its tests don't catch this. The SE050 port (se050_port.c) already decodes DER public keys little-endian, so it disagrees with asn.c. A fix changes the stored format in both directions, including certs/statickeys/x25519*, so it needs a migration decision. Found while working on #10019 and #11671.

No activity

Activity on this issue will appear here.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions